General constraint information and signaling of syntax elements in video coding

Abstract

A method, apparatus, and non-transitory computer-readable storage medium are provided for decoding video data. A decoder receives a bitstream associated with video data. The decoder obtains syntax elements from the bitstream. These syntax elements indicate whether a stripe is a bidirectional predictive stripe (B-strip). The decoder decodes the video data based on these syntax elements.

Description

[0001] Cross-references to related applications

[0002] This application is based on and claims priority to provisional application No. 63 / 027,950, filed on 20 May 2020, and provisional application No. 63 / 030,295, filed on 26 May 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to video encoding / decoding and compression. More specifically, this application relates to systems and methods for general constraint information and signaling for syntax elements in video encoding / decoding. Background Technology

[0004] Various video codec techniques can be used to compress video data. Video codecs are performed according to one or more video codec standards. Examples of video codec standards include Universal Video Coding (VVC), Joint Explore Test Model (JEM), High Efficiency Video Coding (H.265 / HEVC), High-Level Video Coding (H.264 / AVC), and Moving Picture Experts Group (MPEG) coding. Video codecs typically use prediction methods that utilize redundancy present in video images or sequences (such as inter-frame prediction, intra-frame prediction, etc.). A key goal of video codec techniques is to compress video data to a lower bitrate while avoiding or minimizing video quality degradation.

[0005] The following sections will elaborate on some background knowledge related to video encoding / decoding and reference image management. Summary of the Invention

[0006] Embodiments of this disclosure provide methods and apparatus for syntax in video encoding and decoding.

[0007] According to a first aspect of this disclosure, a method for decoding video data is provided. The method may include a decoder receiving a bitstream associated with the video data. The decoder also obtains syntax elements from the bitstream. The decoder further decodes the video data based on the syntax elements.

[0008] It will be understood that the above general description and the following detailed description are merely illustrative and not intended to limit this disclosure. Attached Figure Description

[0009] The accompanying drawings, which are incorporated in and form part of this specification, illustrate examples according to this disclosure and, together with this description, serve to explain the principles of this disclosure.

[0010] Figure 1 This is a block diagram of an encoder according to an example of this disclosure.

[0011] Figure 2 This is a block diagram of a decoder according to an example of this disclosure.

[0012] Figure 3A This is a diagram illustrating block partitioning in a multi-type tree structure according to an example of this disclosure.

[0013] Figure 3B This is a diagram illustrating block partitioning in a multi-type tree structure according to an example of this disclosure.

[0014] Figure 3C This is a diagram illustrating block partitioning in a multi-type tree structure according to an example of this disclosure.

[0015] Figure 3D This is a diagram illustrating block partitioning in a multi-type tree structure according to an example of this disclosure.

[0016] Figure 3E This is a diagram illustrating block partitioning in a multi-type tree structure according to an example of this disclosure.

[0017] Figure 4 This is a diagram showing an example of a CTU segmentation according to the present disclosure.

[0018] Figure 5A This is a diagram illustrating a multi-type tree segmentation pattern according to an example of this disclosure.

[0019] Figure 5B This is a diagram illustrating a multi-type tree segmentation pattern according to an example of this disclosure.

[0020] Figure 5C This is a diagram illustrating a multi-type tree segmentation pattern according to an example of this disclosure.

[0021] Figure 5D This is a diagram illustrating a multi-type tree segmentation pattern according to an example of this disclosure.

[0022] Figure 6 This is a diagram illustrating a progressive intra-frame refresh according to an example of this disclosure.

[0023] Figure 7 This is an example of a method for decoding video data according to this disclosure.

[0024] Figure 8 This is a diagram illustrating a computing environment coupled with a user interface, according to an example of this disclosure. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0026] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in this disclosure and the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein is intended to represent and include any or all possible combinations of one or more of the associated listed items.

[0027] It should be understood that although the terms “first,” “second,” “third,” etc., may be used herein to describe various types of information, such information should not be limited by these terms. These terms are used only to distinguish one type of information from another. For example, without departing from the scope of this application, first information may be referred to as second information; similarly, second information may be referred to as first information. As used herein, depending on the context, the term “if” may be understood to mean “when,” “at,” or “in response to a judgment.”

[0028] Conceptually, the video codec standards mentioned above are similar. For example, they all use block-based processing and share similar video codec diagrams to achieve video compression. Figure 1 A typical encoder block diagram for these standards is shown.

[0029] Figure 1 An overall diagram of a block-based video encoder for VVC is shown. Specifically, Figure 1 A typical encoder 100 is shown. The encoder 100 has a video input 110, motion compensation 112, motion estimation 114, intra / inter-frame mode decision 116, block prediction value 140, adder 128, transform 130, quantization 132, prediction related information 142, intra-frame prediction 118, picture buffer 120, inverse quantization 134, inverse transform 136, adder 126, memory 124, loop filter 122, entropy coding 138, and bitstream 144.

[0030] In encoder 100, video frames are divided into multiple video blocks for processing. For each given video block, a prediction is formed based on either an inter-frame prediction method or an intra-frame prediction method.

[0031] The prediction residual, representing the difference between the current video block (a portion of video input 110) and its predicted value (a portion of block prediction value 140), is sent from adder 128 to transform 130. Transform coefficients are then sent from transform 130 to quantization 132 for entropy reduction. The quantization coefficients are then fed to entropy coding 138 to generate a compressed video bitstream. Figure 1 As shown, prediction-related information 142 from the intra / inter-frame mode decision 116, such as video block partitioning information, motion vectors (MV), reference picture indexes, and intra-frame prediction modes, is also fed into and stored in the compressed bitstream 144 via entropy coding 138. The compressed bitstream 144 includes the video bitstream.

[0032] In encoder 100, additional circuitry associated with the decoder is required to reconstruct pixels for prediction purposes. First, the prediction residual is reconstructed via inverse quantization 134 and inverse transform 136. This reconstructed prediction residual is then combined with block prediction values ​​140 to generate unfiltered reconstructed pixels for the current video block.

[0033] Spatial prediction (or "intra-frame prediction") uses pixels from samples (called reference samples) of coded neighboring blocks in the same video frame as the current video block to predict the current video block.

[0034] Timing prediction (also known as "inter-frame prediction") uses reconstructed pixels from encoded video frames to predict the current video block. Timing prediction reduces the inherent temporal redundancy in the video signal. The timing prediction signal for a given coding unit (CU) or coding block is typically represented by one or more motion vectors (MVs) that indicate the amount and direction of motion between the current CU and its timing reference. Additionally, if multiple reference frames are supported, a reference frame index is sent to identify which reference frame in the reference frame library the timing prediction signal originates from.

[0035] Motion estimation 114 receives video input 110 and signals from image buffer 120 and outputs motion estimation signals to motion compensation 112. Motion compensation 112 receives video input 110, signals from image buffer 120, and motion estimation signals from motion estimation 114 and outputs motion compensation signals to intra / inter-frame mode decision 116.

[0036] After performing spatial and / or temporal prediction, the intra / inter-frame mode decision 116 in encoder 100 selects the optimal prediction mode based on a rate-distortion optimization method. The block prediction value 140 is then subtracted from the current video block, and the resulting prediction residual is decorrelated using transform 130 and quantization 132. The resulting quantized residual coefficients are dequantized by inverse quantization 134 and inverse transformed by inverse transform 136 to form the reconstructed residual, which is then added back to the prediction block to form the reconstructed signal of the CU. Loop filtering 122 (such as deblocking filter, Sample Adaptive Offset (SAO), and / or Adaptive Loop Filter (ALF)) can be further applied to the reconstructed CU before it is placed into the reference picture library of picture buffer 120 and used for encoding and decoding future video blocks. To form the output video bitstream 144, the coding mode (inter-frame or intra-frame), prediction mode information, motion information, and quantized residual coefficients are sent to entropy coding unit 138 for further compression and packing to form the bitstream.

[0037] In this encoder, video frames are segmented into blocks for processing. For each given video block, a prediction is formed based on either inter-frame prediction or intra-frame prediction. In inter-frame prediction, a prediction can be formed based on pixels from previously reconstructed frames, through motion estimation and motion compensation. In intra-frame prediction, a prediction can be formed based on reconstructed pixels in the current frame. Through mode decision, the optimal prediction value can be selected to predict the current block.

[0038] The prediction residual (i.e., the difference between the current video block and its predicted value) is sent to the transform module. The transform coefficients are then sent to the quantization module for entropy reduction. The quantized coefficients are then fed into the entropy coding module to generate a compressed video bitstream.

[0039] like Figure 1 As shown above, prediction-related information from the inter-frame prediction module and / or intra-frame prediction module, such as block segmentation information, motion vectors, reference image indexes, and intra-frame prediction modes, is also fed into the bitstream through the entropy coding module.

[0040] In this encoder, a module associated with the decoder is also needed to reconstruct pixels for prediction. First, the prediction residual is reconstructed through inverse quantization and inverse transform. This reconstructed prediction residual is combined with the block prediction value to generate the unfiltered reconstructed pixels for the current block.

[0041] To improve encoding / decoding efficiency and visual quality, loop filters are commonly used. For example, deblocking filters are used in AVC, HEVC, and the current VVC. In HEVC, an additional loop filter called Sample Adaptive Offset (SAO) is defined to further improve encoding / decoding efficiency. In the latest VVC, another loop filter called Adaptive Loop Filter (ALF) is under active investigation and is very likely to be included in the final standard.

[0042] Figure 2 A block diagram of a typical decoder used for these standards is shown. It can be seen that it is almost identical to the reconstruction-related parts of the encoder. Specifically, Figure 2 A block diagram of a typical decoder 200 is shown. The decoder 200 has a bitstream 210, entropy decoding 212, dequantization 214, inverse transform 216, adder 218, intra / inter-frame mode selection 220, intra-frame prediction 222, memory 230, loop filter 228, motion compensation 224, image buffer 226, prediction-related information 234, and video output 232.

[0043] Decoder 200 is similar to that located in Figure 1 The reconstruction-related part is located in the encoder 100. In the decoder 200, the input video bitstream 210 is first decoded by entropy decoding 212 to derive the quantized coefficient levels and prediction-related information. The quantized coefficient levels are then processed by inverse quantization 214 and inverse transform 216 to obtain the reconstructed prediction residuals. The block prediction mechanism implemented in the intra / inter-frame mode selector 220 is configured to perform intra-frame prediction 222 or motion compensation 224 based on the decoded prediction information. A set of unfiltered reconstructed pixels is obtained by adding the reconstructed prediction residuals from inverse transform 216 to the prediction output generated by the block prediction mechanism using adder 218.

[0044] The reconstructed block can be further processed by a loop filter 228 before being stored in the image buffer 226, which serves as a reference image memory. The reconstructed video in the image buffer 226 can be sent to drive the display device and is used to predict future video blocks. With the loop filter 228 enabled, filtering operations are performed on these reconstructed pixels to derive the final reconstructed video output 232.

[0045] In this decoder, the bitstream is first decoded by an entropy decoding module to derive quantized coefficient levels and prediction-related information. Then, the quantized coefficient levels are processed by an inverse quantization and inverse transform module to obtain the reconstructed prediction residuals. Block prediction values ​​are formed through intra-frame prediction or motion compensation processes based on the decoded prediction information. Unfiltered reconstructed pixels are obtained by adding the reconstructed prediction residuals to the block prediction values. With the loop filter enabled, these pixels are filtered to derive the final reconstructed video for output.

[0046] The first version of the HEVC standard was completed in October 2013, offering approximately 50% bitrate savings or equivalent perceptual quality compared to its predecessor, H.264 / MPEG AVC. While HEVC offered significant codec improvements over its predecessor, evidence suggests that even higher coding efficiency can be achieved using additional codec tools. Building on this, both VCEG and MPEG began exploring new codec technologies for future video coding standardization. In October 2015, ITU-TVECG and ISO / IEC MPEG established a Joint Video Exploration Team (JVET) to conduct significant research on advanced technologies that could significantly improve coding efficiency. JVET maintains a reference software called the Joint Exploration Model (JEM) by integrating several additional codec tools on top of the HEVC Test Model (HM).

[0047] In October 2017, the ITU-T and ISO / IEC issued a joint solicitation of proposals (CfP) for video compression with capabilities exceeding HEVC. In April 2018, at the 10th JVET meeting, 23 CfP responses were received and evaluated, demonstrating compression efficiency improvements of approximately 40% compared to HEVC. Based on these evaluation results, JVET launched a new project to develop a next-generation video codec standard called Multifunctional Video Coding (VVC). That same month, a reference software codebase called the VVC Test Model (VTM) was established to demonstrate a reference implementation of the VVC standard.

[0048] Like HEVC, VVC is built on a block-based hybrid video codec framework. Figure 1A block diagram of a general block-based hybrid video coding system is presented. The input video signal is processed block by block (called a coding unit (CU)). In VTM-1.0, a CU can be up to 128x128 pixels. However, unlike HEVC, which only partitions blocks based on quadtrees, in VVC, a coding tree unit (CTU) is split into multiple CUs to accommodate different local features based on quadtrees / binary trees / tritrees. Furthermore, the concept of multiple partitioned unit types in HEVC is removed; that is, there is no longer a separation of CUs, prediction units (PUs), and transform units (TUs) in VVC. Instead, each CU is always used as the basic unit for prediction and transform without further partitioning. In the multi-type tree structure, a CTU is first partitioned by a quadtree structure. Then, the leaf nodes of each quadtree can be further partitioned using binary and ternary tree structures.

[0049] Figure 3A A diagram illustrating block quadtree segmentation in a multi-type tree structure according to this disclosure is shown.

[0050] Figure 3B A diagram illustrating block vertical binary tree segmentation in a multi-type tree structure according to this disclosure is shown.

[0051] Figure 3C A diagram illustrating block-level binary tree segmentation in a multi-type tree structure according to this disclosure is shown.

[0052] Figure 3D A diagram illustrating block vertical ternary tree segmentation in a multi-type tree structure according to this disclosure is shown.

[0053] Figure 3E A diagram illustrating block-level ternary tree partitioning in a multi-type tree structure according to this disclosure is shown.

[0054] like Figures 3A-3E As shown, there are five types of segmentation: quadruple segmentation, horizontal binary segmentation, vertical binary segmentation, horizontal triple segmentation, and vertical triple segmentation. Figure 1In the encoder, spatial and / or temporal prediction can be performed. Spatial prediction (or "intra-frame prediction") uses pixels from samples (called reference samples) of coded adjacent blocks in the same video picture / strip to predict the current video block. Spatial prediction reduces the spatial redundancy inherent in the video signal. Temporal prediction (also known as "inter-frame prediction" or "motion-compensated prediction") uses reconstructed pixels from coded video pictures to predict the current video block. Temporal prediction reduces the temporal redundancy inherent in the video signal. The temporal prediction signal for a given CU is typically transmitted via a signal consisting of one or more motion vectors (MVs) indicating the amount and direction of motion between the current CU and its temporal reference. Additionally, if multiple reference pictures are supported, a reference picture index is sent to identify which reference picture in the reference picture storage the temporal prediction signal originates from. After spatial and / or temporal prediction, a mode decision block in the encoder selects the best prediction mode, for example, based on a rate-distortion optimization method. This prediction block is then subtracted from the current video block; and the prediction residual is decorrelated and quantized using a transform. The quantized residual coefficients are dequantized and inversely transformed to form the reconstructed residuals, which are then added back to the prediction block to form the reconstructed signal of the CU. Another loop filter, such as a deblocking filter, Sample Adaptive Offset (SAO), and Adaptive Loop Filter (ALF), can be applied to the reconstructed CU before it is placed into the reference picture memory and used to encode subsequent video blocks. To form the output video bitstream, the (inter-frame or intra-frame) encoding / decoding mode, prediction mode information, motion information, and quantized residual coefficients are sent to the entropy coding unit for further compression and packing to form the bitstream.

[0055] Figure 2 (As described above) A general block diagram of a block-based video decoder is given. First, the video bitstream is entropy-decoded in the entropy decoding unit. The encoding / decoding mode and prediction information are sent to the spatial prediction unit (if intra-frame coded) or the temporal prediction unit (if inter-frame coded) to form prediction blocks. These residual transform coefficients are sent to the inverse quantization unit and the inverse transform unit to reconstruct the residual block. The prediction block and the residual block are then added together. Further loop filtering can be applied to the reconstructed block before it is stored in the reference picture memory. The reconstructed video in the reference picture memory is then sent to drive the display device and used to predict subsequent video blocks.

[0056] Generally, the basic intra-prediction scheme used in VVC is the same as that in HEVC, with several modules further extended and / or improved, such as Matrix Weighted Intra-Prediction (MIP) coding mode, Intra-Segmentation-Partition (ISP) coding and decoding mode, Extended Intra-Prediction with Wide-Angle Intra-Direction, Position-Related Intra-Prediction Combination (PDPC), and 4-Tap Intra-Interpolation. The main focus of this disclosure is to improve the design of the existing general constraint information in the VVC standard. The relevant background information is described in detail in the following sections.

[0057] Like HEVC, VVC uses a bitstream structure based on NAL units. The encoded bitstream is divided into multiple NAL units, which should be smaller than the maximum transmission unit size when transmitted over a lossy packet network. Each NAL unit consists of a NAL unit header and a subsequent NAL unit payload. NAL units have two conceptual classifications. Video Coding Layer (VCL) NAL units contain encoded sample data, such as encoded stripe NAL units, while non-VCL NAL units contain metadata that typically belongs to more than one encoded picture, or whose association with a single encoded picture would be meaningless, such as parameter set NAL units, or information that is not needed during the decoding process, such as SEI NAL units.

[0058] VVC inherits the parameter set concept from HEVC, with some modifications and additions. A parameter set can be part of the video bitstream or received by the decoder through other means (including out-of-band transmission using a reliable channel, hard coding in the encoder and decoder, etc.). The parameter set contains an identifier that is referenced directly or indirectly from the stripe header, which will be discussed in detail later. This referencing process is called "activation." Depending on the parameter set type, activation occurs in each picture or each sequence. The concept of activation by reference was introduced, among other reasons, because implicit activation based on the position of this information in the bitstream (as is common with other syntax elements of video codecs) is not available in the case of out-of-band transmission.

[0059] Video Parameter Sets (VPSs) are introduced to convey information applicable to multiple layers and sublayers. VPSs are introduced to address these shortcomings and enable a clean and scalable high-level design for multi-layer codecs. Each layer of a given video sequence, regardless of whether they have the same or different Sequence Parameter Sets (SPSs), refers to the same VPS.

[0060] In VVC, the SPS contains information applicable to all stripes of the encoded video sequence. The encoded video sequence begins with the Instantaneous Decode Refresh (IDR), BLA, or CRA image, which is the first image in the bitstream and includes all subsequent images that are not IDR or BLA images. The bitstream consists of one or more encoded video sequences. The content of the SPS can be broadly categorized into six types: 1) Self-reference (its own ID); 2) Decoder operation point information (outline, level, image size, number of sublayers, etc.); 3) Flags enabling certain tools in the outline, and related codec tool parameters when tools are enabled; 4) Information limiting structural flexibility and transform coefficient encoding / decoding; 5) Temporal scalability controls; 6) Visual Usability Information (VUI), including HRD information.

[0061] For information related to decoder operation points in SPS, there is a list of constraint flags indicating properties that cannot be violated throughout the bitstream. These constraint flags are encapsulated in their own syntax structure, general_constraint_info(). The syntax and related semantics of general constraint information in the current VVC draft specification are described in Tables 1 and 2, respectively.

[0062] Table 1 General Constraint Information Syntax

[0063]

[0064]

[0065]

[0066] Table 2 General Constraint Information Semantics

[0067]

[0068]

[0069]

[0070]

[0071]

[0072]

[0073]

[0074]

[0075]

[0076]

[0077] The Picture Parameter Set (PPS) of VVC contains information that can be changed between pictures. The information contained in the PPS is roughly equivalent to some of the PPS in HEVC, including: 1) self-reference; 2) initial picture control information, such as initial quantization parameters (QP), the number of flags indicating the use or presence of certain tools or control information in the strip header; and 3) tiling information.

[0078] The strip header contains information that can change between strips, as well as relatively small or only image-related information relevant to certain strips or image types. The size of the strip header can be significantly larger than the PPS, especially when there are tile or wavefront entry point offsets in the strip header and RPS, and when modifications to prediction weights or the reference image list are explicitly sent via signaling.

[0079] Universal Video Codec (VVC)

[0080] At the 10th JVET meeting (April 10-20, 2018, San Diego, USA), JVET defined the initial drafts of the Universal Video Codec (VVC) and VVC Test Model 1 (VTM1) as its reference software implementation. It was decided to include a quadtree with nested multi-type trees as an initial new coding feature of VVC. A multi-type tree is a coding block partitioning structure that includes binary and ternary partitions. Since then, the reference software VTM has been developed and updated through the following JVET meetings, implementing the encoding and decoding processes.

[0081] In VVC, images of the input video are segmented into blocks called coding tree units (CTUs). CTUs are further subdivided into coding units (CUs) using a quadtree with a nested multi-type tree structure, where CUs define pixel regions that share the same prediction mode (e.g., intra-frame or inter-frame mode). In this paper, the term "unit" defines a region of an image that covers all components (e.g., luma and chroma components); the term "block" is used to define a region that covers a specific component (e.g., luma component), and blocks for different components (e.g., luma and chroma components) may differ spatially when considering chroma sampling formats (e.g., 4:2:0).

[0082] Segment the image into CTUs

[0083] The image is divided into a sequence of Coding Tree Units (CTUs). The concept of a CTU is the same as that in HEVC. For an image with a three-sample array, a CTU consists of an N×N block of luminance samples and two blocks corresponding to chrominance samples.

[0084] Figure 4 An example of dividing an image into CTUs is shown.

[0085] The maximum permissible size of the luminance block in CTU is stated as 128×128 (but the maximum size of the luminance transform block is 64×64).

[0086] CTU is segmented using a tree structure.

[0087] In HEVC, the CTU is split into CUs using a quadtree structure represented as a coding tree to accommodate various local features. At the CU level, it is determined whether to use inter-image (temporal) prediction or intra-image (spatial) prediction to encode image regions. Depending on the PU splitting type, each CU can be further split into one, two, or four PUs. Within a PU, the same prediction process is applied, and relevant information is transmitted to the decoder based on the PU. After obtaining residual blocks by applying a prediction process based on the PU splitting type, the CU can be divided into transform units (TUs) according to another quadtree structure similar to the coding tree used for CUs. One of the key features of the HEVC structure is that it has multiple partitioning concepts, including CUs, PUs, and TUs.

[0088] In VVC, the concept of multiple partition unit types is replaced by a quadtree with nested multi-type trees using binary and ternary partitioning structures. This removes the separation of CU, PU, ​​and TU concepts, unless a CU with a size too large for the maximum transform length is required, and supports greater flexibility in CU partition shapes. In the coding tree structure, CUs can have square or rectangular shapes. A coding tree unit (CTU) is first partitioned by a quadtree structure. The leaf nodes of the quadtree can then be further partitioned using multi-type tree structures. For example... Figures 5A-5D As shown, there are four partitioning types in the multi-type tree structure.

[0089] Figure 5A The vertical binary partition (SPLIT_BT_VER) is shown.

[0090] Figure 5B The horizontal binary partition (SPLIT_BT_HOR) is shown.

[0091] Figure 5C The vertical ternary partition (SPLIT_TT_VER) is shown.

[0092] Figure 5D The horizontal ternary partition (SPLIT_TT_HOR) is shown.

[0093] The leaf nodes of the multiple types are called coding units (CUs). Unless the CU is too large for the maximum transform length, this segmentation is used for prediction and transform processing without any further segmentation. This means that in most cases, CUs, PUs, and TUs have the same block size in a quadtree with a nested multi-type tree coding block structure. Exceptions occur when the maximum supported transform length is less than the width or height of the color component of the CU.

[0094] Syntax in VVC

[0095] In VVC, the first layer of bitstream for syntax signaling is the Network Abstraction Layer (NAL), where the bitstream is divided into sets of NAL units. Some NAL units send common control parameters to the decoder via signals, such as the Sequence Parameter Set (SPS) and Picture Parameter Set (PPS). Other NAL units contain video data. The Video Coding Layer (VCL) NAL units contain stripes of encoded video. The encoded images are called access units and can be encoded into one or more stripes.

[0096] The encoded video sequence begins with an Instantaneous Decoder Refresh (IDR) picture. All subsequent video pictures are encoded as stripes. A new IDR picture indicates the end of the previous video segment and the beginning of a new one. Each NAL unit begins with a single-byte header, followed by the Raw Byte Sequence Payload (RBSP). The RBSP contains the encoded stripes. The stripes are binary encoded, so they can be padded with zero bits to ensure that the length is an integer number of bytes. A stripe consists of a stripe header and stripe data. The stripe data is represented as a series of CUs.

[0097] The concept of an image header was adopted at the 16th JVET conference. This image header is the first VCL NAL unit transmitted once per image. It was also proposed to group some syntax elements from the previous strip header into the image header. Syntax elements that functionally only need to be transmitted once per image can be moved to the image header instead of being transmitted multiple times within the stripes of a given image.

[0098] In the VVC specification, the syntax table represents a superset of the syntax for all allowed bitstreams. Additional constraints on the syntax can be indicated directly or indirectly in other clauses. Below are the syntax tables for stripe headers and image headers in VVC, Tables 3 and 4, respectively. The semantics of some syntaxes are also explained after the syntax tables.

[0099] Table 3 Syntax with Headers

[0100]

[0101]

[0102]

[0103]

[0104]

[0105] Table 4. Syntax of Image Headers

[0106]

[0107]

[0108]

[0109]

[0110]

[0111]

[0112]

[0113]

[0114] The semantics of the selected syntax element

[0115] `ph_temporal_mvp_enabled_flag` indicates whether temporal motion vector prediction values ​​can be used for inter-frame prediction of stripes associated with the Picture Header (PH). If `ph_temporal_mvp_enabled_flag` equals 0, the syntax elements of the stripes associated with the PH should be constrained so that temporal motion vector prediction values ​​are not used when decoding these stripes. Otherwise (if `ph_temporal_mvp_enabled_flag` equals 1), temporal motion vector prediction values ​​can be used to decode the stripes associated with the PH. When `ph_temporal_mvp_enabled_flag` is not present, its value is inferred to be 0. The value of `ph_temporal_mvp_enabled_flag` should be 0 when there is no reference picture in the Decode Picture Buffer (DPB) with the same spatial resolution as the current picture.

[0116] The derivation of the maximum number of MVP candidates based on sub-block merging, MaxNumSubblockMergeCand, is as follows:

[0117] if (sps_affine_enabled_flag),

[0118] Therefore, MaxNumSubblockMergeCand = 5

[0119] -five_minus_max_num_subblock_merge_cand (1);

[0120] otherwise,

[0121] MaxNumSubblockMergeCand=

[0122] sps_sbtmvp_enabled_flag&&ph_temporal_mvp_enabled_flag

[0123] The value of MaxNumSubblockMergeCand should be in the range of 0 to 5, including the endpoints.

[0124] A slice_collocated_from_l0_flag value of 1 indicates that the co-positioned images used for temporal motion vector prediction are derived from reference image list 0. A slice_collocated_from_l0_flag value of 0 indicates that the co-positioned images used for temporal motion vector prediction are derived from reference image list 1.

[0125] When slice_type equals B or P, ph_temporal_mvp_enabled_flag equals 1, and slice_collocated_from_l0_flag does not exist. The following applies:

[0126] – If rpl_info_in_ph_flag equals 1, then slice_collocated_from_l0_flag is inferred to be equal to ph_collocated_from_l0_flag.

[0127] Otherwise (rpl_info_in_ph_flag equals 0 and slice_type equals P), infer that slice_collocated_from_l0_flag equals 1.

[0128] slice_collocated_ref_idx indicates the reference index of the collocation image used for temporal motion vector prediction.

[0129] When slice_type equals P or slice_type equals B and slice_collocated_from_l0_flag equals 1, slice_collocated_ref_idx refers to the entry in reference image list 0, and the value of slice_collocated_ref_idx should be in the range of 0 to NumRefIdxActive[0]-1, including the endpoint.

[0130] When slice_type equals B and slice_collocated_from_l0_flag equals 0, slice_collocated_ref_idx refers to the entry in reference image list 1, and the value of slice_collocated_ref_idx should be in the range of 0 to NumRefIdxActive[1]-1, including the endpoint.

[0131] The following applies when slice_collocated_ref_idx does not exist:

[0132] —If rpl_info_in_ph_flag equals 1, then it is inferred that the value of slice_collocated_ref_idx is equal to ph_collocated_ref_idx.

[0133] —Otherwise (rpl_info_in_ph_flag equals 0), it is inferred that the value of slice_collocated_ref_idx is equal to 0.

[0134] The image referenced by slice_collocated_ref_idx should be identical across all slices of the encoded image; this is a requirement for bitstream consistency.

[0135] The values ​​of pic_width_in_luma_samples and pic_height_in_luma_samples of the reference image referenced by slice_collocated_ref_idx should be equal to the values ​​of pic_width_in_luma_samples and pic_height_in_luma_samples of the current image, respectively, and RprConstraintsActive[slice_collocated_from_l0_flag? 0:1][slice_collocated_ref_idx] should be equal to 0. This is a requirement for bitstream consistency.

[0136] It should be noted that the value of RprConstraintsActive[i][j] is derived from section 8.3.2 of the VVC specification, as described below.

[0137] Decoding process based on the reference image list

[0138] This process is invoked at the start of the decoding process for each stripe of a non-IDR image.

[0139] Reference images are addressed using reference indices. A reference index is an index of a list of reference images. When decoding an I-strip, the list of reference images is not used when decoding the stripe data. When decoding a P-strip, only reference image list 0 (i.e., RefPicList[0]) is used when decoding the stripe data. When decoding a B-strip, both reference image list 0 and reference image list 1 (i.e., RefPicList[1]) are used to decode the stripe data.

[0140] At the start of the decoding process for each stripe of a non-IDR image, a list of reference images, RefPicList[0] and RefPicList[1], is derived. These lists of reference images are used for decoding the tagging or stripe data of the reference images as described in Section 8.3.3.

[0141] Note 1 – For I-stripes that are not the first stripe of a non-IDR image, RefPicList[0] and RefPicList[1] can be derived for bitstream consistency checks, but their derivation is not necessary for decoding the current image or images following the current image in the decoding order. For P-stripes that are not the first stripe of an image, RefPicList[1] can be derived for bitstream consistency checks, but its derivation is not necessary for decoding the current image or images following the current image in the decoding order.

[0142] The reference image lists RefPicList[0] and RefPicList[1], the reference image scaling ratios RefPicScale[i][j][0] and RefPicScale[i][j][1], and the reference image scaling flags RprConstraintsActive[0][j] and RprConstraintsActive[1][j] are derived as follows:

[0143]

[0144]

[0145]

[0146] fRefWidth is set to be equal to the PicOutputWidthL of the reference image RefPicList[i][j].

[0147] fRefHeight is set to be equal to the PicOutputHeightLrefPicWidth, refPicHeight, refScalingWinLeftOffset, refScalingWinRightOffset, refScalingWinTopOffset, and refScalingWinBottomOffset of the reference image RefPicList[i][j]. The values ​​of pic_width_in_luma_samples, pic_height_in_luma_samples, scaling_win_left_offset, scaling_win_right_offset, scaling_win_top_offset, and scaling_win_bottom_offset of the reference image RefPicList[i][j] are also set to be equal to the values ​​of pic_width_in_luma_samples, pic_height_in_luma_samples, scaling_win_left_offset, scaling_win_right_offset, scaling_win_top_offset, and scaling_win_bottom_offset of the reference image RefPicList[i][j], respectively.

[0148] RefPicScale[i][j][0]=((fRefWidth<<14)+(PicOutputWidthL>>1)) / PicOutputWidthL

[0149] RefPicScale[i][j][1]=((fRefHeight<<14)+(PicOutputHeightL>>1)) / PicOutputHeightL

[0150] RprConstraintsActive[i][j]=(pic_width_in_luma_samples!=refPicWidth||pic_height_in_luma_samples!=refPicHeight||scaling_win_left_offset!=refScalingWinLeftOffs et||scaling_win_right_offset! =refScalingWinRightOffset||scaling_win_top_offset! =refScalingWinTopOffset||scaling_win_bottom_offset! =refScalingWinBottomOffset)

[0151] }

[0152] }

[0153] `scaling_win_left_offset`, `scaling_win_right_offset`, `scaling_win_top_offset`, and `scaling_win_bottom_offset` represent the offsets applied to the image size for scaling ratio calculations. When `scaling_win_left_offset`, `scaling_win_right_offset`, `scaling_win_top_offset`, and `scaling_win_bottom_offset` are not present, their values ​​are inferred to be equal to `pps_conf_win_left_offset`, `pps_conf_win_right_offset`, `pps_conf_win_top_offset`, and `pps_conf_win_bottom_offset`, respectively.

[0154] The value of SubWidthC*(scaling_win_left_offset+scaling_win_right_offset) should be less than pic_width_in_luma_samples, and the value of SubHeightC*(scaling_win_top_offset+scaling_win_bottom_offset) should be less than pic_height_in_luma_samples.

[0155] The variables PicOutputWidthL and PicOutputHeightL are exported as follows:

[0156] PicOutputWidthL=pic_width_in_luma_samples-SubWidthC*(scaling_win_right_offset+scaling_win_left_offset) (3)

[0157] PicOutputHeightL=pic_height_in_luma_samples-SubWidthC*(scaling_win_bottom_offset+scaling_win_top_offset) (79)

[0158] Let refPicOutputWidthL and refPicOutputHeightL be the PicOutputWidthL and PicOutputHeightL of the reference image to the current image of this PPS, respectively. The bitstream consistency requirement satisfies all of the following conditions:

[0159] –PicOutputWidthL*2 should be greater than or equal to refPicWidthInLumaSamples.

[0160] –PicOutputHeightL*2 should be greater than or equal to refPicHeightInLumaSamples.

[0161] –PicOutputWidthL should be less than or equal to refPicWidthInLumaSamples*8.

[0162] –PicOutputHeightL should be less than or equal to refPicHeightInLumaSamples*8.

[0163] –PicOutputWidthL*pic_width_max_in_luma_samples should be greater than or equal to refPicOutputWidthL*(pic_width_in_luma_samples-Max(8,MinCbSizeY)).

[0164] –PicOutputHeightL*pic_height_max_in_luma_samples should be greater than or equal to refPicOutputHeightL*(pic_height_in_luma_samples-Max(8,MinCbSizeY)).

[0165] NAL Unit Syntax

[0166] Similar to HEVC, the VVC specification sends a two-byte NAL unit header table at the beginning of each NAL unit to indicate the basic information of that NAL unit. Table 5 shows the syntax elements present in the current NAL unit header.

[0167] Table 5. Syntax of NAL Unit Header

[0168]

[0169] In Table 5, the first bit is the `forbidden_zero_bit`, used to indicate whether any errors occurred during transmission. 0 indicates a normal NAL unit, while 1 indicates a syntax violation. Therefore, for a normal bitstream, its corresponding value should be equal to 0. The next bit is the `nuh_reserved_zero_bit`, reserved for future use and should be equal to 0. The following 6 bits are used to indicate the value of the syntax `nuh_layer_id`, used to identify the layer to which the NAL unit belongs. The value of `nuh_layer_id` should be in the range of 0 to 55, inclusive. Other values ​​of `nuh_layer_id` are reserved for future use. Afterwards, the syntax element `nal_unit_type` is used to indicate the NAL unit type, that is, the type of RBSP data structure contained in the NAL unit, as shown in the table below.

[0170] Table 6 NAL Unit Types

[0171]

[0172]

[0173]

[0174] Progressive decoding refresh

[0175] Low latency and error recovery are two crucial factors to consider in practical video transmission systems. Intra-frame refresh, which involves periodically inserting IRAP images, is typically used to limit error propagation between time-series images and enhance the error recovery capability of the bitstream. However, because inter-frame coding is far more efficient than intra-frame coding, relatively large intra-frame images can cause latency issues when transmitted over a fixed-rate network. This can lead to unwanted network congestion and packet loss. To address this problem, Progressive Decode Refresh (GDR) is applied to the VVC standard, which distributes the intra-frame coded region across multiple inter-frame images, such as... Figure 6 As shown.

[0176] Figure 6The diagram illustrates the progressive decoding refresh according to this disclosure. 610 is an intra-frame region of the first image. 612 is a dirty region of the first image. 614 is a clean region of the second image. 616 is an intra-frame region of the second image. 618 is a dirty region of the second image. 620 is a clean region of the third image. 622 is an intra-frame region of the third image. 624 is a dirty region of the third image. 626 is a clean region of the fourth image. 628 is an intra-frame region of the fourth image. 630 is a dirty region of the fourth image.

[0177] like Figure 6 As shown, three regions are defined. The clean region corresponds to pixels that have been refreshed during the current GDR cycle, and the dirty region corresponds to a region that has not yet been refreshed and represents the region of the coded block to which intra-frame coding is applied. The principle of GDR is to ensure that pixels from the clean region are reconstructed using pixels from only the refreshed regions of the time reference picture within the same GDR cycle. In the current VVC, the picture header contains three GDR-related syntax elements transmitted via signals: ph_gdr_or_irap_pic_flag, ph_gdr_pic_flag, and ph_recovery_poc_cnt. Table 7 illustrates the corresponding GDR signaling in the picture header and its associated semantics.

[0178] Table 7 GDR Signaling

[0179]

[0180]

[0181] A value of 1 for ph_gdr_or_irap_pic_flag indicates that the current image is a GDR or IRAP image. A value of 0 for ph_gdr_or_irap_pic_flag indicates that the current image is not a GDR image, and may or may not be an IRAP image.

[0182] A ph_gdr_pic_flag value of 1 indicates that the image associated with this pH is a GDR image. A ph_gdr_pic_flag value of 0 indicates that the image associated with this pH is not a GDR image. When ph_gdr_pic_flag does not exist, it is inferred that the value of ph_gdr_pic_flag is equal to 0. When sps_gdr_enabled_flag is equal to 0, the value of ph_gdr_pic_flag should be equal to 0.

[0183] Note 1 – When ph_gdr_or_irap_pic_flag equals 1 and ph_gdr_pic_flag equals 0, the image associated with this PH is an IRAP image.

[0184] ph_recovery_poc_cnt indicates the recovery points of the decoded images in the output order.

[0185] When the current image is a GDR image, the variable recoveryPointPocVal is deduced as follows:

[0186] recoveryPointPocVal=PicOrderCntVal+ph_recovery_poc_cnt (4)

[0187] If the current image is a GDR image, and there exists an image picA in the CLVS with PicOrderCntVal equal to recoveryPointPocVal that follows the current GDR image in decoding order, then image picA is called the recovery point image. Otherwise, the first image in the CLVS with a PicOrderCntVal greater than recoveryPointPocVal in output order is called the recovery point image. Recovery point images should not precede the current GDR image in decoding order. Images associated with the current GDR image and whose PicOrderCntVal is less than recoveryPointPocVal are called the recovery images of the GDR image. The value of ph_recovery_poc_cnt should be in the range of 0 to MaxPicOrderCntLsb-1, inclusive.

[0188] Note 3—When sps_gdr_enabled_flag equals 1 and the PicOrderCntVal of the current image is greater than or equal to the recoveryPointPocVal of the associated GDR image, the current and subsequent decoded images are completely matched with the corresponding images in the output order. These corresponding images are generated by the decoding process that starts from the previous IRAP image. When the previous IRAP image exists, the previous IRAP image is decoded before the associated GDR image in the order of decoding.

[0189] A mixed NAL type in an image

[0190] Unlike the HEVC standard, which requires all stripes within an image to have the same NAL type, mixing is allowed if an image contains both IRAP and non-IRAP NAL unit types. The motivation for this feature is to utilize region-based random access to subpicks. For example, in a 360-degree video stream, a user might view certain regions of a 360-degree video more frequently than others. To better balance encoding / decoding efficiency and average viewpoint switching latency, more frequently viewed regions can be encoded using IRAP images compared to other regions. To this end, a flag `pps_mixed_nalu_types_in_pic_flag` is introduced in PPS. When this flag equals 1, it indicates that each image referencing the PPS has more than one NAL unit, and these NAL units do not have the same `nal_unit_type` value. Otherwise (when the flag equals 0), each image referencing the PPS has one or more NAL units, and the NAL units of each image referencing the PPS have the same `nal_unit_type` value. Furthermore, the flag `pps_mixed_nalu_types_in_pic_flag` is set to 1, applying a bitstream consistency constraint to any given picture. This constraint states that some NAL units in the picture have a specific IRAPNAL unit type, while others have a specific non-IRAPNAL unit type. In other words, any given picture's NAL units cannot have more than one IRAPNAL unit type, nor more than one non-IRAPNAL unit type, as described below:

[0191] For any specific image's VCL NAL unit, the following applies:

[0192] – If pps_mixed_nalu_types_in_pic_flag equals 0, then the value of nal_unit_type should be the same for all VCL NAL units of the picture, and the picture or PU is called to have the same NAL unit type as the encoded stripe NAL unit of that picture or PU.

[0193] – Otherwise (pps_mixed_nalu_types_in_pic_flag equals 1), the following applies:

[0194] – The image should have at least two sub-images.

[0195] – The VCL NAL unit of this image should have two or more different nal_unit_type values.

[0196] – There should be no VCL NAL unit for this image whose nal_unit_type is equal to GDR_NUT.

[0197] – When at least one sub-image of the image has a VCL NAL unit with a specific nal_unit_type value equal to IDR_W_RADL, IDR_N_LP, or CRA_NUT, the VCL NAL units of the other sub-images in the image should all have a nal_unit_type equal to TRAIL_NUT.

[0198] Improvements to general constraint information and syntax elements

[0199] In the current VVC, the `no_sbt_constraint_flag` is sent via a signal in the general constraint information, without any constraints. However, the features controlled by the `no_sbt_constraint_flag` only apply when the stripe is an inter-frame stripe. Therefore, when the stripe is an intra-frame stripe, the value of `no_sbt_constraint_flag` should be equal to 1.

[0200] Similarly, the `no_act_constraint_flag` and `no_chroma_qp_offset_constraint_flag` are sent via signals in the general constraint information, without any constraints. However, the features controlled by the flags `no_act_constraint_flag` and `no_chroma_qp_offset_constraint_flag` only apply when the chroma format is not monochrome. Therefore, when the chroma format is monochrome, the values ​​of these two flags should be equal to 1.

[0201] Similarly, in another example, the `no_mixed_nalu_types_in_pic_constraint_flag` is signaled in the general constraint information, even without any constraints. However, the characteristics controlled by the `no_mixed_nalu_types_in_pic_constraint_flag` only apply when the image has at least two sub-images. Therefore, when the image has only one sub-image, the value of `no_mixed_nalu_types_in_pic_constraint_flag` should be equal to 1.

[0202] Similarly, in yet another example, `no_prof_constraint_flag` is signaled in the general constraint information, without any constraints. However, the features controlled by the `no_prof_constraint_flag` flag only apply when affine mode is enabled. Therefore, when affine mode is disabled, the value of `no_prof_constraint_flag` should be equal to 1.

[0203] Similarly, in another example, `no_bdpcm_constraint_flag` is sent via a signal in the general constraint information, without any constraints. However, the features controlled by the `no_bdpcm_constraint_flag` flag only apply when transformation skip mode is enabled. Therefore, when transformation skip mode is disabled, the value of `no_bdpcm_constraint_flag` should be equal to 1.

[0204] It is also noted that several coding tools are missing from the general constraint information syntax in the current VVC. These coding tool flags should be added to provide the same general constraint control as other tools.

[0205] In the current VVC, the `mvd_l1_zero_flag` is sent via signaling in the image header (PH) without any constraints. However, the features controlled by the `mvd_l1_zero_flag` only apply when the slice is a bidirectional predictive slice (B-slice). Therefore, when the slice associated with the image header is not a B-slice, this flag signaling is redundant.

[0206] Similarly, in another example, ph_disable_bdof_pic_present_flag and ph_disable_dmvr_pic_present_flag are signaled in the PH only when the corresponding enable flags (sps_bdof_pic_present_flag, sps_dmvr_pic_present_flag) sent via signaling in the Sequence Parameter Set (SPS) are true. However, as shown in Table 8, the features controlled by the flags ph_disable_bdof_flag and ph_disable_dmvr_flag are only applicable when the slice is a bidirectional predictive slice (B-slice). Therefore, when the slice associated with the picture header is not a B-slice, the signaling of these two flags is redundant or useless.

[0207] Table 8. Marking Characteristics

[0208]

[0209] Another example can be seen in the syntax element ph_collocated_from_l0_flag, indicating whether the isotopic image comes from list 0 or list 1. Another example can be seen in the syntax pred_weight_table(), which is a syntax element related to weighted tables used for bidirectional prediction.

[0210] Table 9. Marker Characteristics

[0211]

[0212]

[0213]

[0214]

[0215] The third issue relates to the syntax `ph_temporal_mvp_enabled_flag`. In the current VVC, since the resolution of the parsing image chosen for TMVP derivation should be the same as the resolution of the current image, there is a bitstream consistency constraint to check the value of `ph_temporal_mvp_enabled_flag`, as described below:

[0216] When there is no reference image in the DPB with the same spatial resolution as the current image, the value of ph_temporal_mvp_enabled_flag should be equal to 0.

[0217] However, in the current VVC, not only does the resolution of the co-located image affect TMVP enabling, but the offset of the image size used for scaling calculations also affects TMVP enabling. However, in the current VVC, the offset is not considered in the bitstream consistency of ph_temporal_mvp_enabled_flag.

[0218] Furthermore, there is a requirement for bitstream consistency, meaning the image referenced by `slice_collocated_ref_idx` should be identical across all slices of the encoded image. However, when an encoded image has multiple slices and there is no common reference image among all these slices, there is no chance to satisfy this bitstream consistency requirement. In this case, `ph_temporal_mvp_enabled_flag` should be limited to 0.

[0219] According to the current VVC specification, an IRAP picture is referred to as a single picture in which all associated NAL units have the same `nal_unit_type` belonging to the IRAP NAL type. Specifically, the following description defines an IRAP picture in the VVC specification:

[0220] Intra-Frame Random Access Point (IRAP) Picture: An encoded picture in which all VCL NAL units have the same nal_unit_type value in the range IDR_W_RADL to CRA_NUT, including endpoints.

[0221] Note 1 – IRAP images do not use inter-frame prediction during their decoding process and can be CRA or IDR images. The first image in the bitstream in decoding order must be an IRAP or GDR image. If the necessary parameter set is available when needed, IRAP images and all subsequent non-RASL images in CLVS can be decoded correctly without performing the decoding process for any images preceding that IRAP image in decoding order.

[0222] Note 2 – The value of pps_mixed_nalu_types_in_pic_flag for an IRAP image is equal to 0. When pps_mixed_nalu_types_in_pic_flag for an image is equal to 0 and any stripe of the image has a nal_unit_type in the range IDR_W_RADL to CRA_NUT (inclusive), all other stripes of the image have the same nal_unit_type value, and the image is known to be an IRAP image.

[0223] As shown above, for each IRAP image, the pps_mixed_nalu_types_in_pic_flag of the corresponding PPS referenced by that image should be equal to 0. Similarly, in the current VVC specification, a GDR image is referred to as an image, and the nal_unit_type of all NALs associated with that image should be equal to GDR_NUT, as indicated for Progressive Decoding Refresh (GDR) images: each VCL NAL unit has an image with a nal_unit_type equal to GDR_NUT.

[0224] Since all NAL units of a GDR image must have the same NAL type, the flag pps_mixed_nalu_types_in_pic_flag in the corresponding PPS referenced by the GDR image cannot be equal to 1.

[0225] On the other hand, as discussed in the introduction, two flags (ph_gdr_or_irap_pic_flag and ph_gdr_pic_flag) are signaled in the image header to indicate whether an image is an IRAP image or a GDR image. When ph_gdr_or_irap_pic_flag equals 1 and ph_gdr_pic_flag equals 0, the current image is an IRAP image. When both ph_gdr_or_irap_pic_flag and ph_gdr_pic_flag equals 1, the current image is a GDR image. According to the current VVC specification, these two flags are allowed to be represented as 1 or 0 by signals, regardless of the value of the flag pps_mixed_nalu_types_in_pic_flag in PPS. However, as mentioned earlier, an image can only be an IRAP or GDR image if the NAL units in the image have the same nal_unit_type (i.e., the corresponding pps_mixed_nalu_types_in_pic_flag must be zero). Therefore, if one or both of ph_gdr_or_irap_pic_flag and ph_gdr_pic_flag are equal to 1 (i.e., indicating that the current image is an IRAP or GDR image) and the corresponding pps_mixed_naly_types_in_pic_flag is equal to 1 (i.e., indicating that there are multiple NAL types in the current image), the existing IRAP / GDR signaling in the image header is problematic.

[0226] The proposed method

[0227] Several methods are proposed to address the problems described in the statement section. Methods are provided to simplify and / or further improve the existing design of the high-level grammar. Note that these proposed methods can be applied independently or in combination.

[0228] Since the features controlled by the no_sbt_constraint_flag flag only apply when the stripe is an inter-frame stripe, according to the method of this disclosure, a constraint is proposed that the value of no_sbt_constraint_flag should be equal to 1 when the stripe is an inter-frame stripe. An example of the decoding process in the VVC draft is shown below. Changes to the VVC draft are shown in bold and italics.

[0229]

[0230] Since the features controlled by the flags no_act_constraint_flag and no_chroma_qp_offset_constraint_flag only apply when the chroma format is not monochrome, according to the method of the present invention, an additional constraint is proposed that the values ​​of these two flags should be equal to 1 when the chroma format is monochrome. An example of the decoding process of the VVC draft is shown below. Changes to the VVC draft are shown in bold and italics.

[0231]

[0232]

[0233] Below is another example of the decoding process for the VVC draft. Changes to the VVC draft are shown in bold and italics.

[0234]

[0235] Since the features controlled by the `no_mixed_nalu_types_in_pic_constraint_flag` flag only apply when the image has at least two sub-images, according to the method of this disclosure, an additional constraint is proposed: the value of `no_mixed_nalu_types_in_pic_constraint_flag` should be equal to 1 when the image has one sub-image. Another example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics.

[0236]

[0237]

[0238] Since the features controlled by the no_prof_constraint_flag flag only apply when affine mode is enabled, according to the method of this disclosure, an additional constraint is proposed: the value of no_prof_constraint_flag should be equal to 1 when affine mode is enabled. An example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics.

[0239]

[0240] Since the features controlled by the no_bdpcm_constraint_flag flag only apply when transform skip mode is enabled, according to the method of this disclosure, an additional constraint is proposed: the value of no_bdpcm_constraint_flag should be equal to 1 when transform skip mode is enabled. An example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics.

[0241]

[0242] Several encoding tools are missing from the general constraint information syntax. These encoding tool flags should be added to provide the same general constraint control as other flags.

[0243] In the current VVC, `sps_conformance_window_flag` equal to 1 indicates that the consistency trimming window offset parameter is after the SPS. According to this disclosure, a flag `no_conformance_window_constraint_flag` for the trimming function is proposed to be added to the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics.

[0244]

[0245]

[0246] In the current VVC, `sps_weighted_pred_flag` equal to 1 indicates that weighted prediction can be applied to the P-strip of the reference SPS. `sps_weighted_pred_flag` equal to 0 indicates that weighted prediction cannot be applied to the P-strip of the reference SPS. According to this disclosure, it is proposed to add the syntax element `no_weighted_pred_constant_flag` to the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics. Furthermore, since weighted prediction is only applicable when inter-frame coding tools are permitted, it is proposed to add a bitstream consistency constraint when intra-frame coding of the sequence is only permitted; that is, the value of `no_weighted_pred_constant_flag` should be equal to 1.

[0247]

[0248]

[0249]

[0250] In the current VVC, `sps_weighted_bipred_flag` equal to 1 indicates that explicit weighted prediction can be applied to B-strips referencing the SPS. `sps_weighted_bipred_flag` equal to 0 indicates that explicit weighted prediction is not applied to B-strips referencing the SPS. According to this disclosure, it is proposed to add the syntax element `no_weighted_bipred_constraint_flag` to the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics. Furthermore, it is proposed to add a bitstream consistency constraint when only encoding sequences is allowed, i.e., the value of `no_weighted_bipred_constraint_flag` should be equal to 1.

[0251]

[0252]

[0253] In the current VVC, `sps_virtual_boundaries_enabled_flag` equal to 1 indicates that loop filtering across virtual boundaries is enabled and can be applied to encoded images in CLVS. `sps_virtual_boundaries_enabled_flag` equal to 0 indicates that loop filtering across virtual boundaries is disabled and not applied to encoded images in CLVS. Loop filtering operations include deblocking filters, sample adaptive offset filters, and adaptive loop filter operations. According to this disclosure, it is proposed to add the syntax element `no_virtual_boundaries_constraint_flag` to the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics.

[0254]

[0255]

[0256] In the current VVC draft, two flags are signaled in the General Constraints Information syntax table: `no_ref_pic_resampling_constraint_flag` and `no_res_change_in_clvs_constraint_flag`. The first flag indicates whether reference picture resampling is allowed in the coded sequence, while the second flag indicates whether the resolution of pictures in the coded sequence can be adjusted. Since picture resolutions can only differ when reference picture resampling is enabled, a bitstream consistency constraint is proposed: when `no_ref_pic_resampling_constraint_flag` is equal to 1, the value of `no_res_change_in_clvs_constraint_flag` should also be equal to 1, as described below. Furthermore, since reference picture resampling is an inter-frame coding / decoding feature, it cannot be applied when only intra-frame coding is allowed. Therefore, when only intra-frame coding tools are allowed, another bitstream consistency constraint is added to restrict the value of `no_ref_pic_resampling_constraint_flag` to be equal to 1.

[0257] A value of 1 for `no_ref_pic_resampling_constraint_flag` indicates that `sps_ref_pic_resampling_enabled_flag` should be 0. A value of 0 for `no_ref_pic_resampling_constraint_flag` does not impose this constraint. When `intra_only_constraint_flag` is 1, the value of `no_ref_pic_resampling_constraint_flag` should be 1.

[0258] A value of 1 for `no_res_change_in_clvs_constraint_flag` indicates that `sps_res_change_in_clvs_allowed_flag` should be 0. A value of 0 for `no_res_change_in_clvs_constraint_flag` does not impose this constraint. When the value of `no_ref_pic_resampling_constraint_flag` is 1, the value of `no_res_change_in_clvs_constraint_flag` should be 1.

[0259] In the current VVC, `pps_deblocking_filter_disabled_flag` equal to 1 indicates that the deblocking filter operation is not applicable to slices referencing this PPS, for which one of the following two conditions is true: 1) `ph_deblocking_filter_disabled_flag` and `sh_deblocking_filter_disabled_flag` do not exist and are inferred to be equal to it; and 2) `ph_deblocking_filter_disabled_flag` or `sh_deblocking_filter_disabled_flag` exists and is equal to 1. Furthermore, `pps_deblocking_filter_disabled_flag` equal to 1 also indicates that the deblocking filter operation is applicable to slices referencing this PPS, for which one of the following two conditions is true: 1) `ph_deblocking_filter_disabled_flag` and `sh_deblocking_filter_disabled_flag` do not exist and are inferred to be equal to 0; and 2) `ph_deblocking_filter_disabled_flag` or `sh_deblocking_filter_disabled_flag` exists and is equal to 0. A `pps_deblocking_filter_disabled_flag` equal to 0 indicates that the deblocking filter operation applies to slices referencing the PPS, for which one of the following two conditions is true: 1) `ph_deblocking_filter_disabled_flag` and `sh_deblocking_filter_disabled_flag` do not exist; and 2) `ph_deblocking_filter_disabled_flag` or `sh_deblocking_filter_disabled_flag` exists and is equal to 0. Furthermore, a `deblocking_filter_disabled_flag` equal to 0 also indicates that the deblocking filter operation does not apply to slices referencing the PPS, for which `ph_deblocking_filter_disabled_flag` or `sh_deblocking_filter_disabled_flag` exists and is equal to 1 for PPS slices. According to this disclosure, the syntax element `no_deblocking_filter_constraint_flag` is proposed to be added to the general constraint information syntax to provide the same general constraint control as other flags. An example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics.

[0260]

[0261]

[0262] Below is another example of the decoding process for the VVC draft. Changes to the VVC draft are shown in bold and italics.

[0263]

[0264] In the current VVC, `sps_num_subpics_minus1` incremented by 1 indicates the number of subpicks in each picture within the CLVS. The value of `sps_num_subpics_minus1` should be in the range of 0 to Ceil(sps_pic_width_max_in_luma_samples÷CtbSizeY)*Ceil(sps_pic_height_max_in_luma_samples÷CtbSizeY)-1, inclusive. When `sps_num_subpics_minus1` is not present, its value is inferred to be equal to 0. According to this disclosure, it is proposed to add a bitstream consistency constraint that `sps_num_subpics_minus1` should be equal to 0 when the value of `one_subpic_per_pic_constraint_flag` is equal to 1. An example of the decoding process for the VVC draft is illustrated below. Changes to the VVC draft are shown in bold and italics.

[0265]

[0266]

[0267] Figure 7 A method for decoding a video signal according to this disclosure is shown. For example, this method can be applied to a decoder.

[0268] In step 710, the decoder may receive a bitstream associated with the video data.

[0269] In step 712, the decoder obtains the syntax elements from the bitstream.

[0270] In step 714, the decoder decodes the video data based on the syntax element.

[0271] Since the features controlled by the flags mvd_l1_zero_flag, ph_disable_bdof_flag, and ph_disable_dmvr_flag are only applicable when the slice is a bidirectional prediction slice (B-slice), according to the method of this disclosure, it is proposed to signal these flags only when the relevant slice is a B-slice. Note that when the reference picture list is signaled in the PH (e.g., rpl_info_in_ph_flag = 1), it means that all slices of the encoded picture use the same reference picture signaled in the PH. Therefore, when the reference picture list is signaled in the PH and the signaled reference picture list indicates that the current picture is not bidirectional prediction, it is not necessary to signal the flags mvd_l1_zero_flag, ph_disable_bdof_flag, and ph_disable_dmvr_flag.

[0272] In the first embodiment, certain conditions are added to the syntax sent in the image header (PH) to prevent redundant signaling or undefined decoding behavior due to incorrect values ​​sent for some syntax in the image header. Some examples based on this embodiment are illustrated below, where the variable num_ref_entries[i][RplsIdx[i]] represents the number of reference images in list i.

[0273] if (!rpl_info_in_ph_flag||(rpl_info_in_ph_flag&&num_ref_entries[0][RplsIdx[0]]>0&&num_ref_entries[1][RplsIdx[1]]>0))mvd_l1_zero_flag,

[0274] Alternatively, these conditions can be written in a more compact form that yields the same result. Since a bidirectional prediction slice (B-slice) or bidirectional prediction image must have at least one list1 reference image, it is only necessary to check if the current slice / image has a list1 reference image. An example of an alternative condition check is shown below:

[0275] If (!rpl_info_in_ph_flag||(rpl_info_in_ph_flag&&num_ref_entries[1][RplsIdx[1]]>0))mvd_l1_zero_flagmvd_l1_zero_flag, the semantics are also modified to handle the case where no signal notification is sent.

[0276] A value of 1 for `mvd_l1_zero_flag` indicates that the `mvd_coding(x0,y0,1)` syntax structure is not parsed. Let `MvdL1[x0][y0][compIdx]` and `MvdCpL1[x0][y0][cpIdx][compIdx]` be 0 for `compIdx = 0..1` and `cpIdx = 0..2`. A value of 0 for `mvd_l1_zero_flag` indicates that the `mvd_coding(x0,y0,1)` syntax structure is parsed. When it does not exist, the value of `mvd_l1_zero_flag` is inferred to be 0.

[0277] Here are a few examples of conditionally sending the syntax element ph_disable_dmvr_flag via signal:

[0278] if (sps_dmvr_pic_present_flag&&(!rpl_info_in_ph_flag||(rpl_info_in_ph_flag&&num_ref_entries[0][RplsIdx[0]]>0&&num_ref_entries[1][RplsIdx[1]]>0)))ph_disable_dmvr_flag

[0279] Similarly, an example of an alternative condition check is shown below:

[0280] if (sps_dmvr_pic_present_flag&&(!rpl_info_in_ph_flag||(rpl_info_in_ph_flag&&num_ref_entries[1][RplsIdx[1]]>0)))

[0281] ph_disable_dmvr_flag

[0282] The semantics of ph_disable_dmvr_flag have also been modified to handle cases where no signal is sent.

[0283] A value of 1 for ph_disable_dmvr_flag indicates that inter-frame bidirectional prediction based on decoder motion vector refinement is disabled in the slice associated with the PH. A value of 0 for ph_disable_dmvr_flag indicates that inter-frame bidirectional prediction based on decoder motion vector refinement can be enabled or disabled in the slice associated with the PH.

[0284] The following applies when ph_disable_dmvr_flag is not present:

[0285] – If sps_dmvr_enabled_flag equals 1 and sps_dmvr_pic_present_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 0.

[0286] Otherwise, if sps_dmvr_enabled_flag equals 1 and sps_dmvr_pic_present_flag equals 1, then it is inferred that the value of ph_disable_dmvr_flag is equal to 1.

[0287] Otherwise (sps_dmvr_enabled_flag equals 0), it is inferred that the value of ph_disable_dmvr_flag is equal to 1.

[0288] When the value of ph_disable_dmvr_flag is not rendered, the alternative way to export this value is as follows:

[0289] – If you want to export the value of ph_disable_dmvr_flag by considering all conditions when explicitly exporting via signaling or implicitly exporting:

[0290] – If sps_dmvr_enabled_flag equals 1 and sps_dmvr_pic_present_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 0.

[0291] Otherwise, if sps_dmvr_enabled_flag equals 0 and sps_dmvr_pic_present_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 1.

[0292] Otherwise, if sps_dmvr_enabled_flag equals 1, sps_dmvr_pic_present_flag equals 1, and rpl_info_in_ph_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to X.

[0293] (X is explicitly sent via signal)

[0294] Otherwise, if sps_dmvr_enabled_flag equals 1, sps_dmvr_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]>0, then it is inferred that the value of ph_disable_dmvr_flag is equal to X (X is explicitly sent via a signal).

[0295] – Otherwise (sps_dmvr_enabled_flag equals 1, sps_dmvr_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]==0), it is inferred that the value of ph_disable_dmvr_flag is equal to 1.

[0296] Since the syntax element ph_disable_dmvr_flag is explicitly sent via signal in the third and fourth conditions, it can be removed from the derivation of ph_disable_dmvr_flag if it does not exist.

[0297] The following applies when ph_disable_dmvr_flag is not present:

[0298] – If sps_dmvr_enabled_flag equals 1 and sps_dmvr_pic_present_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 0.

[0299] Otherwise, if sps_dmvr_enabled_flag equals 0 and sps_dmvr_pic_present_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 1.

[0300] – Otherwise (sps_dmvr_enabled_flag equals 1, sps_dmvr_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]==0), it is inferred that the value of ph_disable_dmvr_flag is equal to 1.

[0301] These conditions can be edited and simplified as follows:

[0302] The following applies when ph_disable_dmvr_flag is not present:

[0303] – If sps_dmvr_enabled_flag equals 1 and sps_dmvr_pic_present_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 0.

[0304] Otherwise (sps_dmvr_enabled_flag equals 0 or sps_dmvr_pic_present_flag equals 1), infer that the value of ph_disable_dmvr_flag is equal to 1.

[0305] An alternative way to export the value of ph_disable_bdof_flag when it is not rendered is as follows:

[0306] The following applies when ph_disable_bdof_flag is not present:

[0307] – If sps_dmvr_pic_present_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 1 - sps_dmvr_enabled_flag.

[0308] Otherwise, if sps_dmvr_pic_present_flag equals 1 and rpl_info_in_ph_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 1 - sps_dmvr_enabled_flag.

[0309] Otherwise, if sps_dmvr_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]>0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 1-sps_dmvr_enabled_flag.

[0310] – Otherwise (sps_dmvr_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]==0), it is inferred that the value of ph_disable_dmvr_flag is equal to 1.

[0311] Since the syntax element ph_disable_dmvr_flag is explicitly sent via signal in the second and third conditions, it can be removed from the derivation of ph_disable_dmvr_flag if it is not present:

[0312] The following applies when ph_disable_dmvr_flag is not present:

[0313] – If sps_dmvr_pic_present_flag equals 0, then it is inferred that the value of ph_disable_dmvr_flag is equal to 1 - sps_dmvr_enabled_flag.

[0314] Otherwise, it is assumed that the value of ph_disable_dmvr_flag is equal to 1.

[0315] Here are a few examples of conditionally sending the syntax element ph_disable_bdof_flag via a signal:

[0316] if (sps_bdof_pic_present_flag&&(!rpl_info_in_ph_flag||(rpl_info_in_ph_flag&&num_ref_entries[0][RplsIdx[0]]>1&&num_ref_entries[1][RplsIdx[1]]>1)))ph_disable_bdof_flag

[0317] Similarly, an example of an alternative condition check is shown below:

[0318] if (sps_bdof_pic_present_flag&&(!rpl_info_in_ph_flag||(rpl_info_in_ph_flag&&num_ref_entries[1][RplsIdx[1]]>0)))

[0319] ph_disable_bdof_flag

[0320] The semantics of ph_disable_bdof_flag have also been modified to handle the case where no signal is sent.

[0321] A value of 1 for ph_disable_bdof_flag indicates that inter-frame bidirectional prediction based on bidirectional optical flow is disabled in the stripe associated with PH. A value of 0 for ph_disable_bdof_flag indicates that inter-frame bidirectional prediction based on bidirectional optical flow can be enabled or disabled in the stripe associated with PH.

[0322] The following applies when ph_disable_bdof_flag is not present:

[0323] – If sps_bdof_enabled_flag equals 1 and sps_bdof_pic_present_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 0.

[0324] Otherwise, if sps_bdof_enabled_flag equals 1 and sps_bdof_pic_present_flag equals 1, then it is inferred that the value of ph_disable_dmvr_flag is equal to 1.

[0325] Otherwise (sps_bdof_enabled_flag equals 0), infer that the value of ph_disable_bdof_flag is equal to 1.

[0326] When ph_disable_bdof_flag is not rendered, the alternative way to export the value of ph_disable_bdof_flag is as follows:

[0327] If all conditions are considered when explicitly deriving the value of ph_disable_bdof_flag via signaling or implicitly deriving it:

[0328] – If sps_bdof_enabled_flag equals 1 and sps_bdof_pic_present_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 0.

[0329] Otherwise, if sps_bdof_enabled_flag equals 0 and sps_bdof_pic_present_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 1.

[0330] Otherwise, if sps_bdof_enabled_flag equals 1, sps_bdof_pic_present_flag equals 1, and rpl_info_in_ph_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to X (X is explicitly sent via a signal).

[0331] Otherwise, if sps_bdof_enabled_flag equals 1, sps_bdof_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]>0, then it is inferred that the value of ph_disable_bdof_flag is equal to X (X is explicitly sent via signal).

[0332] – Otherwise (sps_bdof_enabled_flag equals 1, sps_bdof_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]==0), it is inferred that the value of ph_disable_bdof_flag is equal to 1.

[0333] Since the syntax element ph_disable_bdof_flag is explicitly sent via signal in the third and fourth conditions, it can be removed from the derivation of ph_disable_bdof_flag if it does not exist.

[0334] The following applies when ph_disable_bdof_flag is not present:

[0335] – If sps_bdof_enabled_flag equals 1 and sps_bdof_pic_present_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 0.

[0336] Otherwise, if sps_bdof_enabled_flag equals 0 and sps_bdof_pic_present_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 1.

[0337] – Otherwise (sps_bdof_enabled_flag equals 1, sps_bdof_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]==0), it is inferred that the value of ph_disable_bdof_flag is equal to 1.

[0338] These conditions can be edited and simplified as follows:

[0339] The following applies when ph_disable_bdof_flag is not present:

[0340] – If sps_bdof_enabled_flag equals 1 and sps_bdof_pic_present_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 0.

[0341] Otherwise (sps_bdof_enabled_flag equals 0 or sps_bdof_pic_present_flag equals 1), infer that the value of ph_disable_bdof_flag is equal to 1.

[0342] An alternative way to export the value of ph_disable_bdof_flag when it is not rendered is as follows:

[0343] The following applies when ph_disable_bdof_flag is not present:

[0344] —If sps_bdof_pic_present_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 1-sps_bdof_enabled_flag.

[0345] —Otherwise, if sps_bdof_pic_present_flag equals 1 and rpl_info_in_ph_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 1-sps_bdof_enabled_flag.

[0346] Otherwise, if sps_bdof_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]>0, then it is inferred that the value of ph_disable_bdof_flag is equal to 1-sps_bdof_enabled_flag.

[0347] – Otherwise (sps_bdof_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1 and num_ref_entries[1][RplsIdx[1]]==0), it is inferred that the value of ph_disable_bdof_flag is equal to 1.

[0348] Since the syntax element ph_disable_bdof_flag is explicitly sent via signal in the second and third conditions, it can be removed from the derivation of ph_disable_bdof_flag if it is not present:

[0349] The following applies when ph_disable_bdof_flag is not present:

[0350] – If sps_bdof_pic_present_flag equals 0, then it is inferred that the value of ph_disable_bdof_flag is equal to 1 - sps_bdof_enabled_flag.

[0351] Otherwise, it is assumed that the value of ph_disable_bdof_flag is equal to 1.

[0352] In addition, the signaling conditions for the syntax elements ph_collocated_from_l0_flag and weight_table() have been modified because these two types of syntax elements only apply when the associated stripes are B stripes.

[0353] Examples of these modified syntax element signaling are shown below.

[0354]

[0355] The semantics of ph_collocated_from_l0_flag have also been modified to handle cases where no signal notification is received.

[0356] A value of 1 for ph_collocated_from_l0_flag indicates that the co-located image used for temporal motion vector prediction comes from reference image list 0. A value of 0 for ph_collocated_from_l0_flag indicates that the co-located image used for temporal motion vector prediction comes from reference image list 1.

[0357] The following applies when ph_collocated_from_l0_flag is not present:

[0358] – If num_ref_entries[0][RplsIdx[0]] is greater than 1, then it is inferred that the value of ph_collocated_from_l0_flag is 1.

[0359] Otherwise (num_ref_entries[1][RplsIdx[1]] is greater than 1), the value of ph_collocated_from_l0_flag is inferred to be 0.

[0360]

[0361]

[0362]

[0363] Similarly, an example of an alternative condition check is shown below:

[0364] if (pps_weighted_bipred_flag&&wp_info_in_ph_flag&&(!rpl_info_in_ph_flag||(rpl_info_in_ph_flag&&num_ref_entries[1][RplsIdx[1]]>0)))

[0365] num_l1_weights

[0366] The semantics of the syntax elements in pred_weight_table() have also been modified to handle cases where they are not signaled.

[0367] num_l1_weights indicates the number of weights sent by the signal for the entries in reference image list 1 when both pps_weighted_bipred_flag and wp_info_in_ph_flag are equal to 1. The value of num_l1_weights should be between 0 and Min(15, num_ref_entries[1][RplsIdx[1]]), including endpoints.

[0368] The following is the exported variable NumWeightsL1:

[0369] if(!pps_weighted_bipred_flag)

[0370] NumWeightsL1=0

[0371] Otherwise (wp_info_in_ph_flag&&rpl_info_in_ph_flag&&

[0372] (num_ref_entries[0][RplsIdx[0]]==0||

[0373] num_ref_entries[1][RplsIdx[1]]>===0))

[0374] NumWeightsL1=0

[0375] Otherwise, if (wp_info_in_ph_flag) (5)

[0376] NumWeightsL1 = num_l1_weights

[0377] otherwise

[0378] NumWeightsL1=NumRefIdxActive[1]

[0379] In the semantics of the syntax elements in `pred_weight_table()`, when `num_l1_weights` is not presented, another way to deduce its value is as follows:

[0380] `num_l1_weights` indicates the number of weights sent via signal for the entries in reference image list 1 when both `pps_weighted_bipred_flag` and `wp_info_in_ph_flag` are equal to 1. The value of `num_l1_weights` should be between 0 and Min(15, num_ref_entries[1][RplsIdx[1]]), inclusive of endpoints. When it does not exist, the value of `num_l1_weights` is inferred to be 0.

[0381] The following is the exported variable NumWeightsL1:

[0382] if(!pps_weighted_bipred_flag)

[0383] NumWeightsL1=0

[0384] Otherwise, if (wp_info_in_ph_flag) (6)

[0385] NumWeightsL1 = num_l1_weights

[0386] otherwise,

[0387] NumWeightsL1=NumRefIdxActive[1]

[0388] In the semantics of the syntax elements in `pred_weight_table()`, when `num_l1_weights` is not presented, another way to deduce its value is as follows:

[0389] if (!pps_weighted_bipred_flag||(wp_info_in_ph_flag&&num_ref_entries[1][RplsIdx[1]]===0))

[0390] NumWeightsL1=0

[0391] Otherwise, if (wp_info_in_ph_flag)

[0392] NumWeightsL1 = num_l1_weights

[0393] otherwise,

[0394] NumWeightsL1=NumRefIdxActive[1]

[0395] Conceptually, a signaling condition is proposed to check whether the current image has reference images from both list0 and list1, and to use reference images for any syntax element applicable only to B-strips, thus avoiding redundant signaling bits. The check condition is not limited to the method described above for checking the size of the two reference image lists (e.g., list0 / list1 reference image lists), and the check condition can be any other method to indicate whether the current image has reference images from both list0 and list1 reference image lists. For example, a flag can be signaled to indicate whether the current image has both list0 and list1 reference images simultaneously.

[0396] When a syntax element is not signaled but reference picture list information is signaled in the picture header (PH), the value of the syntax element is derived to be either list0 or list1 reference pictures based on whether the current picture has list0 and list1 reference pictures or information about the reference pictures it has. In one example, when ph_collocated_from_l0_flag is not signaled, its value is inferred to be the only reference picture that the current picture has. In another example, when sps_bdof_enabled_flag is equal to 1 and sps_bdof_pic_present_flag is equal to 1 but ph_disable_bdof_flag is not signaled, according to the signaling condition proposed for ph_disable_bdof_flag, it means that num_ref_entries[0][RplsIdx[0]] is equal to 0 or num_ref_entries[1][RplsIdx[1]] is equal to 0. Therefore, in this case, ph_disable_bdof_flag is not signaled and is inferred to be 1. In the current VVC, not only the resolution of the co-located image can affect TMVP enabling, but also the offset of the image size used in scaling calculations can affect TMVP enabling. However, in the current VVC, the offset is not considered in the bitstream consistency of ph_temporal_mvp_enabled_flag.

[0397] In the second embodiment, a bitstream consistency constraint is proposed to be added to the current VVC, requiring that the value of ph_temporal_mvp_enabled_flag should depend on the offset applied to the image size for scaling calculation, as shown below:

[0398] When there is no reference image in the DPB that has the same spatial resolution and the same offset applied to the image size for scaling calculation, the value of ph_temporal_mvp_enabled_flag should be equal to 0.

[0399] The above sentence can also be written in another way as described below:

[0400] When the value of the variable RprConstraintsActive[i][j] in the DPB is 0 and there is no reference image, the value of ph_temporal_mvp_enabled_flag should be 0.

[0401] In current VVC, there is a requirement for bitstream consistency, meaning that the image pointed to by slice_collocated_ref_idx should be identical across all slices of the encoded image. However, when the encoded image has multiple slices and there is no common reference image among all these slices, this bitstream consistency cannot be satisfied.

[0402] In a third embodiment of the invention, the bitstream consistency requirement for ph_temporal_mvp_enabled_flag is modified to consider whether there is a common reference image among all stripes in the current image. Based on this embodiment, several exemplary modifications to the VVC specification are described below.

[0403] `ph_temporal_mvp_enabled_flag` indicates whether temporal motion vector prediction values ​​can be used for inter-frame prediction of slices associated with the PH. If `ph_temporal_mvp_enabled_flag` equals 0, the syntax elements of the slices associated with the PH should be constrained so that temporal motion vector prediction values ​​are not used in the decoding of these slices. Otherwise (if `ph_temporal_mvp_enabled_flag` equals 1), temporal motion vector prediction values ​​can be used to decode slices associated with the PH. When none exists, it is inferred that the value of `ph_temporal_mvp_enabled_flag` is equal to 0. The value of `ph_temporal_mvp_enabled_flag` should be equal to 0 when there is no reference picture in the DPB with the same spatial resolution as the current picture. The value of `ph_temporal_mvp_enabled_flag` should be equal to 0 when there is no common reference picture among all slices associated with the PH.

[0404] `ph_temporal_mvp_enabled_flag` indicates whether temporal motion vector prediction values ​​can be used for inter-frame prediction of slices associated with the PH. If `ph_temporal_mvp_enabled_flag` equals 0, the syntax elements of the slices associated with the PH should be constrained so that temporal motion vector prediction values ​​are not used in the decoding of these slices. Otherwise (if `ph_temporal_mvp_enabled_flag` equals 1), temporal motion vector prediction values ​​can be used to decode slices associated with the PH. When not present, it is inferred that the value of `ph_temporal_mvp_enabled_flag` is equal to 0. The value of `ph_temporal_mvp_enabled_flag` should be equal to 0 when there is no reference picture in the DPB with the same spatial resolution as the current picture. The value of `ph_temporal_mvp_enabled_flag` should be equal to 0 when there is no common reference picture among all intra-frame slices associated with the PH.

[0405] `ph_temporal_mvp_enabled_flag` indicates whether temporal motion vector prediction values ​​can be used for inter-frame prediction of slices associated with the PH. If `ph_temporal_mvp_enabled_flag` equals 0, the syntax elements of the slices associated with the PH should be constrained so that temporal motion vector prediction values ​​are not used in the decoding of these slices. Otherwise (if `ph_temporal_mvp_enabled_flag` equals 1), temporal motion vector prediction values ​​can be used to decode slices associated with the PH. When not present, it is inferred that the value of `ph_temporal_mvp_enabled_flag` is equal to 0. The value of `ph_temporal_mvp_enabled_flag` should be equal to 0 when there is no reference picture in the DPB with the same spatial resolution as the current picture. The value of `ph_temporal_mvp_enabled_flag` should be equal to 0 when there is no common reference picture among all non-intra-slices associated with the PH.

[0406] In the fourth embodiment, the bitstream consistency on slice_collocated_ref_idx is simplified as follows:

[0407] The values ​​of pic_width_in_luma_samples and pic_height_in_luma_samples of the reference image referenced by slice_collocated_ref_idx should be equal to the values ​​of pic_width_in_luma_samples and pic_height_in_luma_samples of the current image, respectively. Additionally, RprConstraintsActive[slice_collocated_from_l0_flag? 0:1][slice_collocated_ref_idx] should be equal to 0. This is a bitstream consistency requirement.

[0408] As discussed in the "Problem Statement" section, when the value of pps_mixed_nalu_types_in_pic_flag is equal to 1, each picture referencing the PPS has more than one NAL unit, and these NAL units do not have the same nal_unit_type. On the other hand, in the current picture header signaling, even when the value of the flag pps_mixed_nalu_types_in_pic_flag in the associated PPS is equal to 1, it is allowed to send the values ​​of ph_gdr_or_irap_pic_flag and ph_gdr_pic_flag as 1 via signaling. Because NAL units in an IRAP picture or a GDR picture must have the same nal_unit_type, this signaling scenario should not be allowed. Different approaches to address this problem are proposed below.

[0409] Method 1: In this first method, the presence of the flag `ph_gdr_or_irap_pic_flag` in the image header is conditional on the value of `pps_mixed_nalu_types_in_pic_flag` in PPS. Specifically, `ph_gdr_or_irap_pic_flag` is signaled only when the value of `pps_mixed_nalu_types_in_pic_flag` is equal to 0. Otherwise, when the flag `pps_mixed_nalu_types_in_pic_flag` is equal to 1, the flag `ph_gdr_or_irap_pic_flag` is not signaled and is inferred to be zero. The corresponding image header table after applying the proposed modifications is explained.

[0410]

[0411] Method 2: Method 2 proposes a bitstream consistency constraint, requiring that when the flag pps_mixed_nalu_types_in_pic_flag is equal to 1, the corresponding value of the signaling flag ph_gdr_or_irap_pic_flag should also be equal to 1. Specifically, the proposed bitstream consistency constraint can be explained as follows.

[0412] A value of 1 for `ph_gdr_or_irap_pic_flag` indicates that the current image is a GDR or IRAP image. A value of 0 for `ph_gdr_or_irap_pic_flag` indicates that the current image is not a GDR image and may or may not be an IRAP image. When the value of `pps_mixed_nalu_type_in_pic_flag` is 1, the value of `ph_gdr_or_irap_pic_flag` should be 0.

[0413] Method 3: This method proposes moving the signaling of `pps_mixed_nalu_types_in_pic_flag` from the PPS level to the picture level, stripe level, or other codec levels. For example, assuming this flag is moved to the picture caption, it can be renamed to `ph_mixed_nalu_type_in_pic_flag`. Furthermore, it proposes using this flag to adjust the signaling of `ph_gdr_or_irap_pic_flag`. Specifically, when the flag `ph_mixed_nalu_type_in_pic_flag` is equal to 0, only `ph_gdr_or_rap_pic_flag` is signaled. Otherwise, when the flag `ph_mixed_nalu_type_in_pic_flag` is 1, the flag `ph_gdr_or_rap_pic_flags` is not signaled and is inferred to be 0. In another embodiment, a bitstream consistency constraint is proposed, namely, that the value of ph_gdr_or_irap_pic_flag should be equal to 0 when the value of ph_mixed_nalu_type_in_pic_flag is equal to 1. In yet another embodiment, the presence of ph_mixed_nalu_type_in_pic_flag is regulated using ph_gdr_or_irap_pic_flag. Specifically, when the value of ph_gdr_or_rap_pic_flag is equal to 0, the flag ph_mixed_nalu_type_in_pic_flag is signaled only. Otherwise, when the value of ph_gdr_or_rap_pic_flag is equal to 1, the flag ph_mixed_nalu_type_in_pic_flag is not signaled and is always inferred to be zero.

[0414] Method 4 proposes applying the value of pps_mixed_nalu_type_in_pic_flag only to images that are neither IRAP nor GDR images. Specifically, using this method, the semantics of pps_mixed_nalu_type_in_pic_flag should be modified as follows:

[0415] A value of 1 for `pps_mixed_nalu_types_in_pic_flag` indicates that each image in the reference PPS that is neither an IRAP nor a GDR image has more than one VCL NAL unit, and these VCL NAL units do not have the same `nal_unit_type` value. A value of 0 for `pps_mixed_nalu_types_in_pic_flag` indicates that each image in the reference PPS that is neither an IRAP nor a GDR image has one or more VCL NAL units, and the VCL NAL units of each image in the reference PPS have the same `nal_unit_type` value.

[0416] On the other hand, the current VVC specification requires that all NAL units in a GDR picture must have the same nal_unit_type, which is equal to GDR_NUT. The following bitstream consistency constraint is applied to the definition of the GDR picture so that the corresponding value of pps_mixed_nal_types_in_pic_flag should be equal to 0.

[0417] Progressive Decoding Refresh (GDR) Images: Images where the nal_unit_type of each VCL NAL unit is equal to GDR_NUT. The pps_mixed_nalu_types_in_pic_flag value of a GDR image is 0. When an image's pps_mixed_nalu_types_in_pic_flag is 0 and any stripe of that image has a nal_unit_type of GDR_NUT, all other stripes of that image have the same nal_unit_type value, and the image is identified as a GDR image after receiving the first stripe of that image.

[0418] In another embodiment, it is proposed to remove the GDR NAL unit type from the NAL unit header, while using only the syntax elements ph_gdr_or_irap_pic_flag and ph_gdr_pic_flag to indicate whether the current image is a GDR image.

[0419] Unlike the methods described above that apply the constraints of pps_mixed_nalu_types_in_pic_flag to both IRAP and GDR images, three methods are presented below that apply the constraints to IRAP images instead of GDR images.

[0420] Method 1: In this first method, the presence of the flag `ph_gdr_pic_flag` in the image header is conditional on the value of `pps_mixed_nalu_types_in_pic_flag` in the PPS. Specifically, the flag `ph_gdr_pic_flag` is signaled only when the value of `pps_mixed_nalu_types_in_pic_flag` is equal to 0. Otherwise, when the flag `pps_mixed_nalu_types_in_pic_flag` is equal to 1, the flag `ph_gdr_pic_flag` is not signaled and is inferred to be zero; that is, the current image is not a GDR image. The corresponding image header table after applying the proposed signaling condition is modified as follows.

[0421]

[0422] A `ph_gdr_pic_flag` value of 1 indicates that the image associated with this `PH` is a GDR image. A `ph_gdr_pic_flag` value of 0 indicates that the image associated with this `PH` is not a GDR image. When `pps_mixed_nalu_types_in_pic_flag` is not present, the value of `ph_gdr_pic_flag` is inferred to be 0 when `pps_mixed_nalu_types_in_pic_flag` is 0, and the value of `ph_gdr_pic_flag` is inferred to be equal to the value of `ph_gdr_or_irap_pic_flag` when `pps_mixed_nalu_types_in_pic_flag` is 1. When `sps_gdr_enabled_flag` is 0, the value of `ph_gdr_pic_flag` should be 0.

[0423] Method 2: A bitstream consistency constraint is introduced when ph_gdr_or_irap_pic_flag is 1 and pps_mixed_nalu_types_in_pic_flag is 1, that is, ph_gdr_pic_flag should be equal to 1, as described below.

[0424] A `ph_gdr_pic_flag` value of 1 indicates that the image associated with this `PH` is a GDR image. A `ph_gdr_pic_flag` value of 0 indicates that the image associated with this `PH` is not a GDR image. When `ph_gdr_pic_flag` is not present, its value is presumed to be 0. When `sps_gdr_enabled_flag` is 0, the value of `ph_gdr_pic_flag` should be 0. When `ph_gdr_or_irap_pic_flag` is 1 and `pps_mixed_nalu_types_in_pic_flag` is 1, the value of `ph_gdr_pic_flag` should be 1.

[0425] Note 1 – When ph_gdr_or_irap_pic_flag equals 1 and ph_gdr_pic_flag equals 0, the image associated with this PH is an IRAP image.

[0426] Method 3 proposes applying the flag pps_mixed_nalu_types_in_pic_flag only to non-IRAP images. Specifically, in this method, the semantics of pps_mixed_nalu_types_in_pic_flag should be modified as follows.

[0427] A value of 1 for `pps_mixed_nalu_types_in_pic_flag` indicates that each non-IRAP picture referenced in the PPS has more than one VCL NAL unit, and these VCL NAL units do not have the same `nal_unit_type` value. A value of 0 for `pps_mixed_nalu_types_in_pic_flag` indicates that each non-IRAP picture referenced in the PPS has one or more VCL NAL units, and the VCL NAL units of each picture referenced in the PPS have the same `nal_unit_type` value.

[0428] According to the current VVC, ph_inter_slice_allowed_flag equal to 0 indicates that all coded slices of the image have a sh_slice_type equal to 2. ph_inter_slice_allowed_flag equal to 1 indicates that the image may or may not contain one or more coded slices with a sh_slice_type equal to 0 or 1. ph_gdr_pic_flag equal to 1 indicates that the image associated with the PH is a GDR image. ph_gdr_pic_flag equal to 0 indicates that the image associated with the PH is not a GDR image. When it does not exist, the value of ph_gdr_pic_flag is inferred to be 0. When sps_gdr_enabled_flag equals 0, the value of ph_gdr_pic_flag should be 0. According to this disclosure, the value of ph_inter_slice_allowed_flag is inferred based on the value of ph_gdr_pic_flag. For example, if the PH is a GDR image, the ph_inter_slice_allowed_flag is not sent via the signal at the corresponding encoding level. An example of the decoding process in the VVC draft is shown below. Changes to the VVC draft are shown in bold and italics.

[0429]

[0430] In addition, it was proposed to add a bitstream consistency constraint when ph_gdr_pic_flag equals 1, that is, the value of ph_inter_slice_allowed_flag should be equal to 1.

[0431] A ph_inter_slice_allowed_flag value of 0 indicates that all coded slices in the image have a sh_slice_type of 2. A ph_inter_slice_allowed_flag value of 1 indicates that the image may or may not contain one or more coded slices with a sh_slice_type of 0 or 1.

[0432] When ph_gdr_or_irap_pic_flag equals 1, ph_gdr_pic_flag equals 0 (i.e., the image is an IRAP image), and vps_independent_layer_flag[GeneralLayerIdx[nuh_layer_id]] equals 1, the value of ph_inter_slice_allowed_flag should be equal to 0.

[0433] When ph_gdr_pic_flag equals 1, the value of ph_inter_slice_allowed_flag should also equal 1.

[0434] The methods described above can be implemented using an apparatus comprising one or more circuits, including application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components. The apparatus can also perform the methods using circuits combined with other hardware or software components. Each module, submodule, unit, or subunit disclosed above can be implemented, at least partially, using one or more circuits.

[0435] Figure 8 A computing environment (or computing device) 810 coupled to a user interface 860 is shown. The computing environment 810 may be part of a data processing server. The computing environment 810 includes a processor 820, memory 840, and I / O interface 850. In some embodiments, the computing device 810 may be used to implement an encoder (such as an encoder or decoder) that performs any video encoding process as described herein, including, for example, any encoding process or any decoding process.

[0436] Processor 820 typically controls the overall operation of computing environment 810, such as operations related to display, data acquisition, data communication, and image processing. Processor 820 may include one or more processors to execute instructions to perform all or some of the steps described above. Furthermore, processor 820 may include one or more modules that facilitate interaction between processor 820 and other components. The processor may be a central processing unit (CPU), microprocessor, microcontroller, GPU, etc.

[0437] Memory 840 is configured to store various types of data to support the operation of computing environment 810. Memory 840 may include predefined software 842. Examples of such data include instructions for any application or method operating on computing environment 810. Memory 840 can be implemented using any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0438] I / O interface 850 provides an interface between processor 820 and peripheral interface modules, such as a keyboard, click wheel, and buttons. Buttons may include, but are not limited to, a home button, a start scan button, and a stop scan button. I / O interface 850 can be coupled to encoders and decoders.

[0439] In some embodiments, a non-transitory computer-readable storage medium is also provided, which includes multiple programs, such as those included in memory 840, and is executable by processor 820 in computing environment 810 to perform the methods described above. For example, the non-transitory computer-readable storage medium may be ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0440] A non-transitory computer-readable storage medium stores a plurality of programs for execution by a computing device having one or more processors, wherein the plurality of programs, when executed by the one or more processors, cause the computing device to perform the motion prediction method described above.

[0441] In some embodiments, the computing environment 810 may be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs) for performing the methods described above, graphics processing units (GPUs), controllers, microcontrollers, microprocessors, or other electronic components.

[0442] Other examples of this disclosure will be apparent to those skilled in the art upon consideration of the specification and the practice of this disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure, following its general principles, and including deviations from this disclosure that are known or customary in the art. The specification and examples are intended to be illustrative only.

[0443] It should be understood that this disclosure is not limited to the exact examples shown above and in the accompanying drawings, and various modifications and variations can be made without departing from its scope.

Claims

1. A video data decoding method, comprising: The decoder receives the bitstream associated with the video data; At the decoder, syntax elements are obtained from the bitstream; as well as The video data is decoded at the decoder based on the syntax elements. The syntax elements include no_act_constraint_flag and no_chroma_qp_offset_constraint_flag, both of which are equal to 1 when the chroma format is non-monochrome. When max_chroma_format_constraint_idc is equal to 0, no_act_constraint_flag is equal to 1, and when max_chroma_format_constraint_idc is equal to 0, no_chroma_qp_offset_constraint_flag is equal to 1.

2. The method of claim 1, wherein, When the stripe is an intra-frame stripe and when intra_only_constraint_flag is equal to 1, the syntax element includes no_sbt_constraint_flag equal to 1.

3. The method according to claim 1, wherein, When affine mode is disabled, the syntax element includes no_prof_constraint_flag equal to 1, and no_prof_constraint_flag equals 1 when no_affine_motion_constraint_flag equals 1.

4. The method according to claim 1, wherein, When the transform skip mode is disabled, the syntax element includes no_bdpcm_constraint_flag equal to 1, and no_bdpcm_constraint_flag equals 1 when no_transform_skip_constraint_flag equals 1.

5. The method according to claim 1, wherein, When an image has a sub-image, the syntax element includes no_mixed_nalu_types_in_pic_constraint_flag equal to 1, and no_mixed_nalu_types_in_pic_constraint_flag equals 1 when one_subpic_per_pic_constraint_flag equals 1.

6. The method according to claim 1, wherein, The syntax element indicates that the strip is a bidirectional prediction strip (B-strip).

7. The method according to claim 1, wherein, The syntax elements include ph_collocated_from_l0_flag and weight_table().

8. The method according to claim 7, wherein, The syntax elements include flags that indicate conditions in the image header to prevent redundant signaling, and the syntax elements include mvd_l1_zero_flag, ph_disable_bdof_flag, and ph_disable_dmvr_flag.

9. The method according to claim 8, wherein, The conditions in the image header include: In response to determining that rpl_info_in_ph_flag is not equal to 1 or determining that rpl_info_in_ph_flag is equal to 1 and num_ref_entries[1][RplsIdx[1]] is greater than 0, it is determined that mvd_l1_zero_flag is sent by signal.

10. The method according to claim 8, wherein, The conditions in the image header include: In response to determining that sps_dmvr_pic_present_flag is equal to 1, and determining that rpl_info_in_ph_flag is not equal to 1 or that rpl_info_in_ph_flag is equal to 1 and num_ref_entries[0][RplsIdx[0]] is greater than 0 and num_ref_entries[1][RplsIdx[1]] is greater than 0, it is determined that ph_disable_dmvr_flag is sent by a signal.

11. The method according to claim 8, wherein, The conditions in the image header include: In response to sps_dmvr_enabled_flag being equal to 1 and sps_dmvr_pic_present_flag being equal to 0, it is inferred that ph_disable_dmvr_flag is equal to 0; In response to the fact that sps_dmvr_enabled_flag equals 1 and sps_dmvr_pic_present_flag equals 1, it is inferred that ph_disable_dmvr_flag equals 1; and In response to the fact that sps_dmvr_enabled_flag is equal to 0, it is inferred that ph_disable_dmvr_flag is equal to 1.

12. The method according to claim 8, wherein, The conditions in the image header include: In response to sps_dmvr_enabled_flag being equal to 1 and sps_dmvr_pic_present_flag being equal to 0, it is inferred that the value of ph_disable_dmvr_flag is equal to 0; In response to the fact that sps_dmvr_enabled_flag equals 1, sps_dmvr_pic_present_flag equals 1, and rpl_info_in_ph_flag equals 0, it is inferred that the value of ph_disable_dmvr_flag is equal to the value sent via the signal; and In response to the fact that sps_dmvr_enabled_flag is equal to 1 and sps_dmvr_pic_present_flag is equal to 1 and rpl_info_in_ph_flag is equal to 1 and num_ref_entries[1][RplsIdx[1]] is greater than 0, it is inferred that the value of ph_disable_dmvr_flag is equal to the value sent by the signal.

13. The method according to claim 8, wherein, The conditions in the image header include: In response to sps_bdof_enabled_flag being equal to 1 and sps_bdof_pic_present_flag being equal to 0, it is inferred that the value of ph_disable_bdof_flag is equal to 0; In response to the fact that sps_bdof_enabled_flag equals 1 and sps_bdof_pic_present_flag equals 1, it is inferred that the value of ph_disable_dmvr_flag is equal to 1; and In response to the fact that sps_bdof_enabled_flag is equal to 0, it is inferred that the value of ph_disable_bdof_flag is equal to 1.

14. The method according to claim 8, wherein, The conditions in the image header include: In response to sps_bdof_enabled_flag being equal to 1 and sps_bdof_pic_present_flag being equal to 0, it is inferred that the value of ph_disable_bdof_flag is equal to 0; In response to the fact that sps_bdof_enabled_flag is equal to 0 and sps_bdof_pic_present_flag is equal to 0, it is inferred that the value of ph_disable_bdof_flag is equal to 1; In response to the fact that sps_bdof_enabled_flag equals 1, sps_bdof_pic_present_flag equals 1, and rpl_info_in_ph_flag equals 0, it is inferred that the value of ph_disable_bdof_flag is equal to the value sent by the signal; In response to the fact that sps_bdof_enabled_flag equals 1, sps_bdof_pic_present_flag equals 1, rpl_info_in_ph_flag equals 1, and num_ref_entries[1][RplsIdx[1]] is greater than 0, it is inferred that the value of ph_disable_bdof_flag is equal to the value sent by the signal; and In response to the fact that sps_bdof_enabled_flag is equal to 1, sps_bdof_pic_present_flag is equal to 1, rpl_info_in_ph_flag is equal to 1 and num_ref_entries[1][RplsIdx[1]] is equal to 0, it is inferred that the value of ph_disable_bdof_flag is equal to 1.

15. The method according to claim 8, wherein, The conditions in the image header include: In response to determining that ph_temporal_mvp_enabled_flag is equal to 1, num_ref_entries[0][RplsIdx[0]] is greater than 0 and num_ref_entries[1][RplsIdx[1]] is greater than 0, it is determined that ph_collocated_from_l0_flag is sent by signal.

16. The method according to claim 8, wherein, The conditions in the image header include: In response to num_ref_entries[0][RplsIdx[0]] being greater than 1, it is inferred that the value of ph_collocated_from_l0_flag is equal to 1; and In response to num_ref_entries[1][RplsIdx[1]] being greater than 1, it is inferred that the value of ph_collocated_from_l0_flag is equal to 0.

17. The method according to claim 8, wherein, The conditions in the image header include: In response to pps_weighted_bipred_flag being equal to 1, wp_info_in_ph_flag being equal to 1, and rpl_info_in_ph_flag being equal to 0, or rpl_info_in_ph_flag and num_ref_entries[1][RplsIdx[1]] being greater than 0, it is determined that num_l1_weights is sent by signal.

18. The method according to claim 8, wherein, The conditions in the image header include: In response to determining that wp_info_in_ph_flag is equal to 1, rpl_info_in_ph_flag is equal to 1 and num_ref_entries[0][RplsIdx[0]] is equal to 0 or num_ref_entries[1][RplsIdx[1] is greater than or equal to 0, determine that NumWeightsL1 is equal to 0.

19. The method according to claim 8, wherein, The conditions in the image header include: In response to (!pps_weighted_bipred_flag||(pps_wp_info_in_ph_flag&&num_ref_entries[1][RplsIdx[1]]==0)) being equal to 1, it is determined that NumWeightsL1 is equal to 0.

20. The method according to claim 9, wherein, The conditions in the image header include: In response to determining that ph_gdr_pic_flag is equal to 0, it is determined that ph_inter_slice_allowed_flag is sent via a signal.

21. The method according to claim 1, further comprising: Receive bitstream consistency constraints, which are based on the value of the offset indicator ph_temporal_mvp_enabled_flag applied to the image size.

22. The method according to claim 21, wherein, In response to the absence of a reference image in the decoded image buffer (DPB) with a related variable value of RprConstraintsActive equal to 0, the ph_temporal_mvp_enabled_flag is set to 0.

23. The method according to claim 1, further comprising: Receive bitstream consistency constraints, which are based on the value of ph_temporal_mvp_enabled_flag, which indicates the common reference image between stripes in the current image.

24. The method according to claim 23, wherein, In response to the absence of a common reference image in the strip associated with the image header, the ph_temporal_mvp_enabled_flag is set to 0.

25. The method according to claim 23, wherein, In response to the absence of a common reference image in a non-intra-frame strip associated with the image header, the ph_temporal_mvp_enabled_flag is set to 0.

26. The method according to claim 23, wherein, The bitstream consistency constraint also indicates that the pic_width_in_luma_samples and pic_height_in_luma_samples values ​​of the reference image referenced by the slice_collocated_ref_idx value are equal to the pic_width_in_luma_samples and pic_height_in_luma_samples values ​​of the current image.

27. The method according to claim 1, further comprising: In response to determining that pps_mixed_nalu_types_in_pic_flag is equal to 0, it is determined that ph_gdr_or_irap_pic_flag is sent via a signal.

28. The method according to claim 1, further comprising: In response to determining that the value of pps_mixed_nalu_type_in_pic_flag is equal to 1, the value of ph_gdr_or_irap_pic_flag is determined to be equal to 0.

29. The method according to claim 1, wherein, The syntax element includes pps_mixed_nalu_types_in_pic_flag.

30. The method according to claim 29, wherein, pps_mixed_nalu_types_in_pic_flag equals 1 and indicates that at least one progressively decoded refresh (GDR) picture, which is neither an Intra-Frame Random Access Point (IRAP) nor a Reference Picture Parameter Set (PPS), has more than one Video Coding Layer (VCL) Network Abstraction Layer (NAL) unit.

31. The method according to claim 29, wherein, The value of pps_mixed_nalu_types_in_pic_flag for a GDR image is equal to 0. When pps_mixed_nalu_types_in_pic_flag for an image is equal to 0 and the stripes of the image have a nal_unit_type equal to GDR_NUT, all other stripes of the image have the same nal_unit_type value, and the image is considered a GDR image after the first stripe of the image is received.

32. The method according to claim 1, wherein, The syntax element includes ph_gdr_pic_flag, and the presence of ph_gdr_pic_flag in the image header is based on the value of pps_mixed_nalu_types_in_pic_flag in PPS.

33. The method according to claim 32, wherein, In response to pps_mixed_nalu_types_in_pic_flag being equal to 0, ph_gdr_pic_flag is sent via a signal.

34. The method according to claim 32, wherein, When ph_gdr_pic_flag does not exist, the value of ph_gdr_pic_flag is inferred to be equal to 0 when pps_mixed_nalu_types_in_pic_flag is 0, and the value of ph_gdr_or_irap_pic_flag is inferred to be equal to the value of ph_gdr_or_irap_pic_flag when pps_mixed_nalu_types_in_pic_flag is 1.

35. The method according to claim 1, wherein, The syntax element includes ph_gdr_pic_flag, and the value of ph_gdr_pic_flag is equal to 0 when sps_gdr_enabled_flag is equal to 0.

36. The method according to claim 32, wherein, The syntax element includes a ph_gdr_pic_flag indicating whether the image associated with the image header is a GDR image, wherein the ph_gdr_pic_flag is equal to 1 when ph_gdr_or_irap_pic_flag is equal to 1 and pps_mixed_nalu_types_in_pic_flag is equal to 1.

37. The method according to claim 1, wherein, The syntax element includes pps_mixed_nalu_types_in_pic_flag, where pps_mixed_nalu_types_in_pic_flag equal to 1 indicates that at least one non-intra-random access point (IRAP) picture of the reference picture parameter set (PPS) has more than one video coding layer (VCL) network abstraction layer (NAL) unit, and pps_mixed_nalu_types_in_pic_flag equal to 0 indicates that at least one non-IRAP picture of the reference PPS has one or more VCL NAL units.

38. The method according to claim 1, wherein, The syntax element includes `ph_inter_slice_allowed_flag`, where `ph_inter_slice_allowed_flag` equals 0 when the encoded slices of the image have an `sh_slice_type` equal to 2, and where... When ph_gdr_pic_flag equals 1, the ph_inter_slice_allowed_flag equals 1.

39. The method according to claim 1, wherein, The syntax elements include no_deblocking_filter_constraint_flag, which indicates that the deblocking filter is disabled.

40. The method according to claim 39, wherein, In response to pps_deblocking_filter_disabled_flag, ph_deblocking_filter_disabled_flag and sh_deblocking_filter_disabled_flag being equal to 1, no_deblocking_filter_constraint_flag is equal to 1.

41. An apparatus for video decoding, comprising: One or more processors; and A non-transitory computer-readable storage medium configured to store instructions executable by one or more processors; wherein the one or more processors, when executing the instructions, are configured to perform the method of any one of claims 1-40.

42. A non-transitory computer-readable storage medium for video decoding, the non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by one or more computer processors, cause the one or more computer processors to perform the method of any one of claims 1-40.

Images