Improved extended dependent random access point support in ISO base media file format

Abstract

A mechanism for processing visual media data is disclosed. Extended dependent random access point (EDRAP) samples are determined. The EDRAP samples are samples for which all subsequent samples in the decoding order and the output order can be correctly decoded, with the proviso that the required previous streaming access point (SAP) or EDRAP samples are available for reference when decoding the EDRAP samples and subsequent samples. A conversion between the visual media data and the media data file is performed based on the EDRAP samples.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 340,167, filed May 10, 2022. The entire contents of all of the above patent applications are incorporated herein by reference. Technical Field

[0003] This patent document relates to the generation, storage and consumption of digital audio-visual media information in a file format. Background Art

[0004] Digital video consumes the largest amount of bandwidth used for the Internet and other digital communications networks. As the number of connected user devices capable of receiving and displaying video increases, bandwidth demands for digital video usage are likely to continue to grow. Summary of the invention

[0005] A first aspect relates to a method for processing visual media data, comprising: determining an extended dependent random access point (EDRAP) sample, wherein the EDRAP sample is a sample for which all subsequent samples in a decoding order and an output order can be correctly decoded, provided that when decoding the EDRAP sample and subsequent samples, a required previous streaming access point (SAP) or EDRAP sample is available for reference; and performing conversion between visual media data and a media data file based on the EDRAP sample.

[0006] A second aspect relates to a method for processing visual media data, comprising: determining an Extended Dependent Random Access Point (EDRAP) sample, wherein when a media track has a track reference of type "aest" that refers to a related track, for each EDRAP sample in the media track denoted as sample A, there should be one and only one sample in the related track having the same decoding time as sample A, denoted as sample B; and performing conversion between visual media data and a media data file based on the EDRAP sample.

[0007] A third aspect relates to an apparatus for processing visual media data, comprising: one or more processors; and one or more non-volatile memories having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform any of the aforementioned aspects.

[0008] The fourth aspect relates to a non-transitory computer-readable medium, including a computer program product for use with 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 one or more processors of the video codec device, the video codec device performs the method described in any of the preceding aspects.

[0009] A fifth aspect relates to a non-transitory computer-readable recording medium storing a media data file, which is generated by a method executed by a media processing device, wherein the method includes: determining an extended dependent random access point (EDRAP) sample, wherein the EDRAP sample is a sample that all subsequent samples in a decoding order and an output order can be correctly decoded, provided that when decoding the EDRAP sample and subsequent samples, a required previous streaming access point (SAP) or EDRAP sample is available for reference; and generating a media data file based on the determination.

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

[0011] 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

[0012] 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 represent like parts.

[0013] Figure 1 is a diagram of an example mechanism for random access when decoding a bitstream using an intra random access point (IRAP) picture.

[0014] Figure 2 is a diagram of an example mechanism for random access when decoding a bitstream using a dependent random access point (DRAP) picture.

[0015] Figure 3 is a diagram of an example mechanism for random access when decoding a bitstream using EDRAP pictures.

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

[0017] Figure 5 An example of EDRAP-based random access is shown.

[0018] Figure 6 is a block diagram showing an example video processing system.

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

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

[0021] Fig. 9 is a block diagram illustrating an example video codec system.

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

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

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

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

[0026] The section headings used in this document are intended to facilitate understanding and are not intended to limit the applicability of the techniques and embodiments disclosed in each section to that section. In addition, the use of H.266 terminology in some descriptions is intended to facilitate understanding and is not intended to limit the scope of the disclosed techniques. Therefore, the techniques described herein are also applicable to other video codec protocols and designs. In this document, for drafts of the VVC specification or the ISOBMFF file format specification, editorial changes are shown in bold italics to indicate deleted text, and bold underlined text to indicate added text.

[0027] 1. Preliminary Discussion

[0028] This document relates to media file formats. In particular, it relates to support for Extended Dependent Random Access Point (EDRAP) signaling in the International Organization for Standardization (ISO) Base Media File Format (ISOBMFF). The concepts may 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.

[0029] 2. Video Codec Introduction

[0030] 2.1 Video Codec Standards

[0031] 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 Moving Picture Experts Group (MPEG)-1 and MPEG-4 Visual, and the two organizations jointly produced 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 have been based on a hybrid video codec structure that utilizes temporal prediction plus transform codecs. To explore future video codec technologies beyond HEVC, the Video Codec Experts Group (VCEG) and MPEG jointly established the Joint Video Exploration Team (JVET). JVET has adopted many of the approaches and put them into a reference software called the Joint Exploration Model (JEM) [2]. When the Versatile Video Codec (VVC) project was officially launched, JVET was renamed the Joint Video Experts Team (JVET). VVC[3] is a codec standard that aims to reduce the bit rate by 50% compared to HEVC.

[0032] The Versatile Video Codec (VVC) standard (ITU-T H.266 | ISO / IEC 23090-3)[3][4] and the related Versatile Supplementary Enhancement Information (VSEI) standard (ITU-T H.274 | ISO / IEC 23002-7)[5][6] are intended for the broadest range of applications, including traditional uses such as TV broadcasting, video conferencing or stored media playback, as well as newer and more advanced use cases such as adaptive bitrate streaming, video region extraction, composition and merging of content from multiple codec video bitstreams, multi-view video, scalable layered codecs and viewport-adaptive 360° immersive media.

[0033] 2.2 File Format Standards

[0034] Media streaming applications are based on IP, TCP, and HTTP transport methods and rely on file formats such as the ISO Base Media File Format (ISOBMFF) [7]. One such streaming system is Dynamic Adaptive Streaming over HTTP (DASH) [8]. For using video formats with ISOBMFF and DASH, file format specifications specific to the video format are required, such as the AVC file format and the HEVC file format in [9], to encapsulate video content in ISOBMFF tracks as well as DASH representations and segments. Important information about the video bitstream, such as profile, tier, and level, as well as many other information, needs to be exposed as file format-level metadata and / or DASH Media Presentation Description (MPD) for content selection purposes, e.g., for selecting appropriate media segments for initialization at the start of a streaming session and for stream adaptation during a streaming session.

[0035] Similarly, to use an image format with ISOBMFF, a file format specification specific to the image format would be required, such as the AVC image file format and the HEVC image file format in

[10] .

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

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

[0038] HEVC includes signaling of intra random access point (IRAP) pictures in the NAL unit header via NAL unit types. Three types of IRAP pictures are supported in HEVC. These types are Instantaneous Decoder Refresh (IDR), Clean Random Access (CRA), and Broken Link (BLA) pictures. IDR pictures constrain the inter-picture prediction structure so that it does not reference any pictures before the current Group of Pictures (GOP). Reference pictures in the current GOP can be called closed GOP random access points. CRA pictures are less restrictive and allow some pictures to reference pictures before the current GOP, all of which are discarded in the case of random access. CRA pictures can be called open GOP random access points. BLA pictures are typically derived from the concatenation of two bitstreams or parts of them on a CRA picture, for example during stream switching. In order to enable systems 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 [7], which are used for random access support in dynamic adaptive streaming over the Hypertext Transfer Protocol (DASH) [8].

[0039] 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 RADL picture), and one type of CRA picture. These types are used in a similar manner to HEVC. The BLA picture type in HEVC is not included in VVC for two reasons. First, the basic functionality of a BLA picture can be implemented with a CRA picture plus an end-of-sequence NAL unit, the presence of which indicates that the subsequent picture starts a new CVS in a single-layer bitstream. Second, during the development of VVC, it was hoped that fewer NAL unit types would be specified than in HEVC, as shown by the use of 5 bits instead of 6 bits for the NAL unit type field in the NAL unit header.

[0040] Another difference in random access support between VVC and HEVC is that GDR is supported in a more standardized way in VVC. In GDR, decoding of the bitstream can start from an inter-coded picture. At the start 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 for signaling of GDR random access points and recovery points. In VVC, a NAL unit type is specified to indicate a GDR picture, and the recovery point is signaled in the picture header syntax structure. Codec video sequences (CVSs) and bitstreams are allowed to start from a GDR picture. This means that the entire bitstream is only allowed to contain inter-coded pictures, not a single intra-coded picture. The main benefit of specifying GDR support in this way is to provide consistent behavior for GDR. GDR enables the encoder to smooth the bitrate of the bitstream by distributing intra-coded slices or blocks across multiple pictures, instead of intra-coding the entire picture. This can significantly reduce end-to-end latency, which in many cases is considered even more important as ultra-low latency applications such as wireless displays, online gaming and drone-based applications become more common.

[0041] Another GDR-related feature in VVC is virtual boundary signaling. The boundary between the refresh area (i.e., the correctly decoded area) and the unrefreshed area on the picture between the GDR picture and the corresponding recovery point can be signaled as a virtual boundary. When signaling, cross-border loop filtering is not applied. Therefore, some samples at or near the boundary will not have a decoding mismatch. This may be useful when the application determines to display a correctly decoded area during the GDR process. IRAP pictures and GDR pictures can be collectively referred to as random access point (RAP) pictures.

[0042] 2.4 Video encoding, decoding, storage and streaming based on Extended Dependent Random Access Point (EDRAP)

[0043] 2.4.1 Concept and Standard Support

[0044] This paper describes the concepts of video encoding, decoding, storage and streaming based on EDRAP. Figure 1 As shown, the application (e.g., adaptive streaming) determines the frequency of random access points (RAPs), such as a RAP period of 1 second or 2 seconds. In one example, RAP is provided by encoding and decoding IRAP pictures. Note that inter-frame prediction references for non-critical pictures between RAP pictures are not shown, and are output in order from left to right. When random access is performed from CRA4, the decoder receives CRA4, CRA5, etc. and related inter-frame prediction pictures and decodes them correctly.

[0045] Figure 2 The DRAP method is shown, which improves codec efficiency by allowing DRAP pictures (and subsequent pictures) to reference previous IRAP pictures 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 random access is made from DRAP4, the decoder receives IDR0, DRAP4, DRAP5, etc. and the related inter-frame prediction pictures and decodes them correctly.

[0046] 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 the output order is from left to right. When random access is made from EDRAP4, the decoder receives IDR0, EDRAP2, EDRAP4, EDRAP5, etc. and the related inter-frame prediction pictures and decodes them correctly.

[0047] Figure 4 An example of the EDRAP method using the MSR fragment and the ESR fragment is shown. Figure 5 An example of random access from EDRAP4 is shown. When a random access or switching to a segment starting from EDRAP4 is performed, the decoder receives and decodes a segment including IDR0, EDRAP2, EDRAP4, EDRAP5, etc. and related inter-frame prediction pictures.

[0048] EDRAP-based video codecs are supported by the EDRAP indication SEI message included in the amendment

[11] of the VSEI standard; the storage part is supported by the EDRAP sample group and associated external stream track reference included in the amendment

[12] of the ISOBMFF standard; and the streaming part is supported by the main stream representation (MSR) and external stream representation (ESR) descriptors included in the amendment

[13] of the DASH standard. These standards support are described below.

[0049] 2.4.2 EDRAP Indication SEI Message

[0050] An amendment to the VSEI standard is under development. An example draft specification for this amendment is contained in

[11] , which includes the specification of the EDRAP indication SEI message.

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

[0052]

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

[0054] The presence of the EDRAP indication SEI message indicates that the constraints on picture order and picture references specified in this subclause apply. These constraints enable a decoder to correctly decode an EDRAP picture and pictures in the same layer that follow the EDRAP picture in decoding order and output order without decoding any other pictures of the same layer, except for picture lists referenceablePictures that include 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.

[0055] The constraints indicated by the presence of the EDRAP indication SEI message are as follows (these constraints shall all apply):

[0056] –EDRAP pictures are trailing pictures.

[0057] – The temporal sub-layer identifier of an EDRAP picture is equal to 0.

[0058] – An EDRAP picture does not include any pictures in the same layer in its active entry in the reference picture list, except referenceablePictures.

[0059] – Any picture that is in the same layer and follows the EDRAP picture in both decoding order and output order does not include in its active entry in the reference picture list any pictures that are in the same layer and precede the EDRAP picture in both decoding order or output order, except referenceablePictures.

[0060] – Any picture in the list referenceablePictures does not include in its active entry in the reference picture list any picture in the same layer that is not located earlier in the list referenceablePictures.

[0061] Note that, therefore, even if the first picture in referenceablePictures is an EDRAP picture rather than an IRAP picture, its active entry in the reference picture list does not include any pictures from the same layer.

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

[0063] 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 shall be different.

[0064] edrap_leading_pictures_decodable_flag is equal to 1, indicating that both of the following constraints apply:

[0065] – Any picture that follows an EDRAP picture in decoding order and is in the same layer shall follow in output order any picture that precedes the EDRAP picture in decoding order and is in the same layer.

[0066] – Any picture in the same layer and following the EDRAP picture in decoding order and preceding the EDRAP picture in output order shall not include in its active entry in the reference picture list any pictures in the same layer and preceding the EDRAP picture in decoding order, except referenceablePictures.

[0067] edrap_leading_pictures_decodable_flag equal to 0 does not impose such constraints.

[0068] In bitstreams conforming to this version of this 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.

[0069] edrap_num_ref_rap_pics_minus1 plus 1 represents 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.

[0070] edrap_ref_rap_id[i] represents the RapPicId of the i-th RAP picture that can be included in the active entry of the reference picture list of the EDRAP picture. The i-th RAP picture should be the IRAP picture associated with the current EDRAP picture, or the EDRAP picture associated with the same IRAP picture as the current EDRAP picture.

[0071] 2.4.3 EDRAP sample groups and associated external stream track references

[0072] An amendment to the ISOBMFF standard is under development. The draft specification for this amendment includes the specification of the EDRAP sample set and the associated external flow track reference.

[0073] The specifications of these two ISOBMFF features are as follows.

[0074] 3.1 Definition ...

[0076] 3.2 Abbreviations

[0077] EDRAP extension relies on random access points

[0078] 8.3.3.4 Associated external stream track reference

[0079] A track reference of type "aest" (meaning "associated external stream track") MAY be included within a video track, referencing the associated video track. When present, a TrackReferenceTypeBox with reference_type equal to "aest" SHOULD contain only the track identifier, and SHOULD NOT contain any track group identifiers.

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

[0081] – A video track shall have at least one sample containing an EDRAP picture.

[0082] – For each sample sample A in a video track containing an EDRAP picture, there shall be one and only one sample B in the associated video track that has the same decoding time as sample A, and multiple consecutive samples starting from sample B on the associated video track shall contain only all pictures that are not contained in the video track containing sample A and that are required for random access from the EDRAP picture contained in sample A.

[0083] Each sample in the reference track shall be identified as a sync sample. The referenced track header flags shall have both track_in_movie and track_in_preview set to 0.

[0084] Each reference track should use a limiting scheme as follows:

[0085] 1) At least one of every sample entry of a track shall have sample entry type equal to "resv".

[0086] Note 1: When a track has been through multiple transformations, "resv" does not have to be the sample entry type of the SampleEntry directly contained in the SampleDescriptionBox.

[0087] 2) The unconverted sample entry types are stored in the OriginalFormatBox contained in the RestrictedSchemeInfoBox.

[0088] 3) The scheme_type field in the SchemeTypeBox (located in the RestrictedSchemeInfoBox) is equal to "aest", indicating that the samples in the track may contain more than one codec picture.

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

[0090] 10.11 Extended DRAP (EDRAP) Sample Group

[0091] 10.11.1 Definitions

[0092] This sample group is similar to the DRAP sample group specified in subclause 10.8; however, it enables more flexible cross-RAP referencing.

[0093] An EDRAP sample is a sample such that all samples following the preceding sample in decoding order and output order can be correctly decoded if the closest SAP sample of type 1, 2, or 3 preceding the EDRAP sample and zero or more other identified EDRAP samples preceding the EDRAP sample in decoding order are available for reference.

[0094] 10.11.2 Syntax

[0095]

[0096] 10.11.3 Semantics

[0097] edrap_type is a non-negative integer. When edrap_type is in the range 1 to 3, it indicates the SAP_type (as specified in Annex I) to which the EDRAP sample would have corresponded if the EDRAP sample had not depended on the closest previous SAP or other EDRAP samples. Other type values ​​are reserved.

[0098] num_ref_sap_or_edrap_samples_minus1 plus 1 represents the number of samples in the previous SAP or EDRAP samples that precede the EDRAP sample in decoding order and that need to be referenced when decoding starts from the EDRAP sample in order to enable correct decoding of the EDRAP sample and all samples that follow the EDRAP sample in decoding order and output order. NOTE: For EDRAP samples that are also DRAP samples, the value of num_ref_sap_or_edrap_samples_minus1 is equal to 0.

[0099] The reserved value shall be equal to 0. The semantics of this subclause applies only to sample group description entries with a reserved value equal to 0. When parsing this sample group, the parser shall allow and ignore sample group description entries with a reserved value greater than 0.

[0100] ref_sap_or_edrap_idx_delta[i] represents the i-th required previous SAP or EDRAP sample of the current EDRAP sample. Let the SAP or EDRAP sample list associated with a SAP sample of type 1, 2, or 3 be the SAP sample and all EDRAP samples after this SAP sample and before the next SAP sample (if any). The SAP_or_EDRAP sample index is defined as the index of the 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 EDRAN sample before this 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 this EDRAN sample in decoding order, and so on.

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

[0102] There are some problems in the design of the storage part of EDRAP-based video encoding and decoding, storage, and streaming. The EDRAP specification stipulates that for each sample denoted as sample A in a video track containing an EDRAP picture, there should be one and only one sample in the associated video track that has the same decoding time as sample A, denoted as sample B. In addition, starting from sample B, multiple consecutive samples in the associated video track should only contain all pictures that are not included in the video track containing sample A and are required for random access from the EDRAP picture included in sample A. However, the number of consecutive samples that meet this condition is not specified. Therefore, in order to randomly access a video track from an EDRAP picture, the file parser may have to feed sample B and all subsequent samples in the associated video track to the file player.

[0103] 4. List of solutions and implementation examples

[0104] In order to solve the above problems, the methods summarized as follows are disclosed. The present invention should be regarded as an example to explain the general concept and should not be interpreted narrowly. In addition, these inventions can be applied alone or in combination in any way.

[0105] Example 1

[0106] In one example, the specification may specify that an EDRAP sample is a sample for which all subsequent samples in decoding order and output order can be correctly decoded, provided that a required previous streaming access point (SAP) or EDRAP sample is available for reference when decoding the EDRAP sample and subsequent samples. In one example, the required previous SAP or EDRAP sample consists of one or more of a set of samples starting with the closest previous SAP sample (closestSapSample) of type 1, 2, or 3 in decoding order and including any EDRAP samples between the closestSapSample and the EDRAP sample in decoding order.

[0107] Example 2

[0108] In one example, a specification may specify that when a video track has a track reference of type "aest" that refers to a dependent track, then for each EDRAP sample sample A in the video track in the dependent track, there shall be one and only one sample sample B that has the same decoding time as sample A. Furthermore, sample B shall contain all pictures in the closestSapSample of sample A and any required previous SAP or EDRAP samples of sample A. When present, a TrackReferenceTypeBox with reference_type equal to "aest" shall contain only the track identifier and shall not contain any track group identifiers.

[0109] 5. Examples

[0110] The following are some example embodiments of some of the disclosed items summarized in Section 4 above. Most of the relevant parts that have been added or modified are shown in bold with underlining, and some deleted parts are shown in bold italics. There may be some other changes of an editorial nature, so they are not highlighted.

[0111] First embodiment

[0112] This embodiment is applicable to items 1 and 2 and all their subitems.

[0113] 3.1 Definition ...

[0115] An EDRAP sample is a sample that can be correctly decoded for all subsequent samples in decoding order and output order. This is provided that the required previous SAP or EDRAP samples are available when decoding the sample and subsequent samples, where the required Previously, a SAP or EDRAP sample consisted of one or more of a set of samples, which were in decoding order, type 1, 2 or 3, and includes in decoding order closestSapSample to all EDRAP samples between said sample. ...

[0117] 3.2 Abbreviations ...

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

[0121] 8.3.3.4 Associated external stream track reference

[0122] A track reference of type "aest" (meaning "associated external stream track") MAY be contained within a video track. When present, a TrackReferenceTypeBox with reference_type equal to "aest" SHOULD contain only track identifiers, and SHOULD NOT contain any track group identifiers. When a video track has a track reference of type "aest" that refers to an associated track, the following applies.

[0123] A video track shall have at least one EDRAP sample indicated by an EDRAP sample group.

[0124] For each EDRAP sample sample A in the video track, there shall be one and only one A sample B with the same decoding time as sample A, and sample B should contain all the closestSapSamples in sample A. There are pictures as well as the previous SAP or EDRAP samples required for Sample A. For each sample sample A in a video track containing an EDRAP picture, there shall be one and only one sample B in the associated video track that has the same decoding time as sample A, and multiple consecutive samples starting from sample B on the associated video track shall contain only all pictures that are not contained in the video track containing sample A and that are required for random access from the EDRAP picture contained in sample A.

[0125] Each sample in the associated track shall be identified as a sync sample. The associated track shall have header flags track_in_movie equal to 0 and track_in_preview equal to 0.

[0126] The associated track shall adopt the restricted scheme as follows. At least one sample entry type in each sample entry of the track shall be equal to "resv". NOTE 1: When a track undergoes multiple transformations, "resv" is not necessarily the sample entry type of the SampleEntry directly contained in the SampleDescriptionBox. The untransformed sample entry types are stored in the OriginalFormatBox contained in the RestrictedSchemeInfoBox. The scheme_type field in the SchemeTypeBox (located in the RestrictedSchemeInfoBox) is equal to "aest", indicating that samples in the track may contain more than one codec picture. Bit 0 of the flags field of the SchemeTypeBox is equal to 0, causing the value of (flags & 0x000001) to be equal to 0.

[0127] 10.11 Extended DRAP (EDRAP) Sample Group

[0128] 10.11.1 Definitions

[0129] This sample group is similar to the DRAP sample group specified in subclause 10.8; however, it provides more flexible inter-prediction references for pictures in the EDRAP sample and pictures in subsequent samples, thereby improving the coding and decoding efficiency of these pictures. NOTE 1: Similarly, for DRAP samples, EDRAP samples can only be combined with SAP samples of types 1, 2, and 3. NOTE 2: DRAP samples are always EDRAP samples.

[0130] 10.11.2 Syntax

[0131] class VisualEdrapEntry()

[0132] extends VisualSampleGroupEntry('edrp'){

[0133] unsigned int(3)edrap_type;

[0134] unsigned int(3)num_ref_edrap_pics;

[0135] unsigned int(26)reserved=0;

[0136] for(i=0;i <num_ref_edrap_pics;i++)

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

[0138] }

[0139] 10.11.3 Semantics

[0140] edrap_type is a non-negative integer. When edrap_type is in the range 1 to 3, it indicates the SAP_type (as specified in Annex I) to which the EDRAP sample would have corresponded if it had not depended on the closest previous SAP or other EDRAP samples. Other type values ​​are reserved.

[0141] num_ref_edrap_pics indicates the number of other EDRAP samples that precede the EDRAP sample in decoding order and that need to be referenced in order to enable correct decoding of the EDRAP sample and all samples that follow the EDRAP sample in decoding order and output order when decoding starts from the EDRAP sample. The reserved value shall be equal to 0. The semantics of this subclause applies only to sample group description entries with reserved value equal to 0. When parsing this sample group, the parser shall allow and ignore sample group description entries with reserved value greater than 0.

[0142] ref_edrap_idx_delta[i] represents the difference between the EDRAP sample index (i.e., the index into the list of all EDRAP samples in the sample group in decoding order) of this EDRAP sample and the EDRAP sample index of the i-th EDRAP sample that precedes this EDRAP sample in decoding order and that needs to be referenced when decoding starts from this EDRAP sample in order to be able to correctly decode the EDRAP sample and all samples that follow this EDRAP sample in decoding order and output order. A value of 1 indicates that the i-th EDRAP sample is the last EDRAP sample in the sample group and precedes this EDRAP sample in decoding order, a value of 2 indicates that the i-th EDRAP sample is the second to last EDRAP sample in the sample group and follows this EDRAP sample in decoding order, and so on.

[0143] 7. References

[0144] [1] ITU-T and ISO / IEC, “High Efficiency Video Codecs”, Rec. ITU-T H.265|ISO / IEC 23008-2 (effective version).

[0145] [2] J. Chen, E. Alshina, G. J. Sullivan, J.-R. Ohm, and J. Boyce, “Algorithmic Description of the Joint Exploration Test Model 7 (JEM7),” JVET-G1001, August 2017.

[0146] [3] Rec. ITU-T H.266 | ISO / IEC 23090-3, “Versatile Video Codec”, 2020.

[0147] [4] B. Bross, J. Chen, S. Liu, Y.-K. Wang (eds.), “Versatile Video Codec (Draft 10)”, JVET-S 2001.

[0148] [5] Rec. ITU-T Rec. H.274 | ISO / IEC 23002-7, “Generic Supplementary Enhancement Information Message for Coded Video Bitstreams”, 2020.

[0149] [6] J. Boyce, V. Drugeon, G. J. Sullivan, and Y.-K. Wang (eds.), “Generic Supplemental Enhancement Information Messages for Coded Video Bitstreams (Draft 5)”, JVET-S 2007.

[0150] [7] ISO / IEC 14496-12: “Information technology — Codecs of audiovisual objects — Part 12: ISO base media file format”.

[0151] [8] ISO / IEC 23009-1: "Information technology – Dynamic adaptive streaming over HTTP (DASH) – Part 1: Media presentation description and fragment format".

[0152] [9] ISO / IEC 14496-15: "Information technology — Coding and decoding of audiovisual objects — Part 15: Structured video carried as Network Abstraction Layer (NAL) units in the ISO base media file format."

[0153]

[10] ISO / IEC 23008-12: “Information technology – Efficient coding and media transport in heterogeneous environments – Part 12: Image file formats”.

[0154]

[11] J. Boyce, G. J. Sullivan, and Y.-K. Wang (eds.), “Additional SEI messages for VSEI (Draft 6)”, JVET-Y 2006.

[0155]

[12] ISO / IEC JTC 1 / SC 29 / WG 03 Output Document N0471, “Text AMD 1 Improved Brand Documentation and Other Improvements to CDAM ISO / IEC 14496-12:2021”, January 2022.

[0156]

[13] ISO / IEC JTC 1 / SC 29 / WG 03 Output Document N0486, “ISO / IEC 23009-1 Edition 5 AMD2EDRAP Streaming and Other Extended WDs”, January 2022.

[0157] Figure 6 4000. The 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. The 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), and wireless interfaces such as Wi-Fi or a cellular interface.

[0158] System 4000 may include a codec component 4004 that can implement various codecs or encoding methods described in this document. Codec component 4004 can reduce the average bit rate of the video from input 4002 to the output of codec component 4004 to generate a 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 can be stored or transmitted via connected communication, as represented by component 4006. The bitstream (or codec) representation of the stored or transmitted video received at input 4002 can be used by component 4008 to generate pixel values ​​or send to display interface 4010. The process of generating a user-viewable video from a 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 the codec tool or operation is used at the encoder, and the corresponding decoding tool or operation of the inverse codec result will be performed by the decoder.

[0159] 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 SATA (Serial Advanced Technology Attachment), PCI, IDE interfaces, etc. The technology described in this document may be embodied in various electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and / or video display.

[0160] Figure 7 4106 is a block diagram of an example video processing device 4100. Device 4100 can be used to implement one or more methods described herein. Device 4100 can be embodied in a smartphone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. Device 4100 may include one or more processors 4102, one or more memories 4104, and video processing circuitry 4106. Processor 4102 may be configured to implement one or more methods described in this document. Memory (multiple memories) 4104 may be used to store data and code for implementing the methods and techniques described herein. Video processing circuitry 4106 may be used to implement some of the techniques described in this document in hardware circuitry. In some embodiments, video processing circuitry 4106 may be at least partially included in processor 4102, such as a graphics coprocessor.

[0161] Figure 8 4200 is a flow chart of an example method 4200 for visual media processing. The method 4200 determines an EDRAP sample at step 4202. An EDRAP sample is a sample for which all subsequent samples in decoding order and output order can be correctly decoded, provided that a required previous streaming access point (SAP) or EDRAP sample is available for reference when decoding the EDRAP sample and subsequent samples. At step 4204, conversion between visual media data and a media data file is performed based on the EDRAP sample.

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

[0163] Fig. 943 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 encoding 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.

[0164] Source device 4310 may include video source 4312, video encoder 4314 and input / output (I / O) interface 4316. Video source 4312 may include a source such as a video capture device, an interface for receiving video data from a video content provider, and / or 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 bit stream. The bit stream may include a bit sequence that forms a codec representation of video data. The bit stream may include codec pictures and related data. Codec pictures are codec representations of pictures. Related 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. Encoded video data may be directly transmitted to target device 4320 via network 4330 via I / O interface 4316. Encoded video data may also be stored on storage medium / server 4340 for access by target device 4320.

[0165] 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 coded video data from source device 4310 or storage medium / server 4340. The video decoder 4324 may decode the coded 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, and the target device 4320 may be configured to interface with an external display device.

[0166] 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.

[0167] Fig.10 is a block diagram showing an example of a video encoder 4400, which may be Fig. 94300. Video encoder 4400 may 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 may be shared between various components of video encoder 4400. In some examples, the processor may be configured to perform any or all of the techniques described in the present disclosure.

[0168] The functional components of the video encoder 4400 may include a segmentation unit 4401, a prediction unit 4402, 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, and the prediction unit may include a mode selection unit 4403, a motion estimation unit 4404, a motion compensation unit 4405 and an intra-frame prediction unit 4406.

[0169] In other examples, the video encoder 4400 may include more, fewer, or different functional components. In one 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 where the current video block is located.

[0170] 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 purposes of explanation.

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

[0172] The mode selection unit 4403 may select one of the coding modes (intra or inter), for example, based on the error result, and provide the resulting intra or inter coded block to the residual generation unit 4407 to generate residual block data and 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 a combination of intra and inter prediction (CIIP) modes, where the prediction is based on an inter prediction signal and an intra prediction signal. In the case of inter prediction, the mode selection unit 4403 may also select a resolution of the motion vector for the block (e.g., sub-pixel or integer pixel precision).

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

[0174] 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.

[0175] In some examples, the motion estimation unit 4404 may perform unidirectional prediction for the current video block, and the motion estimation unit 4404 may search the reference pictures of list 0 or list 1 to find the reference video block of the current video block. The motion estimation unit 4404 may then generate a reference index indicating the reference picture containing the reference video block in list 0 or list 1 and a motion vector indicating the 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 the 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.

[0176] In other examples, the motion estimation unit 4404 may perform bidirectional prediction for 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. Then, the motion estimation unit 4404 may generate a reference index indicating a reference picture containing a reference video block in list 0 and list 1 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 the 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.

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

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

[0179] 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.

[0180] 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.

[0181] 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 a predicted video block and various syntax elements.

[0182] The residual generating unit 4407 may generate residual data of the current video block by subtracting the predicted video block 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.

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

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

[0185] 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.

[0186] 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.

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

[0188] 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.

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

[0190] 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, a reconstruction unit 4506, and a buffer 4507. In some examples, the video decoder 4500 may perform a decoding process that is substantially the opposite of the encoding process described with respect to the video encoder 4400.

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

[0192] The motion compensation unit 4502 may generate a motion compensated block, possibly performing interpolation based on an interpolation filter. An identifier of an interpolation filter for use with sub-pixel precision may be included in a syntax element.

[0193] 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.

[0194] The motion compensation unit 4502 can use some syntax information to determine the size of blocks used to encode frames and / or 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.

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

[0196] 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 blocking artifacts. The decoded video block is then stored in a buffer 4507, which provides reference blocks for subsequent motion compensation / intra prediction and also produces a decoded video for presentation on a display device.

[0197] Fig.12 is a schematic diagram of an example encoder 4600. The encoder 4600 is suitable for implementing techniques for VVC. The encoder 4600 includes three in-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, which 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, using codec-side information that signals the offset and filter coefficients. The ALF 4606 is located at the last processing stage of each picture and can be viewed as a tool that attempts to capture and repair artifacts created by previous stages.

[0198] 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 a transform (T) component 4614 and a quantization (Q) component 4616 to generate quantized residual transform coefficients, which are fed to an 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 an inverse quantization component 4620, an inverse transform component 4622, and a 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 the images are stored in the reference picture buffer 4612 .

[0199] Next, a list of preferred solutions is provided for some examples.

[0200] The following solutions show examples of the techniques discussed in this article.

[0201] The following solution shows an example implementation of the technique discussed in the previous section (eg, item 1).

[0202] 1. A method of processing visual media data (e.g., Figure 8 The method 4200 shown in FIG. 4 comprises: determining (4202) an extended dependent random access point (EDRAP) sample, wherein the EDRAP sample is a sample for which all subsequent samples in decoding order and output order can be correctly decoded, provided that when decoding the EDRAP sample and subsequent samples, a required previous streaming access point (SAP) or EDRAP sample is available for reference; and performing (4204) conversion between visual media data and a media data file based on the EDRAP sample.

[0203] 2. The method according to solution 1, wherein the closest previous SAP sample of type 1, 2 or 3 and zero or more previous EDRAP samples are referred to as the required previous SAP sample and the EDRAP sample required by the EDRAP sample.

[0204] The following solution shows an example implementation of the technique discussed in the previous section (eg, item 2).

[0205] 3. A method for processing visual media data, comprising: determining Extended Dependent Random Access Point (EDRAP) samples, wherein, when a video track has a track reference of type "aest" that refers to a related track, for each EDRAP sample in the video track denoted as sample A, there should be one and only one sample in the related track having the same decoding time as sample A, denoted as sample B; and performing conversion between visual media data and a media data file based on the EDRAP samples.

[0206] 4. A method according to any one of solutions 1 to 3, wherein sample B shall contain all pictures in the closestSapSample of sample A and the required previous SAP or EDRAP samples of sample A.

[0207] 5. A device for processing visual media data, comprising: a processor; and a non-volatile memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform a method according to any one of solutions 1 to 4.

[0208] 6. 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 according to any one of solutions 1 to 4.

[0209] 7. A non-transitory computer-readable recording medium storing a media data file, the media data file being generated by a method executed by a media processing device, wherein the method comprises: determining an extended dependent random access point (EDRAP) sample, wherein the EDRAP sample is a sample for which all subsequent samples in decoding order and output order can be correctly decoded, provided that a required previous streaming access point (SAP) or EDRAP sample is available for reference when decoding the EDRAP sample and subsequent samples; and generating a media data file based on the determination.

[0210] 8. A method for storing a media data file of a video, comprising: determining an extended dependent random access point (EDRAP) sample, wherein the EDRAP sample is a sample for which all subsequent samples in a decoding order and an output order can be correctly decoded, provided that a required previous streaming access point (SAP) or EDRAP sample is available for reference when decoding the EDRAP sample and subsequent samples; generating a media data file based on the determination; and storing the media data file in a non-transitory computer-readable recording medium.

[0211] 9. A method, apparatus or system described in this document.

[0212] 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 use the format rules to parse the syntax elements in the codec representation to generate decoded video, knowing the presence or absence of the syntax elements according to the format rules.

[0213] In this document, 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. The bitstream representation of the current video block may, for example, correspond to bits located at the same position or distributed at different positions within the bitstream, as defined by the syntax. For example, a macroblock may be encoded based on error residual values ​​of a transform and codec, and may also use bits in the header and other fields in the bitstream. In addition, during conversion, the decoder may parse the bitstream based on this determination with the knowledge of the presence or absence of some fields, 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.

[0214] The disclosed solutions, examples, embodiments, modules and functional operations and other solutions, examples, embodiments, modules and functional operations described in this document can be implemented in digital electronic circuits or computer software, firmware or hardware, including the structures disclosed in this document and their structural equivalents, or a combination of one or more of them. The disclosed embodiments and other embodiments can be implemented as one or more computer program products, that is, one or more modules of computer program instructions, which are encoded on a computer-readable medium for execution by a data processing device or controlling the operation of the data processing device. The computer-readable medium can 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 of them. The term "data processing device" covers 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 under consideration, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagation signal is an artificially generated signal, such as a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device.

[0215] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or 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 containing other programs or data (e.g., one or more scripts stored in a markup language document), a single file dedicated to the program under consideration, or multiple coordinated files (e.g., files storing one or more modules, subroutines, or portions of code). A computer program may be deployed to execute on one computer or on multiple computers located in one location or distributed in multiple locations and interconnected by a communication network.

[0216] The processes and logic flows described in this document can be performed by executing one or more computer programs by one or more programmable processors to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0217] By way of example, processors suitable for executing computer programs include both 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. In general, a computer may also include or be operably coupled to one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, receive data from them or transfer data to them, or both. However, a computer need not have such a device. 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) disks. The processor and memory may be supplemented by or incorporated in a dedicated logic circuit.

[0218] Although this patent document contains many details, these should not be interpreted as limitations on the scope of any subject matter or what may be claimed, but rather as descriptions of features that may be unique to a particular embodiment of a particular technology. Certain features described in this patent document in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented individually in multiple implementations or in any suitable sub-combination. In addition, although the features may be described above as working in certain combinations and even initially claimed as such, in some cases, one or more features in the claimed combination may be cut out from the combination, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0219] Similarly, although operations are depicted in a particular order in the drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order, or that all illustrated operations be performed to achieve the desired results. In addition, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0220] Only a few implementations and examples are described, and other implementations, enhancements, and variations may be made based on what is described and illustrated in this patent document.

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

[0222] 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 should be considered 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.

[0223] 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. Other examples of changes, substitutions, and modifications may be determined by those skilled in the art and may be made without departing from the spirit and scope of the present disclosure.

Claims

1. A method for processing visual media data, comprising: determining an extended dependent random access point (EDRAP) sample, wherein the EDRAP sample is a sample for which all subsequent samples in decoding order and output order can be correctly decoded if a required previous streaming access point (SAP) or EDRAP sample is available for reference when decoding the EDRAP sample and the subsequent samples; and Conversion between visual media data and media data files is performed based on the EDRAP samples.

2. The method according to claim 1, wherein: The required previous SAP or EDRAP sample comprises one or more of a group of samples starting with the closest previous SAP sample (closestSapSample) of type 1, 2 or 3 in decoding order and including any EDRAP samples between the closestSapSample and the EDRAP sample in decoding order.

3. The method according to claim 1, wherein: When the media track containing the EDRAP sample has a track reference of type "aest" that refers to a related track, for each EDRAP sample denoted sample A in the media track, there shall be one and only one sample in the related track that has the same decoding time as sample A, denoted sample B.

4. The method according to claim 3, wherein: When the media track includes a TrackReferenceTypeBox with reference_type equal to "aest", the TrackReferenceTypeBox shall contain only the track identifier and shall not contain any track group identifiers.

5. The method according to claim 3, wherein: Sample B shall contain all media data of the closestSapSample of type 1, 2 or 3 in decoding order of sample A, and any required previous SAP or EDRAP samples of sample A.

6. The method according to claim 1, wherein: The converting includes generating the media data file from the visual media data.

7. The method according to claim 1, wherein: The converting includes parsing the media data file into the visual media data.

8. A device for processing visual media data, comprising: one or more processors; as well as one or more non-transitory memories having instructions thereon, wherein the instructions, when executed by the one or more processors, cause the one or more processors to: determining an extended dependent random access point (EDRAP) sample, wherein the EDRAP sample is a sample for which all subsequent samples in decoding order and output order can be correctly decoded if a required previous streaming access point (SAP) or EDRAP sample is available for reference when decoding the EDRAP sample and the subsequent samples; and Conversion between visual media data and media data files is performed based on the EDRAP samples.

9. The device according to claim 8, wherein: The required previous SAP or EDRAP sample comprises one or more of a group of samples starting with the closest previous SAP sample (closestSapSample) of type 1, 2 or 3 in decoding order and including any EDRAP samples between the closestSapSample and the EDRAP sample in decoding order.

10. The device according to claim 8, wherein: When the media track containing the EDRAP sample has a track reference of type "aest" that refers to a related track, for each EDRAP sample denoted sample A in the media track, there shall be one and only one sample in the related track that has the same decoding time as sample A, denoted sample B.

11. The device according to claim 10, wherein: When the media track includes a TrackReferenceTypeBox with reference_type equal to "aest", the TrackReferenceTypeBox shall contain only the track identifier and shall not contain any track group identifiers.

12. The device according to claim 10, wherein: Sample B shall contain all media data of the closestSapSample of type 1, 2 or 3 in decoding order of sample A, and any required previous SAP or EDRAP samples of sample A.

13. A non-transitory computer-readable medium, comprising a computer program product for use with 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 one or more processors of the video codec device, the video codec device is caused to: Determine an Extended Dependent Random Access Point (EDRAP) sample, where, The EDRAP sample is a sample for which all subsequent samples in decoding order and output order can be correctly decoded, provided that a required previous stream access point (SAP) or EDRAP sample is available for reference when decoding the EDRAP sample and the subsequent samples; as well as Conversion between visual media data and media data files is performed based on the EDRAP samples.

14. The non-transitory computer readable medium of claim 13, wherein: The required previous SAP or EDRAP sample comprises one or more of a group of samples starting with the closest previous SAP sample (closestSapSample) of type 1, 2 or 3 in decoding order and including any EDRAP samples between the closestSapSample and the EDRAP sample in decoding order.

15. The non-transitory computer readable medium of claim 13, wherein: When the media track containing the EDRAP sample has a track reference of type "aest" that refers to a related track, for each EDRAP sample denoted sample A in the media track, there shall be one and only one sample in the related track that has the same decoding time as sample A, denoted sample B.

16. The non-transitory computer readable medium of claim 15, wherein: When the media track includes a TrackReferenceTypeBox with reference_type equal to "aest", the TrackReferenceTypeBox shall contain only the track identifier and shall not contain any track group identifiers.

17. The non-transitory computer readable medium of claim 15, wherein: Sample B shall contain all media data of the closestSapSample of type 1, 2 or 3 in decoding order of sample A, and any required previous SAP or EDRAP samples of sample A.

18. A non-transitory computer-readable recording medium storing a media data file, wherein the media data file is generated by a method executed by a media processing device, wherein: The method comprises: determining an extended dependent random access point (EDRAP) sample, wherein the EDRAP sample is a sample for which all subsequent samples in decoding order and output order can be correctly decoded if a required previous streaming access point (SAP) or EDRAP sample is available for reference when decoding the EDRAP sample and the subsequent samples; and The media data file is generated based on the determination.

19. The non-transitory computer readable recording medium according to claim 18, wherein: The required previous SAP or EDRAP sample comprises one or more of a group of samples starting with the closest previous SAP sample (closestSapSample) of type 1, 2 or 3 in decoding order and including any EDRAP samples between the closestSapSample and the EDRAP sample in decoding order.

20. The non-transitory computer readable recording medium according to claim 18, wherein When the media track containing the EDRAP sample has a track reference of type "aest" that refers to a related track, for each EDRAP sample denoted sample A in the media track, there shall be one and only one sample in the related track that has the same decoding time as sample A, denoted sample B.

21. The non-transitory computer readable recording medium according to claim 20, wherein: When the media track includes a TrackReferenceTypeBox with reference_type equal to "aest", the TrackReferenceTypeBox shall contain only the track identifier and shall not contain any track group identifiers.

22. The non-transitory computer readable recording medium according to claim 20, wherein: Sample B shall contain all media data of the closestSapSample of type 1, 2 or 3 in decoding order of sample A, and any required previous SAP or EDRAP samples of sample A.

Images