Encoders, decoders, and corresponding methods used for IBC merge lists

Abstract

This document provides coding methods, decoders, and devices implemented by decoding devices. [Solution] A coding method implemented by a decoding device, comprising S101 obtaining the maximum number of values ​​to merge the motion vector prediction MVP candidates for the current block. The current block is predicted using the intrablock copy IBC mode. The method also comprises S102 setting the value of the MVP index to zero when the value of the maximum number of MVP candidates for the current block is equal to 1, S103 obtaining the motion vector of the current block according to the MVP index and candidate list, and S104 obtaining the predicted sample value of the current block according to the motion vector of the current block.

Description

[Technical Field]

[0001] The embodiments of this application (disclosure) generally relate to the field of picture processing, and more specifically to merge lists used for IBC prediction. [Background technology]

[0002] Video coding (video encoding and decoding) is used in a wide range of digital video applications, such as broadcast digital TV, video transmission over the internet and mobile networks, real-time conversation applications like video chat and video conferencing, DVD and Blu-ray discs, video content collection and editing systems, and camcorders in security applications.

[0003] The amount of video data required to depict even relatively short videos is substantial, which can pose difficulties when data is streamed or otherwise transmitted over communication networks with limited bandwidth. Therefore, video data is generally compressed before being transmitted over modern telecommunications networks. Video size can also be a concern when video is stored on storage devices, as memory resources may be limited. Video compression devices often use software and / or hardware at the source to encode video data before transmission or storage, thereby reducing the amount of data required to represent the digital video image. The compressed data is then received at the destination by a video decompression device that decodes the video data. Given limited network resources and the ever-increasing demand for higher video quality, improved compression and decompression techniques that improve compression ratios with little sacrifice to picture quality are desirable. [Overview of the Initiative]

[0004] Embodiments of this application provide apparatus and methods for encoding and decoding according to independent claims. The aforementioned and other objectives are achieved by the subject matter of the independent claim. Further implementations are evident from the dependent claims, specification and drawings.

[0005] A first aspect of the present invention provides a coding method implemented by a decoding device, the method comprising: obtaining a maximum number of values ​​for merging motion vector prediction MVP candidates for the current block, wherein the current block is predicted using an intrablock copy IBC mode; setting the value of an MVP index to zero when the value of the maximum number of MVP candidates for the current block is equal to 1; obtaining the motion vector of the current block according to the MVP index and the candidate list; and obtaining a predicted sample value for the current block according to the motion vector of the current block.

[0006] According to embodiments of the present invention, the motion vector (also called the block vector) of an IBC block is obtained according to a first index in the list when only one MVP candidate exists. Therefore, the value of the MVP index does not need to be sent to the decoder, the motion vector of the IBC block is defined, and the bitstream is reduced.

[0007] As shown in Figure 10, a coding method performed by a decoding device is disclosed, and this method is S101: Obtaining the maximum number of values ​​to merge the motion vector prediction MVP candidates for the current block, which includes obtaining the current block predicted using the Intrablock Copy IBC mode.

[0008] In some embodiments, the maximum number of motion vector prediction MVP candidates to merge is expressed according to six_minus_max_num_ibc_merge_cand.

[0009] When sps_ibc_enabled_flag is equal to 1, six_minus_max_num_ibc_merge_cand specifies the maximum number of IBC merging block vector prediction (BVP) candidates supported by SPS minus 6. The value of six_minus_max_num_ibc_merge_cand must be in the range of 0 to 5. The maximum number of IBC merging BVP candidates, MaxNumIbcMergeCand, is derived as follows:

[0010]

number

[0011] In another example, the IBC mode of a block is signaled by the flag pred_mode_ibc_flag, where a value of pred_mode_ibc_flag equal to 1 indicates that the current coding unit (coding block) will be coded in IBC predictive mode. A value of pred_mode_ibc_flag equal to 0 indicates that the current coding unit (coding block) will not be coded in IBC predictive mode. For example, when pred_mode_ibc_flag is equal to 1, the variables CuPredMode[chType][x][y] are set to equal MODE_IBC for x=x0..x0+cbWidth-1 and y=y0..y0+cbHeight-1. For instance, CuPredMode[0][xCb][yCb] being equal to MODE_IBC indicates that the current block is predicted to use the intrablock copy IBC mode, where (xCb,yCb) specifies the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture.

[0012] In embodiments or implementations of the present invention, in IBC mode, block vectors have the same technical means as motion vectors.

[0013] S102: Set the MVP index value to zero if the value of the maximum number of MVP candidates for the current block is equal to 1. In one embodiment, the MVP index syntax mvp_l0_flag is defined as follows: mvp_l0_flag[x0][y0] specifies the motion vector predictor index in List 0, where x0 and y0 specify the position (x0, y0) of the top-left Luma sample of the coding block to be considered relative to the top-left sample of the picture. If mvp_l0_flag[x0][y0] does not exist, it is assumed to be equal to 0. In one example, Coding unit syntax:

[0014] [Table 1]

[0015] S103: Obtain the motion vector of the current block according to the MVP index and candidate list. For example, to obtain a motion vector, The input to this process is, The luma position (xCb, yCb) of the top - left sample of the current luma coding block with respect to the top - left luma sample of the current picture, a variable cbWidth specifying the width of the current coding block in the luma sample, and a variable cbHeight specifying the height of the current coding block in the luma sample. The output of this process is a luma block vector 1 / 16 sample accuracy bvL.

[0016] The luma block vector bvL is derived by the following steps. 1. When IsGt4by4 is equal to TRUE (in the example, the variable IsGt4by4 is derived as IsGt4by4=(cbWidth*cbHeight)>16), the process of deriving the spatial block vector candidates from adjacent coding units is called with the luma coding block position (xCb, yCb), the luma coding block width cbWidth, and height cbHeight as inputs, and the outputs are the availability flag availableFlagA1, the availability flag availableFlagB1, the block vectors bvA1 and bvB1. 2. When IsGt4by4 is equal to TRUE, the block vector candidate list bvCandList is constructed as follows.

[0017]

Number

[0018]

number

[0019]

number

[0020] S104: Obtain the predicted sample values ​​for the current block according to the motion vector of the current block. For example, the input to this process is: - The luma 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. - The variable cbWidth specifies the width of the current coding block in the Luma sample. - Variable cbHeight specifies the height of the current coding block in the Luma sample. - Block vector bv, - This is the variable cIdx, which specifies the color component index of the current block. The output of this process is, - The sequence of predicted samples is predSamples. When cIdx is equal to 0, the following applies to x = xCb + cbWidth - 1 and y = yCb + cbHeight - 1.

[0021]

number

[0022] If cIdx is not equal to 0, the following applies to x = xCb / subWidthC..xCb / subWidthC + cbWidth / subWidthC-1 and = yCb / subHeightC..yCb / subHeightC + cbHeight / subHeightC-1.

[0023]

number

[0024]

number

[0025] [Table 2]

[0026] In one implementation, the method further includes parsing the MVP index value from the bitstream if the value of the maximum number of MVP candidates for the current block is greater than 1. In one implementation, the MVP index value is parsed from the coding unit level. In one implementation, the MVP index value specifies the motion vector predictor index in List 0. In one implementation, the maximum number of MVP candidates for the current block is obtained by analyzing the sequence parameter set sps level from the bitstream. In one implementation, the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, or pps level. In one implementation, the candidate list is obtained based on at least one adjacent block to the current block, and a history-based motion vector predictor HMVP list, where at least one adjacent block is predicted using IBC mode. One implementation discloses a coding method implemented by a decoding device, and that method is The goal is to obtain the maximum number of MVP candidates for the current block's motion vector prediction, where the current block is predicted using the Intrablock Copy IBC mode. Determine whether the maximum number of MVP candidates in the current block is greater than 1, If the value of the maximum number of MVP candidates for the current block is determined to be greater than 1, the value of the MVP index is analyzed from the bitstream, Obtain the motion vector of the current block according to the MVP index and candidate list, This includes obtaining predicted sample values ​​for the current block according to the current block's motion vector. In one implementation, the method is: This further includes setting the MVP index value to zero if it is determined that the maximum number of MVP candidates for the current block is equal to 1. In one implementation, the MVP index value is parsed from the coding unit level. In one implementation, the MVP index value specifies the motion vector predictor index in List 0. In one implementation, the maximum number of MVP candidates for the current block is obtained by analyzing the sequence parameter set sps level from the bitstream. In one implementation, the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, or pps level. In one implementation, the candidate list is obtained based on at least one adjacent block to the current block, and a history-based motion vector predictor HMVP list, where at least one adjacent block is predicted using IBC mode. In one embodiment, a coding method implemented by a decoding device is disclosed, and the method is: The goal is to obtain the maximum number of MVP candidates for the current block's motion vector prediction, where the current block is predicted using the Intrablock Copy IBC mode. The motion vector of the current block is set to its default value when the current block's MVP index value is 1 and the value of the maximum number of MVP candidates for the current block is equal to 1. This includes obtaining predicted sample values ​​for the current block according to the current block's motion vector. In one implementation, the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, sps level, or pps level. In one implementation, the default value is zero. In one embodiment, a coding method implemented by a decoding device is disclosed, and the method is: The goal is to obtain the maximum number of MVP candidates for the current block's motion vector prediction, where the current block is predicted using the Intrablock Copy IBC mode. Obtaining a candidate list for the current block according to the history-based motion vector predictor HMVP list and at least one adjacent block adjacent to the current block, provided that the value of the maximum number of MVP candidates for the current block is equal to 1, wherein the candidate list for the current block includes 2 candidates and at least one adjacent block is predicted using IBC mode. Obtain the motion vector of the current block according to the current block's MVP index and candidate list, This includes obtaining predicted sample values ​​for the current block according to the current block's motion vector. In one implementation, the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, sps level, or pps level.

[0027] As shown in Figure 11, a second aspect of the present invention provides a decoding device 1100, the decoding device is An MVP module 1101 is configured to obtain the maximum number of values ​​to merge the motion vector prediction MVP candidates for the current block, wherein the current block is predicted using the intrablock copy IBC mode, and the MVP module 1101 is configured to obtain the maximum number of values ​​to merge the current block's motion vector prediction MVP candidates, and the current block is predicted using the intrablock copy IBC mode, Configuration module 1102 is configured to set the MVP index value to zero when the value of the maximum number of MVP candidates for the current block is equal to 1, A motion vector module 1103 is configured to obtain the motion vector of the current block according to the MVP index and candidate list, The system includes a prediction module 1104 configured to obtain predicted sample values ​​for the current block according to the motion vector of the current block. A method according to a first aspect of the present invention may be carried out by a device according to a second aspect of the present invention. Further features and implementation forms of the above method correspond to the features and implementation forms of the apparatus according to a second aspect of the present invention.

[0028] In one embodiment, a decoder (30) is disclosed that includes a processing circuit for carrying out a method according to one of the above embodiments and implementations. In one embodiment, a computer program product is disclosed that includes program code for performing a method according to one of the above embodiments and implementations. In one embodiment, the decoder is, One or more processors, A decoder is disclosed, comprising a non-temporary computer-readable storage medium coupled to a processor and storing a program for execution by the processor, wherein the program configures the decoder to perform a method according to any one of the embodiments and implementations described above when executed by the processor. In one embodiment, a non-temporary storage medium is disclosed, which includes an encoded bitstream decoded by an image decoding device, the bitstream being generated by dividing a frame of a video signal or image signal into a plurality of blocks, and which includes a plurality of syntactic elements, the plurality of syntactic elements including an MVP index mvp_l0_flag according to any one of the above embodiments and implementations. Details of one or more embodiments are described in the accompanying drawings and the following description. Other features, purposes, and advantages will be apparent from the specification, drawings, and claims. [Brief explanation of the drawing]

[0029] Embodiments of the present invention are described in more detail below with reference to the accompanying figures and drawings. [Figure 1A] This is a block diagram showing an example of a video coding system configured to implement an embodiment of the present invention. [Figure 1B] This is a block diagram showing an example of a video coding system configured to implement an embodiment of the present invention. [Figure 2]This is a block diagram showing an example of a video encoder configured to implement embodiments of the present invention. [Figure 3] This is a block diagram showing an exemplary structure of a video decoder configured to implement embodiments of the present invention. [Figure 4] A cabinet of examples of encoding or decoding devices. [Figure 5] A branch of the association of other examples of encoding or decoding devices. [Figure 6] This is a block diagram showing an example of an adjacent block to the current block. [Figure 7] This block shows an example of five spatially adjacent candidate blocks in the current block. [Figure 8] This is a block diagram showing an exemplary structure of a content supply system 3100 that realizes a content distribution service. [Figure 9] A carbon image showing the structure of an example terminal device. [Figure 10] This is a flowchart showing an embodiment of the method. [Figure 11] This is a block diagram of an embodiment of the method.

[0030] Hereafter, unless otherwise explicitly specified, the same reference numeral refers to the same or at least functionally equivalent feature. [Modes for carrying out the invention]

[0031] The following description refers to the accompanying drawings, which form part of this disclosure and illustrate specific embodiments of the invention or specific ways in which embodiments of the invention may be used. It is understood that embodiments of the invention may be used in other ways and may include structural or logical variations not shown in the drawings. Therefore, the following detailed description should not be construed as restrictive, and the scope of the invention is defined by the appended claims.

[0032] For example, disclosures relating to a described method are understood to be true for a corresponding device or system configured to perform such method, and vice versa. For example, if one or more specific method steps are described, the corresponding device may include one or more units, e.g., functional units, even if such one or more units are not explicitly described or shown in the figures, in order to perform the described one or more method steps (e.g., one unit performing one or more steps, or each of the multiple units performing one or more of the multiple steps). On the other hand, if a particular device is described based on one or more units, e.g., functional units, the corresponding method may include one step, even if such one or more steps are not explicitly described or shown in the figures, in order to perform the functionality of one or more units (e.g., one step performing the functionality of one or more units, or multiple steps in which each of the multiple units performs one or more of the functionality of the multiple units). Furthermore, it is understood that the various exemplary embodiments and / or features of the aspects described herein may be combined with each other unless otherwise specified.

[0033] Video coding typically refers to the processing of a series of pictures that form a video or video sequence. The terms "frame" or "image" may be used synonymously in the field of video coding instead of "picture." Video coding (or, more generally, coding) consists of two parts: video encoding and video decoding. Video encoding is performed on the source side and typically involves processing the original video picture (e.g., by compression) to reduce the amount of data required to represent the original video picture (for more efficient storage and / or transmission). Video decoding is performed on the destination side and typically involves processing in the reverse direction compared to the encoder to reconstruct the video picture. Embodiments referring to "coding" of a video picture (or, more generally, a picture) should be understood as relating to the "encoding" or "decoding" of the video picture or its respective video sequence. The combination of an encoding unit and a decoding unit is also called a CODEC (Coding and Decoding).

[0034] In lossless video coding, the original video picture can be reconstructed. That is, the reconstructed video picture has the same quality as the original video picture (assuming there is no transmission loss or other data loss during storage or transmission). In lossy video coding, further compression is performed, for example by quantization, to reduce the amount of data representing the video picture, but it cannot be fully reconstructed by the decoder. That is, the quality of the reconstructed video picture is lower or worse than the quality of the original video picture.

[0035] Several video coding standards belong to the group of “lossy hybrid video codecs” (i.e., they combine 2D transform coding to apply spatial and temporal prediction in the sample domain with quantization in the transform domain). Each picture in a video sequence is typically partitioned into a set of non-overlapping blocks, and coding is typically performed at the block level. In other words, in the encoder, video is processed, i.e., encoded, typically at the block (video block) level, by generating predicted blocks using, for example, spatial (intra-picture) and / or temporal (inter-picture) predictions, subtracting the predicted blocks from the current block (the block currently being processed / to be processed) to obtain residual blocks, transforming the residual blocks, and quantizing the residual blocks in the transform domain to reduce (compress) the amount of data being transmitted. In the decoder, the inverse processing compared to the encoder is applied to the encoded or compressed blocks to reconstruct the current block for presentation. Furthermore, the encoder replicates the decoder processing loop so that both generate identical predictions (e.g., intra-predictions and inter-predictions) and / or process, i.e., generate a reconstruction for coding subsequent blocks. In the following embodiments of the video coding system 10, the video encoder 20 and video decoder 30 are described with reference to Figures 1 to 3.

[0036] Figure 1A is a schematic block diagram showing an exemplary coding system 10, for example, a video coding system 10 (or simply coding system 10) on which the technology of the present application can be utilized. The video encoder 20 (or simply encoder 20) and video decoder 30 (or simply decoder 30) of the video coding system 10 represent examples of devices that may be configured to perform the technology according to the various examples described in the present application. As shown in Figure 1A, the coding system 10 includes, for example, a source device 12 configured to provide encoded picture data 21 to a destination device 14 for decoding encoded picture data 13.

[0037] The source device 12 includes an encoder 20 and may additionally include a picture source 16, a preprocessor (or preprocessing unit) 18, for example, a picture preprocessor 18, and a communication interface or communication unit 22. The picture source 16 may include any kind of picture capture device, for example, a camera for capturing real-world pictures, and / or any kind of picture generation device, for example, a computer graphics processor for generating computer-animated pictures, or any other kind of device for obtaining and / or providing real-world pictures, computer-generated pictures (e.g., screen content, virtual reality (VR) pictures), and / or any combination thereof (e.g., augmented reality (AR) pictures). The picture source may also be any kind of memory or storage for storing any of the pictures described above. To distinguish the preprocessor 18 from the processing performed by the preprocessing unit 18, the picture or picture data 17 may also be called a raw picture or raw picture data 17.

[0038] The preprocessor 18 is configured to receive (raw) picture data 17 and perform preprocessing on the picture data 17 to obtain preprocessed picture data 19 or preprocessed picture data 19. Preprocessing performed by the preprocessor 18 may include, for example, cropping, color format conversion (e.g., RGB to YCbCr), color correction, or noise reduction. The preprocessing unit 18 may be understood to be any component. The video encoder 20 is configured to receive the preprocessed picture data 19 and provide encoded picture data 21 (for example, based on Figure 2, further details are described below). The communication interface 22 of the source device 12 may be configured to receive the encoded picture data 21 and send the encoded picture data 21 (or any further processed version thereof) via the communication channel 13 to another device, for example, the destination device 14 or any other device, for storage or direct reconstruction.

[0039] The destination device 14 includes a decoder 30 (e.g., a video decoder 30) and may additionally, or optionally, include a communication interface or communication unit 28, a post-processor 32 (or post-processing unit 32), and a display device 34.

[0040] The communication interface 28 of the destination device 14 is configured to receive encoded picture data 21 (or a further processed version thereof) for example directly from the source device 12, or from any other source, such as a storage device, such as an encoded picture data storage device, and to provide the encoded picture data 21 to the decoder 30.

[0041] Communication interfaces 22 and 28 may be configured to transmit or receive encoded picture data 21 or encoded data 13 via a direct communication link between the source device 12 and the destination device 14, for example, a direct wired or wireless connection, or any type of network, for example, a wired or wireless network or any combination thereof, or any type of private and public network, or any type of combination thereof.

[0042] The communication interface 22 may be configured, for example, to package the encoded picture data 21 into an appropriate format, e.g., a packet, and / or to process the encoded picture data using any kind of transmission encoding or processing for transmission over a communication link or communication network.

[0043] A communication interface 28 forming a counterpart to communication interface 22 may be configured, for example, to receive transmitted data and process the transmitted data using any kind of corresponding transmission decoding or processing and / or depackaging to obtain encoded picture data 21.

[0044] Both communication interfaces 22 and 28 may be configured as one-way or two-way communication interfaces, as indicated by the arrows on the communication channel 13 in Figure 1A pointing from the source device 12 to the destination device 14, and may be configured, for example, to set up a connection, to send and receive messages to acknowledge and exchange any other information relating to a communication link and / or data transmission, such as encoded picture data transmission.

[0045] The decoder 30 is configured to receive the encoded picture data 21 and provide the decoded picture data 31 or the decoded picture 31 (further details are described below, for example, based on Figure 3 or Figure 5).

[0046] The post-processor 32 of the destination device 14 is configured to post-process the decoded picture data 31, for example, the decoded picture 31, to obtain post-processed picture data 33, for example, the post-processed picture 33. The post-processing performed by the post-processing unit 32 may include, for example, color format conversion (e.g., YCbCr to RGB), color correction, cropping, or resampling, or any other processing to prepare the decoded picture data 31 for display by, for example, the display device 34. The display device 34 of the destination device 14 is configured to receive the post-processed picture data 33 for displaying the picture to, for example, a user or viewer. The display device 34 may be any type of display for representing the reconstructed picture, for example, an integrated display or an external display or monitor, or may include them. The display may include, for example, liquid crystal displays (LCDs), organic light-emitting diode (OLED) displays, plasma displays, projectors, micro-LED displays, liquid crystal on silicon (LCoS), digital optical processors (DLPs), or any other type of display.

[0047] Figure 1A depicts the source device 12 and the destination device 14 as separate devices, but the device embodiment may include both or both functions, the source device 12 or its corresponding functionality, and the destination device 14 or its corresponding functionality. In such embodiments, the source device 12 or its corresponding functionality and the destination device 14 or its corresponding functionality may be implemented by the same hardware and / or software, separate hardware and / or software, or any combination thereof.

[0048] As will be apparent to those skilled in the art based on the description, the presence of different units or functionalities within the source device 12 and / or destination device 14, and the exact division of functionalities, may vary depending on the actual device and application, as shown in Figure 1A.

[0049] The encoder 20 (e.g., video encoder 20), the decoder 30 (e.g., video decoder 30), or both the encoder 20 and the decoder 30 may be implemented by a processing circuit as shown in Figure 1B, one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, hardware, dedicated video coding, or any combination thereof. The encoder 20 may be implemented via a processing circuit 46 to embody various modules, as described with respect to the encoder 20 in Figure 2 and / or any other encoder system or subsystem described herein. The decoder 30 may be implemented via a processing circuit 46 to embody various modules, as described with respect to the decoder 30 in Figure 3 and / or any other decoder system or subsystem described herein. The processing circuit may be configured to perform various operations, as described later. As shown in Figure 5, when the technology is partially implemented in software, the device may store instructions for the software in a suitable non-temporary computer-readable storage medium and execute the instructions in hardware using one or more processors to perform the technology of this disclosure. Either the video encoder 20 or the video decoder 30 may be integrated as part of a combined encoder / decoder (CODED) in a single device, for example, as shown in Figure 1B. The source device 12 and destination device 14 may include any wide range of devices, including any type of handheld or fixed device, such as a notebook or laptop computer, mobile phone, smartphone, tablet or tablet computer, camera, desktop computer, set-top box, television, display device, digital media player, video game console, video streaming device (such as a content service server or content distribution server), broadcast receiver device, broadcast transmitter device, etc., and may use no operating system at all or any type. In some cases, the source device 12 and destination device 14 may be equipped for wireless communication.Therefore, the source device 12 and destination device 14 may be wireless communication devices.

[0050] In some cases, the video coding system 10 shown in Figure 1A is merely an example, and the technology of this application may be applied to video coding configurations (e.g., video coding or video decoding) that do not necessarily involve any data communication between the coding device and the decoding device. In other examples, data may be retrieved from local memory and streamed over a network. The video coding device may code the data and store it in memory, and / or the video decoding device may retrieve the data from memory and decode it. In some examples, coding and decoding are performed by devices that do not communicate with each other and simply code the data into memory and / or retrieve and decode the data from memory. For convenience of explanation, embodiments of the present invention are described herein with reference to, for example, High Efficiency Video Coding (HEVC) or Versatile Video Coding (VVC) reference software, next-generation video coding standards developed by the Joint Collaboration Team on Video Coding (JCT-VC) of the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Motion Picture Coding Experts Group (MPEG). Those skilled in the art will understand that embodiments of the present invention are not limited to HEVC or VVC.

[0051] Encoder and encoding method Figure 2 shows a schematic block diagram of an exemplary video encoder 20 configured to implement the technology of the present application. In the example of Figure 2, the video encoder 20 includes an input 201 (or input interface 201), a residual calculation unit 204, a transformation unit 206, a quantization unit 208, an inverse quantization unit 210, an inverse transformation unit 212, a reconstruction unit 214, a loop filter unit 220, a decoded picture buffer (DPB) 230, a mode selection unit 260, an entropy coding unit 270, and an output 272 (or output interface 272). The mode selection unit 260 may include an inter-prediction unit 244, an intra-prediction unit 254, and a partitioning unit 262. The inter-prediction unit 244 may include a motion estimation unit and a motion compensation unit (not shown). The video encoder 20 shown in Figure 2 may also be called a hybrid video encoder or a video encoder according to a hybrid video codec.

[0052] The residual calculation unit 204, the transformation processing unit 206, the quantization unit 208, and the mode selection unit 260 are sometimes referred to as forming the forward signal path of the encoder 20, while the inverse quantization unit 210, the inverse transformation processing unit 212, the reconstruction unit 214, the buffer 216, the loop filter 220, the decoding picture buffer (DPB) 230, the inter-prediction unit 244, and the intra-prediction unit 254 are sometimes referred to as forming the reverse signal path of the video encoder 20, and the reverse signal path of the video encoder 20 corresponds to the signal path of the decoder (see video decoder 30 in Figure 3). Also, the inverse quantization unit 210, the inverse transformation processing unit 212, the reconstruction unit 214, the loop filter 220, the decoding picture buffer (DRB) 230, the inter-prediction unit 244, and the intra-prediction unit 254 are also referred to as forming the "built-in decoder" of the video encoder 20.

[0053] Picture & Picture Partitioning (Picture & Block) The encoder 20 may be configured to receive, for example, a picture 17 (or picture data 17) via input 201, for example, a series of pictures that form a video or video sequence. The received picture or picture data may also be a pre-processed picture 19 (or pre-processed picture data 19). For simplicity, the following description refers to picture 17. Picture 17 may also be called the current picture or (in particular, in video coding to distinguish the current picture from other pictures, for example, pictures that were encoded and / or decoded before the same video sequence, i.e., a video sequence that also includes the current picture).

[0054] A (digital) picture is, or can be considered, a two-dimensional array or matrix of samples having intensity values. Samples in an array are sometimes called pixels (an abbreviated form of pixel element) or pels. The number of samples in the horizontal and vertical (or axis) directions of an array or picture defines the size and / or resolution of the picture. Typically, three color components are used to represent color; that is, a picture may represent or contain three sample arrays. In the RGB format or color space, a picture contains corresponding red, green, and blue sample arrays. However, in video coding, each pixel is typically represented by a luminance and chromaticity format or color space, e.g., YCbCr, which includes a luminance component represented by Y and two chromaticity components represented by Cb and Cr. The luminance (or abbreviated luma) component Y represents luminance or gray level intensity (e.g., grayscale picture), and the two chrominance (or abbreviated chroma) components Cb and Cr represent chromaticity or color information components. Therefore, a picture in YCbCr format includes a luminance sample array of luminance sample values ​​(Y) and two chrominance sample arrays of chromaticity values ​​(Cb and Cr). A picture in RGB format may be converted to or from YCbCr format, and vice versa; the process is also known as color conversion or conversion. If the picture is monochrome, the picture may include only a luminance sample array. Thus, a picture could be, for example, a lumens sample array in monochrome format, or a lumens sample array and two corresponding arrays of chromens samples in 4:2:0, 4:2:2, and 4:4:4 color formats.

[0055] Embodiments of the video encoder 20 may include a picture partitioning unit (not shown in Figure 2) configured to partition a picture 17 into multiple (typically non-overlapping) picture blocks 203. These blocks may also be called root blocks, macro blocks (H.264 / AVC), coding tree blocks (CTB), or coding tree units (CTU) (H.265 / HEVC and VVC). The picture partitioning unit may use the same block size and corresponding grid defining the block size for all pictures in the video sequence, or it may be configured to change the block size between pictures, subsets or groups of pictures, and divide each picture into a corresponding block.

[0056] In further embodiments, the video encoder may be configured to directly receive blocks 203 of picture 17, for example, one, more, or all of the blocks that make up picture 17. Picture blocks 203 may also be called the current picture block or the picture block being encoded.

[0057] Similar to picture 17, picture block 203 is, again, smaller in dimensions than picture 17, but is a two-dimensional array or matrix of samples having intensity values ​​(sample values), or is considered to be so. In other words, block 203 may include, for example, one sample array (e.g., a lumar array in the case of monochrome picture 17, or a lumar or chromar array in the case of a color picture) or three sample arrays (e.g., a lumar and two chromar arrays in the case of color picture 17) or any other number and / or type of arrays depending on the applied color format. The number of samples in the orientation and vertical (or axis) of block 203 defines the size of block 203. Thus, the block may be, for example, an MxN (M columns × N rows) array of samples, or an MxN array of conversion coefficients.

[0058] The embodiment of the video encoder 20 shown in Figure 2 may be configured to encode the picture 17 block by block, for example, encoding and prediction are performed for each block 203. The embodiment of the video encoder 20 shown in Figure 2 may further be configured to partition and / or encode the picture by using slices (also called video slices), the picture may be partitioned or encoded using one or more slices (typically non-overlapping), each slice may contain one or more blocks (e.g., CTUs).

[0059] The embodiment of the video encoder 20 shown in Figure 2 may be further configured to partition and / or encode a picture using tile groups (also called video tile groups) and / or tiles (also called video tiles), the picture may be partitioned or encoded using one or more tile groups (typically non-overlapping), each tile group may include, for example, one or more blocks (e.g., CTUs) or one or more tiles, each tile may be, for example, rectangular in shape and may include one or more blocks (e.g., CTUs), for example, a complete block or a partial block.

[0060] Residual calculation The residual calculation unit 204 may be configured to calculate the residual block 205 (also called residual 205) based on picture block 203 and prediction block 265 (further details about prediction block 265 will be described later) for each sample (each pixel), for example, by subtracting the sample value of prediction block 265 from the sample value of picture block 203, thereby obtaining the residual block 205 in the sample domain.

[0061] conversion The transformation processing unit 206 may be configured to obtain transformation coefficients 207 in the transformation domain by applying a transformation, such as a discrete cosine transform (DCT) or discrete sine transform (DST), to the sample values ​​of the residual block 205. The transformation coefficients 207 are also called transformation residual coefficients and may represent the residual block 205 in the transformation domain.

[0062] The transformation processing unit 206 may be configured to apply an integer approximation of the DCT / DST, such as the transformation specified for H.265 / HEVC. Compared to the orthogonal DCT transformation, such an integer approximation is typically scaled by a specific factor. An additional scaling factor is applied as part of the transformation process to preserve the norm of the residual blocks processed by the forward and inverse transformations. The scaling factor is typically selected based on specific constraints, such as a scaling factor that is a power of 2 for the shift operation, the bit depth of the transformation coefficients, or a trade-off between precision and implementation cost. A specific scaling factor may be specified for the inverse transformation by, for example, the inverse transformation processing unit 212 (and the corresponding inverse transformation by the inverse transformation processing unit 312 in, for example, the video decoder 30), and a corresponding scaling coefficient for the forward transformation may be specified accordingly in the encoder 20, for example, by the transformation processing unit 206.

[0063] Embodiments of the video encoder 20 (each a conversion processing unit 206) may be configured to output conversion parameters, for example, directly or encoded or compressed, via the entropy encoding unit 270, so that, for example, the video decoder 30 may receive and use the conversion parameters for decoding.

[0064] Quantization The quantization unit 208 may be configured to quantize the transformation coefficient 207 to obtain the quantization coefficient 209 by applying, for example, scalar quantization or vector quantization. The quantization coefficient 209 may also be called the quantization transformation coefficient 209 or the quantization residual coefficient 209.

[0065] The quantization process may reduce the bit depth associated with some or all of the conversion coefficients 207. For example, an n-bit conversion coefficient may be rounded to an m-bit conversion coefficient during quantization, where n is greater than m. The degree of quantization may be modified by adjusting the quantization parameter (QP). For example, in scalar quantization, different scaling may be applied to achieve finer or coarser quantization. Smaller quantization step sizes correspond to finer quantization, and larger quantization step sizes correspond to coarser quantization. Applicable quantization step sizes may be indicated by the quantization parameter (QP). The quantization parameter may be, for example, an index to a predefined set of applicable quantization step sizes. For example, a small quantization parameter may correspond to finer quantization (smaller quantization step size), a large quantization parameter may correspond to coarser quantization (larger quantization step size), or vice versa. Quantization may involve division by the quantization step size, and the corresponding and / or inverse dequantization by the inverse quantization unit 210 may involve multiplication by the quantization step size. Embodiments of some standards, e.g., HEVC, may be configured to use a quantization parameter to determine the quantization step size. Generally, the quantization step size may be calculated based on the quantization parameter using a fixed-point approximation of the equations involving division. Additional scaling factors may be introduced for quantization and dequantization to restore the norm of the residual block, which can be modified for the scaling used in the fixed-point approximation of the equations for the quantization step size and quantization parameter. In one embodiment, the scaling of the inverse transform and dequantization may be combined. Alternatively, a customized quantization table may be used and signaled from the encoder to the decoder, e.g., in a bitstream. Quantization is an irreversible operation in which the loss increases with increasing quantization step size.Embodiments of the video encoder 20 (each a quantization unit 208) may be configured to output quantization parameters encoded directly or via the entropy coding unit 270, for example, so that the video decoder 30 can receive and apply the quantization parameters for decoding.

[0066] inverse quantization The inverse quantization unit 210 is configured to apply the inverse quantization of the quantization unit 208 to the quantization coefficients to obtain the dequantization coefficient 211, for example, by applying the inverse of the quantization scheme applied by the quantization unit 208, based on or using the same quantization step size as the quantization unit 208. The dequantization coefficient 211 is also called the dequantization residual coefficient 211 and typically corresponds to the transformation coefficient 207, although it is not identical to the transformation coefficient due to losses due to quantization.

[0067] Inverse Transform The inverse transformation processing unit 212 is configured to apply the inverse transformation of the transformation applied by the transformation processing unit 206, such as the inverse discrete cosine transform (DCT), the inverse discrete sine transform, or other inverse transformations, to obtain a reconstructed residual block 213 (or the corresponding dequantization coefficient 213) within the sample domain. The reconstructed residual block 213 is also called the transformation block 213.

[0068] Reconstruction The reconstruction unit 214 (e.g., an adder or totaler 214) is configured to obtain a reconstructed block 215 within a sample domain by adding the transformed block 213 (i.e., the reconstructed residual block 213) to the prediction block 365, for example by adding the sample values ​​of the reconstructed residual block 213 and the sample values ​​of the prediction block 265 sample by sample.

[0069] filtering The loop filter unit 220 (or simply "loop filter" 220) is configured to filter the reconstructed block 215 to obtain a filtered block 221, or generally to filter the reconstructed sample to obtain a filtered sample. The loop filter unit is configured, for example, to smooth pixel transitions or otherwise improve video quality. The loop filter unit 220 may include one or more loop filters, such as a deblocking filter, a sample adaptive offset (SAO) filter, or one or more other filters, such as a bilateral filter, an adaptive loop filter (ALF), a sharpening filter, a smoothing filter, or a joint filter, or any combination thereof. Although the loop filter unit 220 is shown as an in-loop filter in Figure 2, in other configurations, the loop filter unit 220 may be implemented as a post-loop filter. The filtered block 221 is also sometimes referred to as a filtered reconstructed block 221.

[0070] Embodiments of the video encoder 20 (each a loop filter unit 220) may be configured to output, for example, loop filter parameters encoded directly or via the entropy encoding unit 270, so that, for example, the decoder 30 may receive and apply the same loop filter parameters or the respective loop filters for decoding.

[0071] Decrypted picture buffer The decoded picture buffer (DRB) 230 may be a memory that stores a reference picture or, in general, reference picture data for encoding video data by the video encoder 20. The DPB 230 may be formed by any of various memory devices, such as dynamic random access memory, including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. The decoded picture buffer 230 may be configured to store one or more filtered blocks 221. The decoded picture buffer 230 may be further configured to store other previously filtered blocks, e.g., previously reconfigured and filtered blocks 221, of the same current picture or a different picture, e.g., a previously reconfigured picture, e.g., a previously reconfigured picture, e.g., a previously reconfigured picture (and its corresponding reference block and sample) and / or a partially reconfigured current picture (and its corresponding reference block and sample) for interpretation. The decoded picture buffer (DRB) 230 may also be configured to store one or more unfiltered configured blocks 215, or generally unfiltered reconstructed samples, if, for example, the reconstructed block 215 has not been filtered by the loop filter unit 220, or is not any other further processed version of the reconstructed block or sample.

[0072] Mode selection (Partitioning & Prediction) The mode selection unit 260 includes a partitioning unit 262, an inter-prediction unit 244, and an intra-prediction unit 254, and is configured to receive original picture data, e.g., the original block 203 (the current block 203 of the current picture 17), and reconstructed picture data, e.g., filtered or unfiltered versions of the same (current) picture, and / or one or more previously decoded pictures, e.g., reconstructed samples or blocks from the decoded picture buffer 230 or other buffers (e.g., line buffers, not shown). The reconstructed picture data is used as reference picture data for predictions, e.g., inter-prediction or intra-prediction, to obtain prediction blocks 265 or predictors 265.

[0073] The mode selection unit 260 may be configured to determine or select partitioning for the current block prediction mode (including no partitioning) and prediction mode (e.g., intra or inter-prediction mode), and to generate corresponding prediction blocks 265 used for calculating residual blocks 205 and reconstructing blocks 215 to be reconstructed.

[0074] Embodiments of the mode selection unit 260 may be configured to select a partitioning and prediction mode (for example, from those supported or available by the mode selection unit 260) that provides the best match, in other words, the minimum residual (minimum residual meaning better compression for transmission or storage), or the minimum signaling overhead (minimum signaling meaning better compression for transmission or storage), or one that considers or balances both. The mode selection unit 260 may also be configured to determine the partitioning and prediction mode based on rate distortion optimization (RDO), i.e., to select a prediction mode that provides the minimum rate distortion. In this context, terms such as “best,” “lowest,” and “optimal” do not necessarily refer to an overall “best,” “lowest,” and “optimal,” but may refer to an ending criterion or selection criterion such as a value above or below a threshold, or the achievement of other constraints that reduce complexity and processing time, which may lead to a “suboptimal selection.”

[0075] In other words, the partitioning unit 262 may be configured to partition block 203 into smaller block partitions or subblocks (forming blocks again) using, for example, quad-tree partitioning (QT), binary partitioning (BT), triple-tree partitioning (TT), or any combination thereof, and to perform predictions for each block partition or subblock, for example, mode selection includes selecting the tree structure of the partitioned block 203, and prediction modes are applied to each block partition or subblock.

[0076] The partitioning (e.g., by the partitioning unit 260) and prediction processing (by the inter-prediction unit 244 and the intra-prediction unit 254) performed by the exemplary video encoder 20 will be described in more detail below.

[0077] Partitioning The partitioning unit 262 can partition (or split) the current block 203 into smaller partitions, such as smaller blocks of a square or rectangle size. These smaller blocks (also called subblocks) may be partitioned into even smaller partitions. This is also called tree partitioning or hierarchical tree partitioning, and the root block, for example, at root tree level 0 (hierarchical level 0, depth 0), may be recursively partitioned, and may be partitioned into two or more blocks at the next lower tree level, such as a node at tree level 1 (hierarchical level 1, depth 1), and these blocks may be further partitioned into two or more blocks at the next lower level, such as tree level 2 (hierarchical level 2, depth 2), until partitioning ends, for example, when a termination criterion is met, such as reaching the maximum tree depth or minimum block size. Blocks that are not further partitioned are also called leaf blocks or leaf nodes of the tree. A tree using partitioning into two partitions is called a binary tree (BT), a tree using partitioning into three partitions is called a ternary tree (TT), and a tree using partitioning into four partitions is called a quad tree (QT). As previously stated, as used herein, the term “block” may be a portion of a picture, in particular a square or rectangular portion. For example, with reference to HEVC and VVC, a block may correspond to a coding tree unit (CTU), coding unit (CU), prediction unit (PU), and transformation unit, and / or to a corresponding block, e.g., a coding tree block (CTB), coding block (CB), transformation block (TB), or prediction block (PB).For example, a coding tree unit (CTU) may be a CTB of luminous samples, two corresponding CTBs of chroma samples of a picture having three sample arrays, or a CTB of samples of a picture coded using three separate color planes and syntactic structures used to code a monochrome picture or sample, or may include these. Correspondingly, a coding tree block (CTB) may be an NxN block of samples of a certain value N, such that the division of a component into a CTB is partitioning. A coding unit (CU) may be a CTB of luminous samples, two corresponding coding blocks of chroma samples of a picture having three sample arrays, or a coding block of samples of a picture coded using three separate color planes and syntactic structures used to code a monochrome picture or sample, or may include these. Correspondingly, a coding block (CB) may be an NxN block of samples of sample values ​​M and N, such that the division of a CTB into a coding block is partitioning.

[0078] In embodiments, for example, according to HEVC, a coding tree unit (CTU) may be split into CUs by using a quad-tree structure, which is shown as the coding tree. The determination of whether to code a picture area using inter-picture (temporal) or intra-picture (spatial) prediction is made at the CU level. Each CU can further be split into one, two, or four PUs, depending on the PU splitting type. Within a single PU, the same prediction process is applied, and the relevant information is sent to the decoder on a PU basis. After obtaining residual blocks by applying the prediction process based on the PU splitting type, the CUs can be partitioned into transform units (TUs) according to another quad-tree structure similar to the coding tree of the CUs. In embodiments, for example, according to the latest video coding standard currently under development, called General-Purpose Video Coding (VVC), a combination of quad-tree and binary-tree (QTBT) partitioning is used, for example, to partition coding blocks. In a QTBT block structure, a CU can have either a square or rectangular shape. For example, a coding tree unit (CTU) is initially partitioned by a quad-tree structure. The quad-tree leaf nodes are further partitioned by a binary tree or a ternary (or triple) tree structure. The partitioned tree leaf nodes are called coding units (CUs), and the segments are used for prediction and transformation processing without further partitioning. This means that CUs, PUs, and TUs have the same block size in the QTBT coding block structure. In parallel, multiple partitions, such as triple-tree partitions, may be used with the QTBT block structure. In one example, the mode selection unit 260 of the video encoder 20 may be configured to perform any combination of the partitioning techniques described herein.

[0079] As described above, the video encoder 20 is configured to determine or select the best or most optimal prediction mode from a set of prediction modes (for example, predetermined). The set of prediction modes may include, for example, an intra-prediction mode and / or an inter-prediction mode.

[0080] Intra Prediction The set of intra-prediction modes may include 35 different intra-prediction modes, e.g., non-directional modes such as DC (or average) mode and planar mode, or directional modes such as those defined for HEVC, or it may include 67 different intra-prediction modes, e.g., non-directional modes such as DC (or average) mode and planar mode, or directional modes such as those defined for VVC.

[0081] The intra-prediction unit 254 is configured to generate an intra-prediction block 265 using reconfigured samples of adjacent blocks of the same current picture, according to the intra-prediction mode of a set of intra-prediction modes.

[0082] The intra-prediction unit 254 (or, generally, the mode selection unit 260) is further configured to output intra-prediction parameters (or, generally, information indicating the intra-prediction mode selected for a block) to the entropy coding unit 270 in the form of syntactic elements 266 for inclusion in the encoded picture data 21, so that, for example, the video decoder 30 can receive and use the prediction parameters for decoding.

[0083] Interpretation The set of interpretations (or possible interpretation modes) depends on the available reference picture (i.e., a picture stored in DBP230 that is at least partially decoded) and other interpretation parameters, such as whether the entire reference picture or only a portion of it is used, whether a search window area around the current block area is used to search for the best-matching reference block, and / or whether pixel interpolation, such as half / semi-per and / or quarter-per interpolation, is applied.

[0084] In addition to the prediction modes described above, skip mode and / or direct mode may be applied. The interpretation unit 244 may include a motion estimation (ME) unit and a motion compensation (MC) unit (neither of which are shown in Figure 2). The motion estimation unit may be configured to receive or acquire, for motion estimation, picture block 203 (the current picture block 203 of the current picture 17) and the decoded picture 231, or at least one or more previously reconfigured blocks, e.g., one or more other / different reconfigured blocks of the previously decoded picture 231. For example, a video sequence may include the current picture and the previously decoded picture 231, in other words, the current picture and the previously decoded picture 231 may be part of a video sequence, or may form a sequence of pictures. The encoder 20 may be configured, for example, to select a reference block from multiple reference blocks of the same or different pictures of multiple other pictures, and to provide the reference picture (or reference picture index) and / or offset (spatial offset) between the position (x, y coordinates) of the reference block and the position of the current block as interprediction parameters to the motion estimation unit. This offset is also called the motion vector (MV). The motion compensation unit is configured to obtain, for example, the interprediction parameters, and to perform interprediction based on or using the interprediction parameters to obtain interprediction blocks 265. Motion compensation performed by the motion compensation unit may involve fetching or generating prediction blocks based on the motion / block vector determined by motion estimation, possibly performing interpolation to sub-pixel precision. Interpolation filtering can generate additional pixel samples from known pixel samples, thus potentially increasing the number of candidate prediction blocks that can be used to code picture blocks.Upon receiving a motion vector for the current picture block's PU, the motion compensation unit may position a predicted block in one of the reference picture lists to which the motion vector points. The motion compensation unit may also generate syntactic elements associated with blocks and video slices for use by the video decoder 30 when decoding the picture blocks of the video slices. In addition to, or as a substitute for, slices and their respective syntactic elements, tile groups and / or tiles and their respective syntactic elements may be generated or used.

[0085] Entropy coding The entropy coding unit 270 applies, for example, an entropy coding algorithm or scheme (e.g., variable-length coding (VLC) scheme, context-adaptive VLC scheme (CAVLC), arithmetic coding scheme, binarization, context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or another entropy coding methodology or technique) or bypass (uncompressed) to the quantization coefficients 209, inter-prediction parameters, intra-prediction parameters, loop filter parameters and / or other syntactic elements to obtain encoded picture data 21 that can be output via output 272 in the form of an encoded bitstream 21, so that, for example, the video decoder 30 can receive and use the parameters for decoding. The encoded bitstream 21 may be transmitted to the video decoder 30 or stored in memory for later transmission or retrieval by the video decoder 30. Other structural variations of the video decoder 20 can be used to encode a video stream. For example, a non-conversion-based encoder 20 can directly quantize the residual signal for a particular block or frame without a conversion processing unit 206. In another implementation, the encoder 20 may have a quantization unit 208 and an inverse quantization unit 210 combined into a single unit.

[0086] Decoder and decoding method Figure 3 shows an example of a video decoder 30 configured to implement the technology of the present application. The video decoder 30 is configured to receive, for example, picture data 21 (e.g., encoded bitstream 21) encoded by the encoder 20 and obtain a decoded picture 331. The encoded picture data or bitstream includes information for decoding the encoded picture data, such as data representing picture blocks (and / or tile groups or tiles) and associated syntactic elements of the encoded video slice.

[0087] In the example in Figure 3, the decoder 30 includes an entropy decoding unit 304, an inverse quantization unit 310, an inverse transformation processing unit 312, a reconstruction unit 314 (e.g., a summer 314), a loop filter 320, a decoded picture buffer 330, a mode application unit 360, an inter-prediction unit 344, and an intra-prediction unit 354. The inter-prediction unit 344 may be or may include a motion compensation unit. In some examples, the video decoder 30 may perform a decoding path that is roughly the reverse of the encoding path described with respect to the video encoder 100 from Figure 2. As described with respect to encoder 20, the inverse quantization unit 210, the inverse transformation processing unit 212, the reconstruction unit 214, the loop filter 220, the decoded picture buffer (DRB) 230, the inter-prediction unit 344, and the intra-prediction unit 354 are also referred to as forming the “built-in decoder” of the video encoder 20. Therefore, the inverse quantization unit 310 may be functionally identical to the inverse quantization unit 110, the inverse transformation unit 312 may be functionally identical to the inverse transformation unit 212, the reconstruction unit 314 may be functionally identical to the reconstruction unit 214, the loop filter 320 may be functionally identical to the loop filter 220, and the decoded picture buffer 330 may be functionally identical to the decoded picture buffer 230. Accordingly, the descriptions provided for each unit and function of the video decoder 30 apply to each unit and function of the video encoder 20.

[0088] Entropy decoding The entropy decoding unit 304 is configured to analyze the bitstream 21 (or generally the encoded picture data 21) and, for example, perform entropy decoding to the encoded picture data 21 to obtain, for example, quantization coefficients 309 and / or the decoded coding parameters (not shown in Figure 3), such as inter-prediction parameters (e.g., reference picture index and motion vector), intra-prediction parameters (e.g., intra-prediction mode or index), transformation parameters, quantization parameters, loop filter parameters, and / or other syntactic elements, or any or all of them. The entropy decoding unit 304 may be configured to apply a decoding algorithm or scheme corresponding to the encoding scheme, as described with respect to the entropy coding unit 270 of the encoder 20. The entropy decoding unit 304 may be further configured to provide the inter-prediction parameters, intra-prediction parameters, and / or other syntactic elements to the mode application unit 360 and other parameters to other units of the decoder 30. The video decoder 30 can receive syntactic elements at the video slice level and / or video block level. In addition to or as an alternative to slices and their respective syntactic elements, tile groups and / or tiles and their respective syntactic elements may be received or used.

[0089] inverse quantization The inverse quantization unit 310 may be configured to receive quantization parameters (QP) (or generally, information related to inverse quantization) and quantization coefficients from the encoded picture data 21 (for example, by analysis and / or decoding by the entropy decoding unit 304), and to apply inverse quantization based on the quantization parameters to the decoded quantization coefficients 309 to obtain dequantization coefficients 311, which may also be called conversion coefficients 311. The inverse quantization process may also include using the quantization parameters determined by the video encoder 20 for each video block in the video slice (or tile or tile group) to determine the degree of quantization and the degree of inverse quantization to be applied.

[0090] Inverse Transform The inverse transform processing unit 312 may be configured to receive the dequantization coefficient 311, also called the transform coefficient 311, and apply a transform to the dequantization coefficient 311 in order to obtain the reconstructed residual block 213 in the sample domain. The reconstructed residual block 213 may also be called the transform block 213. The transform may be an inverse transform, such as an inverse DCT, inverse DST, inverse integer transform, or a conceptually similar inverse transform process. The inverse transform processing unit 312 may be further configured to receive transform parameters or corresponding information from the encoded picture data 21 (for example, by analysis and / or decoding by the entropy decoding unit 304) and determine the transform to be applied to the dequantization coefficient 311.

[0091] Reconstruction The reconstruction unit 314 (e.g., an adder or totaler 314) may be configured to add the reconstructed residual block 313 to the prediction block 365, for example, by adding the sample values ​​of the reconstructed residual block 313 and the sample values ​​of the prediction block 365 to obtain the reconstructed block 315 in the sample domain.

[0092] filtering The loop filter unit 320 (either within or after the coding loop) is configured to filter the reconstructed block 315 to obtain the filtered block 321, for example, to smooth pixel transitions or otherwise improve video quality. The loop filter unit 320 may include one or more loop filters, such as a deblocking filter, a sample-adaptive offset (SAO) filter, or one or more other filters, such as a bilateral filter, an adaptive loop filter (ALF), a sharpening filter, a smoothing filter, or a co-filter, or any combination thereof. Although the loop filter unit 320 is shown as an in-loop filter in Figure 3, in other configurations, the loop filter unit 320 may be implemented as a post-loop filter.

[0093] Decrypted picture buffer Next, the decoded video block 321 of the picture is stored in the decoded picture buffer 330, which stores other pictures and / or reference pictures for subsequent motion compensation for output display, respectively. The decoder 30 is configured to output the decoded picture 311, for example via output 312, for presentation or viewing to the user.

[0094] prediction The inter-prediction unit 344 may be identical to the inter-prediction unit 244 (in particular, the motion compensation unit), and the intra-prediction unit 354 may be functionally identical to the inter-prediction unit 254, and performs splitting or partitioning decision and prediction based on partitioning and / or prediction parameters or respective information received from the decoded picture data 21 (e.g., by analysis and / or decoding by the entropy decoding unit 304). The mode application unit 360 may be configured to perform prediction (intra-prediction or inter-prediction) block by block based on the reconstructed picture, block or each sample (filtered or unfiltered) to obtain a predicted block 365.

[0095] When a video slice is coded as an intra-coded (I) slice, the intra-prediction unit 354 of the mode-applying unit 360 is configured to generate a prediction block 365 for the picture block of the current video slice based on the signaled intra-prediction mode and data from previously decoded blocks of the current picture. When a video picture is coded as an intercoded (i.e., B or P) slice, the inter-prediction unit 344 (e.g., motion compensation unit) of the mode-applying unit 360 is configured to generate a prediction block 365 for the video block of the current video slice based on motion vectors and other syntactic elements received from the entropy decoding unit 304. For inter-prediction, the prediction block may be generated from one of the reference pictures in one of the reference picture lists. The video decoder 30 may configure the reference frame lists, list 0 and list 1, using default configuration techniques based on reference pictures stored in the DPB 330. The same or similar applies to embodiments in which tile groups (e.g., video tile groups) and / or tiles (e.g., video tiles) are used in addition to, or alternative to, slices (e.g., video slices), for example, video may be coded using I, P, or B tile groups and / or tiles.

[0096] The mode application unit 360 is configured to determine predictive information for video blocks in the current video slice by parsing motion vectors or relational information and other syntactic elements, and to use the predictive information to generate predictive blocks for the current video block to be decoded. For example, the mode application unit 360 uses some of the received syntactic elements to determine the predictive mode (e.g., intra or inter-predictive) used to code the video blocks in the video slice, the inter-predictive slice type (e.g., B-slice, P-slice, or GPB-slice), one or more configuration pieces of reference picture list for the slice, motion vectors for each inter-coded video block in the slice, the inter-predictive status for each inter-coded video block in the slice, and other information for decoding the video blocks in the current video slice. The same or similar applies to embodiments in which tile groups (e.g., video tile groups) and / or tiles (e.g., video tiles) are used in addition to or instead of slices (e.g., video slices), for example, video may be coded using I, P, or B tile groups and / or tiles.

[0097] The embodiment of the video decoder 30 shown in Figure 3 may be further configured to partition and / or encode a picture by using slices (also called video slices), the picture may be partitioned or decoded using one or more slices (typically non-overlapping), each slice may contain one or more blocks (e.g., CTUs).

[0098] The embodiment of the video decoder 30 shown in Figure 3 may be configured to partition and / or decode a picture using tile groups (also called video tile groups) and / or tiles (also called video tiles), the picture may be partitioned or decoded using one or more tile groups (typically non-overlapping), each tile group may include, for example, one or more blocks (e.g., CTUs) or one or more tiles, each tile may be, for example, rectangular in shape and may include one or more blocks (e.g., CTUs), for example, a complete block or a partial block. Encoded picture data 21 can be decoded using other variations of the video decoder 30. For example, the decoder 30 can generate an output video stream without a loop filtering unit 320. For example, a non-transformation-based decoder 30 can directly dequantize the residual signal for a particular block or frame without an inverse transformation processing unit 312. In another implementation, the video decoder 30 may have an inverse quantization unit 310 and an inverse transformation processing unit 312 combined into a single unit. It should be understood that the encoder 20 and decoder 30 may further process the results of the current step and output them to the next step. For example, after interpolation filtering, motion vector derivation, or loop filtering, further operations such as clipping or shifting may be performed on the results of interpolation filtering, motion vector derivation, or loop filtering.

[0099] It should be noted that further calculations may be applied to the derived motion vectors of the current block (including, but not limited to, affine mode control point motion vectors, affine, planar, and ATMVP mode subblock motion vectors, temporal motion vectors, etc.). For example, the value of a motion vector is constrained to a predefined range according to its representation bit. If the representation bit of the motion vector is bitDepth, the range is -2^(bitDepth-1)~2^(bitDepth-1)-1, where "^" means exponentiation. For example, if bitDepth is set to 16, the range is -32768~32767, and if bitDepth is set to 18, it is -131072~131071. For example, the value of a derived motion vector (e.g., the MV of a 4x4 subblock in one 8x8 block) is constrained such that the maximum difference between the integer parts of the MVs of four 4x4 subblocks is less than or equal to N pixels, such as 1 pixel or less. Here, we provide two methods for constraining motion vectors according to bitDepth.

[0100] Method 1: Remove the overflow MSB (most significant bit) using flow calculation.

[0101]

number

[0102] For example, if the value of mvx is -32769, then after applying equations (1) and (2), the resulting value is 32767. In computer systems, decimal numbers are stored as two's complement. The two's complement of -32769 is 1,0111,1111,1111 (17 bits), and since the MSB is discarded, the resulting two's complement is 0111,1111,1111,1111 (decimal is 32767), which is the same as the output when equations (1) and (2) are applied.

[0103]

number

[0104] Method 2: Remove the overflow MSB by clipping the value.

[0105]

number

[0106]

number

[0107] Figure 4 is a schematic diagram of a video coding device 400 according to one embodiment of the present disclosure. The video coding device 400 is suitable for implementing the disclosed embodiments described herein. In one embodiment, the video coding device 400 may be a decoder, such as the video decoder 30 in Figure 1A, or an encoder, such as the video encoder 20 in Figure 1A.

[0108] The video coding device 400 includes an inlet port 410 (or input port 410) and a receiver unit (Rx) 420 for receiving data, a processor, logic unit, or central processing unit (CPU) 430 for processing data, a transmitter unit (Tx) 440 and an exit port 450 (or output port 450) for transmitting data, and memory 460 for storing data. The video coding device 400 may also include optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the inlet port 410, the receiver unit 420, the transmitter unit 440, and the exit port 450 for the entry and exit of optical or electrical signals.

[0109] The processor 430 is implemented by hardware and software. The processor 430 may be implemented as one or more CPU chips, cores (e.g., a multi-core processor), FPGAs, ASICs, and DSPs. The processor 430 communicates with an inlet port 410, a receiver unit 420, a transmitter unit 440, an exit port 450, and memory 460. The processor 430 includes a coding module 470. The coding module 470 implements the embodiments disclosed above. For example, the coding module 470 implements, processes, prepares, or provides various coding operations. Thus, including the coding module 470 provides a substantial improvement to the functionality of the video coding device 400, resulting in the conversion of the video coding device 400 to different states. Alternatively, the coding module 470 is implemented as instructions stored in memory 460 and executed by the processor 430.

[0110] Memory 460 may include one or more disks, tape drives, and solid-state drives, and may be used as an overflow data storage device to store a program when such a program is selected for execution, and to store instructions and data read during program execution. Memory 460 may be, for example, volatile and / or non-volatile, and may be read-only memory (ROM), random-access memory (RAM), ternarily content-addressable memory (TCAM), and / or static random-access memory (RSAM).

[0111] Figure 5 is a simplified block diagram of a device 500 which may be used as either or both of the source device 12 and destination device 14 from Figure 1, according to an exemplary embodiment.

[0112] The processor 502 within the device 500 can be a central processing unit. Alternatively, processor 502 can be any other type of device or multiple devices capable of manipulating or processing information that currently exists or will be developed in the future. The disclosed implementation can be carried out using a single processor, e.g., processor 502, as shown, but advantages in speed and efficiency can be achieved by using multiple processors.

[0113] The memory 504 within the device 500 may be a read-only memory (ROM) device or a random-access memory (RAM) device in its implementation. Any other suitable type of storage device can be used as memory 504. Memory 504 may contain code and data 506 accessed by the processor 502 using the bus 512. Memory 504 may further include an operating system 508 and an application program 510, the application program 510 including at least one program that allows the processor 502 to perform the method described herein. For example, the application program 510 may include applications 1 to N, which further include a video coding application that performs the method described herein. The device 500 may also further include one or more output devices, such as a display 518. Display 518 may, in one example, be a touch-sensitive display that combines the display with a touch-sensitive element that can operate to sense touch input. Display 518 may be connected to the processor 502 via the bus 512.

[0114] Although shown here as a single bus, the bus 512 of device 500 can consist of multiple buses. Furthermore, the secondary storage 514 can be directly coupled to other components of device 500 or accessed via a network, and may include a single integrated unit such as a memory card or multiple units such as multiple memory cards. Thus, device 500 can be implemented in a wide range of configurations.

[0115] The interpretation unit 244 may include a motion estimation (ME) unit and a motion compensation (MC) unit (not shown in Figure 2). The motion estimation unit may be configured to receive or acquire, for motion estimation, picture block 203 (the current picture block 203 of the current picture 201) and the decoded picture 331, or at least one or more previously reconfigured blocks, e.g., one or more other / different reconfigured blocks of the previously decoded picture 331. For example, a video sequence may include the current picture and the previously decoded picture 331, in other words, the current picture and the previously decoded picture 331 may be part of a picture that forms a video sequence, or may form a sequence of pictures. The encoder 200 may be configured, for example, to select a reference block from multiple reference blocks of the same or different pictures of multiple other pictures, and to provide the reference picture (or reference picture index, ...) and / or offset (spatial offset) between the position (x, y coordinates) of the reference block and the position of the current block as an interprediction parameter to the motion estimation unit (not shown in Figure 2). This offset is also called the motion vector (MV).

[0116] Merging is a key motion estimation tool used in HEVC and inherited by VVC. To perform merge estimation, the first step is to construct a list of merge candidates, each candidate containing motion data that includes information on whether one or two reference picture lists are used, and the motion data also includes reference index and motion vector information for each list. The list of merge candidates is constructed based on the following candidates: a. up to four spatial merge candidates derived from five spatially adjacent blocks; b. one temporal merge candidate derived from two temporally copositional blocks; and c. additional merge candidates, including combined biprediction candidates and zero motion vector candidates.

[0117] The first candidate added to the merge candidate list is spatially adjacent. As shown in the example on the right side of Figure 6, checking A1, B1, B0, A0, and B2 in that order sequentially will insert up to four candidates into the merge list.

[0118] Before a coding block is available and contains motion information, several additional redundancy checks are performed. These checks can be divided into two categories for two different purposes: a. to avoid having candidates with redundant motion data in the list; and b. to prevent merging two partitions that are represented by other means that generate redundant syntax.

[0119] When N is the number of spatial merge candidates, a complete redundancy check consists of (N·(N-1)) / 2 motion data comparisons. For five potential spatial merge candidates, 10 motion data comparisons are required to ensure that all candidates in the merge list have different motion data. During the development of HEVC, checks for redundant motion data were reduced to a subset in a way that maintained coding efficiency, but the comparison logic was significantly reduced. In the final design, no more than two comparisons are performed per candidate, resulting in five overall comparisons. In the order {A1, B1, B0, A0, B2}, only B0 checks B1, only A0 checks A1, and only B2 checks A1 and B1. In an embodiment of the partitioning redundancy check, the lower PU of a 2N×N partitioning is merged with the upper one by selecting candidate B1. This results in one CU with two PUs having the same motion data that can be equally signaled as a 2N×2N CU. Overall, this check applies to all second PUs of rectangular and asymmetric partitions of 2N×N, 2N×nU, 2N×nD, N×2N, nR×2N, and nL×2N. Note that for spatial merge candidates, only a redundancy check is performed, and motion data is copied directly from the candidate block. Therefore, motion vector scaling is not required here.

[0120] The derivation of motion vectors for temporal merge candidates is the same as for the temporal motion vector predictor TMVP. Since merge candidates contain all motion data and TMVP contains only one motion vector, the derivation of the overall motion data depends on the slice type. For a dual-prediction slice, a TMVP is derived for each reference picture list. Depending on the availability of TMVPs for each list, the prediction type is set to either dual-prediction or a list where TMVPs are available. All associated reference picture indices are set to equal to zero. Therefore, for a single-prediction slice, only the TMVP for list 0 is derived, along with reference picture indices equal to zero.

[0121] If at least one TMVP is available and a temporal merge candidate has been added to the list, no redundancy check is performed. This makes the merge list configuration independent of copositional pictures, which improves error resilience. Consider the case where a temporal merge candidate is redundant and therefore not included in the merge candidate list. In the case of a lost copositional picture, the decoder could not derive a temporal candidate and therefore could not check whether it was redundant. Indexing of all subsequent candidates is affected by this.

[0122] When analyzing robustness reasons, the length of the merge candidate list is fixed. After spatial and temporal merge candidates are added, the list may still not reach the fixed length. Additional candidates are generated to compensate for the coding efficiency loss that occurs with non-length adaptive list index signaling. Depending on the slice type, up to two types of candidates are used to generate the list completely: a. Combined biprediction candidates; b. Zero-motion vector candidates.

[0123] In dual prediction slicing, additional candidates can be generated based on existing ones by combining the motion data from reference picture list 0 of one candidate with the motion data from list 1 of another candidate. This is done by copying Δx0, Δy0, and Δt0 from one candidate, e.g., the first one, and copying Δx1, Δy1, and Δt1 from the other candidate, e.g., the second one. Different combinations are predefined and given in Table 1.

[0124] [Table 3]

[0125] For combined biprediction candidates or single prediction slices, zero-motion vector candidates are computed to complete the list when the list is not yet full. Every zero-motion vector candidate has one zero-displacement motion vector for single prediction slices and two zero-displacement motion vectors for biprediction slices. The reference index is set to zero and incremented by 1 for each additional candidate until the maximum number of reference indices is reached. If further candidates are missing, they are created using the zero-equal reference index. Redundancy checks are not performed for all additional candidates, as it has been found that omitting these checks does not result in a loss of coding efficiency.

[0126] For each PU coded in inter-picture prediction mode, merge_flag indicates that block merge is used to derive motion data. merge_idx is further used to determine the candidate in the merge list that provides the motion data. In addition to this PU-level signaling, multiple candidates in the merge list are signaled in the slice header. The default value is 5, and the number of candidates in the merge list is expressed as the difference from 5 (5_minus_max_num_merge_cand). In this way, 5 is signaled with a short codeword for the 0th candidate, but if only one candidate is used, it is signaled with a long codeword for the 4th candidate. Regarding the impact on the merge candidate list construction process, the list terminates after it contains the maximum number of merge candidates, but the overall process remains the same. In one design, the maximum value of merge index coding was given by the number of available spatial and temporal candidates in the list. For example, if only two candidates are available, the index can be efficiently coded as a flag. However, in order to parse the merge index, the entire merge candidate list must be constructed to obtain the actual number of candidates. Assuming that adjacent blocks are unavailable due to transfer errors, it is no longer possible to parse the merge index.

[0127] The application of the block merge concept in HEVC is in combination with skip mode. In previous video coding standards, skip mode was used to indicate to a block that motion data would be inferred rather than explicitly signaled, and that the predicted residuals would be zero, i.e., no conversion coefficients would be sent. In HEVC, at the beginning of each CU in the inter-picture prediction slice, a skip_flag is signaled, meaning a. the CU contains only one PU (2N×2N partition type), b. merge mode is used to derive motion data (a merge_flag value equal to 1), and c. no residual data is present in the bitstream. Another motion estimation tool introduced in HEVC and specific to VVC is called Advanced Motion Vector Prediction, or AMVP. In AMVP mode, motion vectors are coded as differences to the Motion Vector Predictor (MVP) with respect to the horizontal component (x) and vertical component (y). The calculation of both motion vector difference (MVD) components is shown as MVDx = MVx - MVPx and MVDy = MVy - MVPy.

[0128] The motion vector of the current block is typically correlated with the motion vector of the adjacent block in the current or previously coded picture. Adjacent blocks are likely to correspond to the same moving object with similar motion, and the motion of an object is unlikely to change abruptly over time. Therefore, using the motion vector in the adjacent block as a predictor reduces the size of the signaled motion vector difference. The MVP is typically derived from the already coded motion vectors of the spatially adjacent block, or from the temporally adjacent block in a copositional picture. In HEVC, the approach of implicitly deriving the MVP has been replaced by a technique known as motion vector competition, which explicitly signals which MVP from a list of MVPs is used for motion vector derivation. The variable coding quadtree block structure in HEVC results in a single block, which has several adjacent blocks with motion vectors as potential MVP candidates. Taking left adjacency as an example, in the worst case, if a 64x64 Luma coding tree block is not further split and its left adjacency is split to maximum depth, the 64x64 Luma prediction block can have 16 8x4 Luma prediction blocks to its left. Advanced Motion Vector Prediction (AMVP) was introduced to correct motion vector races to account for flexible block structures. During the development of HEVC, the initial AMVP design was significantly simplified to provide a good trade-off between coding efficiency and implementation-friendly design.

[0129] The initial AMVP design included five MVPs from three different classes of predictors: three motion vectors from spatial adjacencies, the center of three spatial predictors, and scaled motion vectors from copositional temporal adjacencies. Furthermore, the list of predictors was modified by reordering to place the most likely motion predictor in the first position and removing redundant candidates to ensure minimal signaling overhead. This significantly simplified the AMVP design. For example, the center predictor was removed, the number of candidates in the list was reduced from five to two, the order of candidates in the list was corrected, and the number of redundancy checks was reduced. The final design of the AMVP candidate list configuration includes the following two MVP candidates: • Up to two spatially adjacent blocks can be derived from five spatially adjacent blocks. • If both spatial candidate MVPs are unavailable or identical, one temporal candidate MVP is derived from the two temporally copositional blocks. • A zero motion vector when spatial, temporal, or both options are unavailable.

[0130] In the spatial candidate description, the derivation process flow for two spatial candidates, A and B, is shown in Figure 6. For candidate A, motion data from two blocks A0 and A1 in the lower left corner is considered using a two-pass approach. In the first pass, it is checked whether either candidate block contains a reference index equal to the reference index of the current block. The first motion vector found is taken as candidate A. The associated motion vector cannot be used directly when all reference indices from A0 and A1 point to reference pictures different from the reference index of the current block. Therefore, in the second pass, the motion vector needs to be scaled according to the temporal distance between the candidate reference picture and the current reference picture. The temporal distance is expressed as the difference between picture order count (POC) values ​​that define the display order of the pictures.

[0131] For candidate B, candidates B0 through B2 are checked sequentially, just as A0 and A1 are checked in the first pass. However, the second pass is only performed if blocks A0 and A1 do not contain any motion information, i.e., blocks A0 and A1 are unavailable, or if they are coded using intra-picture prediction. Candidate A is then set to equal unscaled candidate B if an unscaled candidate B is found, and candidate B is set to equal the second unscaled or scaled variation of candidate B. If there may still be potential unscaled candidates, the second pass terminates, and the second pass searches for unscaled and scaled MVs derived from candidates B0 through B2. This design allows for the processing of A0 and A1 independently of B0, B1, and B2. The derivation of B should only be aware of the availability of both A0 and A1 in order to search for scaled or additional unscaled MVs derived from B0 and B2. This dependency is acceptable considering that it reduces the complex motion vector scaling operations for candidate B. Reducing the number of motion vector scaling operations represents a significant reduction in complexity in the motion vector predictor derivation process.

[0132] Temporal candidate selection process Figure 6 shows that only the motion vector of the spatially adjacent block to the upper left of the current block is considered as a candidate for spatial MVP. This can be explained by the fact that the block to the lower right of the current block has not yet been decoded, and therefore its motion data is unavailable. Since copositional pictures are already decoded reference pictures, motion data from the block at the same position, from the block to the right of the copositional block, or from the block below can also be considered. HEVC determined that the lower right and central blocks of the current block were the most suitable to provide good temporal motion vector predictors (TMVPs). These candidates are shown in Figure 6, where C0 represents the lower right adjacent block and C1 represents the central block. The motion data for C0 is considered first, and if the motion data for C0 is unavailable, the motion data of the central copositional candidate block is used to derive the temporal MVP candidate C. The motion data for C0 is considered unavailable if the associated PU belongs to a CTU beyond the current CTU row. This minimizes the memory bandwidth requirements for storing copositional motion data. In contrast to spatial MVP candidates, motion vectors can reference the same reference picture, but motion vector scaling is essential for TMVP.

[0133] History-based motion vector predictors (HMVPs) are used for both merge list and AMVP list configurations. History-based MVP (HMVP) merge candidates are added to the merge / AMVP list after the spatial MVP and TMVP. In this method, motion information from previously coded blocks is stored in a table and used as the MVP for the current CU. The table with multiple HMVP candidates is maintained during the coding / decoding process. Whenever a new CTU row is encountered, the table is reset (empty). Whenever there are unintercoded CUs in subblocks, the associated motion information is added to the last entry in the table as a new HMVP candidate.

[0134] In one example, the HMVP table size S is set to 5, indicating that up to 5 history-based MVP (HMVP) candidates may be added to the table. When inserting a new motion candidate into the table, a constrained first-in, first-out (FIFO) rule is used, where a redundancy check is first applied to find out if there is already an identical HMVP in the table. If an identical HMVP exists in the table, the identical HMVP is removed from the table, and then all HMVP candidates are moved forward.

[0135] HMVP candidates can be used in the merge candidate list / AMVP list construction process. The most recent HMVP candidates in the table are checked sequentially and inserted into the candidate list after TMVP candidates. Redundancy checks are applied to HMVP candidates for spatial or temporal merge candidates. To reduce the number of redundancy check calculations, the following simplifications were introduced. Is the number of HMVP candidates to be used to generate the merge list set to (N<=4)? M:(8-N), where N is the number of existing candidates in the merge list and M is the number of available HMVP candidates in the table. The process of constructing the merge candidate list from HMVPs ends when the total number of available merge candidates reaches the maximum allowed merge candidate minus 1.

[0136] The intermode parallelization of the VVC draft introduces the IBC mode. Intra-block copy (IBC) is a tool adopted in the HEVC extension of SCC. It improves the coding efficiency of screen content material. Since IBC mode is implemented as a block-level coding mode, block matching (BM) is performed in the encoder to find the optimal block vector (or motion vector) for each CU. Here, the motion vector is used to indicate the displacement from the current block to a reference block, which has already been reconstructed within the current picture. The chroma motion vector of an IBC-coded CU is integer-precision. The chroma motion vector is also clipped to integer precision. When combined with AMVR, IBC mode can switch between 1-per and 4-per motion vector precisions. IBC-coded CUs are treated as a third prediction mode other than intra or interprediction mode. To reduce memory consumption and decoder complexity, IBC in VTM5 allows the use of only the reconstructed portion of a given region containing the current CTU. This limitation allows for the implementation of IBC mode using local on-chip memory for hardware implementation.

[0137] On the encoder side, hash-based motion estimation is performed on the IBC. The encoder performs RD checks on blocks with a width or height of 16 luma samples or less. In non-merge mode, a block vector search is first performed using a hash-based search. If the hash search does not return any valid candidates, a block matching-based local search is performed.

[0138] In hash-based search, hash key matching (32-bit CRC) between the current block and the reference block is extended to all allowed block sizes. The calculation of hash keys for all positions in the current picture is based on 4x4 subblocks. For larger current blocks, a hash key is determined to match the reference block's hash key if all hash keys in all 4x4 subblocks match the hash keys of the corresponding reference positions. If multiple reference blocks' hash keys are found to match that of the current block, the block vector cost for each matched reference is calculated, and the one with the lowest cost is selected. In block matching search, the search range is set to N samples in the upper left of the current block within the current CTU. At the start of the CTU, the value of N is initialized to 128 if there are no temporal reference pictures, and to 64 if there is at least one temporal reference picture. The hash hit ratio is defined as the percentage of samples in the CTU for which a match was found using hash-based search. If the hash hit ratio is less than 5% while encoding the current CTU, N is reduced by half.

[0139] At the CU level, the IBC mode is signaled with a flag and can be signaled as either IBC AMVP mode or IBC skip / merge mode as follows: IBC Skip / Merge Mode: The merge candidate index is used to indicate which of the adjacent candidate IBC-coded blocks in the list of block vectors will be used to predict the current block. IBC AMVP mode: Block vector difference is coded similarly to motion vector difference. The block vector prediction method uses two candidate predictors. A flag is signaled to indicate the block vector predictor index. Since IBC has introduced IBC Merge / Skip mode and IBC AMVP mode, it is necessary to configure additional IBC merge lists and AMVP lists. In VVC Draft 5.0, BV predictors in merge mode and AMVP mode share a common predictor list, which includes the following elements: • Two spatially adjacent locations (A1, B1) • 5 HMVP entries • Defaults to zero vector In merge mode, up to six entries in this list are used, while in AMVP mode, the first two entries are used. This list also conforms to the shared merge list area requirement (sharing the same list within the SMR). In addition to the above list of BV predictor candidates, another method is used to simplify the pruning operation between HMVP candidates and existing merge candidates (A1, B1). In the simplified version, there are up to two pruning operations. • Last HMVP candidate H k Pruning between A1 • Last HMVP candidate H k Pruning between B1 Pruning means comparing whether two IBC merge candidates are the same. More specifically, pruning compares whether the block vectors between two IBC merge candidates are the same.

[0140] IBC Luma Motion Vector prediction is explained in the following section 8.6.2.2 of JVET-N1001-v5 (VVC Draft 5.0). [Outside 1] TIFF2026113495000016.tif220170 TIFF2026113495000017.tif50170

[0141] In another example, IBC Luma Motion Vector prediction is explained as follows: [Outside 2] TIFF2026113495000018.tif168170 TIFF2026113495000019.tif198170MaxNumMergeCand is derived as follows: six_minus_max_num_merge_cand specifies the maximum number of merging motion vector prediction (MVP) candidates supported by a slice, minus 6. The maximum number of merging MVP candidates, MaxNumMergeCand, is derived as follows: MaxNumMergeCand=6-six_minus_num_merge_cand The value of six_minus_max_num_ibc_merge_cand should be in the range of 1 to 6. `six_minus_max_num_merge_cand` specifies the maximum number of Merging Motion Vector Prediction (MVP) candidates supported by SPS, minus 6. The value of `six_minus_max_num_ibc_merge_cand` should be in the range of 0 to 5. The maximum number of Merging MVP candidates, MaxNumMergeCand, is derived as follows: MaxNumMergeCand=6-six_minus_num_merge_cand In some embodiments, in IBC mode, this syntax may also be named MaxNumIbcMergeCand. In this case, MaxNumMergeCand may be used for interprocessing. When sps_ibc_enabled_flag is equal to 1, six_minus_max_num_ibc_merge_cand specifies the maximum number of IBC merging block vector prediction (BVP) candidates supported by SPS minus 6. The value of six_minus_max_num_ibc_merge_cand must be in the range of 0 to 5. The maximum number of IBC merging BVP candidates, MaxNumIbcMergeCand, is derived as follows: if(sps_ibc_enabled_flag) MaxNumIbcMergeCand=6-6_minus_max_num_ibc_merge_cand else MaxNumIbcMergeCand=0 A sps_ibc_enabled_flag equal to 1 indicates that the IBC prediction mode may be used to decode pictures in the coded Layer Video Sequence CLVS. A sps_ibc_enabled_flag equal to 0 indicates that the IBC prediction mode is not used for CLVS. If sps_ibc_enabled_flag is not present, it is assumed to be equal to 0. general_merge_flag is defined as follows: general_merge_flag[x0][y0] specifies whether the inter-frame prediction parameters for the current coding unit are inferred from adjacent inter-frame prediction partitions. Array indices x0, y0 specify the position (x0, y0) of the top-left luma sample of the coding block being considered, relative to the top-left luma sample of the picture. If general_merge_flag[x0][y0] does not exist, it is assumed to be equal to 0. - If cu_skip_flag[x0][y0] is equal to 1, then general_merge_flag[x0][y0] is presumed to be equal to 1. - Otherwise, general_merge_flag[x0][y0] is presumed to be equal to 0. A value of 1 for cu_skip_flag[x0][y0] specifies that, for the current coding unit, when decoding a P or B slice, no syntactic elements will be parsed after cu_skip_flag[x0][y0], except for one or more of the IBC mode flag pred_mode_ibc_flag[x0][y0] and merge_data() syntactic structures; and when decoding an I slice, no syntactic elements will be parsed after cu_skip_flag[x0][y0], except for merge_idx[x0][y0]. A value of 0 for cu_skip_flag[x0][y0] specifies that the coding unit will not be skipped. The array indices x0, y0 specify the position (x0, y0) of the top-left luma sample of the coding block being considered, relative to the top-left luma sample of the picture. If cu_skip_flag[x0][y0] does not exist, it is assumed to be equal to 0. mvp_l0_flag is defined as follows: mvp_l0_flag[x0][y0] specifies the motion vector predictor index in List 0, where x0 and y0 specify the position (x0, y0) of the top-left Luma sample of the coding block to be considered relative to the top-left sample of the picture. If mvp_l0_flag[x0][y0] does not exist, it is assumed to be equal to 0. When MaxNumMergeCand or MaxNumIbcMergeCand is set to 1, the length of the configured merge candidate list may be 1 or 2, depending on the number of available spatial motion vector candidates. If the mvp_l0_flag of the decoded IBC block is equal to 1, the motion vector of the IBC block may be undefined. To resolve this issue, the following solution is introduced. Table 2 shows the motion vectors in the candidate list, which have availableFlagA1 and availableFlagB1 with various statuses. [Table 4]

[0142] Embodiment 1: If the value of MaxNumMergeCand or MaxNumIbcMergeCand is set to 1, the decoder does not need to analyze the value of mvp_l0_flag from the bitstream, and the value of mvp_l0_flag is estimated to be 0. As an example, the corrected syntax table is shown below. [Table 5] In another example, Coding unit syntax: [Table 6] In this embodiment, General decoding process for coding units coded in IBC prediction mode The input to this process is, - Luma position (xCb, yCb) specifying the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture. - The variable cbWidth specifies the width of the current coding block in the Luma sample. - The variable cbHeight specifies the height of the current coding block in the Luma sample. — The `treeType` variable specifies whether to use a single tree or a dual tree, and if a dual tree is used, it specifies whether the current tree corresponds to a luma component or a chroma component. The output of this process is the corrected and reconstructed picture before in-loop filtering. The quantization parameter derivation process is invoked with the following variables as input: Luma position (xCb, yCb), width of the current coding block in the Luma sample cbWidth, height of the current coding block in the Luma sample cbHeight, and treeType. The variable IsGt4by4 is derived as follows: IsGt4by4=(cbWidth*cbHeight)>16 The decoding process for coding units coded in IBC prediction mode includes the following steps in this order: 1. The block vector component of the current coding unit is derived as follows: - The block vector component derivation process is called with the Luma coding block position (xCb, yCb), Luma coding block width cbWidth, Luma coding block height cbHeight, and Luma block vector bvL as outputs. - When treeType is equal to SINGLE_TREE, the chroma block vector derivation process is called with chroma block vector bvL as input and chroma block vector bvC as output. 2. The predicted samples for the current coding unit are derived as follows: - The IBC block decoding process takes the following inputs: Luma coding block position (xCb, yCb), Luma coding block width cbWidth, Luma coding block height cbHeight, Luma block vector bvL, and a variable cIdx set to 0, and predicts the Luma sample (cbWidth)x(cbHeight) array predSamples. L The IBC prediction samples (predSamples) are called as output. - When treeType is equal to SINGLE_TREE, the predicted sample for the current coding unit is derived as follows: - The IBC block decoding process takes the chroma coding block position (xCb, yCb), chroma coding block width cbWidth, chroma coding block height cbHeight, chroma block vector bvC, and a variable cIdx set to 1 as input, and predicts the chroma sample for the chroma component Cb using the (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array predSamples. Cb The IBC prediction samples (predSamples) are called as output. - The IBC block decoding process takes the chroma coding block position (xCb, yCb), chroma coding block width cbWidth, chroma coding block height cbHeight, chroma block vector bvC, and a variable cIdx set to equal 2 as input, and predicts the chroma sample for the chroma component Cr using the (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array predSamples. Cr The IBC prediction samples (predSamples) are called as output. 3. The residual samples of the current coding unit are derived as follows: - The decoding process of the residual signal of a coding block coded in interpredictive mode takes as input a position (xTb0, yTb0) set to the Luma position (xCb, yCb), a width nTbW set to the Luma coding block width cbWidth, a height nTbH set to the Luma coding block height cbHeight, and a variable cIdx set to 0, and the array resSamples L It is called with the output being [output]. - When treeType is equal to SINGLE_TREE, the decoding process of the residual signal of the coding block coded in the inter prediction mode takes as input the position (xTb0, yTb0) set equal to the chroma position (xCb / SubWidthC, yCb / SubHeightC), the width nTbW set equal to the chroma coding block width cbWidth / SubWidthC, the height nTbH set equal to the chroma coding block height cbHeight / SubHeightC, and the variable cIdx set equal to 1, and the array resSamples Cb is called with the output. - When treeType is equal to SINGLE_TREE, the decoding process of the residual signal of the coding block coded in the inter prediction mode takes as input the position (xTb0, yTb0) set equal to the chroma position (xCb / SubWidthC, yCb / SubHeightC), the width nTbW set equal to the chroma coding block width cbWidth / SubWidthC, the height nTbH set equal to the chroma coding block height cbHeight / SubHeightC, and the variable cIdx set equal to 2, and the array resSamples Cr is called with the output. 4. The reconstructed samples of the current coding unit are derived as follows. - The picture reconstruction process for the color component takes as input the block position (xCurr, yCurr) set equal to (xCb, yCb), the block width nCurrSw set equal to cbWidth, the block height nCurrSh set equal to cbHeight, the variable cIdx set equal to 0, predSamples L the (cbWidth) x (cbHeight) array predSamples set equal to, and the (cbWidth) x (cbHeight) array resSamples set equal to resSamplesL, and the output is the corrected reconstructed image before in-loop filtering. - When treeType is equal to SNGLE_TREE, the picture reconstruction process for the color component is as follows: block position (xCurr, yCurr) set to equal xCb / SubWidthC, yCb / SubHeightC), block width nCurrSw set to equal cbWidth / SubWidthC, block height nCurrSh set to equal cbHeight / SubHeightC, variable cIdx set to equal 1, predSamples Cb The (cbWidth / SubWidthC)x(cbHeight / SubHeightC) arrays predSamples and resSamples are set to be equal to each other. Cb The function is called with a (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array resSamples set to equal to , and the output is the modified and reconstructed picture before filtering within the loop. - When treeType is equal to SNGLE_TREE, the picture reconstruction process for the color component is as follows: block position (xCurr, yCurr) set to equal xCb / SubWidthC, yCb / SubHeightC), block width nCurrSw set to equal cbWidth / SubWidthC, block height nCurrSh set to equal cbHeight / SubHeightC, variable cIdx set to equal 2, predSamples Cr The function is called with a (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array predSamples set equal to and a (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array resSamples set equal to resSamplesCr as input, and the output is the modified and reconstructed picture before in-loop filtering. [Outside 3] TIFF2026113495000023.tif225170 TIFF2026113495000024.tif225170 TIFF2026113495000025.tif215170

[0143] Embodiment 2: If the value of MaxNumMergeCand or MaxNumIbcMergeCand is set to 1, the second candidate in the motion vector candidate list is set to its default value, for example, the zero motion vector. [Outside 4] TIFF2026113495000026.tif220170 TIFF2026113495000027.tif84170

[0144] Embodiment 3: Ensure that the motion vector candidate list has at least two entries for the IBC AMVP mode. In this solution, the motion vector candidate list is constructed depending on general_merge_flag. If general_merge_flag is true (for example, the value of general_merge_flag is 1), the variable maxNumListCand is set to equal to MaxNumMergeCand or MaxNumIbcMergeCand, and if general_merge_flag is false (for example, the value of general_merge_flag is 0), maxNumListCand or MaxNumIbcMergeCand is set to equal to 2. Then, in constructing the motion vector candidate list, HMVP candidates and zero candidates are added to the list until the number of candidates in the list equals maxNumListCand. [Outside 5] TIFF2026113495000028.tif229170 TIFF2026113495000029.tif245170

[0145] Embodiment 4: Ensure that the motion vector candidate list has at least two entries for the IBC AMVP mode. This solution involves constructing a motion vector candidate list that has at least two entries. In the motion vector candidate list configuration, HMVP candidates and zero candidates are added to the list until the number of candidates in the list equals the maximum number between MaxNumMergeCand or MaxNumIbcMergeCand and 2. [Outside 6] TIFF2026113495000030.tif204170 TIFF2026113495000031.tif230170

[0146] Embodiment 5: Ensure that the motion vector candidate list has at least two entries for the IBC AMVP mode. In this solution, the motion vector candidate list configuration is decoupled with MaxNumMergeCand or MaxNumIbcMergeCand, resulting in a motion vector candidate list that always has 6 entries. HMVP candidates and zero candidates are added to the list until the number of candidates in the list reaches 6. [Outside 7] TIFF2026113495000032.tif224170 TIFF2026113495000033.tif229170

[0147] Embodiment 6: Ensure that MaxNumMergeCand or MaxNumIbcMergeCand is greater than 1. [Outside 8] TIFF2026113495000034.tif42170

[0148] Example 1. A coding method implemented by a decoding device, The goal is to obtain the maximum number of MVP candidates for the current block's motion vector prediction, where the current block is predicted using the Intrablock Copy IBC MVP mode. If the value of the maximum number of MVP candidates for the current block is equal to 1, set the MVP index value to zero. Obtain the motion vector of the current block according to the MVP index and candidate list, This includes obtaining predicted sample values ​​for the current block according to the current block's motion vector. Example 2. The value of the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, sps level, or pps level, as in Example 1. Example 3. The candidate list is obtained based on at least one adjacent block adjacent to the current block, and a history-based motion vector predictor HMVP list, wherein at least one adjacent block is predicted using IBC mode, as in Example 1 or 2. Example 4. A coding method implemented by a decoding device, The goal is to obtain the maximum number of MVP candidates for the current block's motion vector prediction, where the current block is predicted using the Intrablock Copy IBC MVP mode. The motion vector of the current block is set to its default value when the current block's MVP index value is 1 and the value of the maximum number of MVP candidates for the current block is equal to 1. This includes obtaining predicted sample values ​​for the current block according to the current block's motion vector. Example 5. The value of the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, sps level, or pps level, as described in Example 4. Example 6. The default value is zero, as described in Example 4 or 5. Example 7. A coding method implemented by a decryption device, The goal is to obtain the maximum number of MVP candidates for the current block's motion vector prediction, where the current block is predicted using the Intrablock Copy IBC MVP mode. Obtaining a candidate list for the current block according to the history-based motion vector predictor HMVP list and at least one adjacent block adjacent to the current block, provided that the value of the maximum number of MVP candidates for the current block is equal to 1, wherein the candidate list for the current block includes 2 candidates and at least one adjacent block is predicted using IBC mode. Obtain the motion vector of the current block according to the current block's MVP index and candidate list, This includes obtaining predicted sample values ​​for the current block according to the current block's motion vector. Example 8. The value of the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, sps level, or pps level, as described in Example 7. Example 9. A decoder (30) including a processing circuit for carrying out the method described in any one of Examples 1 to 8. Example 10. A computer program product containing program code for performing the method described in any one of Examples 1-8. Example 11. One or more processors, A decoder comprising: a non-temporary computer-readable storage medium coupled to a processor and storing a program for execution by the processor, the program configuring the decoder to perform the method described in any one of Examples 1 to 8 when executed by the processor.

[0149] The following describes the application of the encoding and decoding methods shown in the above embodiment and the system using them. Figure 8 is a block diagram of a content supply system 3100 for realizing a content distribution service. This content supply system 3100 includes a capture device 3102 and a terminal device 3106, and optionally includes a display 3126. The capture device 3102 communicates with the terminal device 3106 via a communication link 3104. The communication link may include the communication channel 13 described above. The communication link 3104 includes, but is not limited to, WIFI, Ethernet, cable, wireless (3G / 4G / 5G), USB, or any combination thereof.

[0150] The capture device 3102 may generate data and encode the data using the encoding method shown in the embodiments described above. Alternatively, the capture device 3102 may distribute the data to a streaming server (not shown), which encodes the data and transmits the encoded data to the terminal device 3106. The capture device 3102 includes, but is not limited to, a camera, a smartphone or tablet, a computer or laptop, a video conferencing system, a PDA, an in-vehicle device, or any combination thereof. For example, the capture device 3102 may include the source device 12 as described above. If the data includes video, the video encoder 20 included in the capture device 3102 can actually perform the video encoding process. If the data includes audio (i.e., speech), the audio encoder included in the capture device 3102 can actually perform the audio encoding process. In some practical scenarios, the capture device 3102 distributes the encoded video and audio data by multiplexing them together. In other practical scenarios, such as a video conferencing system, the encoded audio data and encoded video data are not multiplexed. The capture device 3102 distributes the encoded audio data and encoded video data separately to the terminal device 3106.

[0151] In the content supply system 3100, the terminal device 310 receives and plays back encoded data. The terminal device 3106 can be a device capable of receiving and recovering data and decoding the aforementioned encoded data, such as a smartphone or Pad 3108, a computer or laptop 3110, a network video recorder (NVR) / digital video recorder (DVR) 3112, a TV 3114, a set-top box 3116, a video conferencing system 3118, a video surveillance system 3120, a personal digital assistant (PDA) 3122, an in-vehicle device 3124, or any combination thereof. For example, the capture device 3106 may include the source device 14 as described above. If the encoded data includes video, the video decoder 30 included in the terminal device is prioritized to perform video decoding. If the encoded data includes audio, the audio decoder included in the terminal device is prioritized to perform audio decoding.

[0152] In terminal devices with a display, such as a smartphone or tablet 3108, a computer or laptop 3110, a network video recorder / digital video recorder 3112, a TV 3114, a personal digital assistant 3122, or a vehicle-mounted device 3124, the terminal device can supply the decoded data to its display. In devices without a display, such as an STB 3116, a video conferencing system 3118, or a video surveillance system 3120, an external display 3126 is made contact thereto to receive and display the decoded data. When each device in this system performs encoding or decoding, a picture encoding device or a picture decoding device can be used, as shown in the embodiments described above. Figure 9 shows an example configuration of terminal device 3106. After terminal device 3106 receives a stream from capture device 3102, protocol progress unit 3202 analyzes the transmission protocol of the stream. This protocol includes, but is not limited to, the Real-Time Streaming Protocol (RTSP), Hypertext Transfer Protocol (HTTP), HTTP Live Streaming Protocol (HLS), MPEG-DASH, Real-Time Transport Protocol (RTP), Real-Time Messaging Protocol (RTMP), or any combination thereof. After the protocol processing unit 3202 processes the stream, a stream file is generated. The file is output to the demultiplexing unit 3204. The demultiplexing unit 3204 can separate the multiplexed data into encoded audio data and encoded video data. As described above, in some practical scenarios, for example, in a video conferencing system, the encoded audio data and encoded video data are not multiplexed. In this situation, the encoded data is sent to the video decoder 3206 and audio decoder 3208 without going through the demultiplexing unit 3204.

[0153] Through demultiplexing, a video elemental stream (ES), an audio ES, and optionally subtitles are generated. A video decoder 3206, including the video decoder 30 described in the above embodiment, decodes the video ES by the decoding method shown in the above embodiment to generate video frames and transmits this data to the synchronization unit 3212. An audio decoder 3208 decodes the audio ES to generate audio frames and transmits this data to the synchronization unit 3212. Alternatively, video frames may be stored in a buffer (not shown in Figure 9) before being supplied to the synchronization unit 3212. Alternatively, audio frames may be stored in a buffer (not shown in Figure 9) before being supplied to the synchronization unit 3212. The synchronization unit 3212 synchronizes the video frames and audio frames and supplies video / audio to the video / audio display 3214. For example, the synchronization unit 3212 synchronizes the presentation of video information and audio information. The information can be coded using a syntax with timestamps relating to the presentation of encoded audio and visual data and timestamps relating to the delivery of the data stream itself. If subtitles are included in the stream, the subtitle decoder 3210 decodes the subtitles, synchronizes them with the video and audio frames, and supplies the video / audio / subtitle to the video / audio / subtitle display 3216. The present invention is not limited to the system described above, and either the picture encoding device or the picture decoding device in the above embodiments can be incorporated into other systems, such as automotive systems.

[0154] Mathematical operators The mathematical operators used in this application are similar to those used in the C programming language. However, the results of integer division and arithmetic shift operations are more precisely defined, and additional operations such as exponentiation and real-valued division are defined. Numbering and counting rules generally start from 0. For example, "1st" is equivalent to 0, "2nd" is equivalent to 1, and so on.

[0155] Arithmetic operators The following arithmetic operators are defined as follows: + Addition - Subtraction (as a two-argument operator) or negation (as a unary prefix operator) * Multiplication including matrix multiplication x y Exponentiation. Specifies the exponent of x, or the power of y. In other contexts, such notation is used as a superscript not intended to be interpreted as an exponentiation. Integer division where the result is truncated towards zero. For example, 7 / 4 and -7 / -4 are truncated to 1, and -7 / 4 and 7 / -4 are truncated to -1. The division symbol (÷) is used to indicate division in mathematical expressions where rounding or truncation is not intended.

[0156]

number

[0157]

number

[0158] Logical operators The following logical operators are defined as follows: x&&y: Boolean logic "and" for x and y Boolean logic "or" for x||yx and y ! Boolean logic "negation" If x?y:zx is not TRUE or 0, it is evaluated using the value of y; otherwise, it is evaluated using the value of z.

[0159] Relational operators The following relational operators are defined as follows: > larger >= Above < smaller than <= less than or equal to == equal to != not equal to When a relational operator is applied to a syntax element or variable to which the value "na" (not applicable) is assigned, the value "na" is treated as a non-duplicate value of that syntax element or variable. The value "na" is considered not equal to other values.

[0160] Bitwise operators The following bitwise operators are defined as follows. & Bitwise "and". When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on a binary argument that contains fewer bits than another argument, the shorter argument is extended by adding bits equal to 0 at the higher bits. | Bitwise "or". When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on a binary argument that contains fewer bits than another argument, the shorter argument is extended by adding bits equal to 0 at the higher bits. ^ Bitwise "exclusive or". When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on a binary argument that contains fewer bits than another argument, the shorter argument is extended by adding bits equal to 0 at the higher bits. x>>y x is the arithmetic right shift of the two's complement integer representation of y binary digits. This function is defined only for non-negative integer values of y. The bit shifted into the most significant bit (MSB) as a result of the right shift has a value equal to the MSB of x before the shift operation. x<<y x is the arithmetic left shift of the two's complement integer representation of y binary digits. This function is defined only for non-negative integer values of y. The bit shifted into the least significant bit (LSB) as a result of the left shift has a value equal to 0.

[0161] Assignment operators The following assignment operators are defined as follows. = Assignment operator ++ Increment, i.e., x++ is equivalent to x = x + 1, and when used as an array index, it is evaluated with the value of the variable before the increment operation. -- Decrement, i.e., x-- is equivalent to x = x - 1, and when used as an array index, it is evaluated with the value of the variable before the decrement operation. += Increment by the specified amount, i.e., x += 3 is equivalent to x = x + 3, and x += (-3) is equivalent to x = x + (-3). -= Decrement by the specified amount, i.e., x -= 3 is equivalent to x = x - 3, and x -= (-3) is equivalent to x = x - (-3).

[0162] Range notation To specify a range of values, the following notation is used. x = y..z x takes integer values from y to z, where x, y, and z are integers and z is greater than y.

[0163] Mathematical functions The following mathematical functions are defined.

[0164]

Number

[0165]

Number

[0166]

number

[0167]

number

[0168]

number

[0169]

number

[0170] Priority ranking of operations If the precedence of an expression is not explicitly indicated using parentheses, the following rules apply: - Higher-priority operations are evaluated before lower-priority operations. - Operations with the same priority are evaluated sequentially from left to right. The table below specifies the order of operations from highest to lowest, with higher positions in the table indicating higher priority. For these operators, which are also used in the C programming language, the precedence used herein is the same as that used in the C programming language.

[0171] [Table 7] Table: Operation priorities from highest (top of the table) to lowest (bottom of the table)

[0172] Text description of logical operations In this text, the description of logical operations mathematically described in the following format

[0173]

Number

[0174]

Number

[0175]

Number

[0176]

Number

[0177]

number

[0178]

number

[0179] For example, but not limited to, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage or other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Any connection may also be appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other temporary media, but instead refer to non-temporary, tangible storage media. As used herein, discs include compact discs (CDs), laser discs, optical discs, digital multipurpose discs (DVDs), floppy disks, and Blu-ray discs, which typically reproduce data magnetically and optically using lasers. The above combinations should also be included in the scope of computer-readable media.

[0180] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term “processor” as used herein may refer to any of the aforementioned structures or other structures suitable for implementing the technology described herein. Additionally, in some embodiments, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a combined codec. Furthermore, this technology can be fully implemented with one or more circuits or logic elements.

[0181] The technology of this disclosure may be implemented in a wide range of devices or apparatus, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to highlight the functional aspects of devices configured to perform the disclosed technology, but implementation by different hardware units is not necessarily required. Rather, as described above, the various units may be combined within a codec hardware unit, or they may be provided by a set of interoperable hardware units, including one or more processors as described above, together with appropriate software and / or firmware.

Claims

1. A coding method implemented by a decoding device, The method involves performing entropy decoding on a bitstream to obtain the maximum number of values ​​for merging motion vector prediction (MVP) candidates for the current block, wherein the current block is predicted using intrablock copy (IBC) mode. The value of mvp_l0_flag[x0][y0] is set to zero when the value of the maximum number of MVP candidates in the current block is equal to 1, wherein mvp_l0_flag[x0][y0] specifies the motion vector predictor index of list 0, x0, y0 specifies the position (x0, y0) of the top-left luma sample of the coding block relative to the top-left luma sample of the picture, and the value of mvp_l0_flag[x0][y0] is not parsed from the bitstream. Obtain the motion vector of the current block according to the mvp_l0_flag[x0][y0] and the candidate list, A method comprising obtaining a predicted sample value of the current block according to the motion vector of the current block.

2. The method according to claim 1, wherein the mvp_l0_flag[x0][y0] is analyzed from the coding unit level.

3. The method according to claim 1, wherein the value of the maximum number of MVP candidates for the current block is obtained by analyzing the sequence parameter set (sps) level from the bitstream.

4. The method according to claim 1, wherein the value of the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, or picture parameter set (pps) level.

5. The method according to claim 1, wherein the candidate list is obtained according to at least one adjacent block adjacent to the current block and a history-based motion vector predictor (HMVP) list, the at least one adjacent block is predicted using IBC mode.

6. It is a decoder, One or more processors, The system includes a computer-readable storage medium coupled to one or more processors and storing a program for execution by the one or more processors, wherein the program, when executed by the one or more processors, The method involves performing entropy decoding on a bitstream to obtain the maximum number of values ​​for merging motion vector prediction (MVP) candidates for the current block, wherein the current block is predicted using intrablock copy (IBC) mode. The value of mvp_l0_flag[x0][y0] is set to zero when the value of the maximum number of MVP candidates in the current block is equal to 1, wherein mvp_l0_flag[x0][y0] specifies the motion vector predictor index of list 0, x0, y0 specifies the position (x0, y0) of the top-left luma sample of the coding block relative to the top-left luma sample of the picture, and the value of mvp_l0_flag[x0][y0] is not parsed from the bitstream. Obtain the motion vector of the current block according to the mvp_l0_flag[x0][y0] and the candidate list, A decoder configured to perform the operation of obtaining a predicted sample value of the current block according to the motion vector of the current block.

7. The decoder according to claim 6, wherein the mvp_l0_flag[x0][y0] is analyzed from the coding unit level.

8. The decoder according to claim 6, wherein the value of the maximum number of MVP candidates in the current block is obtained by analyzing the sequence parameter set (sps) level from the bitstream.

9. The decoder according to claim 6, wherein the value of the maximum number of MVP candidates for the current block is obtained by parsing syntactic elements from the bitstream at the slice level, tile group level, or picture parameter set (pps) level.

10. The decoder according to claim 6, wherein the candidate list is obtained according to at least one adjacent block adjacent to the current block and a history-based motion vector predictor (HMVP) list, the at least one adjacent block being predicted using IBC mode.

11. A decoder including a processing circuit for carrying out the method according to any one of claims 1 to 5.

12. A device for storing a bitstream of video or images, comprising a communication interface, a processor, and a storage medium, wherein the communication interface is configured to receive and / or transmit the bitstream, the storage medium is configured to store the bitstream, and the processor is The method involves performing entropy decoding on a bitstream to obtain the maximum number of values ​​for merging motion vector prediction (MVP) candidates for the current block, wherein the current block is predicted using intrablock copy (IBC) mode. The value of mvp_l0_flag[x0][y0] is set to zero when the value of the maximum number of MVP candidates in the current block is equal to 1, wherein mvp_l0_flag[x0][y0] specifies the motion vector predictor index of list 0, x0, y0 specifies the position (x0, y0) of the top-left luma sample of the coding block relative to the top-left luma sample of the picture, and the value of mvp_l0_flag[x0][y0] is not parsed from the bitstream. Obtain the motion vector of the current block according to the mvp_l0_flag[x0][y0] and the candidate list, A device that obtains predicted sample values ​​of the current block according to the motion vector of the current block.

Images