Weighted sample biprediction in video coding.

Abstract

To provide a video processing method, a video processing device, and a computer readable medium.SOLUTION: A method contains steps of: leading a prediction block against the current block determined in accordance with a dual-direction coding unit level weighting (BCW) tool to which a weight is used for determining a weight sum of two initial prediction blocks used for determining the prediction block in order to convert the current block of a video image and a coding expression of the video image; and performing a conversion by using the prediction block. The leading of the prediction block contains steps of: adopting the weight to two intermediate prediction samples belonged to each of the two initial prediction blocks in order to lead a final prediction sample; performing a right shift operation pbSample>>(shift1+3) that performs a right shift operation to the final prediction sample in order to convert a bit depth of the final prediction sample; and determining the prediction block on the basis of the final prediction sample.SELECTED DRAWING: Figure 15C

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application is a divisional application of Japanese Patent Application No. 2022-516096, which is the national phase application of International Patent Application No. PCT / CN2020 / 114761 filed on September 11, 2020. It is intended to timely claim priority to and the benefit of International Patent Application No. PCT / CN2019 / 105825, filed September 13, 2019. For all purposes under law, the entire disclosure of said application is incorporated by reference as part of the disclosure of this specification.

[0002] This specification relates to video and image encoding and decoding techniques. [Background technology]

[0003] Digital video accounts for the largest bandwidth usage on the Internet and other digital communications networks, and the bandwidth demands for digital video use are expected to continue to grow as the number of connected user devices capable of receiving and displaying video increases. Summary of the Invention

[0004] Devices, systems, and methods are described for digital video processing, and in particular for co-located motion vectors in video processing. The described methods can be applied to both existing video coding standards (e.g., High Efficiency Video Coding (HEVC)) and future video coding standards (e.g., Versatile Video Coding (VVC)) or codecs.

[0005] In one exemplary aspect, a method of video processing is disclosed, the method including: making a first determination as to whether a co-located video block of a video block of a video is coded using an inter-coding mode or a non-inter-coding mode; making a second determination as to availability of a motion vector of the co-located video block or a derivation mode of the motion vector for the co-located video block based on the first determination; and converting between the video block and a coded representation of the video based on the second determination.

[0006] In another example aspect, a method of video processing is disclosed that includes determining one or more co-located motion vectors based on a reference index or reference list of a co-located video block of a video block for conversion between a video block of a video and a coded representation of the video, and performing the conversion based on the determination.

[0007] In yet another exemplary aspect, a method of video processing is disclosed, the method including: deriving a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, in which weights are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for conversion between a current block of a video and a coded representation of the video; and performing a conversion using the prediction block, in which deriving the prediction block applies weights to two intermediate prediction samples respectively belonging to the two initial prediction blocks to derive a final prediction sample; and performing a right shift operation on the final prediction sample to convert a bit depth of the final prediction sample, the right shift operation being pbSample>>(shift1+3), where pbSample indicates a final prediction sample and shift1 is set equal to Max(2,14-bitDepth), and determining the prediction block based on the final prediction sample.

[0008] In yet another exemplary aspect, a method of video processing is disclosed, the method including: deriving a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, where weights are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for a conversion between a current block of a video and a coded representation of the video; and performing a conversion using the prediction block, where deriving the prediction block includes applying weights to two intermediate prediction samples respectively belonging to two initial prediction blocks to derive a final prediction sample; and adding an offset to the final prediction sample, where the offset is 1<<(shift1+2), where shift1 is set equal to Max(2,14-bitDepth), and determining the prediction block based on the final prediction sample.

[0009] In yet another exemplary aspect, a method of video processing is disclosed that includes deriving a motion vector difference for a merge mode motion vector predictor for a current block according to rules and performing a conversion based on the derivation for a conversion between a current block of a video and a coded representation of the video, the rules specifying whether to clip the motion vector difference to the same range as a range used for clipping a motion vector.

[0010] In yet another exemplary aspect, a method of video processing is disclosed that includes deriving a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, where weights are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for a conversion between a current block of a video and a coded representation of the video, and at least one of the weights belongs to a weight table, the weight table being organized according to a rule, and performing the conversion using the prediction block, the rule specifying that the entries of the weight table are non-monotonic increasing.

[0011] In yet another exemplary aspect, a method of video processing is disclosed that includes deriving a predictive block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, where weights are used to determine a weighted sum of two initial predictive blocks used to determine a predictive block for a conversion between a current block of a video and a coded representation of the video, at least one of the weights belonging to a weight table, the weight table being selected from a plurality of weight tables, and performing the conversion using the predictive block.

[0012] In yet another exemplary aspect, a method of video processing is disclosed, the method includes deriving a prediction block for a current block determined according to a bidirectional coding level weighting (BCW) tool, where weights are used to determine a weighted sum of two initial prediction blocks used to determine the prediction block for conversion between a current block of the video and a coded representation of the video, and performing conversion using the prediction block, where deriving the prediction block includes converting intermediate prediction samples to a first bit depth, applying the weights to the intermediate prediction samples to derive final prediction samples, and converting the final prediction samples to a second bit depth.

[0013] In yet another exemplary aspect, a method of video processing is disclosed, comprising: deriving a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, where first and second weights are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for a conversion between a current block of a video and a coded representation of the video, the first and second weights belonging to at least one weight table, the weight table being organized according to a rule; and performing the conversion using the prediction block, the rule specifying that the weight table is asymmetric.

[0014] In yet another exemplary aspect, the methods described above may be implemented by a video encoder that includes a processing device.

[0015] In yet another exemplary aspect, the methods may be embodied in a form of processor executable instructions and stored on a computer readable program medium.

[0016] These and other aspects are further described herein. [Brief description of the drawings]

[0017] [Figure 1] 1 shows a block diagram of an exemplary encoder. [Diagram 2] 67 examples of intra prediction modes are shown. [Diagram 3] 4 shows examples of horizontal and vertical traverse scans. [Figure 4] 13 illustrates an example of scaling of motion vectors for temporal merge candidates. [Diagram 5] 13 shows candidate positions for temporal merge candidates. [Figure 6A] 1 illustrates spatially neighboring blocks used by alternative temporal motion vector prediction (ATMVP). [Figure 6B] 13 shows an example of deriving sub-CU motion fields. [Figure 7] 1 illustrates search points for a merge with motion vector difference (MMVD) mode. [Figure 8] 1 is a flowchart illustrating an example of a video processing method. [Figure 9] 13 is a flowchart illustrating another example of a video processing method. [Figure 10] 13 is a flowchart illustrating yet another example of a video processing method. [Figure 11] 13 is a flowchart illustrating yet another example of a video processing method. [Figure 12] 13 is a flowchart illustrating yet another example of a video processing method. [Figure 13] 13 is a flowchart illustrating yet another example of a video processing method. [Figure 14A] FIG. 2 is a block diagram illustrating an example of a hardware platform for implementing the visual media decoding or visual media encoding techniques described herein. [Figure 14B] FIG. 2 is a block diagram illustrating an example of a hardware platform for implementing the visual media decoding or visual media encoding techniques described herein. [Figure 15A] FIG. 2 illustrates a flowchart of an exemplary method of video processing consistent with some implementations of the disclosed technology. [Figure 15B] FIG. 2 illustrates a flowchart of an exemplary method of video processing consistent with some implementations of the disclosed technology. [Figure 15C] FIG. 2 illustrates a flowchart of an exemplary method of video processing consistent with some implementations of the disclosed technology. [Figure 15D] FIG. 2 illustrates a flowchart of an exemplary method of video processing consistent with some implementations of the disclosed technology. [Figure 15E] FIG. 2 illustrates a flowchart of an exemplary method of video processing consistent with some implementations of the disclosed technology. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] This specification provides various techniques that can be used by a decoder of an image or video bitstream to improve the quality of the decompressed or decoded digital video or image. For simplicity, the term "video" is used herein to include both a series of pictures (conventionally called video) and individual images. Furthermore, a video encoder may implement these techniques during the encoding process to reconstruct the decoded frames that are used for further encoding.

[0019] Section headings are used herein for ease of understanding and are not intended to limit embodiments disclosed in one section to only that section, and thus embodiments in one section may be combined with embodiments in other sections.

[0020] 1. Summary of the Invention This specification relates to video coding techniques. In particular, the present invention relates to co-located motion vectors and other coding tools. The present invention may be applied to existing video coding standards such as HEVC or to finalize standards (Versatile Video Coding). The present invention may also be applied to future video coding standards or video codecs.

[0021] 2. Initial consultations Video coding standards have evolved mainly through the development of well-known ITU-T and ISO / IEC standards. ITU-T created H.261 and H.263, ISO / IEC created MPEG-1 and MPEG-4 Visual, and the two organizations jointly created H.262 / MPEG-2 Video, H.264 / MPEG-4 AVC (Advanced Video Coding), and H.265 / HEVC standards. Since H.262, video coding standards have been based on a hybrid video coding structure in which temporal prediction + transform coding is utilized. In order to explore future video coding technologies beyond HEVC, in 2015, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET). Since then, many new methods have been adopted by JVET and incorporated into reference software called JEM (Joint Exploration Model). In April 2018, the Joint Video Expert Team (JVET) was established between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG), and is working on formulating the VVC standard with the goal of reducing the bitrate by 50% compared to HEVC.

[0022] 2.1 Color Spaces and Chroma Subsampling A color space, also known as a color model (or color system), is an abstract mathematical model that describes a range of colors simply as a tuple of numbers, typically three or four values, or color components (e.g. RGB). Essentially, a color space is a combination of a coordinate system and a subspace.

[0023] For video compression, the most frequently used color spaces are YCbCr and RGB.

[0024] YCbCr, Y'CbCr, or Y Pb / Cb Pr / Cr, also known as YCBCR or Y'CBCR, is a family of color spaces used as part of the pipeline for color images in video and digital photography systems. Y' is the luminance component, and CB and CR are the blue-difference and red-difference chroma components. Y' (which has a prime number) is distinct from Y, which is luminance, meaning that the light intensity is coded nonlinearly based on the gamma-corrected RGB primaries.

[0025] Chroma subsampling is a method of encoding images by implementing chrominance information at a lower resolution than luminance information, taking advantage of the fact that the human visual system perceives color differences less well than luminance.

[0026] 2.1.1 4:4:4 Each of the three Y'CbCr components has the same sample rate, so there is no chroma subsampling. This method is sometimes used in high-end film scanners and in cinema post-production.

[0027] 2.1.2 4:2:2 The two chroma components are sampled at half the luma sample rate and the horizontal chroma resolution is halved, allowing the bandwidth of the uncompressed video signal to be reduced by a factor of three with little or no visual difference.

[0028] 2.1.3 4:2:0 In 4:2:0, the horizontal sampling is doubled compared to 4:1:1, but the vertical resolution is halved because the scheme samples the Cb and Cr channels only on every other line. Thus, the data rate is the same. Cb and Cr are subsampled by a factor of two in both the horizontal and vertical directions, respectively. There are three variants of the 4:2:0 scheme, with different horizontal and vertical positions:

[0029] ● In MPEG-2, Cb and Cr are arranged side by side horizontally. Cb and Cr are located between pixels vertically (located between the lattices).

[0030] In JPEG / JFIF, H.261, and MPEG-1, Cb and Cr are located in the middle grid of alternating luminance samples.

[0031] ● In 4:2:0 DV, Cb and Cr are placed side by side together in the horizontal direction. In the vertical direction, Cb and Cr are alternating.

[0032] 2.2 Typical video codec encoding flow Figure 1 shows an example of an encoder block diagram for VVC, including three in-loop filtering blocks: Deblocking Filter (DF), Sample Adaptive Offset (SAO) and ALF. Unlike DF, which uses a predefined filter, SAO and ALF utilize the original samples of the current picture and reduce the mean square error between the original and reconstructed samples by adding an offset and applying a Finite Impulse Response (FIR) filter, respectively, with the coding side information signaling the offset and filter coefficients. The ALF is located at the last processing stage of each picture and can be considered as a tool that tries to capture and correct artifacts generated in the previous stage.

[0033] 2.3 Intra-mode coding with 67 intra-prediction modes To capture any edge orientation represented in natural video, the number of directional intra modes, as used in HEVC, is expanded from 33 to 65. The additional directional modes are indicated by the red dotted arrows in Figure 2, while the planar and DC modes remain the same. These denser directional intra prediction modes apply to all block sizes and to both luma and chroma intra prediction.

[0034] The traditional angular intra prediction direction is specified from 45 degrees to -135 degrees in a clockwise direction as shown in Figure 2. In VTM6, some traditional angular intra prediction modes are adaptively replaced with wide-angle intra prediction modes for non-square blocks. The replaced modes are signaled using the original method and remapped to the index of the wide-angle mode after parsing. The total number of intra prediction modes remains unchanged, i.e., 67, and the coding of intra modes remains unchanged.

[0035] In HEVC, all intra-coded blocks have a square shape, and the length of each of their sides is a power of 2. Thus, no division operation is required to generate an intra predictor using DC mode. In VVC, blocks may be rectangular, and in the general case, it is necessary to use a division operation for each block. To avoid division operations for DC prediction, only the long sides are used to calculate the average of non-square blocks.

[0036] 2.4 Inter Prediction For each inter-predicted CU, motion parameters consisting of motion vectors, reference picture indexes, and reference picture list usage indexes, as well as additional information required for the new coding features of VVC used for inter-prediction sample generation. The motion parameters may be signaled explicitly or implicitly. If a CU is coded in skip mode, it is associated with one PU and has no significant residual coefficients, coding motion vector deltas, or reference picture indexes. A merge mode is specified, which includes spatial and temporal candidates, as well as additional schedules introduced in VVC, to obtain motion parameters for the current CU from neighboring CUs. The merge mode can be applied to any inter-predicted CU, not just for skip mode. An alternative to the merge mode is to explicitly transmit the motion parameters, where the motion vector, the reference picture index corresponding to each reference picture list and the reference picture list usage flag, as well as other necessary information, are explicitly signaled for each CU.

[0037] 2.5 Intra Block Copy (IBC) Intra Block Copy (IBC) is a tool adopted in the HEVC extension of SCC. It is known to significantly improve the coding efficiency of screen content material. IBC mode is implemented as a block-level coding mode, so block matching (BM) is performed in the encoder to find the optimal block vector (or motion vector) for each CU. Here, the block vector is used to indicate the displacement from the current block to a reference block already reconstructed inside the current picture. Luma block vectors of IBC coded CUs are integer precision. Chroma block vectors are rounded to integer precision. When combined with AMVR, IBC mode can switch vector precision between 1-pixel and 4-pixel motion. IBC coded CUs are treated as a third prediction mode other than intra or inter prediction modes. IBC mode is applicable for CUs with both width and height less than or equal to 64 luma samples.

[0038] On the encoder side, we perform hash-based motion estimation for IBC. The encoder performs RD check for blocks with width or height less than or equal to 16 luma samples. For non-merge mode, we first perform block vector search using hash-based search. If the hash search does not return a valid candidate, we perform local search-based block matching.

[0039] In hash-based search, we extend the hash key matching (32-bit CRC) between the current block and the reference block to all allowed block sizes. The calculation of the hash key at each location in the current picture is based on 4x4 sub-blocks. If the size of the current block is larger, then if all the hash keys in all 4x4 sub-blocks match the hash key of the corresponding reference location, then the hash key is determined to match that of the reference block. If the hash keys of multiple reference blocks are found to match the hash key of the current block, we calculate the block vector cost of each matched reference block and select the one with the minimum cost.

[0040] In the block matching search, the search range is set to cover both the previous CTU and the current CTU.

[0041] At the CU level, IBC mode is signaled by a flag and can be signaled as IBC AMVP mode or IBC skip / merge mode as follows:

[0042] - IBC skip / merge mode: The merge candidate index is used to indicate which block vector from the list of neighboring candidate IBC coded block candidates to use to predict the current block. The merge list consists of spatial candidates, HMVP candidates, and pairwise candidates.

[0043] - IBC AMVP mode: Block vector differences are coded similarly to motion vector differences. The block vector prediction method uses two candidates as predictors, one from the left neighbor and one from the top neighbor (if IBC coded). If any neighbor is not available, a default block vector is used as predictor. A flag is signaled to indicate the block vector predictor index.

[0044] 2.6 Palette Mode In case of palette mode signaling, the palette mode is coded as the prediction mode for the coding unit, i.e., the prediction mode for the coding unit may be MODE_INTRA, MODE_INTER, MODE_IBC, MODE_PLT. When the palette mode is used, the pixel values ​​in the CU are represented by a small set of representative color values. The set is called the palette. For pixels with values ​​close to the colors in the palette, a palette index is signaled. For pixels with values ​​outside the palette, the pixel is represented by an escape symbol and the quantized pixel value is signaled directly.

[0045] To decode a palette-encoded block, the decoder needs to decode the palette colors and indices. The palette colors are described in a palette table and are encoded by a palette table encoding tool. An escape flag is signaled for each CU to indicate whether an escape symbol is present in the current CU. If an escape symbol is present, the palette table is incremented by one and the last index is assigned to the escape mode. The palette indices of all pixels in a CU form a palette index map and are encoded by a palette index map encoding tool.

[0046] To encode the palette table, a palette predictor is maintained. The predictor is initialized at the beginning of each slice, where the predictor is reset to 0. For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette or not. The reuse flag is transmitted using a run-length encoding of zeros. After this, the number of new palette entries is signaled using an exponential-Golomb code of order 0. Finally, the component values ​​of the new palette entry are signaled. After encoding the current CU, we update the palette predictor with the current palette and add entries from the previous palette predictor that are not reused in the current palette to the end of the new palette predictor until the maximum size allowed is reached (palette stuffing).

[0047] To encode a palette index map, the indices are encoded using horizontal and vertical transverse scans as shown in Figure 3. The palette_transpose_flag is used to explicitly signal the scan order in the bitstream.

[0048] The palette index is coded using the two main palette sample modes: 'INDEX' and 'COPY_ABOVE'. This mode is signalled using the flags except the top row if horizontal scanning is used, except the first column if vertical scanning is used, or using the flag if the previous mode was 'COPY_ABOVE'. In 'COPY_ABOVE' mode, we copy the palette index of the sample in the row above. In 'INDEX' mode, the palette index is signalled explicitly. For both 'INDEX' and 'COPY_ABOVE' modes, a run value is signalled specifying the number of pixels to be coded using the same mode.

[0049] The coding order of the index map is as follows: First, the number of index values ​​for the CU is signaled. This is followed by signaling the actual index value of the entire CU using Truncated Binary Coding. In bypass mode, both the number of indexes and the index value are coded. This groups index-related bypass bins. Next, the palette mode (INDEX or COPY_ABOVE) and run are signaled in an interleaved manner. Finally, the component escape values ​​corresponding to the escape samples for the entire CU are grouped and coded in bypass mode. After signaling the index value, an additional syntax element last_run_type_flag is signaled. This syntax element, in conjunction with the number of indexes, eliminates the need to signal a run value corresponding to the last run in the block.

[0050] In VTM5.0, dual tree is enabled for I slices which separates the coding units for Luma and Chroma. So in this proposal, palette is applied separately for Luma (Y component) and Chroma (Cb, Cr components). When dual tree is disabled, palette is applied jointly for Y, Cb, Cr components, similar to HEVC palette.

[0051] 2.7 Temporal Motion Vector Prediction (TMVP) in VVC To derive the temporal merge candidate, a scaled motion vector is derived based on the co-located CU belonging to the co-located reference picture. In the slice header, the reference picture list used to derive the co-located CU is explicitly signaled. As shown by the dotted line in FIG. 4, the scaled motion vector of the temporal merge candidate is obtained, which is scaled from the motion vector of the co-located CU using the POC distance tb and the POC distance td. tb is defined as the POC distance between the reference picture of the current picture and the current picture, and td is defined as the POC distance between the reference picture of the co-located PU and the co-located picture. Set the reference picture index of the temporal merge candidate equal to zero.

[0052] Select a temporal candidate position between candidates C0 and C1 as shown in Figure 5. If the CU at position C0 is not available, is intra-coded, or is outside the current CTU row, then position C1 is used. Otherwise, position C0 is used to derive the temporal merge candidate.

[0053] 2.8 Sub-block based Temporal Motion Vector Prediction in VVC (SbTMVP) VTM supports the sub-block based temporal motion vector prediction in VVC (SbTMVP) method. SbTMVP, like temporal motion vector prediction in HEVC (TMVP), uses motion fields in co-located pictures to improve the motion vector prediction and merge mode of CUs in the current picture. The same co-located pictures used in TMVP are used for SbTVMP. SbTMVP differs from TMVP in two main aspects:

[0054] 1. TMVP predicts behavior at the CU level, while SbTMVP predicts behavior at the sub-CU level.

[0055] 2. TMVP fetches temporal motion vectors from a co-located block in a co-located picture (a co-located block is a bottom-right or center block with respect to the current CU), while SbTMVP applies a motion shift before fetching temporal motion information from the co-located picture, and the motion shift is obtained from a motion vector of one of the spatially neighboring blocks of the current CU.

[0056] The SbTVMP process is shown in Figure 6. SbTMVP predicts motion vectors of sub-CUs in the current CU in two steps. In the first step, we check the spatial neighborhood A1 in Figure 6A. If A1 has a motion vector that uses a co-located picture as its reference picture, we select this motion vector as the motion shift to be applied. If no such motion is identified, the motion shift is set to (0,0).

[0057] In the second step, the motion shift identified in step 1 is applied (i.e., added to the coordinates of the current block) to obtain sub-CU level motion information (motion vector and reference index) from the co-located picture as shown in FIG. 6B. For example, in FIG. 6B, assume that the motion shift is set to the motion of block A1. Then, for each sub-CU, the motion information of its corresponding block of the co-located picture (the smallest motion grid covering the center sample) is used to derive the motion information of the sub-CU. After identifying the motion information of the co-located sub-CU, it is converted to the motion vector and reference index of the current sub-CU, similar to the TMVP process of HEVC, and temporal motion scaling is applied to align the reference picture of the temporal motion vector to the reference picture of the current CU.

[0058] In VTM6, the combined sub-block-based merge list, including both SbTVMP and affine merge candidates, is used to signal the sub-block-based merge mode. SbTVMP mode is enabled / disabled by a sequence parameter set (SPS) flag. If SbTMVP mode is enabled, add the SbTMVP predictor as the first entry in the list of sub-block-based merge candidates, followed by the affine merge candidates. In the SPS, the size of the sub-block-based merge list is signaled, and in VTM6, the maximum allowed size of the sub-block-based merge list is 5.

[0059] The size of the sub-CUs used in SbTMVP is fixed to 8x8, and similar to the affine merge mode, the SbTMVP mode is only applicable to CUs whose width and height are both 8 or greater.

[0060] The coding logic of the additional SbTMVP merge candidate is the same as other merge candidates, i.e., for each CU in a P slice or B slice, an additional RD check is performed to decide whether to use the SbTMVP candidate.

[0061] [ka]

[0062] 8.5.2.11 Derivation process for temporal luma motion vector prediction The inputs to this process are: - the luminance position (xCb, yCb) of the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, A variable cbHeight that specifies the height of the current coding block in luma samples. A reference index refIdxLX where X is either 0 or 1. The output of this process is: - Motion vector prediction mvLXCol with 1 / 16 fractional sample accuracy. - Availability flag availableFlagLXCol. The variable currCb specifies the current luma coding block at luma location (xCb, yCb). The variables mvLXCol and availableFlagLXCol are derived as follows. - If slice_temporal_mvp_enabled_flag is 0 or (cbWidth*cbHeight) is less than or equal to 32, both modules of mvLXCol are set to 0 and availableFlagLXCol is set to 0. - Otherwise (slice_temporal_mvp_enabled_flag is 1), the following ordered steps apply: 1. The bottom right co-located motion vector, as well as the bottom and right boundary sample positions, are derived as follows: xColBr=xCb+cbWidth (8-421) yColBr=yCb+cbHeight (8-422) rightBoundaryPos=subpic_treated_as_pic_flag[SubPicIdx]? SubPicRightBoundaryPos:pic_width_in_luma_samples-1 (8-423) botBoundaryPos=subpic_treated_as_pic_flag[SubPicIdx]? SubPicBotBoundaryPos:pic_height_in_luma_samples-1 (8-424) - If yCb>>CtbLog2SizeY equals yColBr>>>CtbLog2SizeY and yColBr is less than or equal to botBoundaryPos and xColBr is less than or equal to rightBoundaryPos then the following applies: The variable colCb specifies a luma coding block that covers a modified position given by ((xColBr>>3)<<3,(yColBr>>3)<<3) in the co-located picture specified by ColPic. - The luma position (xColCb, yColCb) is set equal to the top-left sample of the co-located luma coding block specified by colCb, relative to the top-left luma sample of the picture co-located by ColPic. - Invoke the co-located motion vector derivation process specified in Section 8.5.2.12 with currCb, colCb, (xColCb, yColCb), refIdxLX and sbFlag set equal to 0 as input and assign the output to mvLXCol and availableFlagLXCol. - Otherwise, set both modules in mvLXCol equal to 0 and set availableFlagLXCol equal to 0. 2. If availableFlagLXCol is equal to 0, then the centered co-located motion vectors are derived as follows: xColCtr=xCb+(cbWidth>>1) (8-425) yColCtr=yCb+(cbHeight>>1) (8-426) The variable colCb specifies a luma coding block that covers a modified position given by ((xColCtr>>3)<<3,(yColCtr>>3)<<3) in the co-located picture specified by ColPic. - The luma position (xColCb, yColCb) is set equal to the top-left sample of the co-located luma coding block specified by colCb, relative to the top-left luma sample of the picture co-located by ColPic. - Invoke the co-located motion vector derivation process specified in Section 8.5.2.12 with currCb, colCb, (xColCb, yColCb), refIdxLX and sbFlag set equal to 0 as input and assign the output to mvLXCol and availableFlagLXCol.

[0063] 8.5.2.12 Co-located motion vector derivation process The inputs to this process are: - the variable currCb that defines the current coding block, a variable colCb specifying the co-located coding block in the co-located picture specified by ColPic, - The luma position (xColCb, yColCb) specifies the top-left sample of the co-located luma coding block defined by colCb relative to the top-left luma sample of the co-located picture defined by ColPic. A reference index refIdxLX, where X is 0 or 1. - Flag indicating sub-block temporal merging candidate sbFlag. The output of this process is: - Motion vector prediction mvLXCol with 1 / 16 fractional sample accuracy, - Availability flag availableFlagLXCol. The variable currPic specifies the current picture. The arrays predFlagL1Co0[x][y], mlvL0Col[x][y], and refIdxL0Col[x][y] are set equal to PredFlagL0[x][y], MvDmvrL0[x][y], and RefIdxL0[x][y], respectively, of the co-located picture specified by ColPic, and the arrays predFlagL1Col[x][y], mvL1Col[x][y], and refIdxL1Col[x][y] are set equal to PredFlagL1[x][y], MvDmvrL1[x][y], and RefIdxL1[x][y], respectively, of the co-located picture specified by ColPic. The variables mvLXCol and availableFlagLXCol are derived as follows.

[0064] [ka]

[0065] 2.8.1 Derivation of Co-located Motion Vectors When Coding colCb in Inter Blocks - If sbFlag is 0, availableFlagLXCol is set equal to 1 and the following applies: - predFlagL0Col[xColCb][yColCb] is set equal to 0, mvCol, refIdxCol, and listCol are set equal to mvL0Col[xColCb][yColCb], refIdxL0Col[xColCb][yColCb], and L0, respectively. - Otherwise, predFlagL0Col[xColCb][yColCb] is set equal to 1, predFlagL1Col[xColCb][yColCb] is set equal to 0, and mvCol, refxIdCol and listCol are set equal to mvL0Col[xColCb][yColCb], refIdxL0Col[xColCb][yColCb] and L0, respectively. - Otherwise (if predFlagL0Col[xColCb][yColCb] is equal to 1 and predFlagL1Col[xColCb][yColCb] is 1), make the following assignments: - NoBackwardPredFlag is set to 1, mvCol, refIdxCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively. - Otherwise, mvCol, refIdxCol, and listCol are set equal to mvLNCol[xColCb][yColCb], refIdxLNCol[xColCb][yColCb], and LN, respectively, where N is the value of collocated_from_l0_flag. - Otherwise (sbFlag is 1), the following applies: - if predFlagLXCol[xColCb][yColCb] is 1, then mvCol, refxIdCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively, and availableFlagLXCol is set equal to 1. - Otherwise (PredFlagLXCol[xColCb][yColCb] is 0), the following applies: - if NoBackwardPredFlag is equal to 1 and PredFlagLYCol[xColCb][yColCb] is equal to 1 then mvCol, refxIdCol, listCol are set to mvLYCol[xColCb][yColCb], refIdxLYCol[xColCb][yColCb], and LY, respectively, Y is equal to !X, where X is the value of X for invoking this operation, and availableFlagLXCol is set equal to 1. - Otherwise, set both modules in mvLXCol equal to 0 and set availableFlagLXCol equal to 0. If availableFlagLXCol is TRUE, then mvLXCol and availableFlagLXCol are derived as follows: - If LongTermRefPic(currPic, currCb, refIdxLX, LX) is not equal to LongTermRefPic(ColPic, colCb, refIdxCol, listCol), then the modules of mvLXCol are both set to 0 and availableFlagLXCol is set equal to 0. - Otherwise, the variable availableFlagLXCol is set equal to 1, refPicList[listCol][refIdxCol] is set to the picture with reference index refIdxCol in the reference picture list listCol of the slice containing the coding block colCb in the co-located picture specified by ColPic, and then apply: colPocDiff=DiffPicOrderCnt(ColPic,refPicList[listCol][refIdxCol]) (8-427) currPocDiff=DiffPicOrderCnt(currPic,RefPicList[X][refIdxLX]) (8-428) - The co-located motion vector temporal motion buffer compression process as specified in subclause 8.5.2.15 is invoked with mvCol as input and modified mvCol as output. - If RefPicList[X][refIdxLX] is a long-term reference picture or if colPocDiff is equal to currPocDiff, mvLXCol is derived as follows: mvLXCol=mvCol (8-429) Otherwise, mvLXCol is derived as a scaled version of the motion vector mvCol as follows: tx=(16384+(Abs(td)>>1)) / td (8-430) distScaleFactor=Clip3(-4096,4095,(tb*tx+32)>>6) (8-431) mvLXCol=Clip3(-131072,131071,(distScaleFactor*mvCol+128-(distScaleFactor*mvCol>=0))>>8)) (8-432) Here, td and tb are derived as follows: td=Clip3(-128,127,colPocDiff) (8-433) tb=Clip3(-128,127,currPocDiff) (8-434)

[0066] 2.9 CU-level Weighted Bidirectional Prediction (BCW) In HEVC, a bi-predictive signal is generated by averaging two prediction signals taken from two different reference pictures and / or by using two different motion vectors. In VTM6, the bi-predictive mode is extended beyond a simple average to allow a weighted average of the two prediction signals.

[0067]

number

[0068] In weighted average bi-prediction, five weights w∈{-2,3,4,5,10} are allowed. For each bi-predicted CU, the weight w is determined in one of two ways: 1) for non-merged CUs, signal the weight index after the motion vector difference; 2) for merged CUs, infer the weight index from neighboring blocks based on the merge candidate index. Weighted average bi-prediction is only applied to CUs with 256 or more luma samples (i.e., CU width × CU height is 256 or more). For low latency pictures, all five weights are used. For non-low latency pictures, only three weights (w∈{3,4,5}) are used.

[0069] - At the encoder, apply fast search algorithms to find the weight index without significantly increasing the encoder complexity. These algorithms are summarized below. For further details, see VTM software and JVET-L0646. When combined with AMVR, conditionally check for unequal weights only for 1-pixel and 4-pixel motion vector precision if the current picture is a low-latency picture.

[0070] - When combined with affine, affine ME is performed with unequal weights only if an affine mode is selected as the current best mode.

[0071] - If the two reference pictures in bi-prediction are the same, unequal weights are only conditionally checked.

[0072] - Do not search for unequal weights if certain conditions are met based on the POC distance between the current picture and its reference pictures, the coding QP, and the temporal level.

[0073] The BCW weight index is coded using one context coding bin followed by a bypass coding bin: the first context coding bin indicates whether equal weights are used, and if unequal weights are used, an additional bin is signaled using bypass coding to indicate which unequal weights are used.

[0074] Weighted Prediction (WP) is a coding tool supported by H.264 / AVC and HEVC standards to efficiently code video content with fading. The VVC standard also added support for WP. WP allows signaling weighting parameters (weight and offset) for each reference picture in each of the reference picture lists L0 and L1. Then, during motion compensation, the weight and offset of the corresponding reference picture are applied. WP and BCW are designed for different types of video content. To avoid the interaction between WP and BCW, which complicates the design of VVC decoders, when a CU uses WP, the BCW weight index is not signaled and w is inferred to be 4 (i.e., equal weights are applied). For merge CUs, the weight index is inferred from the neighboring blocks based on the merge candidate index. This can be applied to both normal merge mode and inherited affine merge mode. For constructed affine merge mode, the affine motion information is constructed based on the motion information of up to three blocks. To derive the BCW index for a CU using the constructed affine merge mode, the following process is used.

[0075] 1. Divide the range of BCW index {0,1,2,3,4} into three groups: {0}, {1,2,3}, {4}. If the BCW indices of all control points are from the same group, derive the BCW index as in step 2, otherwise set the BCW index to 2.

[0076] If at least two control points have the same BCW index, assign this BCW index value to the candidate; otherwise, set the BCW index of the currently constructed candidate to 2.

[0077] 2.10 Merge mode with MVD (MMVD) In addition to the merge mode, we introduce a merge mode with motion vector difference (MMVD) in VVC when the implicitly derived motion information is directly used for predictive sample generation of the current CU. Immediately after sending the skip and merge flags, we signal the MMVD flag to specify whether the MMVD mode is used for the CU.

[0078] In MMVD, after a merge candidate is selected, it is further refined by signaled MVD information. This further information includes a merge candidate flag, an index to specify the magnitude of motion, and an index to indicate the motion direction. In MMVD mode, one of the first two candidates in the merge list is selected to use as the MV base. A merge candidate flag is signaled to specify which one to use.

[0079] The distance index specifies the magnitude of the motion and indicates an offset from a predefined starting point. The offset is added to either the horizontal or vertical component of the starting MV, as shown in Figure 7. The relationship between the distance index and the predefined offsets is shown in Table 1.

[0080] [Table 1]

[0081] The direction index represents the direction of the MVD relative to the starting point. The direction index can represent four directions, as shown in Table 2. Note that the meaning of the MVD code may be different according to the information of the starting MV. If the starting MV is an unpredicted MV or a bi-predictive MV, and both lists point to the same side of the current picture (i.e., the POC of the two reference codes are both greater than the POC of the current picture, or both less than the POC of the current picture), the code in Table 2 specifies the sign of the MV offset added to the starting MV. If the starting MV is a bi-predictive MV, and the two MVs point to different sides of the current picture (i.e., the POC of one reference is greater than the POC of the current picture, and the POC of the other reference is less than the POC of the current picture), the code in Table 2 specifies the sign of the MV offset added to the list0 MV component of the starting MV, and the sign of the list1 MV has an inverse value.

[0082] [Table 2]

[0083] 2.11 Alternative Luminance Half-Pixel Interpolation Filter In JVET-N0309, an alternative half-pixel interpolation filter is proposed.

[0084] The switching of half-pixel luma interpolation filters is done based on the motion vector precision. In addition to the existing quarter-pixel, full-pixel, and 4-pixel AMVR modes, a new half-pixel precision AMVR mode is introduced. Only in the case of half-pixel motion vector precision can the alternative half-pixel luma interpolation filter be selected.

[0085] 2.11.1 1 / 2 pixel AMVR mode An additional AMVR mode for non-affine non-merged inter coded CUs is proposed, which allows to signal motion vector differences with half pixel precision. The existing AMVR scheme of the current VVC draft is extended simply as follows: Immediately after the syntax element amvr_flag there is a new context modeled binary syntax element hpel_amvr_flag, which indicates the use of the new half pixel AMVR mode if hpel_amvr_flag==1. Otherwise, i.e. if hpel_amvr_flag==0, the choice between full pixel and 4 pixel AMVR modes is indicated by the syntax element amvr_precision_flag, as in the current VVC draft.

[0086] 2.11.2 Alternative Luminance Half-Pixel Interpolation Filters For non-affine non-merged inter coded CUs using half-pixel motion vector precision (i.e., half-pixel AMVR modes), switch between the HEVC / VVC half-pixel luma interpolation filter and one or more alternative half-pixel interpolators based on the value of the new syntax element if_idx. The syntax element if_idx is signaled only for half-pixel AMVR modes. For skip / merge modes with spatial merge candidates, the value of the syntax element if_idx is inherited from the neighboring blocks.

[0087] 2.11.2.1 Test 1: One Alternating Half-Pixel Interpolation Filter In this test case, there is one 6-tap interpolation filter as an alternative to the normal HEVC / VVC 1 / 2 pixel interpolation filter. The following table shows the mapping between the values ​​of the syntax element if_idx and the selected 1 / 2 pixel luma interpolation filter.

[0088] [Table 3]

[0089] 2.11.2.1 Test 2: Two alternative half-pixel interpolation filters In this test case, there are two 8-tap interpolation filters as alternatives to the normal HEVC / VVC 1 / 2 pixel interpolation filters. The following table shows the mapping between the values ​​of the syntax element if_idx and the selected 1 / 2 pixel luma interpolation filters.

[0090] [Table 4]

[0091] [ka] It is signaled to indicate whether the current CU is using 1 / 2 pixel, 1 pixel or 4 pixel MV precision. There are 2 bins to be coded.

[0092] [ka] It is signaled to indicate whether to use the default half-pel interpolation filter or an alternative half-pel interpolation filter. If two alternative half-pel interpolation filters are used, there are two bins to code.

[0093] 3. Shortcomings of existing implementations Current designs for deriving co-located motion vectors in inter prediction have the following problems.

[0094] 1. The derivation of the co-located motion vector in TMVP and SbTMVP depends on the prediction mode of the co-located coding block. In current VVC, if the co-located coding block is coded in intra prediction mode or IBC prediction mode, the co-located motion vector is set to a zero motion vector. Thus, even if the co-located block is palette coded, it may still return an undefined co-located motion vector since there is no motion vector associated with the palette prediction mode.

[0095] 2. Deriving weighted sample predictions may not be efficient in BCW.

[0096] 3. In the current VVC, MV is clipped to 18 bits. However, if the merged motion vector difference is clipped to 16 bits, the accuracy may be reduced.

[0097] 4. Signaled cu_skip_flag may cause overhead bits. Currently in VVC, the maximum width and height for a coding unit of IBC is 64. In an I-slice, there is no need to signal cu_skip_flag for blocks whose either width or height is greater than 64.

[0098] 5. The alternative luma half-pixel interpolation filter flag may be set equal to TRUE even if the CU / PU / block does not have half-pixel or coarse MV components.

[0099] 4. Exemplary Methods of Co-located Motion Vectors in Video Coding The following detailed inventions should be considered as examples to illustrate the general concept. These inventions should not be construed in a narrow sense. Moreover, these inventions can be combined in any manner.

[0100] [ka]

[0101] 1. Instead of checking whether the co-located coding block is intra-coded or IBC-coded, how to derive the co-located motion vector and / or the availability of the co-located motion vector may depend on whether the prediction mode of the co-located coding block is inter-coded or not. In this case, there is no need to store four prediction modes per block, and only one bit is needed to signal whether the block is inter or non-inter. a. In one example, when a co-located coding block is coded in palette prediction mode, how to derive a co-located motion vector and / or the availability of a co-located motion vector may be similar to when the co-located coding block is coded in intra / IBC prediction mode. b. In one example, if the co-located coding block is coded in a non-inter prediction mode (e.g., intra, palette, or IBC), the co-located motion vector may be set to unavailable. c. Alternatively, the co-located motion vector may be marked as available, and if the co-located coding block is coded in a non-inter prediction mode (e.g., intra, palette, or IBC), a default motion vector may be assigned as the co-located motion vector. d. Alternatively, if the co-located coding block is coded in a non-inter prediction mode, other blocks (e.g., an inter coding block in one neighborhood of the co-located coding block) may be checked. i. In one example, the neighboring block may be the nearest inter-coded block located to the left / right / above / below of the co-located coded block. 2. The determination of the co-located motion vector may depend on the reference list and / or reference index of the co-located coding block. a. In one example, when the reference index of the reference list X (e.g., L1) of the coded blocks arranged at the same position is not equal to a specific value (e.g., 0), the motion vectors arranged at the same position may be derived (e.g., using the prior art as described in 2.8.1). b. In one example, when the reference index of the reference list X (e.g., L1) of the coded blocks arranged at the same position is equal to a specific value (e.g., 0), the derivation of the motion vectors arranged at the same position may be invoked. c. Further, alternatively, when the coded blocks arranged at the same position are coded in a non-inter prediction mode (including or not including IBC), or when their reference pictures do not meet the predetermined conditions, the MVs arranged at the same position are set to be unavailable. i. Alternatively, the MVs arranged at the same position are set to default values.

[0102]

Chemical formula

[0103] 3. The weight table applied in the BCW coding mode may be asymmetric. a. In one example, for the weight W as an entry in the table, (1 - W) may not be a table entry, W is within the range of [a, b], and (a + b) is equal to 1. b. In one example, for the weight W as an entry in the table, assuming that the final prediction block is generated by (W0 * P0 + W1 * P1) >> N, where W0 and W1 are two weights applied to two prediction blocks P0 and P1 respectively, and (W0 + W1) is equal to (1 << N), (2 N -W) may not be a table entry. 4. The weights in the weight table applied in the BCW coding mode may not be in an order that monotonically increases. a. In one example, the (i + 1)-th entry of the table may have a value smaller than the i-th entry of the table. 5. In one example, the forecasting process for weighted samples of BCW may rely on different weighting lookup tables. In one example, {4,5,3,10,2} / {4,3,5,10,2} / {4,5,3,10,1} / {4,3,5,10,1} / {4,5,3,10,-1} may be used as the weight lookup table for BCW. 6. In one example, in the weighted sample prediction process of BCW, intermediate prediction samples of each prediction direction can be converted to a first bit depth (if necessary, for example, if the first bit depth is not equal to the bit depth of the intermediate prediction sample), and then weighted prediction can be applied and the final prediction sample can be converted to a second bit depth. In one example, the second bit depth is the same as the input bit depth of the current color component. b. In one example, when converting between different bit depths, a right shift (e.g., converting samples from a higher bit depth to a lower bit depth) or a left shift (e.g., converting samples from a lower bit depth to a higher bit depth) may be applied. i. Additionally, alternatively, an offset may be added before the right or left shift. c. In one example, the first bit depth is the same as the bit depth of the intermediate prediction samples. The weighted sample prediction of BCW is pbSamples[x][y]=Clip3(0,(1<<bitDepth)-1,(w0*predSamplesL0[x][y]+w1*predSamplesL1[x][y]+offset3)> >(shift1+3)), where shift1 is set to Max(2,14-bitDepth), the variable offset3 is set to 1<<(shift1+2), and bitDepth is the bit depth of the current color component. d. In one example, the first bit depth is the same as the input bit depth of the current color component. The weighted sample prediction of the BCW is pbSamples[x][y]=Clip3(0,(1<<bitDepth)-1,(w0*((predSamplesL0[x][y]+offset1)> >shift1)+w1*((predSamplesL1[x][y]+offset1)>>shift1)+4)>>3), where shift1 is set to Max(2,14-bitDepth) and variable offset1 is set to 1<<(shift1-1).

[0104] [ka]

[0105] 7. In one example, the merged motion vector difference may be clipped to the same range as the motion vector. In one example, the merge motion vector difference is 18 bits, which is the same range of motion vectors in VVC, e.g., [-2 17 ,2 17 -1]. b. In one example, the merge motion vector difference is [-2 17 +1,2 17 -1]. c. In one example, the merged motion vector difference may not be clipped. i. For example, add the merged motion vector difference to the candidate motion vector prediction, then clip the motion vector result to 18 bits.

[0106] [ka]

[0107] 8.CU / PU / Block [ka] It is proposed that the indication of whether a block is coded with may be conditionally signaled depending on the size of the coding block. In one example, if the current slice type is an I slice, sps_ibc_enabled_flag is TRUE, and both the block width and the block height are less than or equal to N (N is an integer), [ka] For example, N=64. b. In one example, if the current block is coded in IBC mode, when both the block width and the block height are less than or equal to N (N is an integer), [ka] may be signaled. For example, N=64.

[0108] [ka]

[0109] 9. Whether encoding tool X (e.g., X is TMVP / ATMVP / BCW / MMVD / PDPC) can be applied to a block of a first color component may depend on whether it is applied to one or more corresponding blocks in a second color component. a. In one example, use of encoding tool X for a first color component (e.g., chroma) block may be disabled if the encoding tool is applied to a corresponding second color component (e.g., luma) block. b. In one example, use of encoding tool X for a first color component (e.g., chroma) block may be disabled if encoding tool Y (where Y is different from X) is applied to a corresponding second color component (e.g., luma) block. c. In one example, a message (e.g., a flag or index) may be conditionally signaled to indicate whether encoding tool X applies to a first color component of a block. The condition may be defined as whether it applies to a corresponding second color component block. Additionally, alternatively, if it does not apply to a corresponding second color component block, it is not applied without signaling to the first component of the block. i. In one example, coding tool X may be applied in different ways to different color components. 1) It may be informed how to apply encoding tool X separately to luma and chroma components. d. In one example, the first color component is a chroma component and the second color component is a luma component. e. In one example, the first color component is one chroma color component and the second color component is another chroma color component. f. In one example, the first color component is a luma color component and the second color component is a chroma color component. g. In the above description, a "corresponding second color component block" may refer to a second color component block that covers at least one "corresponding sample" of a first color component block. i. In one example, the first color component is a chroma component and the second color component is a luma component. ii. The sample positions may be scaled according to the color format, such as 4:4:4 or 4:2:0. Let the top-left position of the chroma block be (x0,y0), and the width and height of the chroma block be W and H, both scaled to luma sample units. iii. In one example, the corresponding sample may be (x0, y0). iv. In one example, the corresponding sample may be (x0+W-1, y0+H-1). v. In one example, the corresponding sample may be (x0+W / 2-1, y0+H / 2-1). vi. In one example, the corresponding sample may be (x0+W / 2, y0+H / 2). vii. In one example, the corresponding sample may be (x0+W / 2, y0+H / 2-1). viii. In one example, the corresponding sample may be (x0+W / 2-1, y0+H / 2). h. In the above description, a "chroma component" may refer to "one or more chroma components." 10. When coding a luma block at the same position of a chroma block in some modes, it is proposed to disable the position-dependent intra-prediction sample filtering process (aka PDPC) for some chroma components. In one example, such processing may be disabled if the co-located luma block of a chroma block is coded in Matrix-based Intra Prediction (MIP) mode. b. In one example, such processing may be disabled if the co-located luma block of a chroma block is coded in Multiple Reference Line (MRL) mode. 11. If a CU / PU / block has only MV components with precision finer than half pixel (e.g., quarter pixel, eighth pixel, etc.), the indication of whether to use an alternative half pixel interpolation filter may be set equal to false, i.e., a default half pixel interpolation filter may be used instead of the alternative half pixel interpolation filter. In one example, if the reconstructed MV has only MV components with precision finer than ½ pixel, such indication may be set to false in MMVD mode. b. In one example, such indication may be set to false for a pair-wise merge candidate if it has only MV components finer than ½ pixel. c. In one example, when converting reconstructed bi-predictive motion information to uni-predictive motion information having only MV components with precision finer than ½ pixel (e.g., applied to small blocks such as 4*8 or / and 8*4 blocks), such an indication may be set to false. 12. The indication of whether to use an alternative half-pixel interpolation filter may, in some cases, always be set equal to false, i.e., in these cases, the default half-pixel interpolation filter may always be used. In one example, such an indication may always be set to false in MMVD mode. b. In one example, such an indication may always be set to false in MMVD mode when a particular MVD is selected. i. For example, if a MVD with quarter pixel accuracy is selected, then such indication may be set equal to false. c. In one example, such an indication may always be set to false for pair-wise merge candidates. d. In one example, when converting reconstructed bi-predictive motion information into uni-predictive motion information (e.g., applied to small blocks such as 4*8 or / and 8*4 blocks), such an indication may be set to false.

[0110] [ka]

[0111] 13. Whether and / or how to apply the above disclosed methods may be signaled at the sequence level / picture level / slice level / tile group level, for example in the sequence header / picture header / SPS / VPS / DPS / PPS / APS / slice header / tile group header.

[0112] The above examples may be included in the context of the methods described below, such as methods 800, 900, 1000, 1100, 1200 and 1300, which may be implemented in a video decoder or a video encoder.

[0113] 8 shows a flow chart of an example video processing method. The method 800 includes, at step 810, determining the availability of one or more co-located motion vectors based on a prediction mode of a co-located video block relative to a current video block.

[0114] The method 800 includes, at step 820, converting between the current block and a bitstream representation of the current block based on one or more co-located motion vectors, and the indication of the prediction mode includes one bit indicating whether the current video block is coded in inter mode or non-inter mode.

[0115] 9 shows a flow chart of an exemplary video processing method. The method 800 includes, at step 910, determining a type of a co-located video block of the video block for conversion between the coded representation of the video block and the video block, the type taking only one of two possible values.

[0116] The method 800 includes, at step 920, performing a transformation based on the determination.

[0117] 10 shows a flowchart of an exemplary video processing method. The method 800 includes, at step 1010, deriving a prediction sample for a current block based on a first weight table associated with a coding unit (CU) level weighted bi-prediction (BCW) process, the first weight table being asymmetric.

[0118] The method 800 includes, at step 1020, converting between the current block and a bitstream representation of the current block based on the predicted samples.

[0119] 11 shows a flow chart of an example video processing method. The method 800 includes, at step 1110, making a decision based on a dimension of the current video block regarding selective signaling of an indication of skip mode encoding of the current video block in a bitstream representation of the current video block.

[0120] The method 800 includes, at step 1120, converting between the current block and the bitstream representation of the current block based on the determination.

[0121] 12 shows a flow chart of an exemplary video processing method. The method 800 includes, at step 1210, making a decision regarding selective application of a second encoding tool to at least one block of a second color component of a current video block based on application of a first encoding tool to one or more blocks in a first color component of the current video block.

[0122] The method 800 includes, at step 1220, converting between the current block and the bitstream representation of the current block based on the determination.

[0123] 13 shows a flow chart of an exemplary video processing method. The method 800 includes, at step 1310, making a decision regarding selective signaling of an instruction to use an alternative half-pel interpolation filter instead of a default half-pel interpolation filter based on the accuracy of the motion vector in the current video block.

[0124] The method 800 includes, at step 1320, converting between the current block and the bitstream representation of the current block based on the determination.

[0125] Some embodiments of the disclosed technology include determining or determining to enable a video processing tool or mode. In one example, if a video processing tool or mode is enabled, the encoder uses or implements the tool or mode when processing one video block, but does not necessarily modify the resulting bitstream based on the use of the tool or mode. That is, the conversion from a block of video to a bitstream representation of video uses the video processing tool or mode if the video processing tool or mode is enabled based on the decision or determination. In another example, if the video processing tool or mode is enabled, the decoder processes the bitstream knowing that the bitstream has been modified based on the video processing tool or mode. That is, the conversion from the bitstream representation of video to a block of video is performed using the video processing tool or mode enabled based on the decision or determination.

[0126] Some embodiments of the disclosed techniques include deciding or determining 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 a video into a bitstream representation of the video. In another example, when a video processing tool or mode is disabled, a decoder processes the bitstream with the knowledge that the bitstream has not been modified using the video processing tool or mode that was disabled based on the decision or determination.

[0127] As used herein, the term "video processing" can refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during conversion of 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 spread to the same or different locations in the bitstream, e.g., as specified by a syntax. For example, one macroblock may be coded in terms of transformed and coded error residual values, and using bits in the header and other fields in the bitstream.

[0128] 5. Examples of the Disclosed Technology The changes are highlighted in bold and italic text. Deleted text is marked with double brackets (e.g., [[a]] means the letter "a" is deleted).

[0129] 5.1 Embodiment #1 The working draft specified in JVET-O2001-vE may be modified as follows: 8.5.2.12 Co-located motion vector derivation process … The variables mvLXCol and availableFlagLXCol are derived as follows.

[0130] [ka]

[0131] - Otherwise, the motion vector mvCol, the reference index refIdxCol and the reference list identifier listCol are derived as follows: … Alternatively, the following can be applied: The variables mvLXCol and availableFlagLXCol are derived as follows.

[0132] [ka]

[0133] - Otherwise, the motion vector mvCol, the reference index refIdxCol and the reference list identifier listCol are derived as follows: …

[0134] 5.2 Example #2 The working draft specified in JVET-O2001-vE may be modified as follows: 8.5.1 General Decoding Process for Inter-Prediction Coded Units … 3. The decoder-side motion vector refinement luma and chroma motion vector arrays refMvLX[xSbIdx][ySbIdx] and refMvCLX[xSbIdx][ySbIdx] (for X = 0 and 1) are derived as follows for xSbIdx = 0..numSbX-1, ySbIdx = 0..numSbY-1: - if dmvrFlag is 1, the derivation process for chroma motion vectors of section 8.5.2.13 is invoked with refMvLX[xSbIdx][ySbIdx] and refIdxLX as input and refMvCLX[xSbIdx][ySbIdx] as output, and the input refMvLX[xSbIdx][ySbIdx] is derived as follows: refMvLX[xSbIdx][ySbIdx]=mvLX[xSbIdx][ySbIdx]+dMvLX[xSbIdx][ySbIdx] (8-287) refMvLX[xSbIdx][ySbIdx][0]=Clip3(-2 17 ,2 17 -1,refMvLX[xSbIdx][ySbIdx][0]) (8-288) refMvLX[xSbIdx][ySbIdx][1]=Clip3(-2 17 ,2 17-1,refMvLX[xSbIdx][ySbIdx][1]) (8-289) - Otherwise (dmvrFlag is 0), the following applies: refMvLX[xSbIdx][ySbIdx]=mvLX[xSbIdx][ySbIdx] (8-290) refMvCLX[xSbIdx][ySbIdx]=mvCLX[xSbIdx][ySbIdx] (8-291) NOTE: The array refMvLX is stored in MvDmvrLX and is used to derive the co-located motion vectors of item 8.5.2.12. After decoding a slice, When encoding a coding block Cb[xSbIdx][ySbIdx] in IBC prediction mode, MvDmvrLX[xSbIdx][ySbIdx] and the corresponding reference indexes are all set equal to −1. The array of non-precise luma motion vectors MvLX is used for spatial motion vector prediction and the deblocking boundary strength derivation process. … 8.5.2.12 Co-located motion vector derivation process … The variables mvLXCol and availableFlagLXCol are derived as follows. If colCb is coded in intra or IBC prediction mode, then both components of mvLXCol are set equal to 0 and availableFlagLXCol is set equal to 0. - Otherwise, the motion vector mvCol, the reference index refIdxCol and the reference list identifier listCol are derived as follows: predFlagL0Col[xColCb][yColCb] is equal to 0, If predFlagL1Col[xColCb][yColCb] is equal to 0, then both components of mvLXCol are set equal to 0 and availableFlagLXCol is set equal to 0. - Otherwise the following applies: - If sbFlag is 0, availableFlagLXCol is set equal to 1 and the following applies: - If predFlagL0Col[xColCb][yColCb] is 0, then mvCol, refIdxCol, and listCol are set equal to mvL1Col[xColCb][yColCb], refIdxL1Col[xColCb][yColCb], and L1, respectively. - Otherwise, if predFlagL0Col[xColCb][yColCb] is equal to 1 and predFlagL1Col[xColCb][yColCb] is 0, then mvCol, refxIdCol, and listCol are set equal to mvL0Col[xColCb][yColCb], refIdxL0Col[xColCb][yColCb] and L0, respectively. - Otherwise (predFlagL0Col[xColCb][yColCb] is equal to 1 and predFlagL1Col[xColCb][yColCb] is 1), make the following assignments: - If NoBackwardPredFlag is 1, then mvCol, refIdxCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively. - Otherwise, set mvCol, refIdxCol, and listCol equal to mvLNCol[xColCb][yColCb], refIdxLNCol[xColCb][yColCb], and LN, respectively, where N is the value of collocated_from_l0_flag. - Otherwise (sbFlag is 1), the following applies: - if predFlagLXCol[xColCb][yColCb] is 1, then mvCol, refxIdCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], LX, respectively, and availableFlagLXCol is set equal to 1. - Otherwise (PredFlagLXCol[xColCb][yColCb] is 0), the following applies: - if NoBackwardPredFlag is equal to 1 and PredFlagLYCol[xColCb][yColCb] is equal to 1 then mvCol, refxIdCol and listCol are set to mvLYCol[xColCb][yColCb], refIdxLYCol[xColCb][yColCb] and LY respectively, Y is equal to !X where X is the value of X for invoking this operation and availableFlagLXCol is set to 1. - Otherwise, set both modules in mvLXCol equal to 0 and set availableFlagLXCol equal to 0. …

[0135] 5.3 Example #3 The working draft specified in JVET-O2001-vE may be modified as follows: 8.5.6.6.2 Default Weighted Sample Prediction Process … The variables shift1, shift2, offset1, offset2, and offset3 are derived as follows: - The variable shift1 is set equal to Max(2,14-bitDepth). The variable shift2 is set equal to Max(3,15-bitDepth). - The variable offset1 is set equal to 1<<(shift1-1). - The variable offset2 is set equal to 1<<(shift2-1). The variable offset3 is set equal to 1<<(shift2+1[[2]]). … - Otherwise (predFlagL0 is 1 and predFlagL1 is 1), the following applies: - If bcwIdx is equal to 0 or ciip_flag[xCb][yCb] is equal to 1, the predicted sample values ​​are derived as follows: pbSamples[x][y]=Clip3(0,(1< <bitDepth)-1, (8-823) (predSamplesL0[x][y]+predSamplesL1[x][y]+offset2)>>shift2) - Otherwise (bcwIdx is not equal to 0 and ciip_flag[xCb][yCb] is equal to 0), the following applies: - The variable w1 is set equal to bcwWLut[bcwIdx], where bcwWLut[k] = {4, 5, 3, 10, -2}. - The variable w0 is set equal to (8-w1). The predicted sample values ​​are derived as follows: pbSamples[x][y]=Clip3(0,(1< <bitDepth)-1, (8-824)

[0136] [ka]

[0137] … Alternatively, the following can be applied: … The variables shift1, shift2, offset1, offset2, and offset3 are derived as follows: - The variable shift1 is set equal to Max(2,14-bitDepth) and [[the variable shift2 is set equal to Max(3,15-bitDepth)]]. - The variable offset1 is set equal to 1<<(shift1-1).

[0138] [ka]

[0139] … - Otherwise (predFlagL0 is 1 and predFlagL1 is 1), the following applies: - If bcwIdx is equal to 0 or ciip_flag[xCb][yCb] is equal to 1, the predicted sample values ​​are derived as follows: pbSamples[x][y]=Clip3(0,(1< <bitDepth)-1, (8-823)

[0140] [ka]

[0141] - Otherwise (bcwIdx is not equal to 0 and ciip_flag[xCb][yCb] is equal to 0), the following applies: - The variable w1 is set equal to bcwWLut[bcwIdx], where bcwWLut[k] = {4, 5, 3, 10, -2}. - The variable w0 is set equal to (8-w1). The predicted sample values ​​are derived as follows: pbSamples[x][y]=Clip3(0,(1< <bitDepth)-1, (8-824)

[0142] [ka]

[0143] … Alternatively, the following can be applied: … The variables shift1, shift2, offset1, offset2, and offset3 are derived as follows: - The variable shift1 is set equal to Max(2, 14-bitDepth) and the variable shift2 is set equal to Max(3, 15-bitDepth). - The variable offset1 is set equal to 1<<(shift1-1). - The variable offset2 is set equal to 1<<(shift2-1). - [[The variable offset3 is set equal to 1<<(shift2+2). ]] … - Otherwise (predFlagL0 is 1 and predFlagL1 is 1), the following applies: If bcwIdx is equal to 0 or ciip_flag[xCb][yCb] is equal to 1, the predicted sample value is derived as follows: pbSamples[x][y]=Clip3(0,(1< <bitDepth)-1, (8-823) (predSamplesL0[x][y]+predSamplesL1[x][y]+offset2)>>shift2) - Otherwise (bcwIdx is not equal to 0 and ciip_flag[xCb][yCb] is equal to 0), the following applies: - The variable w1 is set equal to bcwWLut[bcwIdx], where bcwWLut[k] = {4, 5, 3, 10, -2}. - The variable w0 is set equal to (8-w1). The predicted sample values ​​are derived as follows: pbSamples[x][y]=Clip3(0,(1< <bitDepth)-1, (8-824)

[0144] [ka]

[0145] 5.4 Example #4 The working draft specified in JVET-O2001-vE may be modified as follows: 8.5.6.6.2 Default Weighted Sample Prediction Process … - Otherwise (bcwIdx is not equal to 0 and ciip_flag[xCb][yCb] is equal to 0), the following applies: The variable w1 is set equal to bcwWLut[bcwIdx],

[0146] [ka]

[0147] 5.5 Embodiment #5 The working draft specified in JVET-O2001-vE may be modified as follows: 8.5.2.7 Merged Motion Vector Difference Derivation Process …

[0148] [ka]

[0149] 5.6 Example #6 The working draft specified in JVET-O2001-vE may be modified as follows: 7.3.8.5 Coding Unit Syntax …

[0150] [Table 5] [Table 6]

[0151] FIG. 14A is a block diagram of a video processing device 1400. The device 1400 may be used to implement one or more of the methods described herein. The device 1400 may be implemented in a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The device 1400 may include one or more processing devices 1402, one or more memories 1404, and video processing hardware 1406. The one or more processing devices 1402 may be configured to implement one or more methods described herein (including, but not limited to, methods 800, 900, 1000, 1100, 1200, and 1300). The memory(s) 1404 may be used to store data and code used to implement the methods and techniques described herein. The video processing hardware 1406 may be used to implement the techniques described herein in a hardware circuit. In some embodiments, the hardware 1406 may be fully or partially implemented in the processor 1402, for example, a graphics co-processor.

[0152] 14B is a block diagram illustrating an example video processing system 1410 capable of implementing various techniques disclosed herein. Various implementations may include some or all of the modules of the system 1410. The system 1410 may include an input unit 1412 for receiving video content. The video content may be received in a raw or uncompressed format, for example, 8 or 10 bit multi-module pixel values, or may be received in a compressed or encoded format. The input unit 1412 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.

[0153] The system 1410 may include an encoding module 1414 that may implement various encoding or coding methods described herein. The encoding module 1414 may reduce the average bit rate of the video from the input unit 1412 to the output of the encoding module 1414, generating an encoded representation of the video. Thus, this encoding technique may be referred to as a video compression or video transcoding technique. The output of the encoding module 1414 may be stored or transmitted via a connected communication, as represented by module 1416. The bitstream (or encoded) representation of the video received at the input unit 1412, stored or communicated, may be used by module 1418 to generate pixel values ​​or displayable video that are sent to the display interface unit 1420. The process of generating a user-viewable video from the bitstream representation may be referred to as video decompression. Furthermore, although a particular video processing operation is referred to as an "encoding" operation or tool, the encoding tool or operation is performed by an encoder and a corresponding decoding tool or operation that reverses the result of the decoding, performed by a decoder.

[0154] Examples of peripheral bus interface units or display interface units may include Universal Serial Bus (USB) or High-Definition Multimedia Interface (HDMI) or DisplayPort, etc. Examples of storage interfaces include Serial Advanced Technology Attachment (SATA), PCI, IDE interfaces, etc. The techniques described herein may be implemented in various electronic devices such as mobile phones, laptops, smartphones, or other devices capable of digital data processing and / or video display.

[0155] In some embodiments, the video encoding method may be performed using an apparatus implemented on a hardware platform, such as those described with reference to FIG. 14A or FIG. 14B.

[0156] The following list provides embodiments that can address the technical problems described herein, among others. The first set of items describes certain features and aspects of the technology disclosed in the previous section.

[0157] 1. A video processing method comprising: determining the availability of one or more co-located motion vectors based on a prediction mode of a co-located video block relative to a current video block; and converting between the current block and a bitstream representation of the current block based on the one or more co-located motion vectors, wherein the indication of the prediction mode includes one bit indicating whether the current video block was coded in inter mode or non-inter mode.

[0158] 2. A video processing method comprising: determining a type of a video block co-located with the video block for a conversion between an encoded representation of the video block and the video block, the type taking only one of two possible values; and performing the conversion based on the determination.

[0159] 3. The method of claim 1, wherein the two possible values ​​include a first value indicating that the co-located video block is inter-coded and a second value indicating that the co-located video block is coded using a non-inter-coded mode.

[0160] 4. A method according to any one of items 1 to 3, wherein the decision is the same when the current video block is coded in palette prediction mode and when the current video block is coded in intra or intra block copy (IBC) prediction mode.

[0161] 5. A method according to any one of items 1 to 3, wherein if the co-located video block is coded in a non-inter prediction mode, it is determined that the co-located motion vector is unavailable.

[0162] 6. A method according to any one of items 1 to 3, wherein if the image block located at the same position is encoded in a non-inter prediction mode, a motion vector located at the same position is determined to be available and includes a default motion vector.

[0163] 7. The method according to item 5 or 6, wherein the non-inter prediction mode is an intra prediction mode, a palette prediction mode, or an intra block copy (IBC) prediction mode.

[0164] 8. The method according to any of items 1 to 3, wherein the determination is based on a reference index or a reference list of the co-located video block.

[0165] 9. The method according to claim 8, wherein the reference index is a predetermined value.

[0166] 10. The method of claim 8, wherein the reference index excludes predetermined values.

[0167] 11. The method according to item 9 or 10, wherein the predetermined value is 0.

[0168] 12. A video processing method comprising: deriving a prediction sample for a current block based on a first weighting table associated with weighted bi-prediction (BCW) processing at a coding unit (CU) level, the first weighting table being asymmetric; and performing a conversion between the current block and a bitstream representation of the current block based on the prediction sample.

[0169] 13. The method of claim 12, wherein the entries in the first weight table are non-monotonic increasing.

[0170] 14. The method of claim 12, wherein the BCW process is further based on a second weight table different from the first weight table.

[0171] 15. The method of claim 12, wherein deriving the prediction sample includes converting an intermediate prediction sample to a first bit depth, applying weights from a first weight table to the intermediate prediction sample to derive the prediction sample, and converting the prediction sample to a second bit depth.

[0172] 16. The method of claim 15, wherein the second bit depth is a bit depth of a color component of the current image block.

[0173] 17. A method of video processing comprising: determining, based on dimensions of a current video block, a selective signaling of an indication of skip mode encoding of the current video block in a bitstream representation of the current video block; and performing a conversion between the current block and the bitstream representation of the current block based on the determination.

[0174] 18. The method of claim 17, wherein the indication is signaled upon determining that the slice type containing the current video block is an I slice, sps_ibc_enabled_flag is set to TRUE, and the height and width of the current video block are less than or equal to N.

[0175] 19. The method of claim 17, wherein the indication is signaled if it is determined that the current video block is coded in intra block copy (IBC) mode and the height and width of the current video block are less than or equal to N.

[0176] 20. The method according to item 18 or 19, wherein N=64.

[0177] 21. A method of video processing comprising: making a decision based on application of a first encoding tool to one or more blocks in a first color component of a current video block, regarding selective application of a second encoding tool to at least one block of a second color component of the current video block; and performing a conversion between the current block and a bitstream representation of the current block based on the decision.

[0178] 22. The method according to claim 21, further comprising applying a second encoding tool if the second encoding tool is determined to be identical to the first encoding tool.

[0179] 23. The method of claim 21, wherein if the second encoding tool is determined to be different from the first encoding tool, the second encoding tool is not applied.

[0180] 24. The method of claim 21, wherein the determination is further based on an indication in the bitstream representation.

[0181] 25. The method according to any one of items 21 to 24, wherein the first color component is a luminance component and the second color component is a chroma component.

[0182] 26. The method according to any one of items 21 to 24, wherein the first color component is a first chroma color component and the second color component is a second chroma color component.

[0183] 27. A method according to any of items 21 to 26, wherein the first encoding tool and the second encoding tool are one of temporal motion vector prediction (TMVP), alternative temporal motion vector prediction (ATMVP), coding unit (CU) level weighted bi-prediction (BCW) processing, merge mode with motion vector difference (MMVD), or position-dependent prediction combination (PDPC) processing.

[0184] 28. A method of video processing comprising: making a decision regarding selective signaling of an instruction to use an alternative half-pixel interpolation filter instead of a default half-pixel interpolation filter based on accuracy of a motion vector in a current video block; and performing a conversion between the current block and the bitstream representation of the current block based on the decision.

[0185] 29. The method described in item 28, wherein the default half-pixel interpolation filter is used when the current video block is coded in merge mode with motion vector difference (MMVD) and the accuracy of the reconstructed motion vector is determined to be less than half pixel.

[0186] 30. A method according to any of items 1 to 29, wherein the conversion is further based on signalling in a decoder parameter set (DPS), a sequence parameter set (SPS), a picture parameter set (PPS), an adaptation parameter set (APS), a video parameter set (VPS), a sequence header, a picture header, a slice header, or a tile group header.

[0187] 31. A method according to any one of items 1 to 30, wherein performing the conversion includes generating the bitstream representation from the current video block.

[0188] 32. A method according to any one of items 1 to 30, wherein performing the conversion includes generating the current video block from the bitstream representation.

[0189] 33. A video decoding device comprising a processing device configured to implement the method according to any one of items 1 to 32.

[0190] 34. A computer program product stored on a non-transitory computer-readable medium, the computer program product comprising a program code for performing the method according to any one of items 1 to 32.

[0191] The second set of items describes particular features and aspects of the technology disclosed in the previous section (eg, items 1 and 2).

[0192] 1. A method of processing an image comprising: making a first determination as to whether a co-located video block of an image block of an image has been coded using an inter coding mode or a non-inter coding mode; making a second determination as to availability of a motion vector for the co-located video block or a derivation mode of a motion vector for the co-located video block based on the first determination; and performing a conversion between the video block and a coded representation of the image based on the second determination.

[0193] 2. The method according to item 1, wherein the non-inter coding mode is an intra mode, a palette mode, or an IBC (Intra Block Copy) mode.

[0194] 3. The method of claim 1, wherein the second determination is made to be the same for the co-located video block coded in palette mode and the co-located video block coded in intra mode.

[0195] 4. The method of claim 1, wherein the second determination is made to be the same for the co-located video block coded in palette mode and the co-located video block coded in intra block copy mode.

[0196] 5. The method of claim 1, wherein the second decision is made so that the second decision is the same for the co-located video block coded in intra mode and the co-located video block coded in intra block copy mode.

[0197] 6. The method of claim 1, wherein making the first determination includes generating a bit to indicate whether the co-located video block is coded using the inter coding mode or the non-inter coding mode.

[0198] 7. The method of claim 1, wherein making the second determination determines that a motion vector for the co-located video block is unavailable based on the first determination that the co-located video block is coded using the non-inter coding mode.

[0199] 8. The method of claim 1, wherein making the second determination determines that a motion vector for the co-located video block is available based on the first determination that the co-located video block is coded using the non-inter coding mode, and a default motion vector is assigned as the motion vector for the co-located video block.

[0200] 9. The method of claim 1, further comprising checking another video block instead of the co-located video block if the co-located video block is coded using the non-inter coding mode.

[0201] 10. The method of claim 9, wherein the other video block is a neighboring block that is the closest inter-coded block to the left, right, above, or below the co-located video block.

[0202] 11. A method of video processing, comprising: determining one or more co-located motion vectors based on a reference index or reference list of a co-located video block of a video block for conversion between a video block of a video and a coded representation of the video; and performing the conversion based on the determination.

[0203] 12. The method of claim 11, deriving the one or more co-located motion vectors if a reference index in a reference list of the co-located video block is not equal to a predetermined value.

[0204] 13. The method of claim 11, further comprising deriving the one or more co-located motion vectors when a reference index in a reference list of the co-located video block is a predetermined value.

[0205] 14. The method according to item 12 or 13, wherein the predetermined value is 0.

[0206] 15. The method of claim 11, further comprising setting one or more co-located motion vectors to unavailable if the co-located video block is coded in a non-inter coding mode or if the reference picture of the co-located video block does not satisfy a given condition.

[0207] 16. The method of claim 11, further comprising setting the one or more co-located motion vectors to a default value if the co-located video block is coded in a non-inter coding mode or if the reference picture of the co-located video block does not satisfy a given condition.

[0208] 17. A method according to any one of items 1 to 16, wherein the conversion includes encoding the video into the encoded representation.

[0209] 18. A method according to any one of items 1 to 16, wherein the converting includes decoding the encoded representation to generate the image.

[0210] 19. A video processing device comprising a processing device configured to carry out the method according to any one or more of items 1 to 16.

[0211] 20. A computer readable medium having stored thereon program code which, when executed, causes a processor to perform the method recited in any one or more of items 1 to 16.

[0212] 21. A computer-readable medium storing an encoded or bitstream representation generated according to any of the methods described above.

[0213] The third set of items describes particular features and aspects of the techniques disclosed in the previous section (eg, items 3-7).

[0214] 1. A video processing method (e.g., method 1530 shown in FIG. 15C ) comprising: deriving a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, in which weights are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for a conversion between a current block of a video and a coded representation of the video; performing a conversion using the prediction block, in which deriving the prediction block includes applying weights to two intermediate prediction samples respectively belonging to the two initial prediction blocks to derive a final prediction sample (1534); performing a right shift operation on the final prediction sample to convert a bit depth of the final prediction sample, in which the right shift operation is pbSample>>(shift1+3), where pbSample indicates the final prediction sample and shift1 is set equal to Max(2,14-bitDepth); and determining the prediction block based on the final prediction sample.

[0215] 2. The method of claim 1, further comprising adding an offset to the final predicted sample before performing the right shift operation.

[0216] 3. The method according to item 1, wherein the offset is 1<<(shift1+2).

[0217] 4. The final predicted sample pbSamples[x][y] is pbSamples[x][y]=Clip3(0,(1<<bitDepth)-1,(w0*predSamplesL0[x][y]+w1*predSamplesL1[x][y]+offset3)> >(shift1+3)), where w0 and w1 are weights, and predSamplesL0[x][y] and predSamplesL1[x][y] are two intermediate prediction samples.

[0218] 5. The method of claim 1, wherein at least one of the weights belongs to a weight table, the entries of which are non-monotonic increasing.

[0219] 6. A video processing method comprising: deriving a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, in which weights are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for a conversion between a current block of a video and a coded representation of the video; performing a conversion using the prediction block, in which deriving the prediction block includes applying weights to two intermediate prediction samples respectively belonging to two initial prediction blocks to derive a final prediction sample; adding an offset to the final prediction sample, in which the offset is 1<<(shift1+2), where shift1 is set to Max(2,14-bitDepth); and determining the prediction block based on the final prediction sample.

[0220] 7. The method of claim 6, wherein determining the prediction block based on the final predicted sample includes performing a right shift operation on the final predicted sample and converting a bit depth of the final predicted sample.

[0221] 8. The method according to any one of items 1 to 7, wherein the right shift operation is pbSample>>(shift1+3), where pbSample represents the final predicted sample.

[0222] 9. The final predicted sample pbSamples[x][y] is pbSamples[x][y]=Clip3(0,(1<<bitDepth)-1,(w0*predSamplesL0[x][y]+w1*predSamplesL1[x][y]+offset3)> >(shift1+3)), w0 and w1 are weights, and predSamplesL0[x][y] and predSamplesL1[x][y] are two intermediate prediction samples.

[0223] 10. The method of claim 6, wherein at least one of the weights belongs to a weight table, the entries of which are non-monotonic increasing.

[0224] 11. A video processing method (method 1540 shown in FIG. 15D) for converting between a current block of a video and a coded representation of the video, comprising deriving (1542) a motion vector difference for a merge mode motion vector predictor for the current block according to rules, and performing conversion based on this derivation (1544), the rules specifying whether to clip the motion vector difference to the same range as the range used for clipping the motion vector.

[0225] 12. The method according to claim 11, wherein the rules specify clipping motion vector differences to the same range as that used to clip motion vectors.

[0226] 13. The method according to item 11, wherein the range used for clipping the motion vectors is 18 bits.

[0227] 14. The range used to clip motion vectors is [-2 17 ,2 17Item 14. The method according to item 13, wherein the above-mentioned formula (1) is -1.

[0228] 15. The rule is to set the motion vector difference to [-2 17 +1,2 17 Item 12. The method according to item 11, which specifies clipping to [−1].

[0229] 16. The method according to claim 11, wherein the rule specifies not to clip the motion vector difference.

[0230] 17. The method according to claim 16, wherein the rule specifies that a result obtained by adding the motion vector difference to a motion vector prediction candidate is clipped to 18 bits.

[0231] 18. A method of processing video, comprising: deriving a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, in which weights are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for a transformation between a current block of a video and a coded representation of the video, at least one of the weights belonging to a weight table, the weight table being organized according to a rule; and performing the transformation using the prediction block, the rule specifying that the entries of the weight table are non-monotonic increasing.

[0232] 19. The method according to item 18, wherein the weight table includes an (i+1)th entry whose value is less than the value of the ith entry.

[0233] 20. A method for processing video, comprising: deriving a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, in which weights are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for a conversion between a current block of a video and a coded representation of the video, at least one of the weights belonging to a weight table, the weight table being selected from a plurality of weight tables; and performing the conversion using the prediction block.

[0234] 21. The method of claim 20, wherein the plurality of weight tables include {4,5,3,10,2}, {4,3,5,10,2}, {4,5,3,10,1}, {4,3,5,10,1}, or {4,5,3,10,-1}.

[0235] 22. A method of video processing comprising: deriving a prediction block for a current block of a video determined in accordance with a bidirectional coding unit level weighting (BCW) tool, in which weights are used to determine a weighted sum of two initial prediction blocks used to determine the prediction block for converting between the current block of the video and a coded representation of the video; and performing the conversion using the prediction block, wherein deriving the prediction block comprises converting intermediate prediction samples to a first bit depth, applying weights to the intermediate prediction samples to derive final prediction samples, and converting the final prediction samples to a second bit depth.

[0236] 23. The method of claim 22, wherein the second bit depth is a bit depth of a color component of the current block.

[0237] 24. The method of item 22, wherein the first bit depth is not equal to the bit depth of the intermediate prediction samples.

[0238] 25. The method of claim 22, wherein deriving the prediction block includes a right shift operation that converts samples from a higher bit depth to a lower bit depth, or a left shift operation that converts the samples from a lower bit depth to a higher bit depth.

[0239] 26. The method of claim 25, further comprising adding an offset before a right or left shift operation.

[0240] 27. The final predicted sample pbSamples[x][y] is pbSamples[x][y]=Clip3(0,(1<<bitDepth)-1,(w0*((predSamplesL0[x][y]+offset1)> 23. The method of claim 22, wherein w0 and w1 are weights, shift1 is set equal to Max(2,14-bitDepth), and offset1 is set equal to 1<<(shift1-1), and offset1 is derived as follows: w0*w1*((predSamplesL1[x][y]+offset1)>>shift1)+4)>>3), where w0 and w1 are weights, shift1 is set equal to Max(2,14-bitDepth), and offset1 is set equal to 1<<(shift1-1).

[0241] 28. A video processing method (method 1550 shown in FIG. 15E) comprising: deriving (1552) a prediction block for a current block determined according to a bidirectional coding unit level weighting (BCW) tool, in which a first weight and a second weight are used to determine a weighted sum of two initial prediction blocks used to determine a prediction block for a conversion between a current block of a video and a coded representation of the video, the first weight and the second weight belonging to at least one weight table, the weight table being organized according to a rule; and performing the conversion using the prediction block, the rule specifying that the weight table is asymmetric.

[0242] 29. The weight table includes an entry whose value corresponds to the first weight W and does not include an entry whose value corresponds to the second weight (1 - W), whereby W is within the range of [a, b], and the sum (a + b) of a and b is equal to 1, the method according to item 28.

[0243] 30. When the prediction sample is generated by (W0 * P0 + W1 * P1) >> N, the weight table includes an entry whose value corresponds to the first weight W and does not include an entry whose value corresponds to the second weight (2 N - W), whereby W0 and W1 are the first weight and the second weight applied to the first two prediction blocks P0 and P1 respectively, and (W0 + W1) is equal to (1 << N), the method according to item 28.

[0244] 31. Performing the conversion includes generating the encoded representation from the current video block, the method according to any one of items 1 to 30.

[0245] 32. Performing the conversion includes generating the current video block from the encoded representation, the method according to any one of items 1 to 30.

[0246] 33. A video processing apparatus including a processing apparatus configured to perform the method according to any one or more of items 1 to 32.

[0247] 34. A computer-readable medium storing program code that, when executed, causes a processing apparatus to perform the method according to any one or more of items 1 to 32.

[0248] 35. A computer-readable medium storing the encoded representation or bitstream representation generated according to any of the above-described methods.

[0249] While specific embodiments of the disclosed technology have been described above for purposes of illustration, it will be understood that various modifications may be made without departing from the scope of the invention. Accordingly, the disclosed technology is not to be limited except as by the appended claims.

[0250] Implementations of the subject matter and functional operations described in this patent specification may be implemented in various systems, digital electronic circuits, or computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in one or more combinations thereof. Implementations of the subject matter described herein may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible, non-transportable computer-readable medium for execution by or for controlling the operation of a data processing device. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter that provides a machine-readable propagated signal, or one or more combinations thereof. The term "data processing unit" or "data processing device" includes all apparatus, devices, and machines for processing data, including, for example, a programmable processing device, a computer, or multiple processing devices or computers. In addition to hardware, the apparatus may include code that creates an environment for the execution of the computer program, such as code that constitutes a processing device firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof.

[0251] A computer program (also called a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and 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 may be recorded as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), may be stored in a single file dedicated to the program, or may be stored in multiple coordinating files (e.g., a file that stores one or more modules, subprograms, or code portions). A computer program can be deployed to run on one computer located at one site, or on multiple computers distributed across multiple sites and interconnected by a communication network.

[0252] The processes and logic flows described herein may be performed by one or more programmable processing devices 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 devices may be implemented as, special purpose logic circuits, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0253] Processing devices suitable for executing computer programs include, for example, both general purpose and special purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, a processing device receives 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 storage devices for storing instructions and data. Typically, a computer may include one or more mass storage devices, e.g., magnetic, magneto-optical, or optical disks, for storing data, or may be operatively coupled to receive data from or transfer data to these mass storage devices. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all types of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, flash memory devices, and the like. The processing device and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0254] This specification, together with the drawings, are for illustrative purposes only, and illustrative is intended to mean example. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Additionally, the use of "or" is intended to include "and / or" unless the context clearly indicates otherwise.

[0255] Although this patent specification contains many details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather as descriptions of features that may be specific to certain embodiments of a particular invention. Certain features described in this patent document in the context of separate embodiments may be implemented in combination in one example. Conversely, various features described in the context of one example may be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in a particular combination and initially claimed as such, one or more features from a claimed combination may, in some cases, be extracted from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0256] Similarly, although operations are shown in a particular order in the figures, this should not be understood as requiring that such operations be performed in the particular order or sequential order shown, or that all of the operations shown be performed, to achieve desired results, nor should the separation of various system components in the examples described in this patent specification be understood as requiring such separation in all embodiments.

[0257] Only certain implementations and examples have been described; other embodiments, extensions and variations are possible based on the content described and illustrated in this patent document.

Claims

1. A method for processing video data, comprising the steps of: A step of converting between a video block of a current picture of a video and a bitstream of the video based on a prediction mode, in which in the prediction mode, the video block is divided into at least one sub-block, and motion information of the at least one sub-block is derived based on motion information of a neighboring video block disposed in a neighboring picture of the current picture, the position of the neighboring video block is derived based on temporal motion information initialized and set to default motion information, and in response to a specific neighboring block being available, is set to specific motion information associated with the specific neighboring block adjacent to a lower left corner of the video block; In the prediction mode, the process of deriving the motion information of the neighboring video blocks comprises: making a first determination whether the neighboring video block is coded in a first coding mode in which reconstructed samples are represented by a set of representative color values, the set of representative color values ​​including at least one of: 1) a palette predictor; 2) escape samples; or 3) palette information included in the bitstream; making a second decision about the availability of a motion vector of the neighboring video block and a value of the motion vector of the neighboring video block based on the first decision, wherein the second decision for the neighboring video block coded in the first coding mode is performed to be identical to the second decision for the neighboring video block coded in an intra-coding mode or a second coding mode, in which prediction samples are derived from a block of sample values ​​of the same decoded slice as determined by a block vector. method.

2. the second determination, in response to the first determination that the neighboring video block is coded in the first coding mode, determining that the availability of a motion vector for the neighboring video block is unavailable. The method of claim 1.

3. the availability of motion vectors of the neighboring video blocks coded in the first coding mode is the same as the availability of motion vectors of the neighboring video blocks coded in the intra-coding mode or the second coding mode. The method according to claim 1 or 2.

4. and in response to the first determination that the neighboring video block is coded in the first coding mode, setting a flag indicating the availability of a motion vector for the neighboring video block to 0. The method of claim 2.

5. the second determination determines a value of the motion vector of the neighboring video block coded in the first coding mode to be equal to a value of the motion vector of the neighboring video block coded in the intra-coding mode or the second coding mode. The method according to any one of claims 1 to 4.

6. in response to the first determination that the adjacent video block is coded in the first coding mode, components of both motion vectors of the adjacent video block coded in the first coding mode are set to zero. The method according to any one of claims 1 to 5.

7. and in response to determining that the neighboring video block is coded in the first coding mode, the intra-coding mode, or the second coding mode, setting a flag indicating the availability of a motion vector of the neighboring video block to 0 and setting components of both motion vectors of the neighboring video block to 0. The method according to any one of claims 1 to 6.

8. the derivation process of the motion information of the neighboring video blocks coded in the first coding mode, the intra-coding mode, or the second coding mode is different from the derivation process of the motion information of the neighboring video blocks coded in an intra-coding mode. The method according to any one of claims 1 to 7.

9. the prediction mode is a sub-block-based temporal motion vector prediction (SbTMVP) mode, the first coding mode is a palette mode, and the second coding mode is an intra block copy (IBC) mode; The method according to any one of claims 1 to 8.

10. the transforming includes encoding the video blocks into the bitstream. The method according to any one of claims 1 to 9.

11. the converting includes decoding the video block from the bitstream. The method according to any one of claims 1 to 9.

12. 1. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions stored thereon, the instructions, when executed by the processor, causing the processor to: Converting between a video block of a current picture of a video and a bitstream of the video based on a prediction mode, the prediction mode being such that the video block is divided into at least one sub-block, motion information of the at least one sub-block is derived based on motion information of a neighboring video block in a neighboring picture of the current picture, a position of the neighboring video block is derived based on temporal motion information initialized and set to default motion information, and in response to a particular neighboring block being available, set to particular motion information associated with the particular neighboring block adjacent to a lower left corner of the video block; In the prediction mode, the process of deriving the motion information of the neighboring video blocks comprises: making a first determination whether the neighboring video block is coded in a first coding mode in which reconstructed samples are represented by a set of representative color values, the set of representative color values ​​including at least one of: 1) a palette predictor; 2) escape samples; or 3) palette information included in the bitstream; making a second decision about the availability of a motion vector of the neighboring video block and a value of the motion vector of the neighboring video block based on the first decision, wherein the second decision for the neighboring video block coded in the first coding mode is performed to be identical to the second decision for the neighboring video block coded in an intra-coding mode or a second coding mode, in which prediction samples are derived from a block of sample values ​​of the same decoded slice as determined by a block vector. Device.

13. A non-transitory computer-readable storage medium having stored thereon instructions for causing a processor to: converting between a video block of a current picture of a video and a bitstream of the video based on a prediction mode, the prediction mode being such that the video block is divided into at least one sub-block, motion information of the at least one sub-block is derived based on motion information of a neighboring video block in a neighboring picture of the current picture, a position of the neighboring video block is derived based on temporal motion information initialized and set to default motion information, and in response to a particular neighboring block being available, set to particular motion information associated with the particular neighboring block adjacent to a lower left corner of the video block; In the prediction mode, the process of deriving the motion information of the neighboring video blocks comprises: making a first determination whether the neighboring video block is coded in a first coding mode in which reconstructed samples are represented by a set of representative color values, the set of representative color values ​​including at least one of: 1) a palette predictor; 2) escape samples; or 3) palette information included in the bitstream; making a second decision about the availability of a motion vector of the neighboring video block and a value of the motion vector of the neighboring video block based on the first decision, wherein the second decision for the neighboring video block coded in the first coding mode is performed to be identical to the second decision for the neighboring video block coded in an intra-coding mode or a second coding mode, in which prediction samples are derived from a block of sample values ​​of the same decoded slice as determined by a block vector. A non-transitory computer-readable storage medium.

14. 1. A method for storing a video bitstream, comprising the steps of: generating the bitstream of the video from a video block of a current picture of the video based on a prediction mode, the prediction mode being such that the video block is divided into at least one sub-block, motion information of the at least one sub-block is derived based on motion information of a neighboring video block in a neighboring picture of the current picture, a position of the neighboring video block is derived based on temporal motion information initialized and set to default motion information, and in response to a particular neighboring block being available, set to particular motion information associated with the particular neighboring block adjacent to a lower left corner of the video block; storing the bitstream on a non-transitory computer readable storage medium; In the prediction mode, the process of deriving the motion information of the neighboring video blocks comprises: making a first determination whether the neighboring video block is coded in a first coding mode in which reconstructed samples are represented by a set of representative color values, the set of representative color values ​​including at least one of: 1) a palette predictor; 2) escape samples; or 3) palette information included in the bitstream; making a second decision about the availability of a motion vector of the neighboring video block and a value of the motion vector of the neighboring video block based on the first decision, wherein the second decision for the neighboring video block coded in the first coding mode is performed to be identical to the second decision for the neighboring video block coded in an intra-coding mode or a second coding mode, in which prediction samples are derived from a block of sample values ​​of the same decoded slice as determined by a block vector. method.

Images