Prediction type signaling in video coding
The implementation of decoder-side motion vector refinement and adaptive resolution management in video coding standards addresses inefficiencies in ARC and RPR, enhancing coding efficiency and user experience in dynamic resolution scenarios.
Patent Information
- Application Number
- JP2023204308
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2019-10-12
- Filing Date
- 2023-12-04
- Publication Date
- 2026-01-06
- Estimated Expiration
- 2040-10-12
AI Technical Summary
Current video coding standards lack efficient mechanisms for adaptive resolution change (ARC) and reference picture resampling (RPR), leading to increased complexity, resource usage, and poor user experience in scenarios requiring dynamic resolution adjustments.
Implement methods for video processing that include decoder-side motion vector refinement, bidirectional optical flow coding, and adaptive resolution management, utilizing interpolation filters and adaptation windows to handle resolution differences between reference and current video blocks, enabling seamless resolution changes.
Enhances video coding efficiency by reducing complexity and resource usage during dynamic resolution changes, improving user experience in video conferencing and streaming applications.
Smart Images

Figure 0007794791000114 
Figure 0007794791000115 
Figure 0007794791000116
Abstract
Description
[Technical Field]
[0001] This application is a divisional application of Patent Application No. 2022-521586, which is based on International Patent Application No. PCT / CN2020 / 120289 filed on October 12, 2020, which claims priority to and the benefit of International Patent Application No. PCT / CN2019 / 110902 filed on October 12, 2019. All of the foregoing applications are incorporated herein by reference in their entireties.
[0002] This patent document relates to video coding techniques, devices and systems. [Background technology]
[0003] Efforts are currently underway to improve the performance of current video codec technology, either to provide better compression ratios or to provide video coding and decoding schemes that are lower in complexity or allow for parallel implementation. Industry experts have recently proposed several new video coding tools, and testing is currently underway to determine their effectiveness. Summary of the Invention
[0004] Devices, systems, and methods related to digital video coding, particularly those related to motion vector management, are described. The described methods may be applied to both existing video coding standards (e.g., High Efficiency Video Coding (HEVC)) or general-purpose video coding and future video coding standards or codecs.
[0005] In one exemplary aspect, the disclosed technology can be used to provide a method for video processing, the method including performing a conversion between a video and a bitstream representation of the video, the bitstream representation conforming to format rules that specify that applicability of decoder-side motion vector refinement coding tools and bidirectional optical flow coding tools to the video pictures be indicated separately in the bitstream representation.
[0006] In another representative aspect, the disclosed techniques may be used to provide a method for video processing, the method including performing a conversion between a picture of a video and a bitstream representation of the video, the bitstream representation conforming to format rules specifying the use of coding tools indicated in a picture header corresponding to the video picture.
[0007] In another representative aspect, the disclosed techniques may be used to provide a method for video processing. The method includes performing a conversion between a video including a video picture including one or more video units and a bitstream representation of the video, the bitstream representation conforming to format rules specifying that a first syntax element be included in a picture header indicating allowed prediction types for at least some of the one or more video units in the video picture.
[0008] In another representative aspect, the disclosed techniques may be used to provide a method for video processing that includes performing a transformation between a current video block and a coded representation of the current video block, where, during the transformation, if the resolution and / or size of the reference picture differs from the resolution and / or size of the current video block, the same interpolation filter is applied to groups of adjacent or non-adjacent samples that are predicted using the current video block.
[0009] In another representative aspect, the disclosed techniques may be used to provide another method for video processing that includes performing a conversion between a current video block and a coded representation of the current video block, wherein, during the conversion, if a resolution and / or size of a reference picture differs from a resolution and / or size of the current video block, a block predicted using the current video block is only allowed to use integer-value motion information related to the current block.
[0010] In another representative aspect, the disclosed techniques may be used to provide another method for video processing, which includes performing a conversion between a current video block and a coded representation of the current video block, where, during the conversion, if a resolution and / or size of a reference picture differs from a resolution and / or size of the current video block, an interpolation filter is applied to derive a predicted block using the current video block, and the interpolation filter is selected based on a rule.
[0011] In another representative aspect, the disclosed techniques may be used to provide another method for video processing, including performing a transformation between a current video block and a coded representation of the current video block, wherein, during the transformation, if a resolution and / or size of a reference picture differs from a resolution and / or size of the current video block, selectively applying a deblocking filter, the strength of the deblocking filter being set according to a rule relating the resolution and / or size of the reference picture to the resolution and / or size of the current video block.
[0012] In another representative aspect, the disclosed techniques may be used to provide another method for video processing that includes performing a transformation between a current video block and a coded representation of the current video block, where the reference picture for the current video block is resampled according to a rule that is based on dimensions of the current video block.
[0013] In another representative aspect, the disclosed techniques may be used to provide another method for video processing that includes performing a conversion between a current video block and a coded representation of the current video block, wherein use of coding tools for the current video block is selectively enabled or disabled depending on the resolution / size of a reference picture for the current video block relative to the resolution / size of the current video block.
[0014] In another representative aspect, the disclosed techniques may be used to provide another method for video processing, the method including performing a conversion between a plurality of video blocks and a coded representation of the plurality of video blocks, wherein during the conversion, a first adaptation window is defined for the first video block and a second adaptation window is defined for the second video block, and a width and / or height ratio of the first adaptation window to the second adaptation window complies with at least a rule based on the adaptation bitstream.
[0015] In another representative aspect, the disclosed techniques may be used to provide another method for video processing, the method including performing a conversion between a plurality of video blocks and a coded representation of the plurality of video blocks, wherein during the conversion, a first adaptation window is defined for the first video block and a second adaptation window is defined for the second video block, and a width and / or height ratio of the first adaptation window to the second adaptation window complies with at least a rule based on the adaptation bitstream.
[0016] Additionally, in a representative aspect, an apparatus in a video system is disclosed that includes a processor and a non-transitory memory having instructions that, when executed by the processor, cause the processor to implement any one or more of the disclosed methods.
[0017] In one representative aspect, a video decoding device is disclosed that includes a processor configured to implement the methods described herein.
[0018] In one representative aspect, a video encoding device is disclosed that includes a processor configured to implement the methods described herein.
[0019] Disclosed is a non-transitory computer program product stored on a non-transitory computer readable medium, the computer program product including program code for performing any one or more of the disclosed methods.
[0020] The above aspects and features of the disclosed technology are described in more detail in the drawings, specification and claims. [Brief explanation of the drawings]
[0021] [Figure 1] 1 shows examples of sub-block motion vectors (VSB) and motion vector differences. [Figure 2] An example is shown in which a 16x16 video block is divided into sixteen 4x4 regions. [Figure 3A] Examples of specific locations within a sample are shown below. [Figure 3B] Another example of a specific location within a sample is shown. [Figure 3C] 10 shows yet another example of a specific location within a sample. [Figure 4A] An example of the position of the current sample and its reference sample is shown. [Figure 4B] 10 shows another example of the positions of the current sample and its reference sample. [Figure 5] FIG. 1 is a block diagram of an example hardware platform for implementing the visual media decoding or visual media encoding techniques described in this document. [Figure 6] 1 shows a flowchart of an exemplary method for video coding. [Figure 7]FIG. 1 is a block diagram of an example video processing system in which the disclosed techniques may be implemented. [Figure 8] 1 is a block diagram illustrating an example video coding system. [Figure 9] FIG. 2 is a block diagram illustrating an encoder according to some embodiments of the present disclosure. [Figure 10] FIG. 2 is a block diagram illustrating a decoder according to some embodiments of the present disclosure. [Figure 11] 1 is a flowchart representation of a video processing method in accordance with the present technology. [Figure 12] 1 is a flowchart representation of another video processing method in accordance with the present technology. [Figure 13] 10 is a flowchart representation of yet another video processing method in accordance with the present technology. DETAILED DESCRIPTION OF THE INVENTION
[0022] 1. Video Coding in HEVC / H.265 Video coding standards have evolved primarily through the development of well-known ITU-T and ISO / IEC standards. ITU-T created H.261 and H.263, while ISO / IEC created MPEG-1 and MPEG-4 Visual. The two organizations jointly developed the H.262 / MPEG-2 Video and H.264 / MPEG-4 Advanced Video Coding (AVC) standards and the H.265 / HEVC standard. Starting with H.262, video coding standards have been based on a hybrid video coding architecture that utilizes temporal prediction plus transform coding. In 2015, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) to explore future video coding technologies beyond HEVC. Since then, many new methods have been adopted by the JVET and incorporated into reference software, named the Joint Exploration Model (JEM). In April 2018, the Joint Video Expert Team (JVET) was established by VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) to work on the VVC standard, which aims to reduce the bitrate by 50% compared to HEVC.
[0023] 2. Overview 2.1. Adaptive Resolution Scale (ARC) AVC and HEVC do not have the ability to change resolution without having to introduce IDR or Intra Random Access Point (IRAP) pictures; such a capability is sometimes called Adaptive Resolution Change (ARC). Use cases and application scenarios that benefit from the ARC feature include:
[0024] Rate Adaptation in Video Telephony and Conferencing: To adapt coded video to changing network conditions, when network conditions worsen and available bandwidth decreases, the encoder may adapt by encoding pictures with smaller resolutions. Currently, picture resolution changes can only be made after IRAP pictures, but this presents several problems. Reasonable-quality IRAP pictures are much larger than inter-coded pictures, and decoding is correspondingly more complex, which takes time and resources. This becomes problematic when a resolution change is required by the decoder for load reasons. It would destroy low-delay buffering requirements, force audio resynchronization, and increase the end-to-end delay of the stream, at least temporarily. This can result in a poor user experience.
[0025] - Active speaker change in multi-party video conference: In multi-party video conference, it is common for the active speaker to be shown with a larger video size than the videos of the remaining conference participants. When the active speaker changes, the picture resolution for each participant also needs to be refined. The need for having ARC function becomes more and more when such changes of the active speaker occur frequently.
[0026] - Fast start in streaming: In streaming applications, it is common for the application to buffer up to a certain length of decoded pictures before starting to display them. Starting the bitstream at a smaller resolution allows the application to have enough pictures in the buffer to start displaying sooner.
[0027] Adaptive stream switching in streaming: The Dynamic Adaptive Streaming over HTTP (DASH) specification has a feature named @mediaStreamStructureId, which enables switching between different representations at open GOP random access points with non-decodable leading pictures, such as a CRA picture with an associated RASL picture in HEVC. When two different representations of the same video have different bitrates but the same spatial resolution while the @mediaStreamStructureId value is the same, switching between the two representations can be performed at a CRA picture with an associated RASL picture, allowing the RASL picture associated with the switching CRA picture to be decoded with acceptable quality, thus enabling seamless switching. In ARC, the @mediaStreamStructureId feature can also be used to switch between DASH representations with different spatial resolutions.
[0028] ARC is also known as dynamic resolution conversion.
[0029] ARC may also be considered as a special case of Reference Picture Resampling (RPR) as per H.263 Annex P.
[0030] 2.2. Reference Picture Resampling in H.263 Annex P This mode describes an algorithm to warp a reference picture before using it for prediction. This can be useful for resampling a reference picture that has a different source format than the picture being predicted. It can also be useful for global or rotational motion estimation by warping the shape, size, and position of the reference picture. The syntax includes the warp parameters used as well as the resampling algorithm. The simplest operational level of the reference picture resampling mode is the implicit 4 resampling factor, since only an FIR filter needs to be applied to the upsampling and downsampling processes. In this case, no additional signaling overhead is required, since its use is understood when the size of the new picture (indicated in the picture header) is different from that of the previous picture.
[0031] 2.3. VVC Adaptation Window A relevance window in VVC defines a rectangle. Samples within the relevance window belong to the picture of interest. Samples outside the relevance window may be discarded at output.
[0032] When a fitting window is applied, a scaling ratio in the RPR is derived based on the fitting window. [Table 1] pic_width_in_luma_samples specifies the width of each decoded picture referencing the PPS in units of luma samples. pic_width_in_luma_samples shall not be equal to 0, shall be an integer multiple of Max(8,MinCbSizeY), and shall be less than or equal to pic_width_max_in_luma_samples. When subpics_present_flag is equal to 1, the value of pic_width_in_luma_samples shall be equal to pic_width_max_in_luma_samples. pic_height_in_luma_samples specifies the height of each decoded picture referencing the PPS in units of luma samples. pic_height_in_luma_samples shall not be equal to 0, shall be an integer multiple of Max(8,MinCbSizeY), and shall be less than or equal to pic_height_max_in_luma_samples. When subpics_present_flag is equal to 1, the value of pic_height_in_luma_samples shall be equal to pic_height_max_in_luma_samples. refPicWidthInLumaSamples and refPicHeightInLumaSamples shall be the pic_width_in_luma_samples and pic_height_in_luma_samples, respectively, of the reference picture of the current picture that references this PPS. The requirements for bitstream conformance are that the following conditions be met: [Outside 1] A conformance_window_flag equal to TIFF0007794791000002.tif541691 indicates that conformance cropping window offset parameters follow the SPS. A conformance_window_flag equal to 0 indicates that conformance cropping window offset parameters are not present. conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset specify the sample of the picture in the CVS output from the decoding process with respect to the rectangular area specified in picture coordinates for output. When conformance_window_flag is equal to 0, the values of conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset are inferred to be equal to 0. The adaptive cropping window has horizontal picture coordinates from SubWidthC*conf_win_left_offset to pic_width_in_luma_samples-(SubWidthC*conf_win_right_offset+1) inclusive, and vertical picture coordinates from SubHeightC*conf_win_top_offset to pic_height_in_luma_samples-(SubHeightC*conf_win_bottom_offset+1) inclusive. The value of SubWidthC*(conf_win_left_offset+conf_win_right_offset) is smaller than pic_width_in_luma_samples, and the value of SubHeightC*(conf_win_top_offset+conf_win_bottom_offset) is smaller than pic_height_in_luma_samples. The variables PicOutputWidthL and PicOutputHeightL are derived as follows:
number
[0033] 2.4. Reference Picture Resampling (RPR) In some implementations, ARC is also known as reference picture resampling (RPR). In RPR, TMVP is disabled when a co-located picture has a different resolution than the current picture. Furthermore, bidirectional optical flow (BDOF) and decoder-side motion vector refinement (DMVR) are disabled when the reference picture has a different resolution than the current picture.
[0034] To handle regular MC when the reference picture has a different resolution than the current picture, the interpolation section defines the following: 8.5.6.3. Fractional Sample Interpolation Process 8.5.6.3.1 Overview The inputs to this process are: - a luminance position (xSb, ySb) specifying the top-left sample of the current coding sub-block relative to the top-left sample of the current picture - variable sbWidth that specifies the width of the current coding sub-block - variable sbHeight that specifies the height of the current coding sub-block - Motion vector offset mvOffset - Refined motion vectors refMvLX - selected reference picture sample array refPicLX - Half-sample interpolation filter index hpelIfIdx - Bidirectional optical flow flag bdofFlag - variable cIdx that specifies the color component index of the current block The output of this process is as follows: - predSamplesLX, a (sbWidth+brdExtSize)x(sbHeight+brdExtSize) array of predicted sample values The prediction block boundary extension size brdExtSize is derived as follows.
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
number
[0035] 2.5. Refined Sub-Block-Based Affine Motion Compensation Prediction The techniques disclosed herein include a method for refining sub-block-based affine motion compensation prediction with optical flow. After sub-block-based affine motion compensation is performed, the predicted samples are refined by adding differentials derived from optical flow equations, called prediction refinement by optical flow (PROF). The proposed method can achieve inter-pixel prediction without increasing memory access bandwidth.
[0036] To achieve finer granularity of motion compensation, this contribution proposes a method to refine sub-block-based affine motion compensation prediction by optical flow. After sub-block-based affine motion compensation is performed, the luma prediction samples are refined by adding the difference derived by the optical flow equation. The proposed prediction refinement with optical flow (PROF) is described in the following four steps: Step 1) Sub-block based affine motion compensation is performed to generate the sub-block prediction I(i,j). Step 2) Spatial gradients of subblock predictions g x (i,j) and g y (i,j) is calculated at each sample location using a 3-tap filter [-1,0,1].
number
[0037] Subblock predictions are extended by one pixel on each side for gradient computation. To reduce memory bandwidth and complexity, pixels on the extended boundaries are copied from the nearest integer-pixel location in the reference picture. Thus, additional interpolation for the padding area is avoided. Step 3) The luminance prediction accuracy (denoted as ΔI) is calculated by the optical flow equation.
number
[0038] Because the affine model parameters and pixel location relative to the sub-block center do not change from sub-block to sub-block, Δv(i,j) can be calculated for the first sub-block and reused for other sub-blocks within the same CU. Let x and y be the horizontal and vertical offsets from the pixel location to the sub-block center, Δv(x,y) can be derived by the following equation:
number
number
number
number
[0039] Some details are described as follows:
[0040] a) How to derive the gradient of PROF
[0041] In some embodiments, a gradient is calculated for each sub-block (4x4 sub-block in VTM-4.0) for each reference list. For each sub-block, the nearest integer sample of the reference block is fetched to pad the four edges of the sample.
[0042] Let the MV for the current sub-block be (MVx,MVy). Then the fractional part is calculated as (FracX,FracY)=(MVx&15,,MVy&15). The integer part is calculated as (IntX,IntY)=(MVx>>4,MVy>>4). The offset (OffsetX,OffsetY) is derived as follows:
number
[0043] Let the top left coordinate of the current sub-block be (xCur, yCur) and the dimensions of the current sub-block be W x H. Then, (xCor0, yCor0), (xCor1, yCor1), (xCor2, yCor2) and (xCor3, yCor3) are calculated as follows:
number
[0044] Let PredSample[x][y] (x=0..W-1, y=0...H-1) store the predicted samples for a sub-block. Then, the padding samples are derived as follows:
number
[0045] The slope of PROF is calculated as follows:
number
[0046] Note that predSamples[x][y] maintains precision after interpolation.
[0047] a) How to derive Δv for PROF
[0048] The derivation of Δv (expressed as dMvH[posX][posY] and dMvV[posX][posY] (posX=0...W-1, posY=0...H-1)) is written as follows:
[0049] Let the dimensions of the current block be cbWidth×cbHeight, the number of control point motion vectors be numCpMv, and the control point motion vector be cpMvLX[cpIdx] (cpIdx=0..numCpMv−1, X represents two reference lists).
[0050] The variables log2CbW and log2CbH are derived as follows:
number
[0051] The variables mvScaleHor, mvScaleVer, dHorX, and dVerX are derived as follows:
number
[0052] The variables dHorY and dVerY are derived as follows: - If numCpMv is equal to 3, the following applies:
number
number
[0053] The variables qHorX, qVerX, qHorY, and qVerY are derived as follows.
number
[0054] dMvH[0][0] and dMvV[0][0] are calculated as follows:
number
[0055] For xPox between 1 and W-1, dMvH[xPos][0] and dMvV[xPos][0] are derived as follows:
number
[0056] For yPos from 1 to H-1, the following applies:
number
[0057] Finally, dMvH[xPos][yPos] and dMvV[xPos][yPos] (posX=0..W-1,posY=0..H-1) are right-shifted as follows:
number
number
[0058] In one example, offset0 and / or offset1 are (1<<n)> It is set to -1.
[0059] a) How to derive ΔI for PROF
[0060] For a position (posX,posY) in a sub-block, its corresponding Δv(i,j) is denoted as (dMvH[posX][posY],dMv[posX][posY]), and its corresponding gradient is denoted as (gradientH[posX][posY],gradientV[posX][posY]).
[0061] Then, ΔI(posX, posY) is derived as follows:
[0062] (dMvH[posX][posY],dMvV[posX][posY]) is clipped as follows:
number
[0063] d) How to derive PROF's I'
[0064] If the current block is not coded as bidirectional or weighted prediction,
number
[0065] Otherwise (if the current block is coded as bi-predictive or weighted predictive), I'(posX,posY) is stored and used to generate an inter prediction according to other predictions and / or weighting values. [Table 5] TIFF0007794791000055.tif232161TIFF0007794791000056.tif232161TIFF0007794791000057.tif232161TIFF0007794791000058.t if232161TIFF0007794791000059.tif232161TIFF0007794791000060.tif232161TIFF0007794791000061.tif232161TIFF00077947910 00062.tif220161TIFF0007794791000063.tif232166TIFF0007794791000064.tif232161TIFF0007794791000065.tif232161TIFF000 7794791000066.tif229161TIFF0007794791000067.tif230161TIFF0007794791000068.tif221161TIFF0007794791000069.tif185161
[0066] 2.10. Example Picture Header In some implementations, the picture header is designed to have the following properties:
[0067] 1. The temporal Id and layer Id of the picture header NAL unit are the same as the temporal Id and layer Id of the layer access unit that contains the picture header.
[0068] 2. The picture header NAL unit precedes the NAL unit containing the first slice of the associated picture, thereby establishing the association between the picture header and the slice of the picture associated with it, without the need for a picture header Id to be signaled in the picture header and referenced from the slice header.
[0069] 3. The picture header NAL unit shall conform to picture-level parameter sets or higher levels, such as DPS, VPS, SPS, PPS, etc. Consequently, these parameter sets are required not to be repeated / absent within a picture or access unit.
[0070] 4. The picture header contains information about the picture type of the associated picture. Picture types may be used to define the following (non-exhaustive list): a. The picture is an IDR picture. b. The picture is a CRA picture. c. The picture is a GDR picture. d. The picture is a non-IRAP, non-GDR picture and contains only I-slices. e. The picture may be a non-IRAP, non-GDR picture and may contain only P slices and I slices. f. The picture is a non-IRAP, non-GDR picture and contains any of a B slice, a P slice, and / or an I slice.
[0071] 5. Move the signaling of picture level syntax elements in the slice header to the picture header.
[0072] 6. Non-picture level syntax elements in a slice header that are usually the same for all slices of the same picture in the picture header. When these syntax elements are not present in the picture header, they may be signaled in the slice header.
[0073] In some implementations, a mandatory picture header concept is used, transmitted once per picture, as the first VCL NAL unit of a picture. We also propose to move syntax elements currently in slice headers to this picture header. Syntax elements that functionally need to be transmitted only once per picture can be moved to the picture header instead of being transmitted multiple times for a given picture, e.g., syntax elements in a slice header are transmitted once per slice. The movement of slice header syntax elements is constrained to be the same within a picture.
[0074] Syntax elements are already constrained to be the same for all slices of a picture. We argue that moving these fields to the picture header and signaling them only once per picture instead of once per slice avoids unnecessary redundant transmission of bits, without any change in the functionality of these syntax elements.
[0075] 1. In some implementations, the following semantic constraints apply:
[0076] When present, the value of each of the slice header syntax elements slice_pic_parameter_set_id, non_reference_picture_flag, colour_plane_id, slice_pic_order_cnt_lsb, recovery_poc_cnt, no_output_of_prior_pics_flag, pic_output_flag, and slice_temporal_mvp_enabled_flag shall be the same in all slice headers of a coded picture. Thus, each of these syntax elements can be moved to the picture header, avoiding unnecessary redundant bits.
[0077] recovery_poc_cnt and no_output_of_prior_pics_flag are not moved to the picture header in this contribution. Their presence in the slice header depends on a conditional check of the slice header nal_unit_type, so it is recommended to study them if you want to move these syntax elements to the picture header.
[0078] 2. In some implementations, the following semantic constraints apply: When present, the value of slice_lmcs_aps_id shall be the same for all slices of a picture. When present, the value of slice_scaling_list_aps_id shall be the same for all slices of a picture. Thus, each of these syntax elements can be moved to the picture header, avoiding unnecessary redundant bits.
[0079] In some embodiments, syntax elements are not currently constrained to be the same in all slices of a picture. Due to the purported complexity impact of processing a large number of syntax elements in all slice headers, it is recommended to evaluate the expected use of these syntax elements to determine which syntax elements can be moved to the picture header to simplify the overall VVC design.
[0080] 1. It is proposed to move the following syntax elements to the picture header. There are currently no restrictions on having different values for different slices, but it is argued that there is only benefit / minimal benefit and coding loss in sending them in each slice header because their expected use changes at the picture level: a. six_minus_max_num_merge_cand b. five_minus_max_num_subblock_merge_cand c. slice_fpel_mmvd_enabled_flag d. slice_disable_bdof_dmvr_flag e. max_num_merge_cand_minus_max_num_triangle_cand f. slice_six_minus_max_num_ibc_merge_cand
[0081] 2. It is proposed to move the following syntax elements to the picture header: There are currently no restrictions on having different values for different slices, but it is argued that there is only benefit / minimal benefit and coding loss in sending them in each slice header since their expected use changes at the picture level: a. partition_constraints_override_flag b. slice_log2_diff_min_qt_min_cb_luma c. slice_max_mtt_hierarchy_depth_luma d. slice_log2_diff_max_bt_min_qt_luma e. slice_log2_diff_max_tt_min_qt_luma f. slice_log2_diff_min_qt_min_cb_chroma g. slice_max_mtt_hierarchy_depth_chroma h. slice_log2_diff_max_bt_min_qt_chroma i. slice_log2_diff_max_tt_min_qt_chroma
[0082] The conditional check "slice_type==I" associated with these syntax elements has been removed as they have been moved to the picture header.
[0083] 3. It is proposed to move the following syntax elements to the picture header: While there are currently no restrictions on having different values for different slices, it is argued that there is only benefit / minimal benefit and coding loss in sending them in each slice header since their expected use changes at the picture level: a. mvd_l1_zero_flag
[0084] The conditional check "slice_type==B" associated with these syntax elements has been removed as they have been moved to the picture header.
[0085] 4. It is proposed to move the following syntax elements to the picture header: While there are currently no restrictions on having different values for different slices, it is argued that there is only benefit / minimal benefit and coding loss in sending them in each slice header since their expected use changes at the picture level: a. dep_quant_enabled_flag b. sign_data_hiding_enabled_flag [Table 6] TIFF0007794791000071.tif233166TIFF0007794791000072.tif229166TIFF0007794791000073.tif192166
[0086] 3. Shortcomings of existing implementations DMVR and BIO do not involve the original signal when refining the motion vector, which may result in coding blocks with inaccurate motion information. Also, DMVR and BIO use fractional motion vectors after motion refinement, while screen video usually has integer motion vectors, which makes the current motion information more inaccurate and worsens coding performance.
[0087] When RPR is applied in VVC, RPR(ARC) may have the following problems. 1. In RPR, the interpolation filter may be different for adjacent samples within a block, which is undesirable in a SIMD (Single Instruction Multiple Data) implementation. 2. Boundary areas do not take RPR into account. 3. Note that "the adaptive cropping window offset parameters are only applied at output time. All internal decoding processes apply to the uncropped picture size." However, these parameters may be used in the decoding process when RPR is applied. 4. When deriving the reference sample position, RPR only considers the ratio between the two fit windows. However, the difference in the top-left offset between the two fit windows should also be considered. 5. The ratio of the width / height of a reference picture to the width / height of the current picture is constrained in VVC, but the ratio of the width / height of the matching window of the reference picture to that of the matching window of the current picture is not constrained. 6. Not all syntax elements are correctly processed in the picture header. 7. In the current VVC, in the TPM and GEO prediction modes, chrominance mixing weights are derived regardless of the chrominance sample position type of the video sequence. For example, in TPM / GEO, if chrominance weights are derived from luma weights, the luma weights may need to be downsampled to match the sampling of the chrominance signal. Chrominance downsampling is usually applied assuming chrominance sample position type 0, which is widely used in ITU-R BT.601 or ITU-R BT.709 containers. However, if a different chrominance sample position type is used, this may result in a mismatch between the chrominance samples and the downsampled luma samples, which may degrade coding performance.
[0088] 4. Exemplary Techniques and Embodiments The detailed embodiments described below should be considered as examples to illustrate the general concept. These embodiments should not be construed narrowly. Furthermore, these embodiments can be combined in any way.
[0089] The methods described below may also be applicable to other decoder motion information derivation techniques in addition to DMVR and BIO mentioned below.
[0090] A motion vector is denoted by (mv_x, mv_y), where mv_x is the horizontal component and mv_y is the vertical component.
[0091] In this disclosure, the resolution (or dimensions, or width / height, or size) of a picture may refer to the resolution (or dimensions, or width / height, or size) of the coded / decoded picture, or may refer to the resolution (or dimensions, or width / height, or size) of an adapted window of the coded / decoded picture. Motion compensation in RPR 1. When the resolution of the reference picture is different from that of the current picture, or when the width and / or height of the reference picture is larger than that of the current picture, predicted values for a group of samples (at least two samples) of the current block may be generated using the same horizontal and / or vertical interpolation filter. In one example, a group may include all samples within a region of a block. For example, a block may be divided into S non-overlapping MxN rectangles, each of which is a group. In the example shown in Figure 2, a 16x16 block may be divided into 16 4x4 rectangles, each of which is a group. ii. For example, a row having N samples is a group, where N is an integer less than or equal to the block width. In one example, N is 4 or 8, or the block width. iii. For example, a group is a column with N samples, where N is an integer less than or equal to the block height. In one example, N is 4 or 8, or the block height. iv. M and / or N may be predefined or derived on the fly, e.g., based on block dimensions / coded information, or may be signaled. b. In one example, samples within a group may have the same MV (denoted as shared MV). c. In one example, samples within a group may have MVs with the same horizontal component (denoted as a shared horizontal component). d. In one example, samples within a group may have MVs with the same vertical component (denoted as a shared vertical component). e. In one example, samples within a group may have MVs that have the same fractional portion of a horizontal component (denoted as a shared fractional horizontal component). i. For example, if the MV for the first sample is (MV1x, MV1y) and the MV for the second sample is (MV2x, MV2y), then MV1x & (2 M -1) is MV2x&(2 M -1) (where M indicates the MV precision). For example, M=4. f. In one example, samples within a group may have MVs that have fractional parts of the same vertical component (denoted as shared fractional vertical components). i. For example, if the MV for the first sample is (MV1x, MV1y) and the MV for the second sample is (MV2x, MV2y), then MV1y & (2 M -1) is MV2y&(2 M -1) (M indicates the MV precision). For example, M=4. g. In one example, for samples in the predicted group, MV bThe motion vector denoted by is first derived from the resolution of the current picture and the resolution of the reference picture (e.g., 8.5.6.3.1 in JVET-O2001-v14 (refx L ,refy L )) may be derived according to MV b may be further modified (e.g., rounded / truncate / clipped) to MV′ to meet requirements such as those in the above bullets, and MV′ will be used to derive a predicted sample for the sample. i. In one example, MV' is MV b and the fractional part of MV' is set to the shared fractional horizontal and / or vertical component. ii. In one example, MV' has a shared fractional horizontal and / or vertical component, and MV b is set to the closest h. The shared motion vector (and / or shared horizontal component and / or shared vertical component and / or shared fractional vertical component and / or shared fractional vertical component) may be set to the motion vector (and / or horizontal component and / or vertical component and / or fractional vertical component and / or fractional vertical component) of a particular sample in the group. i. For example, a particular sample may be at the corner of a rectangular group, such as "A," "B," "C," and "D" shown in FIG. 3A. ii. For example, a particular sample may be at the center of a group of rectangles, such as "E," "F," "G," and "H" shown in FIG. 3A. iii. For example, a particular sample may be at the end of a row-shaped or column-shaped group, such as "A" and "D" shown in Figures 3B and 3C. iv. For example, a particular sample may be in the center of a row-shaped or column-shaped group such as "B" and "C" shown in Figures 3B and 3C. v. In one example, the motion vector for a particular sample is the MV mentioned in bullet g. b may be. i. The shared motion vector (and / or shared horizontal component and / or shared vertical component and / or shared fractional vertical component and / or shared fractional vertical component) may be set to the motion vector (and / or horizontal component and / or vertical component and / or fractional vertical component and / or fractional vertical component) of a virtual sample located at a different position compared to all samples in this group. i. In one example, the virtual sample is not within a group, but is located in a region that covers all samples in the group. 1) Alternatively, the virtual sample is located outside the region covering all samples in the group, for example next to the bottom right position of the region. ii. In one example, the MVs of the virtual samples are derived in the same way as the real samples, but at different locations. iii. "V" in Figures 3A-3C shows three examples of hypothetical samples. j. The shared MV (and / or shared horizontal component and / or shared vertical component and / or shared fractional vertical component and / or shared fractional vertical component) may be set to a function of the MV (and / or horizontal component and / or vertical component and / or fractional vertical component and / or fractional vertical component) of multiple samples and / or virtual samples. i. For example, the shared MV (and / or shared horizontal component and / or shared vertical component and / or shared fractional vertical component and / or shared fractional vertical component) may be set to the average of the MV (and / or horizontal component and / or fractional vertical component and / or fractional vertical component) of all or some of the samples in the group, or of samples "E", "F", "G", and "H" in FIG. 3A, or of samples "E" and "H" in FIG. 3A, or of samples "A", "B", "C", and "D" in FIG. 3A, or of samples "A" and "D" in FIG. 3A, or of samples "B" and "C" in FIG. 3B, or "A" and "D" in FIG. 3B, or of samples "B" and "C" in FIG. 3C, or of samples "A" and "D" in FIG. 3C. 2. It is proposed that when the resolution of the reference picture is different from that of the current picture, or when the width and / or height of the reference picture is larger than that of the current picture, only integer MVs are allowed to perform the motion compensation process to derive the prediction block for the current block. In one example, the decoded motion vector for the sample to be predicted is rounded to an integer MV before being used. b. In one example, the decoded motion vector for the predicted sample is rounded to the nearest integer MV to the decoded motion vector. c. In one example, the decoded motion vector for the predicted sample is rounded to the nearest integer MV to the decoded motion vector in the horizontal direction. d. In one example, the decoded motion vector for the predicted sample is rounded to the nearest integer MV to the decoded motion vector in the vertical direction. 3. The motion vectors used in the motion compensation process for samples in the current block (e.g., the shared MVs / shared horizontal or vertical or fractional components / MV' mentioned in the above bullet points) may be stored in the decoded picture buffer or utilized for motion vector prediction of subsequent blocks in the current / different picture. a. Alternatively, the motion vectors (e.g., the shared MVs / shared horizontal or vertical or fractional components / MVs' mentioned in the above bullet points) used in the motion compensation process for samples in the current block may not be allowed to be utilized for motion vector prediction of a subsequent block in the current / different picture. i. In one example, the decoded motion vectors (e.g., MV in the above item) b ) may be utilized for motion vector prediction of a subsequent block in the current / different picture. b. In one example, the motion vectors used in the motion compensation process for the samples in the current block may be used in the filtering process (eg, deblocking filter / SAO / ALF). i. Alternatively, the decoded motion vectors (e.g., MV in the above item) b ) may be utilized in the filtering process. c. In one example, such MVs may be derived at the sub-block level and stored for each sub-block. 4. It is proposed that the interpolation filter used in the motion compensation process to derive a prediction block for the current block may be selected depending on whether the resolution of the reference picture is different from that of the current picture or whether the width and / or height of the reference picture is larger than that of the current picture. a. In one example, an interpolation filter with fewer taps may be applied if condition A is met, where condition A depends on the dimensions of the current picture and / or the reference picture. i. In one example, condition A is that the resolution of the reference picture is different from that of the current picture. ii. In one example, condition A is that the width and / or height of the reference picture is greater than that of the current picture. iii. In one example, condition A is W1>a*W2 and / or H1>b*H2, where (W1, H1) represent the width and height of the reference picture, (W2, H2) represent the width and height of the current picture, and a and b are two factors, for example, a=b=1.5. iv. In one example, condition A may also depend on whether bi-prediction is used. v. In one example, a 1-tap filter is applied, in other words, integer pixels without filtering are output as the interpolated result. vi. In one example, a bilinear filter is applied when the resolution of the reference picture is different from the current picture. vii. In one example, a 4-tap filter or a 6-tap filter is applied when the resolution of the reference picture is different from that of the current picture, or when the width and / or height of the reference picture is larger than that of the current picture. 1) A 6-tap filter may also be used for affine motion compensation. 2) A 4-tap filter may also be used for interpolation for the chrominance samples. b. In one example, padding samples are used to perform interpolation when the resolution of the reference picture is different from that of the current picture, or when the width and / or height of the reference picture is larger than that of the current picture. c. Whether and / or how to apply the methods disclosed in bullet 4 may depend on the color component. i. For example, the method is applied only to the luminance component. d. Whether and / or how to apply the method disclosed in bullet 4 may depend on the direction of the interpolation filtering. i. For example, the method is only applicable for horizontal filtering. ii. For example, the method is only applicable for vertical filtering. 5. We propose to apply a two-stage process for prediction block generation when the resolution of the reference picture is different from that of the current picture, or when the width and / or height of the reference picture is larger than that of the current picture. a. In the first stage, depending on the width and / or height of the current picture and the reference picture, a virtual reference block is generated by upsampling or downsampling an area in the reference picture. b. In the second stage, predicted samples are generated from the virtual reference blocks by applying interpolation filtering, independent of the width and / or height of the current and reference pictures. 6. In some embodiments, the top left coordinate of the border block for the reference sample padding (xSbInt L ,ySbInt L We propose that the calculation of ) can be derived depending on the width and / or height of the current picture and the reference picture. a. In one example, the luma position in full samples is modified as follows:
number
number
[0092] Additional Exemplary Embodiments Below, text changes are indicated in underlined, bold, italic font.
[0093] 5.1. Implementation of Constraints on the Fit Window conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset specify the sample of the picture in the CVS output from the decoding process with respect to the rectangular area specified in picture coordinates for output. When conformance_window_flag is equal to 0, the values of conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, conf_win_bottom_offset are inferred to be equal to 0. The adaptive cropping window has horizontal picture coordinates from SubWidthC*conf_win_left_offset to pic_width_in_luma_samples-(SubWidthC*conf_win_right_offset+1), inclusive, and vertical picture coordinates from SubHeightC*conf_win_top_offset to pic_height_in_luma_samples-(SubHeightC*conf_win_bottom_offset+1SubHeightC*conf_win_bottom_offset+1), inclusive. The value of SubWidthC*(conf_win_left_offset+conf_win_right_offset) shall be less than pic_width_in_luma_samples, and the value of SubHeightC*(conf_win_top_offset+conf_win_bottom_offset) shall be less than pic_height_in_luma_samples. The variables PicOutputWidthL and PicOutputHeightL are derived as follows:
number
[0094] 5.2. Reference Sample Position Derivation Embodiment 1 8.5.6.3.1 Overview ... The variable fRefWidth is set equal to the PicOutputWidthL of the reference picture in luma samples. The variable fRefHeight is set equal to the PicOutputHeightL of the reference picture in luma samples. [Outside 4] TIFF0007794791000082.tif31169 The motion vector mvLX is set equal to (refMvLX-mvOffset). - If cIdx is equal to 0, the following applies: - The scaling factor and its fixed-point representation are defined as follows:
number
number
number
number
number
[0095] 5.3. Reference Sample Position Derivation Embodiment 2 8.5.6.3.1 Overview ... The variable fRefWidth is set equal to the PicOutputWidthL of the reference picture in luma samples. The variable fRefHeight is set equal to the PicOutputHeightL of the reference picture in luma samples. [Outside 5] TIFF0007794791000088.tif28169 The motion vector mvLX is set equal to (refMvLX-mvOffset). - If cIdx is equal to 0, the following applies: - The scaling factor and its fixed-point representation are defined as follows:
number
number
number
number
number
[0096] 5.4. Reference Sample Position Derivation Embodiment 3 8.5.6.3.1 Overview ... The variable fRefWidth is set equal to the PicOutputWidthL of the reference picture in luma samples. The variable fRefHeight is set equal to the PicOutputHeightL of the reference picture in luma samples. [Outside 6] TIFF0007794791000094.tif30169 The motion vector mvLX is set equal to (refMvLX-mvOffset). - If cIdx is equal to 0, the following applies: - The scaling factor and its fixed-point representation are defined as follows:
number
number
number
number
number
[0097] 5.5. Reference Sample Position Clipping Embodiment 1 8.5.6.3.1 Overview The inputs to this process are: - a luminance position (xSb, ySb) specifying the top-left sample of the current coding sub-block relative to the top-left sample of the current picture - variable sbWidth that specifies the width of the current coding sub-block - variable sbHeight that specifies the height of the current coding sub-block - Motion vector offset mvOffset - Refined motion vectors refMvLX - selected reference picture sample array refPicLX - Half-sample interpolation filter index hpelIfIdx - Bidirectional optical flow flag bdofFlag - variable cIdx that specifies the color component index of the current block The output of this process is as follows: - predSamplesLX, a (sbWidth+brdExtSize)x(sbHeight+brdExtSize) array of predicted sample values The prediction block boundary extension size brdExtSize is derived as follows.
number
number
number
number
number
number
[0098] 5.6. Reference Sample Position Clipping Embodiment 2 8.5.6.3.1 Overview The inputs to this process are: - a luminance position (xSb, ySb) specifying the top-left sample of the current coding sub-block relative to the top-left sample of the current picture - variable sbWidth that specifies the width of the current coding sub-block - variable sbHeight that specifies the height of the current coding sub-block - Motion vector offset mvOffset - Refined motion vectors refMvLX - selected reference picture sample array refPicLX - Half-sample interpolation filter index hpelIfIdx - Bidirectional optical flow flag bdofFlag - variable cIdx that specifies the color component index of the current block The output of this process is as follows: - predSamplesLX, a (sbWidth+brdExtSize)x(sbHeight+brdExtSize) array of predicted sample values The prediction block boundary extension size brdExtSize is derived as follows.
number
number
number
number
number
number
[0099] 6. Exemplary Implementations of the Disclosed Techniques 5 is a block diagram of a video processing device 500. The device 500 may be used to implement one or more of the methods described herein. The device 500 may be embodied in a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The device 500 may include one or more processors 502, one or more memories 504, and video processing hardware 506. The processor 502 may be configured to implement one or more methods described herein. The memory(s) 504 may be used to store data and code used to implement the methods and techniques described herein. The video processing hardware 506 may be used to implement some of the techniques described herein in a hardware circuit or may be partially or fully part of the processor 502 (e.g., a graphics processor core GPU or other signal processing circuitry).
[0100] In this document, the term "video processing" or coding may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. The bitstream representation of a current video block may correspond to bits that are co-located or spread to different locations within the bitstream, e.g., as defined by a syntax. For example, a macroblock may be coded with respect to transformed coded error residual values and using bits in headers and other fields within the bitstream.
[0101] It will be appreciated that the disclosed methods and techniques are beneficial to embodiments of video encoders and / or decoders embedded within video processing devices such as smartphones, laptops, desktops, and similar devices by enabling the use of the techniques disclosed herein.
[0102] 6 is a flowchart of an example method for video processing. The method 600 includes, at 610, performing a conversion between a current video block and a coded representation of the current video block, where, during the conversion, if the resolution and / or size of the reference picture differs from the resolution and / or size of the current video block, the same interpolation filter is applied to groups of adjacent or non-adjacent samples that are predicted using the current video block.
[0103] Some embodiments may be described using the following section-based format.
[0104] 1. A method of video processing, comprising: 1. A method comprising: performing a transformation between a current video block and a coded representation of the current video block, wherein, during the transformation, if a resolution and / or size of a reference picture differs from a resolution and / or size of the current video block, the same interpolation filter is applied to groups of adjacent or non-adjacent samples that are predicted using the current video block.
[0105] 2. The same interpolation filter is a vertical interpolation filter, as in item 1.
[0106] 3. The same interpolation filter is a horizontal interpolation filter, as in item 1.
[0107] 4. The method of item 1, wherein the group of adjacent or non-adjacent samples includes all samples located in the region of the current video block.
[0108] 5. The method of item 4, where the current video block is divided into multiple rectangles, each of size MXN.
[0109] 6. The method of paragraph 5, wherein M and / or N are predetermined.
[0110] 7. The method of clause 5, wherein M and / or N are derived from the dimensions of the current video block.
[0111] 8. The method of clause 5, wherein M and / or N are signaled in a coded representation of the current video block.
[0112] 9. A group of samples shares the same motion vector.,method of item 1.
[0113] 10. The method of item 9, where groups of samples share the same horizontal component and / or identical fractions of the horizontal component.
[0114] 11. The method of item 9, where groups of samples share the same vertical component and / or identical fractions of a vertical component.
[0115] 12. One or more of the methods of clauses 9-11, wherein the same motion vector or component thereof satisfies one or more rules based on at least one of the resolution of the reference picture, the size of the reference picture, the resolution of the current video block, the size of the current video block, or the precision value.
[0116] 13. The method of one or more of clauses 9-11, wherein the same motion vector or its components correspond to motion information of samples located within the current video block.
[0117] 14. The method of one or more of clauses 9 to 11, wherein the same motion vector or its components are set in the motion information of virtual samples located inside or outside the group.
[0118] 15. A method of video processing, comprising: 1. A method comprising: performing a transformation between a current video block and a coded representation of the current video block; wherein, during the transformation, if a resolution and / or size of a reference picture differs from a resolution and / or size of the current video block, a block predicted using the current video block is only allowed to use integer-value motion information related to the current block.
[0119] 16. The method of clause 15, wherein integer-valued motion information is derived by rounding the original motion information of the current video block.
[0120] 17. The method of clause 15, wherein the original motion information of the current video block is horizontal and / or vertical.
[0121] 18. A method of video processing, comprising: 1. A method comprising: performing a transformation between a current video block and a coded representation of the current video block; and, during the transformation, if a resolution and / or size of a reference picture differs from a resolution and / or size of the current video block, applying an interpolation filter to derive a predicted block using the current video block, the interpolation filter being selected based on a rule.
[0122] 19. The method of clause 18, wherein the rule relates the resolution and / or size of the reference picture to the resolution and / or size of the current video block.
[0123] 20. The method of paragraph 18, wherein the interpolation filter is a vertical interpolation filter.
[0124] 21. The method of paragraph 18, wherein the interpolation filter is a horizontal interpolation filter.
[0125] 22. The method of clause 18, wherein the interpolation filter is one of a 1-tap filter, a bilinear filter, a 4-tap filter, or a 6-tap filter.
[0126] 23. The method of item 22, in which the interpolation filter is used as part of another step in the transformation.
[0127] 24. The interpolation filter is the method of clause 18, including the use of padding samples.
[0128] 25. The method of clause 18, wherein the use of the interpolation filter depends on the color components of the samples of the current video block.
[0129] 26. A method of video processing, comprising: 1. A method comprising: performing a transformation between a current video block and a coded representation of the current video block; and, during the transformation, if a resolution and / or size of a reference picture differs from a resolution and / or size of the current video block, selectively applying a deblocking filter, the strength of the deblocking filter being set according to a rule relating the resolution and / or size of the reference picture to the resolution and / or size of the current video block.
[0130] 27. The method of clause 27, wherein the strength of the deblocking filter varies from one video block to another.
[0131] 28. A method of video processing, comprising: 1. A method comprising: performing a conversion between a current video block and a coded representation of the current video block; and, during the conversion, if a sub-picture of the current video block is present, the conforming bitstream satisfies rules relating the resolution and / or size of the reference picture to the resolution and / or size of the current video block.
[0132] 29. The method of clause 28, further including splitting the current video block into one or more sub-pictures, the splitting depending at least on the resolution of the current video block.
[0133] 30. A method of video processing, comprising: 1. A method comprising: performing a transformation between a current video block and a coded representation of the current video block, wherein during the transformation, a reference picture for the current video block is resampled according to a rule based on dimensions of the current video block.
[0134] 31. A method of video processing, comprising: 1. A method comprising: performing a conversion between a current video block and a coded representation of the current video block, wherein, during the conversion, use of a coding tool for the current video block is selectively enabled or disabled depending on a resolution / size of a reference picture for the current video block relative to a resolution / size of the current video block.
[0135] 32. A method according to one or more of the preceding paragraphs, wherein the group of samples is located within a fitting window.
[0136] 33. The method of claim 32, wherein the fitting window is rectangular in shape.
[0137] 34. The method of any one or more of the preceding clauses, wherein the resolution relates to the resolution of the coded / decoded video block or the resolution of the fitting window within the coded / decoded video block.
[0138] 35. The method of any one or more of the preceding clauses, wherein the size relates to the size of the coded / decoded video block or the size of an adapted window within the coded / decoded video block.
[0139] 36. The method of any one or more of the preceding clauses, wherein the dimensions relate to dimensions of a coded / decoded video block or dimensions of an adaptive window within the coded / decoded video block.
[0140] 37. The method of clause 32, wherein the adaptive window is defined by a set of adaptive cropping window parameters.
[0141] 38. The method of clause 37, wherein at least a portion of the set of adaptive cropping window parameters is implicitly or explicitly signaled in the coded representation.
[0142] 39. The method of any one or more of the preceding clauses, wherein the set of adaptive cropping window parameters is not allowed to be signaled in the coded representation.
[0143] 40. The method of any one or more of the preceding clauses, wherein the position of the reference sample is derived relative to the top-left sample of the current video block within the adaptation window.
[0144] 41. A method of video processing, comprising: 1. A method comprising: performing a conversion between a plurality of video blocks and a coded representation of the plurality of video blocks, wherein during the conversion, a first adaptation window is defined for the first video block and a second adaptation window is defined for the second video block, and a width and / or height ratio of the first adaptation window to the second adaptation window complies with at least a rule based on the adaptation bitstream.
[0145] 42. A video decoding device, comprising a processor configured to implement the methods defined in one or more of clauses 1 to 41.
[0146] 43. A video encoding apparatus comprising a processor configured to implement the methods defined in one or more of clauses 1 to 41.
[0147] 44. A computer program product having stored thereon computer code which, when executed by a processor, causes the processor to implement a method defined in any one of clauses 1 to 41.
[0148] 45. Any method, apparatus or system described herein.
[0149] 7 is a block diagram illustrating an example video processing system 700 capable of implementing various techniques disclosed herein. Various implementations may include some or all of the components of system 700. System 700 may include an input 702 for receiving video content. The video content may be received in raw or uncompressed format, e.g., 8- or 10-bit multi-component pixel values, or in a compressed or encoded format. Input 702 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, passive optical network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.
[0150] System 700 may include a coding component 704 that may implement various coding or encoding methods described herein. The coding component 704 may reduce the average bitrate of the video from the input 702 to the output of the coding component 704 to generate a coded representation of the video. Thus, the coding techniques are sometimes referred to as video compression or video transcoding techniques. The output of the coding component 704 may be stored or transmitted via a connected communication, as represented by component 706. The stored or communicated bitstream (or coded) representation of the video received at the input 702 may be used by component 708 to generate pixel values or displayable video that are sent to a display interface 710. The process of generating user-viewable video from the bitstream representation is sometimes referred to as video decompression. Furthermore, while certain video processing operations are referred to as “coding” operations or tools, it will be understood that the coding tools or operations are used in an encoder, or that corresponding decoding tools or operations that reverse the results of the coding are performed by a decoder.
[0151] Examples of peripheral bus interfaces or display interfaces include universal serial bus (USB), high definition multimedia interface (HDMI), or display port, etc. Examples of storage interfaces include serial advanced technology attachment (SATA), PCI, IDE interfaces, etc. The techniques described herein may be embodied in various electronic devices such as mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and / or video display.
[0152] FIG. 8 is a block diagram illustrating an example video coding system 100 that can utilize the techniques of this disclosure.
[0153] 8, video coding system 100 may include source device 110 and destination device 120. Source device 110 generates encoded video data, which may be referred to as a video encoding device. Destination device 120 may decode the encoded video data generated by source device 110, which may be referred to as a video decoding device.
[0154] The source device 110 may include a video source 112, a video encoder 114, and an input / output (I / O) interface 116.
[0155] The video source 112 may include a source such as a video capture device, an interface for receiving video data from a video content provider, and / or a computer graphics system for generating video data, or a combination of such sources. The video data may include one or more pictures. The video encoder 114 encodes the video data from the video source 112 to generate a bitstream. The bitstream may include a sequence of bits forming a coded representation of the video data. The bitstream may include coded pictures and associated data. A coded picture is a coded representation of a picture. The associated data may include sequence parameter sets, picture parameter sets, and other syntax structures. The input / output interface 116 may include a modulator / demodulator (modem) and / or a transmitter. The coded video data may be transmitted directly to the destination device 120 via the I / O interface 116 over the network 130a. The coded video data may also be stored on a storage medium / server 130b for access by the destination device 120.
[0156] The destination device 120 may include an I / O interface 126 , a video decoder 124 , and a display device 122 .
[0157] I / O interface 126 may include a receiver and / or a modem. I / O interface 126 may obtain encoded video data from source device 110 or storage medium / server 130b. Video decoder 124 may decode the encoded video data. Display device 122 may display the decoded video data to a user. Display device 122 may be integrated with destination device 120 or may be external to destination device 120 configured to interface with an external display device.
[0158] Video encoder 114 and video decoder 124 may operate according to a video compression standard, such as the High Efficiency Video Coding (HEVC) standard, the Versatile Video Coding (VVC) standard, and other current and / or future standards.
[0159] FIG. 9 is a block diagram illustrating an example of a video encoder 200, which may be video encoder 114 in system 100 shown in FIG.
[0160] Video encoder 200 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 9, video encoder 200 includes multiple functional components. The techniques described in this disclosure may be shared among various components of video encoder 200. In some examples, a processor may be configured to perform any or all of the techniques described in this disclosure.
[0161] The functional components of the video encoder 200 may include a partition unit 201, a prediction unit 202, which may include a mode selection unit 203, a motion estimation unit 204, a motion compensation unit 205, and an intra prediction unit 206, a residual generation unit 207, a transform unit 208, a quantization unit 209, an inverse quantization unit 210, an inverse transform unit 211, a reconstruction unit 212, a buffer 213, and an entropy coding unit 214.
[0162] In other examples, video encoder 200 may include more, fewer, or different functional components. In one example, prediction unit 202 may include an intra block copy (IBC) unit. The IBC unit may perform prediction in an IBC mode, where at least one reference picture is the picture in which the current video block is located.
[0163] Furthermore, some components, such as the motion estimation unit 204 and the motion compensation unit 205, may be highly integrated, but are depicted separately in the example of FIG. 5 for illustrative purposes.
[0164] Partition unit 201 may partition a picture into one or more video blocks. Video encoder 200 and video decoder 300 may support a variety of video block sizes.
[0165] The mode select unit 203 selects one of the coding modes, intra or inter, based on, for example, an error result, and provides the resulting intra- or inter-coded block to the residual generation unit 207 to generate residual block data and to the reconstruction unit 212 to reconstruct a coded block for use as a reference picture. In some examples, the mode select unit 203 may select a combined intra- and inter-prediction (CIIP) mode, in which prediction is based on an inter-prediction signal and an intra-prediction signal. The mode select unit 203 may also select a resolution (e.g., sub-pixel or integer-pixel precision) for the motion vector for the block in the case of inter-prediction.
[0166] To perform inter prediction on the current video block, motion estimation unit 204 may generate motion information for the current video block by comparing one or more reference frames from buffer 213 with the current video frame. Motion compensation unit 205 may determine a predicted video block for the current video block based on the motion information and decoded samples of pictures from buffer 213 other than the picture associated with the current video block.
[0167] Motion estimation unit 204 and motion compensation unit 205 may perform different operations on the current video block depending on, for example, whether the current video block is in an I slice, a P slice, or a B slice.
[0168] In some examples, motion estimation unit 204 may perform unidirectional prediction on the current video block, and motion estimation unit 204 may search reference pictures in list 0 or list 1 for a reference video block for the current video block. Motion estimation unit 204 may then generate a reference index indicating a reference picture in list 0 or list 1 that includes the reference video block and a motion vector that indicates a spatial displacement between the current video block and the reference video block. Motion estimation unit 204 may output the reference index, the prediction direction indicator, and the motion vector as motion information for the current video block. Motion compensation unit 205 may generate a predictive video block for the current block based on the reference video block indicated by the motion information of the current video block.
[0169] In another example, motion estimation unit 204 may perform bidirectional prediction on the current video block, and motion estimation unit 204 may search reference pictures in list 0 for a reference video block for the current video block and may also search reference pictures in list 1 for another reference video block for the current video block. Motion estimation unit 204 may then generate reference indices indicating the reference pictures in lists 0 and 1 that include the reference video blocks and motion vectors that indicate spatial displacements between the reference video blocks and the current video block. Motion estimation unit 204 may output the reference index and motion vector of the current video block as motion information for the current video block. Motion compensation unit 205 may generate a predictive video block for the current block based on the reference video block indicated by the motion information of the current video block.
[0170] In some examples, the motion estimation unit 204 may output a full set of motion information for the decoding process of the decoder.
[0171] In some examples, motion estimation unit 204 may not output a complete set of motion information for the current video. Rather, motion estimation unit 204 may signal the motion information of the current video block by reference to motion information of other video blocks. For example, motion estimation unit 204 may determine that the motion information of the current video block is sufficiently similar to the motion information of neighboring video blocks.
[0172] In one example, motion estimation unit 204 may indicate, in a syntax structure associated with the current video block, a value that indicates to video decoder 300 that the current video block has the same motion information as another video block.
[0173] In another example, motion estimation unit 204 may identify another video block and a motion vector difference (NVD) in a syntax structure associated with the current video block. The motion vector difference indicates a difference between the motion vector of the current video block and the motion vector of the indicated video block. Video decoder 300 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.
[0174] As mentioned above, video encoder 200 may predictively signal motion vectors. Two examples of predictive signaling techniques that may be implemented by video encoder 200 include advanced motion vector prediction (AMVP) and merge mode signaling.
[0175] Intra prediction unit 206 may perform intra prediction on the current video block. When intra prediction unit 206 makes an intra prediction on the current video block, intra prediction unit 206 may generate predictive data for the current video block based on decoded samples of other video blocks in the same picture. The predictive data for the current video block may include a predictive video block and various syntax elements.
[0176] Residual generation unit 207 may generate residual data for the current video block by subtracting (e.g., indicated by a minus sign) the prediction video block of the current video block from the current video block. The residual data for the current video block may include residual video blocks that correspond to different sample components of the samples in the current video block.
[0177] In other examples, for example, in skip mode, residual data for the current video block may not exist and residual generation unit 207 may not perform a subtraction operation.
[0178] Transform processing unit 208 may generate one or more transform coefficient video blocks for the current video block by applying one or more transforms to the residual video block associated with the current video block.
[0179] After transform processing unit 208 generates a transform coefficient video block associated with the current video block, quantization unit 209 may quantize the transform coefficient video block associated with the current video block based on one or more quantization parameter (QP) values associated with the current video block.
[0180] Inverse quantization unit 210 and inverse transform unit 211 may apply inverse quantization and inverse transform, respectively, to the transform coefficient video block to reconstruct a residual video block from the transform coefficient video block. Reconstruction unit 212 may add the reconstructed residual video block to corresponding samples from one or more prediction video blocks generated by prediction unit 202 to generate a reconstructed video block related to the current block for storage in buffer 213.
[0181] After reconstruction unit 212 reconstructs the video blocks, a loop filtering operation may be performed to reduce video blocking artifacts within the video blocks.
[0182] The entropy encoding unit 214 may receive data from other functional components of the video encoder 200. When the entropy encoding unit 214 receives the data, the entropy encoding unit 214 performs one or more entropy encoding operations to generate entropy-coded data and outputs a bitstream that includes the entropy-coded data.
[0183] FIG. 10 is a block diagram illustrating an example of a video decoder 300, which may be video decoder 124 in system 100 shown in FIG.
[0184] Video decoder 300 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 10, video decoder 300 includes multiple functional components. The techniques described in this disclosure may be shared among various components of video decoder 300. In some examples, a processor may be configured to perform any or all of the techniques described in this disclosure.
[0185] 10, video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. Video decoder 300 may, in some examples, perform a decoding path that is generally the reverse of the encoding path described with respect to video encoder 200 (e.g., FIG. 9).
[0186] The entropy decoding unit 301 may retrieve an encoded bitstream. The encoded bitstream may include entropy-coded video data (e.g., encoded blocks of video data). The entropy decoding unit 301 may decode the entropy-coded video data, and from the entropy-decoded video data, the motion compensation unit 302 may determine motion information including motion vectors, motion vector precision, reference picture list indexes, and other motion information. The motion compensation unit 302 may determine such information by, for example, implementing AMVP and merge mode.
[0187] The motion compensation unit 302 may generate motion-compensated blocks and may optionally perform interpolation based on an interpolation filter, and an identifier for the interpolation filter used with sub-pixel precision may be included in the syntax element.
[0188] Motion compensation unit 302 may calculate interpolated values for sub-integer pixels of the reference block using interpolation filters used by video encoder 200 in encoding the video block. Motion compensation unit 302 determines the interpolation filters used by video encoder 200 according to received syntax information and uses the interpolation filters to generate the predictive block.
[0189] The motion compensation unit 302 may use some of the syntax information to determine the size of the blocks used to encode the frames and / or slices of the encoded video sequence, partitioning information describing how each macroblock of a picture of the encoded video sequence is partitioned, a mode indicating how each partition is encoded, one or more reference frames (and reference frame lists) for each inter-coded block, and other information for decoding the encoded video sequence.
[0190] The intra prediction unit 303 may form a prediction block from spatially adjacent blocks, for example, using an intra prediction mode received in the bitstream. The inverse quantization unit 303 inverse quantizes, or dequantizes, the quantized video block coefficients provided in the bitstream and decoded by the entropy decoding unit 301. The inverse transform unit 303 applies an inverse transform.
[0191] Reconstruction unit 306 may sum the residual blocks with corresponding prediction blocks generated by motion compensation unit 202 or intra prediction unit 303 to form decoded blocks. If desired, a deblocking filter may be applied to filter the decoded blocks to remove blockiness artifacts. The decoded video blocks are then stored in buffer 307, which provides reference blocks for subsequent motion compensation.
[0192] 11 is a flowchart representation of a video processing method in accordance with the present technology. The method 1100 includes, at act 1110, performing a conversion between video and a bitstream representation of the video. The bitstream representation conforms to format rules that specify that the applicability of decoder-side motion vector refinement coding tools and bidirectional optical flow coding tools for the video pictures are indicated separately in the bitstream representation.
[0193] In some embodiments, the decoder-side motion vector refinement tool includes performing automatic refinement of motion vectors to perform motion compensation at the decoder side without transmitting additional motion data. In some embodiments, the bidirectional optical flow coding tool includes enhancing bidirectional predictive prediction samples of a block via higher precision motion vectors derived from two reference blocks. In some embodiments, applicability is indicated in a picture header field of the bitstream representation.
[0194] 12 is a flowchart representation of a video processing method in accordance with the present technology. The method 1200 includes, at act 1210, performing a conversion between a picture of the video and a bitstream representation of the video. The bitstream representation conforms to format rules that specify the use of coding tools indicated in a picture header corresponding to the video picture.
[0195] In some embodiments, the format rules specify that the indication of the coding tools in the picture header is based on syntax elements associated with the coding tools in the sequence parameter set, video parameter set, or decoder parameter set of the bitstream representation. In some embodiments, the coding tools include at least one of a prediction refinement by optical flow (PROF) coding tool, a cross-component adaptive loop filtering (CCALF) coding tool, or an inter-prediction by geometric partitioning (GEO) coding tool. In some embodiments, the use of the coding tools is indicated by one or more syntax elements.
[0196] In some embodiments, the formatting rules specify that use of the coding tool is conditionally indicated based on a syntax element indicating enablement or disablement of the coding tool in the sequence parameter set. In some embodiments, the coding tool includes a prediction refinement by optical flow (PROF) coding tool. In some embodiments, the coding tool includes a cross-component adaptive loop filtering (CCALF) coding tool. In some embodiments, the coding tool includes an inter-prediction by geometric partitioning (GEO) coding tool. In some embodiments, the use is further conditionally indicated in the slice header based on the picture header.
[0197] 13 is a flowchart representation of a video processing method in accordance with the present technology. The method 1300 includes, at operation 1310, performing a conversion between a video including a video picture including one or more video units and a bitstream representation of the video. The bitstream representation conforms to a format rule that specifies that a first syntax element be included in a picture header indicating allowed prediction types for at least some of the one or more video units in the video picture.
[0198] In some embodiments, a video unit of the one or more video units includes a slice, a brick, or a tile. In some embodiments, the picture header includes a first syntax element indicating whether all of the one or more video units have the same prediction type. In some embodiments, the same prediction type is an intra-coding type. In some embodiments, the second syntax element indicating the type of the slice is omitted in the slice header corresponding to the slice if the first syntax element indicates that all slices of the corresponding video picture have the same prediction type. In some embodiments, the picture header includes a third syntax element indicating whether at least one of the plurality of video units is not intra-coded.
[0199] In some embodiments, an indication of coding tools allowed for a particular prediction type is conditionally signaled in the bitstream representation based on whether the indicated same prediction type is the particular prediction type. In some embodiments, when the same prediction type is a bidirectional prediction type, the coding tools allowed for the particular prediction type include a decoder-side motion vector refinement coding tool, a bidirectional optical flow coding tool, a triangular partitioning mode coding tool, or a geometric partitioning (GEO) coding tool. In some embodiments, when the particular prediction type is an intra-coding type, the coding tools allowed for the same prediction type include a dual-tree coding tool. In some embodiments, the formatting rules specify that the use of coding tools is indicated based on the indication of the same prediction type. In some embodiments, the use of coding tools is determined based on the indication of the same prediction type.
[0200] In some embodiments, the conversion includes encoding the video into a bitstream representation. In some embodiments, the conversion includes decoding the bitstream representation into the video.
[0201] Some embodiments of the disclosed techniques include making a determination or decision to enable a video processing tool or mode. In one example, when a video processing tool or mode is enabled, an encoder uses or implements the tool or mode in processing blocks of video, but may not necessarily modify the resulting bitstream based on the use of the tool or mode. That is, conversion from blocks of video to a bitstream representation of video uses the video processing tool or mode when enabled based on the determination or decision. In another example, when a video processing tool or mode is enabled, a decoder processes the bitstream knowing that the bitstream has been modified based on the video processing tool or mode. That is, conversion from a bitstream representation of video to blocks of video is performed using the video processing tool or mode enabled based on the determination or decision.
[0202] Some embodiments of the disclosed techniques include making a determination or decision to disable a video processing tool or mode. In one example, when a video processing tool or mode is disabled, an encoder does not use the tool or mode when converting blocks of video to a bitstream representation of video. In another example, when a video processing tool or mode is disabled, a decoder processes the bitstream knowing that the bitstream has not been modified using the video processing tool or mode that was enabled based on the determination or decision.
[0203] The disclosed and other solutions, examples, embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuitry, or computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for executing or controlling the operation of a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of these. The term "data processing apparatus" encompasses all apparatuses, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, an apparatus can include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations of these. A propagated signal is an artificially generated signal, for example, a machine-generated electrical, optical, or electromagnetic signal generated to encode information for transmission to a suitable receiver device.
[0204] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple refined files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program can be deployed to run on one computer or one site, or distributed across multiple sites and interconnected by a communications network.
[0205] The processes and logic flows described herein may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
[0206] Processors suitable for executing a computer program include, by way of example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor will receive instructions and data from a read-only memory or a random-access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include, or be operatively coupled to receive and / or transfer data from, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical, or optical disks. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic, magneto-optical, or optical disks, e.g., internal or removable hard disks; and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special-purpose logic circuitry.
[0207] While this patent document contains many details, these should not be construed as limitations on the scope of any subject matter or what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular technique. Certain features that are described in this patent document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, while features may be described above as acting in a particular combination and initially claimed by themselves, one or more features from a claimed combination can, in some cases, be deleted from the combination, and the claimed combination may be directed to subcombinations or variations of the subcombination.
[0208] Similarly, although the figures depict acts in a particular order, this should not be understood as requiring such acts to be performed in a particular order or sequentially, or that all of the depicted acts be performed, to achieve desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.
[0209] Only a few implementations and examples have been described, and other implementations, extensions and variations can be made based on what is described and shown in this patent document.
Claims
1. 1. A method for processing video data, comprising: determining, for a conversion between a video including a video picture including one or more video units and a bitstream of the video based on one or more syntax elements, a prediction type of at least one of the one or more video units in the video picture; performing the conversion based on the determination; the one or more syntax elements are included in a picture header in the bitstream; the one or more video units are one or more slices; the one or more syntax elements include a first syntax element indicating whether a prediction type of all of the one or more slices is a first prediction type; the first prediction type is intra prediction; The method, wherein the one or more syntax elements conditionally include a second syntax element that indicates whether at least one of the one or more slices is a non-I slice.
2. 2. The method of claim 1, wherein a syntax element indicating a slice type is not included in a slice header in the bitstream when the first syntax element indicates that all slices of the video picture are I-slices.
3. the bitstream conforms to format rules; The method of claim 1 , wherein the format rules specify that applicability of decoder-side motion vector refinement coding tools and bidirectional optical flow coding tools to the video pictures is indicated separately in the bitstream.
4. the decoder-side motion vector refinement coding tool performing motion vector refinement at offsets; The method of claim 3 , wherein the bidirectional optical flow coding tool includes obtaining motion vector offsets for blocks based on gradients in different directions.
5. two first syntax elements are included in a sequence parameter set in the bitstream that specify whether the decoder-side motion vector refinement coding tool is enabled and whether the bidirectional optical flow coding tool is enabled, respectively; 5. The method of claim 3, wherein two second syntax elements are conditionally included in the picture header in the bitstream, specifying whether the decoder-side motion vector refinement coding tool is disabled and whether the bidirectional optical flow coding tool is disabled, respectively.
6. 6. The method of claim 5, wherein a syntax element specifying whether the decoder-side motion vector refinement coding tool is disabled is conditionally included in the picture header based on a syntax element that is conditionally included in the sequence parameter set based on at least one of the first two syntax elements.
7. 6. The method of claim 5, wherein a syntax element specifying whether the bidirectional optical flow coding tool is disabled is conditionally included in the picture header based on a syntax element that is conditionally included in the sequence parameter set based on at least one of the first two syntax elements.
8. 4. The method of claim 3, wherein a syntax element specifying whether optical flow based prediction refinement coding tools are disabled is conditionally included in the picture header in the bitstream based on an optical flow based affine prediction refinement enabled flag included in a sequence parameter set in the bitstream.
9. 4. The method of claim 3, wherein a syntax element specifying whether cross-component ALF coding tools are enabled is conditionally included in a picture header in the bitstream based on a cross-component ALF enabled flag included in a sequence parameter set in the bitstream.
10. The method of any one of claims 1 to 9, wherein the converting comprises encoding the video into the bitstream.
11. The method of any one of claims 1 to 9, wherein the converting comprises decoding the video from the bitstream.
12. 1. An apparatus for processing video data, comprising: a processor; and a non-transitory memory having instructions that, when executed by the processor, cause the processor to: determining, for a conversion between a video including a video picture including one or more video units and a bitstream of the video based on one or more syntax elements, a prediction type of at least one of the one or more video units in the video picture; performing the conversion based on the determination; the one or more syntax elements are included in a picture header in the bitstream; the one or more video units are one or more slices; the one or more syntax elements include a first syntax element indicating whether a prediction type of all of the one or more slices is a first prediction type; the first prediction type is intra prediction; The apparatus, wherein the one or more syntax elements conditionally include a second syntax element that indicates whether at least one of the one or more slices is a non-I slice.
13. A non-transitory computer-readable storage medium storing instructions, the instructions causing a processor to: determining, for a conversion between a video including a video picture including one or more video units and a bitstream of the video based on one or more syntax elements, a prediction type of at least one of the one or more video units in the video picture; performing the conversion based on the determination; the one or more syntax elements are included in a picture header in the bitstream; the one or more video units are one or more slices; the one or more syntax elements include a first syntax element indicating whether a prediction type of all of the one or more slices is a first prediction type; the first prediction type is intra prediction; The one or more syntax elements conditionally include a second syntax element that indicates whether at least one of the one or more slices is a non-I slice.
14. 1. A method for storing a video bitstream, comprising: for the video including a video picture including one or more video units, determining a prediction type for at least one of the one or more video units in the video picture based on one or more syntax elements; generating the bitstream of the video based on the determination; and storing the bitstream on a non-transitory computer-readable recording medium; the one or more syntax elements are included in a picture header in the bitstream; the one or more video units are one or more slices; the one or more syntax elements include a first syntax element indicating whether a prediction type of all of the one or more slices is a first prediction type; the first prediction type is intra prediction; The method, wherein the one or more syntax elements conditionally include a second syntax element that indicates whether at least one of the one or more slices is a non-I slice.
Citation Information
Cited By
Predictive type signaling in video coding
JP2025169961A