Enhanced signaling of extension dependent random access sample point samples in media files

Abstract

A mechanism for processing media data is disclosed. In one aspect, a method includes determining that a track identifier (ID) identifying a reference track of the media data is included in a track reference type box (TrackReference Type Box) of a reference type equal to an associated external stream track ('ae'). The method further includes performing a transition between the media data and the media data file based on the track identifier.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 410,827, filed on September 28, 2022, which is incorporated herein by reference. Technical Field

[0003] The present disclosure relates to the generation, storage and use of digital audio-visual media information in file format. Background Art

[0004] Digital video occupies the largest share of bandwidth used on the Internet and other digital communications networks. As the number of networked user devices capable of receiving and displaying video increases, the bandwidth requirements used by digital video are likely to continue to grow. Summary of the invention

[0005] A first aspect relates to a method for processing media data, comprising: determining that a track identifier (ID) identifying a reference track of the media data is included in a track reference type box (TrackReferenceTypeBox) having a reference type (reference_type) equal to an associated external stream track ('aest'); and performing conversion between the media data and a media data file based on the track identifier.

[0006] Optionally, in any of the preceding aspects, another implementation of this aspect provides that: the track ID is the first entry in the TrackReferenceTypeBox with the reference_type equal to 'aest'.

[0007] Optionally, in any of the aforementioned aspects, another implementation of this aspect provides that: when there is the TrackReferenceTypeBox with the reference_type equal to 'aest', the TrackReferenceTypeBox only includes the track identifier and does not include any track group identifier.

[0008] Optionally, in any of the preceding aspects, another implementation of this aspect provides that: when there is the TrackReferenceTypeBox with the reference_type equal to 'aest', the TrackReferenceTypeBox includes the track identifier in the first entry and includes the group track identifier in subsequent entries, if any.

[0009] Optionally, in any of the preceding aspects, another implementation of this aspect provides that: the first entry in the TrackReferenceTypeBox with the reference_type equal to 'aest' must be the track identifier.

[0010] Optionally, in any of the preceding aspects, another embodiment of this aspect provides that: the media data file specifies whether a most recent preceding stream access point (SAP) sample of type 1, 2 or 3 is required for random access from an extended dependent random access point (EDRAP) sample.

[0011] Optionally, in any of the aforementioned aspects, another embodiment of this aspect provides that: an EDRAP sample is a sample for which all subsequent samples can be correctly decoded in both decoding order and output order, provided that a required previous SAP or EDRAP sample is available for decoding the sample and subsequent samples, and wherein the required previous SAP or EDRAP sample includes one or more of a sample set, the sample set starting from the closestSapSample of type 1, 2 or 3 in decoding order, and including all EDRAP samples between the closestSapSample and the sample in decoding order.

[0012] Optionally, in any of the aforementioned aspects, another embodiment of this aspect provides that: an EDRAP sample is a sample for which all subsequent samples can be correctly decoded in both decoding order and output order, provided that a required previous SAP or EDRAP sample can be used to decode the sample and subsequent samples, wherein the required previous SAP or EDRAP sample includes zero or more of a sample set, the sample set starting from the closestSapSample of type 1, 2 or 3 in decoding order, and including all EDRAP samples between the closestSapSample and the sample in decoding order.

[0013] Optionally, in any of the aforementioned aspects, another implementation of this aspect provides that: when a media track has a reference_type of 'aest', for each EDRAP sample sampleA in the media track, there must be one and only one sample sampleB in the referenced track that has the same decoding time as sampleA, and wherein sampleB must include all media data of the most recent SAP sample of type 1, 2 or 3 that precedes sampleA in the decoding order, as well as all media data of the previous SAP or EDRAP sample required by sampleA.

[0014] Optionally, in any of the aforementioned aspects, another implementation of this aspect provides that: for any EDRAP sample sampleA mapped to the EDRAP sample group, the sample sequence (sampleSeq) is a sequence of samples, wherein the sequence of samples includes the SAP or EDRAP sample identified by ref_sap_or_edrap_idx_delta[i], where i ranges from 0 to num_ref_sap_or_edrap_samples_minus1 in decoding order, including the endpoints, sampleA, and all samples in the track that follow sampleA in both decoding order and output order.

[0015] Optionally, in any of the foregoing aspects, another embodiment of the aspect provides that: for each sample sampleB in sampleSeq, all data required to process sampleB must be accessible in the referenced sample entry, in sampleB, or in any sample that precedes sampleB in decoding order and exists in sampleSeq.

[0016] Optionally, in any of the foregoing aspects, another implementation of this aspect provides that VisualEdrapEntry() is defined as follows:

[0017]

[0018] Optionally, in any of the aforementioned aspects, another embodiment of this aspect provides that: num_ref_sap_or_edrap_samples_minus1 plus 1 indicates the number of samples in the required previous SAP or EDRAP sample, which is earlier than the EDRAP sample in the decoding order and needs to be referenced when decoding starts from the EDRAP sample to be able to correctly decode the EDRAP sample and all samples after the EDRAP sample in the decoding order and output order.

[0019] Optionally, in any of the aforementioned aspects, another embodiment of the aspect provides that: ref_sap_or_edrap_idx_delta[i] indicates the i-th required previous SAP or EDRAP sample of the current EDRAP sample, wherein the SAP or EDRAP sample list associated with the SAP sample of type 1, 2 or 3 includes the SAP sample and all EDRAP samples after the SAP sample and before the next SAP sample, wherein the SAP_or_EDRAP sample index is an index to the SAP or EDRAP sample list, wherein ref_sap_or_edrap_idx_delta[i] indicates the i-th required previous SAP or EDRAP sample of the current EDRAP sample, wherein the SAP or EDRAP sample list associated with the SAP sample of type 1, 2 or 3 includes the SAP sample and all EDRAP samples after the SAP sample and before the next SAP sample, wherein the SAP_or_EDRAP sample index is an index to the SAP or EDRAP sample list, wherein The value of _edrap_idx_delta[i] is equal to the difference between the SAP_or_EDRAP sample index of the current EDRAP sample and the SAP_or_EDRAP sample index of the i-th required previous SAP or EDRAP sample, wherein a value of 1 indicates that the i-th required SAP or EDRAP sample is the last SAP or EDRAP sample before the EDRAP sample in decoding order, and wherein a value of 2 indicates that the i-th required SAP or EDRAP sample is the second to last EDRAP sample before the EDRAP sample in decoding order.

[0020] Optionally, in any of the aforementioned aspects, another implementation of this aspect provides that: the conversion includes encoding the media data into a bit stream.

[0021] Optionally, in any of the preceding aspects, another implementation of this aspect provides that: the conversion includes decoding the media data from a bitstream.

[0022] A second aspect relates to an apparatus for processing media data, comprising: a processor; and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform any one of the disclosed methods.

[0023] A third aspect relates to a non-transitory computer-readable medium, which includes a computer program product for use by a video codec device, the computer program product including computer executable instructions stored on the non-transitory computer-readable medium, so that when executed by a processor, the video codec device performs any one of the disclosed methods.

[0024] A fourth aspect relates to a non-transitory computer-readable recording medium storing a bit stream of a video generated by a method performed by a video processing device, wherein the method includes any one of the disclosed methods.

[0025] A fifth aspect relates to a method for storing a bitstream of a video, which comprises any one of the disclosed methods.

[0026] A sixth aspect relates to a method, device or system described in the present disclosure.

[0027] For clarity, any of the foregoing embodiments may be combined with one or more of the other foregoing embodiments to create new embodiments within the scope of the present disclosure.

[0028] These and other features will become more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] For a more complete understanding of the present disclosure, reference is now made to the following brief description taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals refer to like parts.

[0030] Figure 1 A diagram illustrating an example mechanism for random access when decoding a bitstream using an intra random access point (IRAP) picture.

[0031] Figure 2 A diagram illustrating an example mechanism for random access when decoding a bitstream using a picture dependent random access point (DRAP) picture.

[0032] Figure 3 A diagram illustrating an example mechanism for random access when decoding a bitstream using an Extended Dependent Random Access Point (EDRAP) picture.

[0033] Figure 4 is a diagram of an example mechanism for signaling an external bit stream to support EDRAP-based random access.

[0034] Figure 5 An example of random access based on EDRAP is shown.

[0035] Figure 6 is a block diagram illustrating an example video processing system.

[0036] Figure 7 is a block diagram of an example video processing device.

[0037] Figure 8 is a flow chart of an example method of video processing.

[0038] Fig. 9 is a block diagram illustrating an example video encoding and decoding system.

[0039] Fig.10 is a block diagram illustrating an example encoder.

[0040] Fig.11 is a block diagram illustrating an example decoder.

[0041] Fig.12 is a schematic diagram of an example encoder. DETAILED DESCRIPTION

[0042] First, it should be understood that although exemplary implementations of one or more embodiments are provided below, the disclosed systems and / or methods may be implemented using any number of techniques, whether currently known or yet to be developed. The present disclosure should not be limited in any way to the exemplary implementations, drawings, and techniques shown below, including the exemplary designs and implementations shown and described herein, but may be modified within the full scope of the appended claims and their equivalents.

[0043] The section titles used in this disclosure are for ease of understanding and do not limit the techniques and embodiments disclosed in each section to only that section. In addition, the use of H.266 terminology in some descriptions is for ease of understanding only and is not intended to limit the scope of the disclosed technology. Therefore, the techniques described in this disclosure are also applicable to other video codec protocols and designs. In this disclosure, with respect to drafts of the Common Video Codec (VVC) specification or the International Organization for Standardization (ISO) media file format format (ISOBMFF) file format specification, editorial changes to the text are shown in bold italics to indicate canceled text and in bold to indicate added text.

[0044] 1. Preliminary Discussion

[0045] The present disclosure relates to media file formats. In particular, it relates to signaling of Extended Dependent Random Access Point (EDRAP) samples in media files. These ideas can be applied alone or in various combinations to media files according to any media file format, such as ISOBMFF and file formats derived from ISOBMFF.

[0046] 2. Video Codec Introduction

[0047] 2.1 Video Codec Standards

[0048] Video codec standards have evolved primarily through the development of standards by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T) and ISO / International Electrotechnical Commission (IEC). ITU-T produced H.261 and H.263, ISO / IEC produced the Moving Picture Experts Group (MPEG-1) and MPEG-4 Vision, and the two organizations jointly produced the H.262 / MPEG-2 Video and H.264 / MPEG-4 Advanced Video Codec (AVC) and H.265 / High Efficiency Video Codec (HEVC) [1] standards. Since H.262, video codec standards are based on a hybrid video codec structure that utilizes temporal prediction plus transform coding.

[0049] Recently, the Versatile Video Codec (VVC) standard (ITU-TH.266 | ISO / IEC 23090-3) [2] and the associated Versatile Supplementary Enhancement Information (VSEI) standard (ITU-TH.274 | ISO / IEC 23002-7) [3] have been designed for the widest range of applications, including traditional uses (such as television broadcasting, video conferencing or playback from storage media), and also including newer and more advanced use cases such as adaptive bitrate streaming, video region extraction, content synthesis and merging of video bitstreams from multiple codecs, multi-view video, scalable layered codecs, and viewport-adaptive 360° immersive media. The Essential Video Codec (EVC) standard (ISO / IEC 23094-1) is another video codec standard recently developed by MPEG.

[0050] 2.2 File Format Standards

[0051] Media streaming applications are based on Internet Protocol (IP), Transmission Control Protocol (TCP) and Hypertext Transfer Protocol (HTTP) transport methods and rely on file formats such as ISO Base Media File Format (ISOBMFF) [4]. One such streaming system is Dynamic Adaptive Streaming over HTTP (DASH) [5]. For video formats using ISOBMFF and DASH, the file format specification specific to the video format is also called Network Abstraction Layer File Format (NALFF) [6], which includes the file format specifications of all Network Abstraction Layer (NAL) unit-based video codecs, such as AVC, HEVC, VVC and their extensions, to encapsulate video content in ISOBMFF tracks and DASH representations and segments. Important information about the video bitstream, such as profiles, tiers and levels, etc., needs to be exposed as file format-level metadata and / or DASH Media Presentation Description (MPD) to facilitate content selection, such as selecting appropriate media segments for initialization at the start of a streaming session and for stream adaptation during a streaming session. Similarly, for image formats using ISOBMFF, there are file format specifications specific to the image format (e.g., the AVC image file format and the HEVC image file format in [7]).

[0052] 2.3 Random Access and Support in HEVC and VVC

[0053] Random access means accessing a bitstream starting from a picture that is not the first picture of the bitstream in decoding order and decoding the bitstream. In order to support tuning and channel switching in broadcast, multicast and multi-party video conferencing, local playback and seeking in a stream, and stream adaptation in a stream, the bitstream should include frequent random access points. These random access points can be intra-coded pictures, but can also be inter-coded pictures, for example in the case of gradual decoding refresh.

[0054] HEVC includes the signaling of intra random access point (IRAP) pictures in the NAL unit header via the NAL unit type. HEVC supports three types of IRAP pictures. These are Instantaneous Decoder Refresh (IDR), Pure Random Access (CRA), and Broken Link (BLA) pictures. IDR pictures restrict the inter-picture prediction structure so that it does not reference any pictures before the current group of pictures (GOP). The reference pictures in the current GOP can be called closed GOP random access points. CRA pictures are less restricted and allow some pictures to reference pictures before the current GOP, all of which will be discarded in the case of random access. CRA pictures can be called open GOP random access points. BLA pictures are usually derived from the concatenation of two bitstreams or parts of them at the CRA picture, for example during stream switching. In order to enable the system to better use IRAP pictures, six different NAL units are defined to signal the properties of IRAP pictures. These properties can be used to better match the stream access point types defined in ISOBMFF [4], which are used for random access support in dynamic adaptive streaming based on the Hypertext Transfer Protocol (DASH) [5].

[0055] VVC supports three types of IRAP pictures, two types of IDR pictures (one type with an associated random access decodable preamble (RADL) picture and the other type without an associated random access decodable preamble (RADL) picture), and one type of CRA picture. These pictures are used in a similar way to HEVC. The BLA picture type in HEVC is not included in VVC for two reasons. First, the basic functionality of the BLA picture can be implemented by a CRA picture plus a sequence end NAL unit, the presence of which indicates that the subsequent picture starts a new coded video sequence (CVS) in a single-layer bitstream. Secondly, in the process of developing VVC, it is hoped to specify fewer NAL unit types than HEVC, which is indicated by using five bits instead of six bits for the NAL unit type field in the NAL unit header.

[0056] Another difference between VVC and HEVC in terms of random access support is that gradual decoding refresh (GDR) is supported in a more standardized way in VVC. In GDR, decoding of the bitstream can start from an inter-frame coded picture. At the beginning of access, the entire picture area cannot be correctly decoded. However, after multiple pictures, the entire picture area is correctly decoded. AVC and HEVC also support GDR by using recovery point supplementary enhancement information (SEI) messages to signal GDR random access points and recovery points. In VVC, NAL unit types are specified to indicate GDR pictures, and recovery points are signaled in the picture header syntax structure. Codec video sequences (CVSs) and bitstreams are allowed to start with GDR pictures. This means that the entire bitstream is allowed to include only inter-frame coded pictures, without including a single intra-frame coded picture. The main benefit of specifying GDR support in this way is to provide standard-compliant behavior for GDR. GDR enables the encoder to smooth the bit rate of the bitstream by distributing intra-frame coded strips or blocks across multiple pictures, as opposed to intra-coding the entire picture. This can significantly reduce end-to-end latency, which is considered more important in many cases as ultra-low latency applications such as wireless displays, online gaming and drone-based applications become more popular.

[0057] Another GDR-related feature in VVC is virtual boundary signaling. In the picture between the GDR picture and the corresponding recovery point, the boundary between the refresh area (i.e., the correctly decoded area) and the unrefreshed area can be transmitted as a virtual boundary through a signal. When transmitted by a signal, loop filtering across the boundary is not applied. Therefore, some samples at or near the boundary will not be decoded mismatched. This may be useful when the application determines that the correctly decoded area is displayed during the GDR process. IRAP pictures and GDR pictures may be collectively referred to as random access point (RAP) pictures.

[0058] 2.4 Video Coding, Decoding, Storage and Streaming Based on Extended Dependent Random Access Points (EDRAP)

[0059] 2.4.1 Concept and Standard Support

[0060] This paper describes the concepts of video encoding, decoding, storage and streaming based on EDRAP.

[0061] like Figure 1 As shown, the application (e.g., adaptive streaming) determines the frequency of random access points (RAPs), for example, the RAP period is 1s or 2s. In one example, the RAP is provided by the codec of the IRAP picture. Note that the inter-frame prediction references of non-critical pictures between RAP pictures are not shown, and are output in order from left to right. When randomly accessing from CRA4, the decoder receives and correctly decodes CRA4, CRA5, etc. and related inter-frame prediction pictures.

[0062] Figure 2 The DRAP method is shown, which improves codec efficiency by allowing DRAP pictures (and subsequent pictures) to refer to the previous IRAP picture for inter-frame prediction. Note that inter-frame prediction of non-critical pictures between RAP pictures is not shown, and the output order is from left to right. When randomly accessed from DRAP4, the decoder receives and correctly decodes IDR0, DRAP4, DRAP5, etc. and related inter-frame prediction pictures.

[0063] Figure 3 The EDRAP method is shown, which provides more flexibility by allowing EDRAP pictures (and subsequent pictures) to reference some earlier RAP pictures (IRAP or EDRAP). Note that inter-frame prediction of non-critical pictures between RAP pictures is not shown and is in output order from left to right. When randomly accessing from EDRAP4, the decoder receives IDR0, EDRAP2, EDRAP4, EDRAP5, etc. and the related inter-frame predicted pictures and decodes them correctly.

[0064] Figure 4 An example of an EDRAP method using main stream representation (MSR) segments and external stream representation (ESR) segments is shown. Figure 5 An example of random access from EDRAP4 is shown. When randomly accessing or switching to a segment starting from EDRAP4, the decoder receives and correctly decodes segments including IDR0, EDRAP2, EDRAP4, EDRAP5, etc. and related inter-frame prediction pictures.

[0065] EDRAP-based video codecs are supported by the EDRAP indication supplemental enhancement information (SEI) message included in the second version of the VSEI standard [3]; the storage part is supported by the EDRAP sample group and associated external stream track reference included in the version of the ISOBMFF standard [8]; and the streaming part is supported by the main stream representation (MSR) and external stream representation (ESR) descriptors included in the DASH standard amendment [9]. These standard supports are described below.

[0066] 2.4.2 EDRAP indication SEI message

[0067] The syntax and semantics of the EDRAP indication SEI message are as follows.

[0068]

[0069] A picture associated with the Extended DRAP (EDRAP) indication SEI message is called an EDRAP picture.

[0070] The presence of the EDRAP indication SEI message indicates that the constraints on picture order and picture references specified in this clause apply. These constraints may enable a decoder to correctly decode an EDRAP picture and pictures that follow it in both decoding order and output order at the same layer without decoding any other pictures in the same layer, except for the picture list referenceablePictures that includes an IRAP or EDRAP picture list in decoding order that is within the same CLVS and identified by the edrap_ref_rap_id[i] syntax element.

[0071] The constraints indicated by the presence of the EDRAP indication SEI message must all apply, as follows: The EDRAP picture is a trailing picture. The EDRAP picture has a temporal sub-layer identifier equal to 0. The EDRAP picture does not include any pictures in the same layer, except referenceablePictures, in its active entry in the reference picture list. Any picture that is in the same layer as the EDRAP picture and follows the EDRAP picture in both decoding order and output order does not include any pictures in the same layer and precedes the EDRAP picture in decoding order or output order, except referenceablePictures, in its active entry in the reference picture list. Any picture in the list referenceablePictures does not include any pictures in the same layer in its active entry in the reference picture list that are not earlier pictures in the list referenceablePictures. NOTE - Therefore, even if the first picture in referenceablePictures is an EDRAP picture rather than an IRAP picture, it will not include any pictures from the same layer in its active entry in the reference picture list.

[0072] edrap_rap_id_minus1 plus 1 specifies the RAP picture identifier of the EDRAP picture, which is denoted as RapPicId.

[0073] Each IRAP or EDRAP picture is associated with a RapPicId value. The RapPicId value of an IRAP picture is inferred to be equal to 0. The RapPicId values ​​of any two EDRAP pictures associated with the same IRAP picture must be different.

[0074] edrap_leading_pictures_decodable_flag equal to 1 specifies that both of the following constraints apply: Any picture at the same layer as an EDRAP picture and after the EDRAP picture in decoding order must follow any picture at the same layer and before the EDRAP picture in decoding order in output order. Any picture at the same layer as an EDRAP picture, after the EDRAP picture in decoding order and before the EDRAP picture in output order must not include any picture at the same layer and before the EDRAP picture in its active entry in the reference picture list, except for referenceablePictures.

[0075] When edrap_leading_pictures_decodable_flag is equal to 0, these constraints are not imposed.

[0076] In bitstreams conforming to this version of the specification, edrap_reserved_zero_12bits shall be equal to 0. Other values ​​of edrap_reserved_zero_12bits are reserved for use by ITU-T | ISO / IEC. A decoder shall ignore the value of edrap_reserved_zero_12bits.

[0077] edrap_num_ref_rap_pics_minus1 plus 1 indicates the number of IRAP or EDRAP pictures that are within the same CLVS as the EDRAP picture and that can be included in the active entry of the reference picture list of the EDRAP picture.

[0078] edrap_ref_rap_id[i] indicates the RapPicId of the ith RAP picture that may be included in the active entry of the reference picture list of the EDRAP picture. The ith RAP picture must be one of the following: an IRAP picture associated with the current EDRAP picture, or an EDRAP picture associated with the same IRAP picture as the current EDRAP picture.

[0079] 2.4.3 EDRAP sample groups and associated external flow track references

[0080] The specification of the EDRAP sample set and associated external stream track reference in [8] is as follows.

[0081] 3.1 Definition ...

[0083] EDRAP Example

[0084] A sample for which all subsequent samples, in both decoding order and output order, can be correctly decoded provided that, when decoding this sample and subsequent samples, the most recent previous SAP sample of type 1, 2, or 3 and zero or more previous EDRAP samples are available. Item Note 1. The most recent previous SAP sample of type 1, 2, or 3 and zero or more previous EDRAP samples as described above are referred to as the required previous SAP sample and EDRAP sample of the EDRAP sample. ...

[0086] 3.2 Abbreviations ...

[0088] EDRAP extension relies on random access points ...

[0090] 8.3.3.4.1 Associated external stream track reference

[0091] Media tracks may include track references of type 'aest' (standing for "associated external stream track").

[0092] When a media track has a track reference of type 'aest', the following applies:

[0093] - A media track shall have at least one sample identified as an EDRAP sample by being associated with an EDRAP sample group.

[0094] -The reference track must obey the following constraints:

[0095] o Every sample in the referenced track must be identified as a sync sample.

[0096] ○ The referenced track must have header flags track_in_movie and track_in_preview both equal to 0.

[0097] ○ The referenced orbit must use the following constraints:

[0098] ■The scheme_type field in the SchemeTypeBox in the RestrictedSchemeInfoBox is equal to 'spkt', and the value of the mode field in the SamplePackingInformationBox is equal to 1.

[0099] ■Bit 0 of the flags field of SchemeTypeBox is equal to 0, making the value of (flags&0x000001) equal to 0.

[0100] - For each EDRAP sample sampleA in a media track, there must be one and only one sample sampleB in the referenced track that has the same decoding time as sampleA, and sampleB must include all media data of the required previous SAP and EDRAP samples of sampleA.

[0101] 8.15.6 Sample Grouping Track

[0102] 8.15.6.1 Introduction

[0103] When using a restricted scheme with SchemeType 'spkt' for a track, the sample associated with a sample entry may be a grouped sample, for example, the grouped sample may include more than one sample of the original track. Such a current track is called a sample grouped track.

[0104] 8.15.6.2 Sample Group Information Box

[0105] 8.15.6.2.1 Definition

[0106] Box type: 'spki'

[0107] Container: SchemeInformationBox

[0108] Mandatory: yes (when SchemeType is 'spkt')

[0109] Quantity: 1

[0110] 8.15.6.2.2 Syntax

[0111] aligned(8)class SamplePackingInformationBox extends FullBox('spki',version=0,flags=0)

[0112] {

[0113] unsigned int(8)mode;

[0114] }

[0115] 8.15.6.2.1 Semantics

[0116] Mode equal to 0 specifies that all samples of the original stream have been retained. A value of 1 specifies that only some samples have been retained. All other values ​​are reserved for future use.

[0117] 10.11 Extended DRAP (EDRAP) Sample Group

[0118] 10.11.1 Definitions

[0119] The EDRAP sample group records some or all EDRAP samples in a track. This sample group is similar to the DRAP sample group; however, this sample group can signal additional samples that can also be used for random access with more flexible dependencies.

[0120] Note 1: Similar to DRAP samples, EDRAP samples can only be used in conjunction with SAP samples of types 1, 2, and 3.

[0121] Note 2: A DRAP sample is always an EDRAP sample.

[0122] The following applies to any EDRAP sample sampleA that is mapped to the EDRAP sample group:

[0123] -Let sampleSeq be the sample sequence consisting of the following samples in the order of the following bullet points:

[0124] ○ the most recent previous SAP sample of type 1, 2, or 3,

[0125] o The EDRAP sample identified by ref_edrap_idx_delta[i], where i ranges from 0 to num_ref_edrap_sample–1, inclusive, in decoding order,

[0126] ○sampleA, and

[0127] ○ All samples after sampleA in the track, in both decoding and output order.

[0128] - For each sample sampleB in sampleSeq, all data needed to process sampleB must be accessible either in the referenced sample entry, in sampleB itself, or in any sample that precedes sampleB in decoding order and that is present in sampleSeq.

[0129] Note 3: For some video codecs, all the data needed to process sample sampleB includes the parameter set required to decode sampleB.

[0130] 10.11.2 Syntax

[0131] class VisualEdrapEntry()extends VisualSampleGroupEntry('edrp'){

[0132] unsigned int(3)edrap_type;

[0133] unsigned int(3)num_ref_edrap_samples;

[0134] unsigned int(2)reserved=0;

[0135] for(i=0;i <num_ref_edrap_samples;i++)

[0136] unsigned int(16)ref_edrap_idx_delta[i];

[0137] }

[0138] 10.11.3 Semantics

[0139] edrap_type is a non-negative integer. When edrap_type is in the range of 1 to 3, edrap_type indicates the SAP_type (as specified in Annex I) to which the EDRAP sample must correspond, provided that it does not depend on the nearest preceding SAP or other EDRAP samples. Other values ​​of edrap_type are reserved.

[0140] Note 1: An EDRAP sample and all subsequent samples in the same track may depend on the most recent previous SAP and / or some previous EDRAP samples, and not on any other sample before the EDRAP sample. Thus, if the encoder chooses to encode an EDRAP sample such that it does not depend on the most recent previous SAP or any previous EDRAP sample, then the EDRAP sample will become a SAP.

[0141] num_ref_edrap_sample indicates the number of other EDRAP samples that are earlier than the EDRAP sample in decoding order and that need to be referenced when decoding starts from the EDRAP sample in order to be able to correctly decode the EDRAP sample and all samples after the EDRAP sample in decoding order and output order.

[0142] Note 2: EDRAP samples are also DRAP samples, and their num_ref_edrap_sample is equal to 0.

[0143] reserved MUST be equal to 0. The semantics of this subclause applies only to sample group description entries with reserved equal to 0. When reserved is greater than 0, parsers SHOULD ignore sample group description entries.

[0144] ref_edrap_idx_delta[i] indicates the i-th required previous EDRAP sample for the current EDRAP sample. Let the EDRAP sample list associated with a SAP sample of type 1, 2, or 3 be all EDRAP samples after the SAP sample and before the next SAP sample, if any. The EDRAP sample index is defined as the index of this EDRAP sample list. The value of ref_edrap_idx_delta[i] is equal to the difference between the EDRAP sample index of the current EDRAP sample and the EDRAP sample index of the i-th required previous EDRAP sample. A value of 1 indicates that the i-th EDRAP sample is the last EDRAP sample before the EDRAP sample in decoding order, a value of 2 indicates that the i-th EDRAP sample is the second to last EDRAP sample before the EDRAP sample in decoding order, and so on.

[0145] 3. Technical problems solved by the disclosed technical solutions

[0146] An example design of the storage portion of EDRAP-based media encoding and decoding, storage, and streaming is associated with the following issues.

[0147] First, like any track reference, an 'aest' track reference may reference multiple tracks or groups of tracks, unless otherwise permitted. Therefore, the phrase "referenced track" is ambiguous.

[0148] Second, it is assumed that random access from an EDRAP sample always requires the most recent previous SAP sample of type 1, 2, or 3. However, this assumption is inconsistent with the EDRAP design in the VSEI specification, where random access from an EDRAP picture may or may not require the previous IRAP picture in decoding order.

[0149] 4. List of solutions and implementation examples

[0150] In order to solve the above problems, the methods summarized as follows are disclosed. These examples should be regarded as examples to explain the general concept and should not be interpreted narrowly. In addition, these examples can be applied individually or in combination in any way.

[0151] Example 1

[0152] To solve the first problem, in one example, one of the following aspects is specified, and the referenced track is a track whose track ID is the first entry in TrackReferenceTypeBox whose reference_type is equal to 'aest'.

[0153] When a TrackReferenceTypeBox with reference_type equal to 'aest' is present, the TrackReferenceTypeBox shall include only the track identifier, and shall not include any track group identifiers.

[0154] When there is a TrackReferenceTypeBox with reference_type equal to 'aest', the TrackReferenceTypeBox must include the track identifier in the first entry, and the other entries must include the track group identifier, if any.

[0155] When there is a TrackReferenceTypeBox with reference_type equal to 'aest', the first entry in the TrackReferenceTypeBox must be the track identifier.

[0156] Example 2

[0157] To address the second problem, in one example, it is specified that random access from an EDRAP sample may or may not require the most recent previous SAP sample of type 1, 2 or 3. One or more of the following aspects are specified.

[0158] In one example, the term EDRAP sample is defined as follows: an EDRAP sample is a sample for which all subsequent samples can be correctly decoded in both decoding order and output order, provided that a required previous SAP or EDRAP sample is available for decoding the sample and subsequent samples, wherein the required previous SAP or EDRAP sample consists of one or more samples in a sample set, the sample set starting from the closestSapSample of type 1, 2 or 3 in decoding order, and including all EDRAP samples between the closestSapSample and the sample in decoding order.

[0159] In one example, the term EDRAP sample is defined as follows: an EDRAP sample is a sample for which all subsequent samples can be correctly decoded in both decoding order and output order, provided that a required previous SAP or EDRAP sample is available for decoding the sample and subsequent samples, wherein the required previous SAP or EDRAP sample consists of zero or more samples in a sample set, the sample set starting with the closestSapSample of type 1, 2, or 3 in decoding order, and including all EDRAP samples between the closestSapSample and the sample in decoding order.

[0160] In one example, when a media track has a track reference of type 'aest', for each EDRAP sample sampleA in the media track, there must be one and only one sample sampleB in the referenced track with the same decoding time as sampleA, and sampleB must include all media data of the required previous SAP or EDRAP sample of sampleA.

[0161] In one example, for any EDRAP sample sampleA mapped to an EDRAP sample group, the following applies:

[0162] – Let sampleSeq be the sample sequence consisting of the following samples in the order of the following bullet points:

[0163] o the SAP or EDRAP sample identified by ref_sap_or_edrap_idx_delta[i], where i ranges from 0 to num_ref_sap_or_edrap_samples_minus1, inclusive, in decoding order,

[0164] ○sampleA, and

[0165] ○ All samples in the track that follow sampleA in decoding and output order.

[0166] – For each sample sampleB in sampleSeq, all data needed to process sampleB must be accessible in the referenced sample entry, in sampleB itself, or in any sample that precedes sampleB in decoding order and that is present in sampleSeq.

[0167] In one example, the syntax for VisualEdrapEntry() is as follows:

[0168]

[0169] In one example, the semantics of num_ref_sap_or_edrap_samples_minus1 is defined as follows.

[0170] num_ref_sap_or_edrap_samples_minus1 plus 1 indicates the number of samples in the required previous SAP or EDRAP sample that is earlier than the EDRAP sample in decoding order and that need to be referenced when decoding starts from the EDRAP sample to be able to correctly decode the EDRAP sample and all samples after the EDRAP sample in decoding order and output order.

[0171] In one example, the semantics of ref_sap_or_edrap_idx_delta[i] is defined as follows:

[0172] ref_sap_or_edrap_idx_delta[i] indicates the i-th required previous SAP or EDRAP sample for the current EDRAP sample. Let the EDRAP sample list associated with a SAP or EDRAP sample of type 1, 2, or 3 be the SAP sample and all EDRAP samples after the SAP sample and before the next SAP sample, if any. The SAP_or_EDRAP sample index is defined as the index into this SAP or EDRAP sample list. The value of ref_sap_or_edrap_idx_delta[i] is equal to the difference between the SAP_or_EDRAP sample index of the current EDRAP sample and the SAP_or_EDRAP sample index of the i-th required previous SAP or EDRAP sample. A value of 1 indicates that the i-th required SAP or EDRAP sample is the last SAP or EDRAP sample before the EDRAP sample in decoding order, a value of 2 indicates that the i-th required SAP or EDRAP sample is the second to last EDRAP sample before the EDRAP sample in decoding order, and so on.

[0173] 5. Examples

[0174] The following are some example embodiments of some of the disclosure items summarized in Section 4 above. Most of the relevant parts that have been added or modified are shown in bold font, and some deleted parts are shown in italic bold font. There may be some other changes that are editorial in nature and are therefore not highlighted.

[0175] 5.1 First Embodiment

[0176] This example is for items 1 and 2.

[0177] 3.1 Definition ...

[0179] EDRAP Example

[0180] For a sample, all subsequent samples of the sample can be correctly decoded in both decoding order and output order, provided that the nearest previous SAP sample of type 1, 2 or 3 and zero or more previous EDRAP samples are available when decoding the sample and subsequent samples, and the required previous SAP or EDRAP samples can be used to decode the sample and subsequent samples, where the required previous SAP or EDRAP samples consist of one or more samples in a group of samples starting from the nearest previous SAP sample (closestSapSample) of type 1, 2 or 3 in decoding order, and including all EDRAP samples between the closestSapSample and the sample in decoding order.

[0181] Item Note 1 The most recent previous SAP sample of type 1, 2, or 3 as described above and zero or more previous EDRAP samples are referred to as the previous SAP sample and EDRAP samples required by the EDRAP sample. ...

[0183] 8.3.3.4.1 Associated external stream track reference

[0184] Track references of type 'aest' (for "associated external stream track") may be included in media tracks. When a TrackReferenceTypeBox with reference_type equal to 'aest' is present, the TrackReferenceTypeBox MUST include only the track identifier and MUST NOT include any track group identifiers.

[0185] When a media track has a track reference of type 'aest', the following applies:

[0186] - A media track shall have at least one sample identified as an EDRAP sample by being associated with an EDRAP sample group.

[0187] -The reference track must obey the following constraints:

[0188] ○ Every sample in the referenced track should be identified as a synchronization sample.

[0189] ○ The referenced track must have header flags track_in_movie and track_in_preview both equal to 0.

[0190] ○ The referenced orbit should use the following constraint scheme:

[0191] ■The scheme_type field in the SchemeTypeBox in the RestrictedSchemeInfoBox is equal to 'spkt', and the value of the mode field in the SamplePackingInformationBox is equal to 1.

[0192] ■Bit 0 of the flags field of SchemeTypeBox is equal to 0, making the value of (flags&0x000001) equal to 0.

[0193] - For each EDRAP sample sampleA in a media track, there must be one and only one sample sampleB in the referenced track that has the same decoding time as sampleA, and sampleB must include all media data of the required previous SAP and or EDRAP samples of sampleA.

[0194] 10.11 EDRAP Sample Group

[0195] 10.11.1 Definitions

[0196] The EDRAP sample group records some or all EDRAP samples in a track. This sample group is similar to the DRAP sample group; however, this sample group can signal additional samples that can also be used for random access with more flexible dependencies.

[0197] Note 1: Similar to DRAP samples, EDRAP samples can only be used in conjunction with SAP samples of types 1, 2, and 3.

[0198] NOTE 1 A DRAP sample is always an EDRAP sample.

[0199] The following applies to any EDRAP sample sampleA that is mapped to an EDRAP sample group:

[0200] -Let sampleSeq be the sample sequence consisting of the following samples in the order of the following bullet points:

[0201] ○ the most recent previous SAP sample of type 1, 2, or 3,

[0202] ○ SAP or EDRAP samples identified by ref_sap_or_edrap_idx_delta[i], where i ranges from 0 to num_ref_edrap_samples–1num_ref_sap_or_edrap_samples_minus1, inclusive, in decoding order,

[0203] ○sampleA, and

[0204] ○ All samples in the track that follow sampleA in decoding and output order.

[0205] - For each sample sampleB in sampleSeq, all data needed to process sampleB must be accessible in the referenced sample entry, in sampleB itself, or in any sample that precedes sampleB in decoding order and that is present in sampleSeq.

[0206] NOTE 2 For some video codecs, all the data needed to process sample sampleB includes the parameter set required to decode sampleB.

[0207] 10.11.2 Syntax

[0208]

[0209] 10.11.3 Semantics

[0210] edrap_type is a non-negative integer. When edrap_type is in the range of 1 to 3, edrap_type indicates the SAP_type (as specified in Annex I) to which the EDRAP sample should correspond, provided that it does not depend on the nearest preceding SAP or other EDRAP samples. Other values ​​of edrap_type are reserved.

[0211] Note 1: An EDRAP sample and all subsequent samples in the same track may depend on the most recent previous SAP and / or some previous EDRAP samples, and not on any other samples before the EDRAP sample. Thus, if the encoder chooses to encode an EDRAP sample such that it does not depend on the most recent previous SAP or any previous EDRAP sample, the EDRAP sample will become a SAP.

[0212] num_ref_edrap_sample indicates the number of other EDRAP samples that are earlier than the EDRAP sample in decoding order and that need to be referenced when decoding starts from the EDRAP sample in order to be able to correctly decode the EDRAP sample and all samples after the EDRAP sample in decoding order and output order.

[0213] Note 2: The EDRAP sample is also a DRAP sample, and its num_ref_edrap_sample is equal to 0.

[0214] If a sample is present in a previous SAP or any previous EDRAP, then the EDRAP sample becomes a SAP.

[0215] num_ref_sap_or_edrap_samples_minus1 plus 1 indicates the number of samples in the required preceding SAP or EDRAP sample that are earlier than the EDRAP sample in decoding order and that need to be referenced when decoding starts from the EDRAP sample to be able to correctly decode the EDRAP sample and all samples that follow the EDRAP sample in decoding and output order.

[0216] Note 2: For EDRAP samples that are also DRAP samples, the value of num_ref_sap_or)edrap_samples_minus1 is equal to 0.

[0217] reserved MUST be equal to 0. The semantics of this subclause applies only to sample group description entries with reserved equal to 0. When reserved is greater than 0, parsers SHOULD ignore sample group description entries.

[0218] ref_edrap_idx_delta[i] indicates the i-th required previous EDRAP sample for the current EDRAP sample. Let the EDRAP sample list associated with a SAP sample of type 1, 2, or 3 be all EDRAP samples after the SAP sample and before the next SAP sample, if any. The EDRAP sample index is defined as the index of this EDRAP sample list. The value of ref_edrap_idx_delta[i] is equal to the difference between the EDRAP sample index of the current EDRAP sample and the EDRAP sample index of the i-th required previous EDRAP sample. A value of 1 indicates that the i-th EDRAP sample is the last EDRAP sample before the EDRAP sample in decoding order, a value of 2 indicates that the i-th EDRAP sample is the second to last EDRAP sample before the EDRAP sample in decoding order, and so on.

[0219] ref_sap_or_edrap_idx_delta[i] indicates the i-th required previous SAP or EDRAP sample for the current EDRAP sample. Let the EDRAP sample list associated with a SAP or EDRAP sample of type 1, 2, or 3 be the SAP sample and all EDRAP samples after the SAP sample and before the next SAP sample, if any. The SAP_or_EDRAP sample index is defined as the index into this SAP or EDRAP sample list. The value of ref_sap_or_edrap_idx_delta[i] is equal to the difference between the SAP_or_EDRAP sample index of the current EDRAP sample and the SAP_or_EDRAP sample index of the i-th required previous SAP or EDRAP sample. A value of 1 indicates that the i-th required SAP or EDRAP sample is the last SAP or EDRAP sample before the EDRAP sample in decoding order, a value of 2 indicates that the i-th required SAP or EDRAP sample is the second to last EDRAP sample before the EDRAP sample in decoding order, and so on.

[0220] 6. References

[0221] [1]ITU-T and ISO / IEC, "High efficiency video coding", Rec.ITU-T H.265|ISO / IEC 23008-2 (in force edition).

[0222] [2]Rec.ITU-T H.266|ISO / IEC 23090-3, "Versatile Video Coding".

[0223] [3]Rec.ITU-T Rec.H.274|ISO / IEC 23002-7, "Versatile SupplementalEnhancement Information Messages for Coded Video Bitstreams".

[0224] [4]ISO / IEC 14496-12: "Information technology—Coding of audio-visualobjects—Part 12:ISO base media file format".

[0225] [5]ISO / IEC 23009-1:"Information technology—Dynamic adaptivestreaming over HTTP(DASH)—Part 1:Media presentation description and segmentformats".

[0226] [6]ISO / IEC 14496-15:"Information technology—Coding of audio-visualobjects—Part 15:Carriage of network abstraction layer(NAL)unit structuredvideo in the ISO base media file format".

[0227] [7]ISO / IEC 23008-12:"Information technology—High efficiency codingand media delivery in heterogeneous environments—Part 12:Image File Format".

[0228] [8]ISO / IEC JTC 1 / SC 29 / WG 03output document N0651,"Text of ISO / IECDIS14496-12 8th edition ISO Base Media File Format",Sept.2022.

[0229] ISO / IEC JTC 1 / SC 29 / WG 03output document N0630,"WD of ISO / IEC 23009-15th edition AMD 2EDRAP streaming and other extensions",Jul.2022.

[0230] Figure 64000 is a block diagram illustrating an exemplary video processing system 4000 in which various techniques disclosed herein may be implemented. Various embodiments may include some or all of the components of system 4000. System 4000 may include an input 4002 for receiving video content. The video content may be received in a raw or uncompressed format (e.g., 8-bit or 10-bit multi-component pixel values), or may be received in a compressed or encoded format. Input 4002 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces, such as Ethernet, a passive optical network (PON), etc., and wireless interfaces, such as wireless fidelity (Wi-Fi) or a cellular interface.

[0231] System 4000 may include a codec component 4004, which may implement various codecs or coding methods described in the present disclosure. Codec component 4004 may reduce the average bit rate of the video from the input 4002 to the codec component 4004 to the output, to generate the codec representation of the video. Therefore, codec technology is sometimes referred to as video compression or video transcoding technology. The output of codec component 4004 may be stored or sent via the connected communication, as represented by component 4006. The stored or transmitted bitstream (or codec) representation of the video received at input 4002 may be used by component 4008 to generate pixel values ​​or displayable video, which is sent to display interface 4010. The process of generating user-visible video from bitstream representation is sometimes referred to as video decompression. In addition, although some video processing operations are referred to as "codec" operations or tools, it should be understood that codec tools or operations are used in encoders, and decoders will perform corresponding decoding tools or operations that reverse codec results.

[0232] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB) or High Definition Multimedia Interface (HDMI) or Display Port, etc. Examples of storage interfaces include Serial Advanced Technology Attachment (SATA), Peripheral Component Interconnect (PCI), Integrated Drive Electronics (IDE) interface, etc. The technology described in the present disclosure may be embodied in various electronic devices (e.g., mobile phones, laptop computers, smart phones, or other devices capable of performing digital data processing and / or video display).

[0233] Figure 74100. The device 4100 may be used to implement one or more methods described herein. The device 4100 may be embodied as a smart phone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. The device 4100 may include one or more processors 4102, one or more memories 4104, and a video processing circuit 4106. The processor 4102 may be configured to implement one or more methods described in the present disclosure. The memory (multiple memories) 4104 may be used to store data and code for implementing the methods and techniques described herein. The video processing circuit 4106 may be used to implement some of the techniques described in the present disclosure in a hardware circuit. In some embodiments, the video processing circuit 4106 may be at least partially included in the processor 4102 (e.g., a graphics coprocessor).

[0234] Figure 8 4200 is a flow chart of an example method 4200 for video processing. The method 4200 determines at step 4202 that a track includes a track identifier. The track identifier is the first entry in the TrackReferenceTypeBox with reference_type equal to 'aest'. At step 4204, conversion between media data and a media data file is performed based on the track identifier. In addition, the conversion of step 4204 may include encoding to a media data file or decoding from a media data file.

[0235] It should be noted that the method 4200 may be implemented in an apparatus for processing video data, the apparatus comprising a processor and a non-transitory memory having instructions thereon, such as the video encoder 4400, the video decoder 4500, and / or the encoder 4600. In this case, the instructions, when executed by the processor, cause the processor to perform the method 4200. In addition, the method 4200 may be performed by a non-transitory computer-readable medium including a computer program product for use by a video codec device. The computer program product includes computer executable instructions stored on a non-transitory computer-readable medium, such that when executed by the processor, the video codec device performs the method 4200.

[0236] Fig. 9 43 is a block diagram illustrating an example video codec system 4300 that can utilize the techniques of the present disclosure. The video codec system 4300 may include a source device 4310 and a target device 4320. The source device 4310 generates encoded video data, which may be referred to as a video codec device. The target device 4320 may decode the encoded video data generated by the source device 4310, which may be referred to as a video decoding device.

[0237] Source device 4310 may include video source 4312, video encoder 4314 and input / output (I / O) interface 4316. Video source 4312 may include, for example, a video capture device, an interface for receiving video data from a video content provider and / or a source of a computer graphics system for generating video data, or a combination of such sources. Video data may include one or more pictures. Video encoder 4314 encodes video data from video source 4312 to generate a bitstream. The bitstream may include a series of bits that form a codec representation of video data. The bitstream may include a codec picture and associated data. The codec picture is a codec representation of a picture. Associated data may include sequence parameter sets, picture parameter sets and other syntax structures. I / O interface 4316 may include a modulator / demodulator (modem) and / or a transmitter. The encoded video data may be directly sent to target device 4320 via network 4330 via I / O interface 4316. The encoded video data may also be stored on storage medium / server 4340 for access by target device 4320.

[0238] Target device 4320 may include an I / O interface 4326, a video decoder 4324, and a display device 4322. The I / O interface 4326 may include a receiver and / or a modem. The I / O interface 4326 may obtain encoded video data from source device 4310 or storage medium / server 4340. The video decoder 4324 may decode the encoded video data. The display device 4322 may display the decoded video data to a user. The display device 4322 may be integrated with the target device 4320, or may be external to the target device 4320, which may be configured to interface with an external display device.

[0239] The video encoder 4314 and the video decoder 4324 may operate according to a video compression standard, such as the High Efficiency Video Codec (HEVC) standard, the Versatile Video Codec (VVM) standard, and other current and / or additional standards.

[0240] Fig.10 is a block diagram showing an example of a video encoder 4400, which may be Fig. 9 Video encoder 4314 in system 4300 shown. Video encoder 4400 can be configured to perform any or all of the techniques of the present disclosure. Video encoder 4400 includes multiple functional components. The techniques described in the present disclosure can be shared between the various components of video encoder 4400. In some examples, the processor can be configured to perform any or all of the techniques described in the present disclosure.

[0241] The functional components of the video encoder 4400 may include a segmentation unit 4401, a prediction unit 4402 (which may include a mode selection unit 4403, a motion estimation unit 4404, a motion compensation unit 4405, an intra-frame prediction unit 4406), a residual generation unit 4407, a transform processing unit 4408, a quantization unit 4409, an inverse quantization unit 4410, an inverse transform unit 4411, a reconstruction unit 4412, a buffer 4413 and an entropy coding unit 4414.

[0242] In other examples, the video encoder 4400 may include more, fewer, or different functional components. In an example, the prediction unit 4402 may include an intra block copy (IBC) unit. The IBC unit may perform prediction in an IBC mode, where at least one reference picture is a picture in which the current video block is located.

[0243] Furthermore, some components, such as the motion estimation unit 4404 and the motion compensation unit 4405 , may be highly integrated but are represented separately in the example of the video encoder 4400 for explanation purposes.

[0244] The segmentation unit 4401 may segment the picture into one or more video blocks. The video encoder 4400 and the video decoder 4500 may support various video block sizes.

[0245] The mode selection unit 4403 may select one of the coding modes, for example, based on the error result, and provide the resulting intra-frame or inter-frame coded block to the residual generation unit 4407 to generate residual block data and provide it to the reconstruction unit 4412 to reconstruct the coded block for use as a reference picture. In some examples, the mode selection unit 4403 may select an intra-frame and inter-frame prediction (CIIP) mode combination, where the prediction is based on an inter-frame prediction signal and an intra-frame prediction signal. The mode selection unit 4403 may also select a resolution of motion vectors for the block in the case of inter-frame prediction (e.g., sub-pixel or integer pixel precision).

[0246] To perform inter-frame prediction on the current video block, the motion estimation unit 4404 may generate motion information for the current video block by comparing one or more reference frames from the buffer 4413 with the current video block. The motion compensation unit 4405 may determine a predicted video block for the current video block based on the motion information and decoded samples of a picture from the buffer 4413 (not the picture associated with the current video block).

[0247] The motion estimation unit 4404 and the motion compensation unit 4405 may perform different operations on the current video block, for example, depending on whether the current video block is in an I slice, a P slice, or a B slice.

[0248] In some examples, the motion estimation unit 4404 may perform unidirectional prediction on the current video block, and the motion estimation unit 4404 may search for a reference video block for the current video block in the reference pictures of list 0 or list 1. The motion estimation unit 4404 may then generate a reference index indicating a reference picture in list 0 or list 1, the reference picture including the reference video block and a motion vector indicating a spatial displacement between the current video block and the reference video block. The motion estimation unit 4404 may output the reference index, the prediction direction indicator, and the motion vector as motion information of the current video block. The motion compensation unit 4405 may generate a predicted video block of the current block based on the reference video block indicated by the motion information of the current video block.

[0249] In other examples, the motion estimation unit 4404 may perform bidirectional prediction on the current video block, and the motion estimation unit 4404 may search for a reference video block of the current video block in the reference pictures in list 0, and may also search for another reference video block of the current video block in the reference pictures in list 1. The motion estimation unit 4404 may then generate a reference index indicating a reference picture in list 0 and list 1, the reference picture including a reference video block and a motion vector indicating a spatial displacement between the reference video block and the current video block. The motion estimation unit 4404 may output the reference index and the motion vector of the current video block as motion information of the current video block. The motion compensation unit 4405 may generate a predicted video block of the current video block based on the reference video block indicated by the motion information of the current video block.

[0250] In some examples, motion estimation unit 4404 may output a complete set of motion information for use in a decoding process of a decoder. In some examples, motion estimation unit 4404 may not output a complete set of motion information for the current video. Rather, motion estimation unit 4404 may reference motion information of another video block to signal motion information of the current video block. For example, motion estimation unit 4404 may determine that motion information of the current video block is sufficiently similar to motion information of an adjacent video block.

[0251] In one example, the motion estimation unit 4404 may indicate a value in a syntax structure associated with the current video block that indicates to the video decoder 4500 that the current video block has the same motion information as another video block.

[0252] In another example, the motion estimation unit 4404 may identify another video block and a motion vector difference (MVD) in a syntax structure associated with the current video block. The motion vector difference indicates the difference between the motion vector of the current video block and the motion vector of the indicated video block. The video decoder 4500 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.

[0253] As discussed above, the video encoder 4400 can predictively signal motion vectors.Two examples of predictive signaling techniques that can be implemented by the video encoder 4400 include Advanced Motion Vector Prediction (AMVP) and merge mode signaling.

[0254] The intra prediction unit 4406 may perform intra prediction on the current video block. When the intra prediction unit 4406 performs intra prediction on the current video block, the intra prediction unit 4406 may generate prediction data for the current video block based on decoded samples of other video blocks in the same picture. The prediction data for the current video block may include the predicted video block and various syntax elements.

[0255] The residual generation unit 4407 may generate residual data for the current video block by subtracting the prediction video block(s) of the current video block from the current video block. The residual data of the current video block may include residual video blocks corresponding to different sample components of samples in the current video block.

[0256] In other examples, such as in skip mode, there may be no residual data for the current video block of the current video block, and the residual generation unit 4407 may not perform a subtraction operation.

[0257] The transform processing unit 4408 may generate a transform coefficient video block for a current video block by applying one or more transforms to the residual video block associated with the current video block.

[0258] After the transform processing unit 4408 generates a transform coefficient video block associated with the current video block, the quantization unit 4409 may quantize the transform coefficient video block associated with the current video block based on one or more quantization parameter (QP) values ​​associated with the current video block.

[0259] The inverse quantization unit 4410 and the inverse transform unit 4411 may apply inverse quantization and inverse transform to the transform coefficient video block, respectively, to reconstruct a residual video block from the transform coefficient video block. The reconstruction unit 4412 may add the reconstructed residual video block to corresponding samples from one or more prediction video blocks generated by the prediction unit 4402 to generate a reconstructed video block associated with the current block for storage in the buffer 4413.

[0260] After the reconstruction unit 4412 reconstructs the video block, a loop filtering operation may be performed to reduce video blocking effects in the video block.

[0261] The entropy coding unit 4414 may receive data from other functional components of the video encoder 4400. When the entropy coding unit 4414 receives data, the entropy coding unit 4414 may perform one or more entropy coding operations to generate entropy coded data and output a bitstream including the entropy coded data.

[0262] Fig.11 is a block diagram showing an example of a video decoder 4500, which may be Fig. 9 Video decoder 4324 in the system 4300 shown. Video decoder 4500 can be configured to perform any or all of the techniques of the present disclosure. In the example shown, video decoder 4500 includes multiple functional components. The techniques described in the present disclosure can be shared between the various components of video decoder 4500. In some examples, the processor can be configured to perform any or all of the techniques described in the present disclosure.

[0263] In the example shown, the video decoder 4500 includes an entropy decoding unit 4501, a motion compensation unit 4502, an intra prediction unit 4503, an inverse quantization unit 4504, an inverse transform unit 4505, and a reconstruction unit 4506, a buffer 4507. In some examples, the video decoder 4500 can perform a decoding pass that generally corresponds to the encoding pass described with respect to the video encoder 4400.

[0264] The entropy decoding unit 4501 may retrieve an encoded bitstream. The encoded bitstream may include entropy-encoded video data (e.g., encoded video data blocks). The entropy decoding unit 4501 may decode the entropy-encoded video data, and the motion compensation unit 4502 may determine motion information based on the entropy-decoded video data, including motion vectors, motion vector precision, reference picture list indexes, and other motion information. The motion compensation unit 4502 may determine such information, for example, by performing AMVP and merge mode.

[0265] The motion compensation unit 4502 may generate a motion compensated block, possibly performing interpolation based on an interpolation filter. The identification of the interpolation filter used with sub-pixel precision may be included in a syntax element.

[0266] The motion compensation unit 4502 may calculate interpolation of sub-integer pixels of a reference block using an interpolation filter used by the video encoder 4400 during encoding of the video block. The motion compensation unit 4502 may determine the interpolation filter used by the video encoder 4400 according to received syntax information and use the interpolation filter to generate a prediction block.

[0267] The motion compensation unit 4502 can use some syntax information to determine the size of the blocks used to encode (multiple) frames and / or (multiple) slices of the encoded video sequence, partitioning information describing how each macroblock of the pictures of the encoded video sequence is partitioned, a mode indicating how each partition is encoded, one or more reference frames (and reference frame lists) for each inter-frame codec block, and other information used to decode the encoded video sequence.

[0268] The intra prediction unit 4503 may form a prediction block from spatially adjacent blocks using, for example, an intra prediction mode received in the bitstream. The inverse quantization unit 4504 inversely quantizes, i.e., dequantizes, the video block coefficients provided in the bitstream and decoded and quantized by the entropy decoding unit 4501. The inverse transform unit 4505 applies an inverse transform.

[0269] The reconstruction unit 4506 may add the residual block to the corresponding prediction block generated by the motion compensation unit 4502 or the intra prediction unit 4503 to form a decoded block. If necessary, a deblocking filter may also be applied to filter the decoded block to remove block artifacts. The decoded video block is then stored in a buffer 4507, which provides reference blocks for subsequent motion compensation / intra prediction and also generates a decoded video for presentation on a display device.

[0270] Fig.12 4600 is a schematic diagram of an example encoder 4600. The encoder 4600 is suitable for implementing VVC technology. The encoder 4600 includes three loop filters, namely, a deblocking filter (DF) 4602, a sample adaptive offset (SAO) 4604, and an adaptive loop filter (ALF) 4606. Unlike the DF 4602 that uses a predefined filter, the SAO 4604 and the ALF 4606 utilize the original samples of the current picture to reduce the mean square error between the original samples and the reconstructed samples by adding an offset and applying a finite impulse response (FIR) filter, respectively, and using codec side information signaling to notify the offset and filter coefficients. The ALF 4606 is at the last processing stage of each picture and can be seen as a tool that attempts to capture and repair artifacts created by previous stages.

[0271] The encoder 4600 also includes an intra prediction component 4608 and a motion estimation / compensation (ME / MC) component 4610 configured to receive an input video. The intra prediction component 4608 is configured to perform intra prediction, while the ME / MC component 4610 is configured to perform inter prediction using a reference picture obtained from a reference picture buffer 4612. The residual block from the inter prediction or intra prediction is fed to the transform (T) component 4614 and the quantization (Q) component 4616 to generate quantized residual transform coefficients, which are fed to the entropy coding component 4618. The entropy coding component 4618 entropy codes and decodes the prediction result and the quantized transform coefficients and sends them to a video decoder (not shown). The quantized component output from the quantization component 4616 can be fed to the inverse quantization (IQ) component 4620, the inverse transform component 4622, and the reconstruction (REC) component 4624. The REC component 4624 is capable of outputting images to the DF 4602 , SAO 4604 , and ALF 4606 for filtering before these pictures are stored in the reference picture buffer 4612 .

[0272] A list of solutions preferred by some examples is provided next.

[0273] The following solutions illustrate examples of the techniques discussed herein.

[0274] The following solutions illustrate example embodiments of the techniques discussed in the previous sections.

[0275] 1. A method for processing media data, comprising: determining that a track includes a track identifier, the track identifier being the first entry in a TrackReferenceTypeBox with reference_type equal to 'aest'; and performing conversion between media data and a media data file based on the track identifier.

[0276] 2. The method as in solution 1, wherein the TrackReferenceTypeBox with reference_type equal to 'aest' must include only track identifiers and must not include any track group identifiers.

[0277] 3. The method as described in any of the solutions 1 to 2, wherein the TrackReferenceTypeBox with reference_type equal to 'aest' must include a track identifier in the first entry and other entries including track group identifiers.

[0278] 4. The method as described in any of solutions 1 to 3, wherein the first entry in the TrackReferenceTypeBox with reference_type equal to 'aest' must be the track identifier.

[0279] 5. A method as described in any of solutions 1 to 4, wherein the media data file specifies whether random access from an extended dependent random access point (EDRAP) sample requires a most recent previous stream access point (SAP) sample of type 1, 2 or 3.

[0280] 6. A method as described in any of Solutions 1 to 5, wherein an EDRAP sample is a sample for which all subsequent samples can be correctly decoded in both decoding order and output order, provided that a required previous SAP or EDRAP sample is available for decoding the sample and subsequent samples, and wherein the required previous SAP or EDRAP sample includes one or more of a set of samples, the set of samples starting from the closestSapSample of type 1, 2 or 3 in decoding order, and including all EDRAP samples between the closestSapSample and the sample in decoding order.

[0281] 7. A method as described in any of Solutions 1 to 6, wherein an EDRAP sample is a sample for which all subsequent samples can be correctly decoded in both decoding order and output order, provided that a required previous SAP or EDRAP sample is available for decoding the sample and subsequent samples, wherein the required previous SAP or EDRAP sample includes zero or more of a sample set, the sample set starting from the closestSapSample of type 1, 2 or 3 in decoding order, and including all EDRAP samples between the closestSapSample and the sample in decoding order.

[0282] 8. A method as described in any of solutions 1 to 7, wherein when a media track has a track reference of type 'aest', for each EDRAP sample sampleA in the media track, there must be one and only one sample sampleB in the referenced track with the same decoding time as sampleA, and wherein sampleB must include all media data of the required previous SAP or EDRAP sample of sampleA.

[0283] 9. A method as described in any of solutions 1 to 8, wherein for any EDRAP sample sampleA mapped to an EDRAP sample group, sampleSeq is a sample sequence including samples, wherein the samples include a SAP or EDRAP sample identified by ref_sap_or_edrap_idx_delta[i], wherein i ranges from 0 to num_ref_sap_or_edrap_samples_minus1, inclusive, in decoding order, sampleA, and all samples after sampleA in the track in both decoding and output order, and for each sample sampleB in sampleSeq, all data required to process sampleB must be accessible in the referenced sample entry, in sampleB, or in any sample that precedes sampleB in decoding order and exists in sampleSeq.

[0284] 10. A method as described in any one of solutions 1 to 9, wherein VisualEdrapEntry() is defined as follows:

[0285]

[0286] 11. A method as described in any of solutions 1 to 10, wherein num_ref_sap_or_edrap_samples_minus1 plus 1 indicates the number of samples in the previous SAP or EDRAP sample required, which are earlier than the EDRAP sample in decoding order and need to be referenced when decoding starts from the EDRAP sample to enable correct decoding of the EDRAP sample and all samples after the EDRAP sample in decoding order and output order.

[0287] 12. A method as described in any of solutions 1 to 11, wherein ref_sap_or_edrap_idx_delta[i] indicates the i-th required previous SAP or EDRAP sample of the current EDRAP sample, wherein the SAP or EDRAP sample list associated with a SAP sample of type 1, 2 or 3 includes the SAP sample and all EDRAP samples after the SAP sample and before the next SAP sample, wherein SAP_or_EDRAP sample index is an index to the SAP or EDRAP sample list, wherein ref_sap_or_edrap_idx_delta[i] indicates the i-th required previous SAP or EDRAP sample of the current EDRAP sample, wherein the SAP or EDRAP sample list associated with a SAP sample of type 1, 2 or 3 includes the SAP sample and all EDRAP samples after the SAP sample and before the next SAP sample, wherein SAP_or_EDRAP sample index is an index to the SAP or EDRAP sample list, wherein ref_sap_or_ The value of edrap_idx_delta[i] is equal to the difference between the SAP_or_EDRAP sample index of the current EDRAP sample and the SAP_or_EDRAP sample index of the i-th required previous SAP or EDRAP sample, wherein a value of 1 indicates that the i-th required SAP or EDRAP sample is the last SAP or EDRAP sample before the EDRAP sample in decoding order, and wherein a value of 2 indicates that the i-th required SAP or EDRAP sample is the second to last EDRAP sample before the EDRAP sample in decoding order.

[0288] 13. A device for processing video data, comprising: a processor; and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform a method as described in any one of solutions 1 to 12.

[0289] 14. A non-transitory computer-readable medium, comprising a computer program product for use by a video codec device, the computer program product comprising computer executable instructions stored on the non-transitory computer-readable medium, so that when executed by a processor, the video codec device performs a method as described in any one of Solutions 1 to 12.

[0290] 15. A non-transitory computer-readable recording medium storing a bitstream of a video generated by a method performed by a video processing device, wherein the method comprises: determining that a track includes a track identifier, the track identifier being the first entry in a TrackReferenceTypeBox with reference_type equal to 'aest'; and generating a bitstream based on the determination.

[0291] 16. A method for storing a bitstream of a video, comprising: determining that a track includes a track identifier, the track identifier being the first entry in a TrackReferenceTypeBox with reference_type equal to 'aest'; generating a bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium.

[0292] 17. A method, apparatus or system as described in this patent document.

[0293] In the solution described herein, an encoder can comply with the format rules by generating a codec representation according to the format rules. In the solution described herein, a decoder can parse syntax elements in the codec representation using the format rules and generate decoded video based on the presence and absence of syntax elements known according to the format rules.

[0294] In the present disclosure, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during conversion from a pixel representation of a video to a corresponding bitstream representation (or vice versa). For example, the bitstream representation of a current video block may correspond to bits that are co-located or distributed at different locations in the bitstream, as defined by the syntax. For example, a macroblock may be encoded based on error residual values ​​from a transform and codec, and also encoded using bits in a header and other fields in the bitstream. In addition, during conversion, the decoder may parse the bitstream based on a determination that certain fields may or may not be present, as described in the above solution. Similarly, the encoder may determine whether to include certain syntax fields and generate the codec representation accordingly by including or excluding the syntax fields in the codec representation.

[0295] The disclosed and other solutions, examples, embodiments, modules and functional operations described in the present disclosure may be implemented in digital electronic circuits or computer software, firmware or hardware or a combination of one or more thereof, which includes the structures disclosed in the present disclosure and their equivalents. The disclosed and other embodiments may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions, encoded on a computer-readable medium to be executed by a data processing device or to control the operation of the data processing device. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a material composition that affects a machine-readable propagation signal, or a combination of one or more thereof. The term "data processing device" encompasses all devices, equipment and machines for processing data, including, for example, a programmable processor, a computer or multiple processors or computers. In addition to hardware, the device may also include code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more thereof. A propagation signal is an artificially generated signal, for example, a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device.

[0296] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or any other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store portions of one or more modules, subroutines, or code). A computer program may be deployed to execute on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0297] The processes or logic flows described in the present disclosure may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and the devices may also be implemented as, special purpose logic circuits (e.g., field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs)).

[0298] As an example, processors suitable for executing computer programs include general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, the computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or be operably coupled to receive data from one or more mass storage devices or transfer data to one or more mass storage devices or both. However, the computer does not have to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices, such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and compact disk read-only memory (CD ROM) and digital versatile disk read-only memory (DVD-ROM) optical disks. The processor and memory may be supplemented or incorporated therein by dedicated logic circuits.

[0299] Although the present disclosure includes many details, these details should not be interpreted as limitations on any subject matter or content that may be claimed, but should be interpreted as descriptions of features of specific embodiments that may be specific to a particular technology. Certain features described in the context of separate embodiments in the present disclosure may also be implemented in combination in a single embodiment. Conversely, the individual features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any appropriate sub-combination. In addition, although the above may describe features as acting in certain combinations and even initially claiming protection, in some cases, one or more features from the claimed combination may be removed from the combination, and the claimed combination may involve a sub-combination or a deformation of a sub-combination.

[0300] Similarly, although operations are shown in a particular order in the figures, this should not be understood as requiring such operations to be performed in the particular order shown or in a sequential order or to perform all of the operations shown to achieve the desired results. In addition, the separation of various system components described in this disclosure should not be understood as requiring such separation in all embodiments.

[0301] Only a few implementations and examples are described, and other implementations, enhancements, and modifications may be made based on what is described and illustrated in this disclosure.

[0302] A first component is directly coupled to a second component when there are no intermediate components other than a line, trace, or another medium between the first and second components. A first component is indirectly coupled to a second component when there are intermediate components other than a line, trace, or another medium between the first and second components. The term "coupled" and variations thereof include direct coupling and indirect coupling. Unless otherwise specified, the use of the term "about" is meant to include a range of ±10% of the subsequent value.

[0303] Although several embodiments are provided in the present disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are considered to be illustrative rather than restrictive, and are not intended to be limited to the details given herein. For example, various elements or components may be combined or integrated in another system, or certain features may be omitted or not implemented.

[0304] In addition, without departing from the scope of the present disclosure, the techniques, systems, subsystems and methods described and shown as discrete or separate in various embodiments may be combined or integrated with other systems, modules, techniques or methods. Other items shown or discussed as coupled may be directly connected, or may be indirectly coupled or communicated through some interface, device or intermediate component, whether electrically, mechanically or otherwise coupled or communicated. Other examples of changes, substitutions and alterations may be identified by those skilled in the art, and these changes, substitutions and alterations may be made without departing from the spirit and scope disclosed herein.

Claims

1. A method for processing media data, comprising: determining that a track identifier (ID) identifying a reference track of the media data is included in a track reference type box (TrackReferenceTypeBox) having a reference type (reference_type) equal to an associated external stream track ('aest'); as well as Conversion between the media data and a media data file is performed based on the track identifier.

2. The method of claim 1, wherein: The track ID is the first entry in the TrackReferenceTypeBox with the reference_type equal to 'aest'.

3. The method according to any one of claims 1 to 2, wherein: When the TrackReferenceTypeBox with the reference_type equal to 'aest' is present, the TrackReferenceTypeBox includes only the track identifier and does not include any track group identifier.

4. The method according to any one of claims 1 to 2, wherein: When the TrackReferenceTypeBox with the reference_type equal to 'aest' exists, the TrackReferenceTypeBox includes the track identifier in the first entry and the group track identifier, if any, in subsequent entries.

5. The method according to any one of claims 1 to 4, wherein: The first entry in the TrackReferenceTypeBox with reference_type equal to 'aest' must be the track identifier.

6. The method according to any one of claims 1 to 5, wherein: The media data file specifies whether a most recent preceding stream access point (SAP) sample of type 1, 2 or 3 is required for random access from an extended dependent random access point (EDRAP) sample.

7. The method according to any one of claims 1 to 6, wherein: An EDRAP sample is a sample for which all subsequent samples can be correctly decoded in both decoding order and output order, provided that a required previous SAP or EDRAP sample is available for decoding the sample and subsequent samples, and wherein the required previous SAP or EDRAP sample comprises one or more of a set of samples starting with the closestSapSample of type 1, 2, or 3 in decoding order and including all EDRAP samples between the closestSapSample and the sample in decoding order.

8. The method according to any one of claims 1 to 6, wherein: An EDRAP sample is a sample for which all subsequent samples can be correctly decoded in both decoding order and output order, provided that a required previous SAP or EDRAP sample is available for decoding the sample and subsequent samples, wherein the required previous SAP or EDRAP sample includes zero or more of a set of samples, the set of samples starting with the closestSapSample of type 1, 2, or 3 in decoding order and including all EDRAP samples between the closestSapSample and the sample in decoding order.

9. The method according to any one of claims 1 to 8, wherein: When a media track has reference_type 'aest', for each EDRAP sample sampleA in the media track, there must be one and only one sample sampleB in the referenced track that has the same decoding time as sampleA, and where sampleB must include all media data of the most recent SAP sample of type 1, 2, or 3 that precedes sampleA in decoding order, and all media data of the previous SAP or EDRAP sample required by sampleA.

10. The method according to any one of claims 1 to 9, wherein: For any EDRAP sample sampleA mapped to an EDRAP sample group, the sample sequence (sampleSeq) is a sequence of samples including the SAP or EDRAP sample identified by ref_sap_or_edrap_idx_delta[i], where i ranges from 0 to num_ref_sap_or_edrap_samples_minus1 in decoding order, including the endpoints, sampleA, and all samples after sampleA in the track in both decoding order and output order.

11. The method of claim 10, wherein: For each sample sampleB in sampleSeq, all data needed to process sampleB must be accessible in the referenced sample entry, in sampleB, or in any sample that precedes sampleB in decoding order and that is present in sampleSeq.

12. The method according to any one of claims 1 to 11, wherein: VisualEdrapEntry() is defined as follows:

13. The method according to any one of claims 1 to 12, wherein: num_ref_sap_or_edrap_samples_minus1 plus 1 indicates the number of samples in the required previous SAP or EDRAP sample, which are earlier than the EDRAP sample in decoding order and need to be referenced when decoding starts from the EDRAP sample to enable correct decoding of the EDRAP sample and all samples after the EDRAP sample in decoding order and output order.

14. The method according to any one of claims 1 to 13, wherein: ref_sap_or_edrap_idx_delta[i] indicates the i-th required previous SAP or EDRAP sample of the current EDRAP sample, wherein a SAP or EDRAP sample list associated with a SAP sample of type 1, 2, or 3 includes the SAP sample and all EDRAP samples after the SAP sample and before the next SAP sample, wherein SAP_or_EDRAP sample index is an index into the SAP or EDRAP sample list, wherein ... The value of lta[i] is equal to the difference between the SAP_or_EDRAP sample index of the current EDRAP sample and the SAP_or_EDRAP sample index of the i-th required previous SAP or EDRAP sample, wherein a value of 1 indicates that the i-th required SAP or EDRAP sample is the last SAP or EDRAP sample before the EDRAP sample in decoding order, and wherein a value of 2 indicates that the i-th required SAP or EDRAP sample is the second to last EDRAP sample before the EDRAP sample in decoding order.

15. The method according to any one of claims 1 to 14, wherein: The converting includes encoding the media data into a bitstream.

16. The method according to any one of claims 1 to 14, wherein: The converting includes decoding the media data from a bitstream.

17. A device for processing media data, comprising: processor; and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method of any one of claims 1 to 16.

18. A non-transitory computer-readable medium, comprising a computer program product for use by a video codec device, the computer program product comprising computer executable instructions stored on the non-transitory computer-readable medium, so that when executed by a processor, the video codec device performs the method as claimed in any one of claims 1 to 16.

19. A non-transitory computer-readable recording medium storing a bit stream of a video generated by a method performed by a video processing device, wherein: The method comprises the method of any one of claims 1 to 16.

20. A method for storing a bit stream of a video, comprising the method as claimed in any one of claims 1 to 16.

21. A method, apparatus or system as described in the present disclosure.

Images