Video image data encoding / decoding

Abstract

【Solution】The present application relates to the prediction of blocks of a video image including signaling the type of the intra block copy mode, where the type indicates whether the intra block copy prediction mode is set to predict video content captured by a camera, and when the type of the intra block copy mode indicates that the intra block copy prediction mode is set to predict video content captured by a camera, set the intra block copy prediction mode to predict blocks of the video image, and derive a predicted block of the block of the video image based on the set intra block copy mode prediction mode.

Description

Technical Field

[0001] This application generally relates to the encoding and decoding of video images. Specifically and non-exclusively, the technical field of this application relates to the prediction of blocks of video images based on intra-block copy.

Background Art

[0002] This section aims to introduce various aspects of the art to the reader, and these aspects are related to each aspect of at least one exemplary embodiment of this application described below and / or claimed for protection. This description is considered useful in providing background information to the reader to better understand various aspects of this application. Therefore, these techniques do not admit prior art and should be read from the above perspective.

[0003] In state-of-the-art video compression systems such as HEVC (ISO / IEC 23008-2 High Efficiency Video Coding, ITU-T Recommendation H.265, https: / / www.itu.int / rec / T-REC-H.265-202108-P / en) or VVC (ISO / IEC 23090-3 Versatile Video Coding, ITU-T Recommendation H.266, https: / / www.itu.int / rec / T-REC-H.266-202008-I / en), low-level and high-level image partitions are provided to divide video images into image regions called coding tree units (CTUs). In the case of HEVC, the size of the coding tree unit (CTU) is usually between 16×16 pixels and 64×64 pixels. In the case of VVC, the size of the coding tree unit (CTU) may be 32×32, 64×64 or 128×128 pixels.

[0004] The CTU partitioning of video images forms a grid of fixed-size CTUs, i.e., a CTU grid, whose upper and left boundaries spatially overlap with the upper and left boundaries of the video image. The CTU grid represents the spatial partitioning of the video image.

[0005] In VVC and HEVC, the CTU size (CTU width and CTU height) of all CTUs in a CTU grid is equal to the same default CTU size (default CTU width CTU DW and default CTU height CTU DH). For example, the default CTU size (default CTU height, default CTU width) may be 128 (CTU DW = CTU DH = 128). The default CTU size (height, width) is encoded into a bitstream, which is then encoded into a sequence level in a sequence parameter set (SPS), for example.

[0006] The spatial position of a CTU within a CTU grid is determined based on the CTU address ctuAddr, which defines the spatial position of the CTU from the origin at its upper-left corner. As shown in Figure 1, the CTU address can define the spatial position of the CTU from the upper-left corner of the higher-level spatial structure S containing the CTU.

[0007] The encoding tree is associated with each CTU and determines the tree partitioning of the CTU.

[0008] As shown in Figure 1, in HEVC, the coding tree is a quadtree partition of CTUs, and each leaf is called a coding unit (CU). The spatial location of a CU in a video image is defined by the CU index cuIdx, which indicates the spatial location from the upper-left corner of the CTU. A CU is spatially divided into one or more prediction units (PUs). The spatial location of a PU in a video image VP is defined by the PU index puIdx, which defines the spatial location from the upper-left corner of the CTU, and the spatial location of the elements of a partitioned PU is defined by the PU partition index puPartIdx, which defines the spatial location from the upper-left corner of the PU. Each PU is assigned some intra or inter-prediction data.

[0009] The intra- or inter-coding mode is assigned at the CU level. This means that the same intra / inter-coding mode is assigned to each PU of the CU, even though the prediction parameters differ among the PUs.

[0010] Based on a quadtree called a transformation tree, a CU can be spatially divided into one or more transformation units (TUs). A transformation unit is a leaf of the transformation tree. The spatial position of a TU in a video image is defined by the TU index tuIdx, which defines the spatial position from the upper-left corner of the CU. Several transformation parameters are assigned to each TU. A transformation type is assigned at the TU level, and a 2D single transformation is performed at the TU level during the encoding or decoding period of the image block.

[0011] The PU partition types present in HEVC are shown in Figure 2. They include square partitions (2N×2N and N×N), which are the only partitions used in both intra-predictive CUs and inter-predictive CUs; ​​symmetric non-square partitions (2N×N, N×2N, used only in inter-predictive CUs); and asymmetric partitions (used only in inter-predictive CUs). For example, PU type 2N×nU represents an asymmetric horizontal partition of the PU, with the smaller partition located at the top of the PU. In another example, PU type 2N×nL represents an asymmetric horizontal partition of the PU, with the smaller partition located at the top of the PU.

[0012] As shown in Figure 3, in VVC, the coding tree begins with the root node (i.e., CTU). The quadtree (or quad-tree) partition then divides the root node into four nodes corresponding to four subblocks of the same size (solid lines). Subsequently, the leaves of the quadtree (or quad-tree) can be further partitioned by so-called multi-type trees, which relate to one of the four partitioning modes shown in Figure 4, either binary or ternary. These partitioning types are the vertical and horizontal binary partitioning modes denoted as SBTV and SBTH, and the vertical and horizontal ternary partitioning modes SPTTV and STTH.

[0013] In the case of a co-encoded tree where the luma and chroma components are shared, the leaf of the CTU's encoding tree is the CU.

[0014] In contrast to HEVC, in VVC, the CU, PU, ​​and TU are almost always the same size, and except for some specific encoding modes, the encoding unit is generally not divided into PU or TU.

[0015] Figures 5 and 6 provide an overview of the video encoding / decoding methods used in current video standard compression systems (e.g., HEVC or VVC).

[0016] Figure 5 shows an illustrative block diagram of the steps of method 100 for encoding a video image VP based on prior art.

[0017] In step 110, the video image VP is divided into sample blocks, and the division information data is signaled to the bitstream. Each block contains a sample of one component of the video image VP. Therefore, these blocks contain samples of each component that defines the video image VP.

[0018] For example, in HEVC, an image is divided into coding tree units (CTUs). Each CTU can be further divided into quadtree subdivisions, where each leaf of the quadtree represents a coding unit (CU). The division information data may include data describing the CTUs and the quadtree subdivisions of each CTU.

[0019] Subsequently, each sample block (abbreviated as block) may be a CU (if the CU contains a single PU) or a PU of a CU.

[0020] Each block is encoded along the coding loop (also called "in-loop") using intra or inter-prediction mode.

[0021] Intra-prediction (step 120) uses intra-prediction data. Intra-prediction predicts the current block using intra-prediction blocks based on already encoded, decoded, and reconstructed samples located around the current block (typically at the top and left of the current block). Intra-prediction is performed in the spatial domain.

[0022] In inter-prediction mode, motion estimation (step 130) and motion compensation (135) are performed. Motion estimation searches for candidate reference blocks that can serve as good predictors for the current block in one or more reference video images that predictively encode the current video image. For example, a good predictor for the current block is a predictor similar to the current block. The output of motion estimation step 130 is inter-prediction data that includes motion information associated with the current block (typically one or more motion vectors and one or more reference video image indices) and other information for obtaining the same predicted block on the encoding / decoding side. Subsequently, motion compensation (step 135) obtains a predicted block using the (one or more) motion vectors and (one or more) reference video image indices determined in motion estimation step 130. Essentially, any block belonging to the selected reference video images and pointed to by the motion vectors is available as a predicted block for the current block. Furthermore, because motion vectors are represented as fractions of integer pixel positions (known as subpixel MV precision representation), motion compensation typically involves spatial interpolation of several reconstructed samples of the reference video image to compute the predicted block.

[0023] Prediction information data is signaled to the bitstream. The prediction information may include the prediction mode (intra, inter, or skip), intra / inter prediction data, and any other information necessary to obtain the same prediction CU on the decoding side.

[0024] Method 100 selects a prediction mode (intra or inter-prediction mode) by optimizing the rate-distortion trade-off, for example, by considering the encoding of prediction residual blocks calculated by subtracting candidate prediction blocks from the current block, and the signaling of prediction information data necessary to determine the candidate prediction blocks on the decoding side.

[0025] Generally, the best prediction mode is given as follows as the prediction mode of the best encoding mode p* for the current block.

[0026]

Number

[0027] Here, P is the set of all candidate encoding modes of the current block, p is a candidate encoding mode in the set, and RD cost (p) is the rate-distortion cost of the candidate encoding mode p, and is usually shown as follows. RD cost (p)=D(p)+λ.R(p)

[0028] D(p) is the distortion between the current block and the reconstructed block obtained by encoding / decoding the current block using the candidate encoding mode p, R(p) is the rate cost associated with the encoding of the current block by the encoding mode p, λ is the Lagrange parameter representing the rate constraint for encoding the current block, and is generally calculated based on the quantization parameter for encoding the current block.

[0029] Generally, the current block is encoded based on the prediction residual block PR. More precisely, for example, the prediction residual block PR is calculated by subtracting the best prediction block from the current block. Then, for example, a transformation of the DCT (Discrete Cosine Transform) or DST (Discrete Sine Transform) type or any other suitable transformation is used to transform the prediction residual block PR (step 140), and the obtained transform coefficient block is quantized (step 150).

[0030] In a variant, method 100 can skip the transformation step 140, skip the encoding mode by so-called transformation, and directly apply quantization (step 150) to the prediction residual block PR.

[0031] The quantized transformation coefficient block (or quantized prediction residual block) is entropy-encoded into a bitstream (step 160).

[0032] Next, as part of the coding loop, the quantized transformation coefficient block (or quantized residual block) is subjected to inverse quantization (step 170) and inverse transformation (180) (or not inversely transformed) to generate a decoded predicted residual block. The decoded predicted residual block and the predicted block are then combined and usually summed, which provides the reconstructed block.

[0033] Furthermore, other informational data may be entropically encoded in step 160 to encode the current block of the video image VP.

[0034] Artifacts can be reduced by applying an intra-loop filter (step 190) to the reconstructed image (including the reconstructed blocks). After all image blocks have been reconstructed, a loop filter can be applied. These include, for example, a deblocking filter, a sample self-adaptive offset (SAO), or a self-adaptive loop filter.

[0035] The reconstructed block or filtered reconstructed block is formed as a reference image, which can be stored in a decoded image buffer (DPB), so that it can be used as the next current block of the video image VP or as the encoded reference image of the next video image to be encoded.

[0036] Figure 6 shows an exemplary block diagram of the steps of method 200 for decoding a video image VP based on the prior art.

[0037] In step 210, the bitstream of encoded video image data is entropy-decoded to obtain segmentation information data, prediction information data, and quantized transformation coefficient blocks (or quantized residual blocks). For example, this bitstream is generated based on method 100.

[0038] By entropy decoding other information data, it is also possible to decode the current block of the video image VP from the bitstream.

[0039] In step 220, the reconstructed image is divided into current blocks based on the division information. Each current block is entropy-decoded from the bitstream along the decoding loop (also called "in the loop"). Each decoded current block is either a quantized transformation coefficient block or a quantized prediction residual block.

[0040] In step 230, the current block is dequantized and, if applicable, the inverse transform (step 240) is performed to obtain the decoded predicted residual block.

[0041] On the other hand, the prediction information data is used to predict the current block. The predicted block is obtained by its intra-prediction (step 250) or motion-compensated time prediction (step 260). The prediction process performed on the decoding side is the same as the prediction process performed on the encoding side.

[0042] Next, the decoded prediction residual blocks and prediction blocks are merged and usually summed, which provides the blocks for reconstruction.

[0043] In step 270, the intra-loop filter is applicable to the reconstructed image (including the reconstructed blocks), and the reconstructed blocks or filtered reconstructed blocks are formed as a reference image, which can be stored in the decoded image buffer (DPB) described above (Figure 5).

[0044] In steps 130 / 135 of Figure 5 or step 260 of Figure 6, an interprediction block is defined from interprediction data associated with the current block (CU or PU of CU) of the video image. This interprediction data contains motion information that can be displayed (encoded) based on so-called AMVP mode (self-adaptive motion vector prediction) or so-called merge mode.

[0045] In HEVC, in AMVP mode, motion information for defining an interprediction block is represented by up to two reference video image indices, each associated with up to two reference video image lists (typically represented as L0 and L1). Reference video image list L0 contains at least one reference video image, and reference video image list L1 contains at least one reference video image. Each reference video image index is a time prediction for the current block. The motion information further includes up to two motion vectors, each motion vector associated with one reference video image index from the two reference video image lists. Each motion vector is predictively encoded and signaled to the bitstream; that is, a motion vector difference MVd is derived from the motion vectors, one AMVP (self-adaptive motion vector predictor) candidate is selected from an AMVP candidate list (constructed on the encoding and decoding side), and the MVd is signaled to the bitstream. The AMVP candidate index of the AMVP candidate selected from the AMVP candidate list is similarly signaled to the bitstream.

[0046] Figure 7 shows an illustrative example of constructing an AMVP candidate list, which is used to define the interpretation block of the current block of the current video image.

[0047] The AMVP candidate list may include two spatial MVP (motion vector predictor) candidates derived from the current video image. The first spatial MVP candidate is derived from motion information associated with the interprediction block of the current block and, if present, is located at adjacent positions A0, A1 to the left of the current block. The second MVP candidate is derived from motion information associated with the interprediction block of the current block and, if present, is located at adjacent positions B0, B1, and B2 at the top of the current block. Then, a redundancy check is performed among the derived spatial MVP candidates, i.e., duplicate derived MVP candidates are discarded. The AMVP candidate list may further include a temporal MVP candidate, which is derived from motion information associated with a co-located block (if present) at spatial position H or, in other cases, spatial position C in the reference video image. The temporal MVP candidate is scaled based on the temporal distance between the current video image and the reference video image. Finally, if the AMVP candidate list contains fewer than two MVP candidates, the AMVP candidate list is filled with zero motion vectors.

[0048] In HEVC, in merge mode, motion information for defining interpretation blocks is represented by a single merge index that merges the MVP candidate list. Each merge index points to motion predictor information that indicates which MVP to use to derive motion information. Motion information is represented by one unidirectional or bidirectional time prediction type, up to two reference video image indices, and up to two motion vectors, with each motion vector associated with one of two reference video image lists (L0 or L1).

[0049] No information other than the merge index is signaled. This means that the motion vector of the current block is equal to the motion vector of the MVP candidate indicated by the merge index. Therefore, contrary to the merge mode, the MVd and reference image index are not signaled to the bitstream. In the bitstream, only the index of the merge candidate selected from the merge candidate list is signaled.

[0050] Therefore, unlike AMVP mode, in merge mode, the MVd and reference images are not signaled. Only the merge index is signaled to the bitstream.

[0051] The merged MVP candidate list may contain five spatial MVP candidates, which are derived from the current video image shown in Figure 7. The first spatial MVP candidate is derived from motion information associated with the interprediction block and, if present, is located at the left adjacent position A1; the second spatial MVP candidate is derived from motion information associated with the interprediction block and, if present, is located at the upper adjacent position B1; the third spatial MVP candidate is derived from motion information associated with the interprediction block and, if present, is located at the upper right adjacent position B0; the fourth spatial MVP candidate is derived from motion information associated with the interprediction block and, if present, is located at the lower left adjacent position A0; and the fifth spatial MVP candidate is derived from the above motion associated with the interprediction block and, if present, is located at the left adjacent position B2. Subsequently, a redundancy check is performed among the derived spatial MVPs, i.e., duplicate derived MVP candidates are discarded. The merge candidate list may further include time MVP candidates called TMVP candidates, which are derived from motion information associated with a collated block (if any) located at position H of the reference video image or central spatial position "C". Then, a redundancy check is performed among the derived spatial MVPs, i.e., duplicate derived MVP candidates are discarded. Finally, if a bidirectional time prediction type is used, and the merge candidate list contains fewer than five MVP candidates, a merge candidate is added to the merge candidate list. The merge candidate is derived from the motion information of one MVP candidate associated with one reference video image list and present in the merge candidate list, and the motion information corresponds to another MVP candidate associated with another reference video image list and present in the merge candidate list. Finally, if the merge candidate list is still not filled (with five merge candidates), the merge candidate list is filled with zero motion vectors.

[0052] In ECM ("Description of the Algorithm of Extended Compression Model 4 (ECM 4)", M. Coban, F. Le Leannec, K. Naser, J. Strom, Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29, 23rd Meeting, Teleconference, July 7-16, 2021, Document JVET-Y202-v2, https: / / jvet-experts.org / doc_end_user / documents / 25_Teleconference / wg11 / JVET-Y2025-v2.zip), the template matching (TM) method may be used to determine several MVP candidates in AMVP and merge mode. The TM method is a method for refining the motion vector on the decoder side. It refines the motion vector of a block by matching the template regions above and to the left of the current block with the template in the search region of the reference image, as shown in Figure 8. Search for a more suitable MV around the initial MV of the current block, for example, within a [-8, +8] pixel search range. Obtain the refined MV by minimizing the so-called template matching cost (TMcost) between the template around the current block and the candidate template in the reference video image. Select the MVP candidate with the lowest template matching cost and refine it further.

[0053] Encoding motion information according to VVC allows for the representation of richer motion information than HEVC encoding.

[0054] VVC can provide motion representation based on AMVP mode or merge mode.

[0055] In VVC, motion information for defining interpretation blocks in AMVP mode is represented similarly to HEVC AMVP mode. If present, the AMVP candidate list may include MVP candidates in space and time, similar to HEVC. If present, the AMVP candidate list may further include four additional HMVP (History-Based Motion Vector Prediction) candidates. Finally, if the AMVP candidate list contains fewer than two MVP candidates, the AMVP candidate list is filled with zero motion vectors.

[0056] HMVP candidates are derived from previously encoded MVPs of adjacent or non-adjacent blocks associated with the current block. Therefore, both the encoder and decoder maintain an HMVP candidate table, updating it in real-time as a first-in, first-out (FIFO) buffer for MVPs. The table contains a maximum of five HMVP candidates. After encoding a block, the table is updated with new HMVP candidates by appending the relevant motion information to the end of the table. FIFO rules are applied to manage the table; in addition to the basic FIFO mechanism, redundant candidates in the HMVP table are removed first, rather than the first candidate. The table is reset at each CTU row to enable parallel processing.

[0057] AMVP mode employs the AMVR (Self-Adaptive Motion Vector Resolution) algorithm. The AMVR tool can signal MVd with luminance sample resolutions of 1 / 4 pixel, 1 / 2 pixel, integer pixels, or 4 pixels. This allows for bit saving when encoding MVd information. In AMVR, the resolution of the motion vector is selected at the block level.

[0058] Finally, the internal motion vector representation is implemented with a sampling accuracy of 1 / 16 luminance, rather than the 1 / 4 luminance sampling accuracy used in HEVC.

[0059] In VVC, motion information for defining interprediction blocks in merge mode is represented in a similar way to HEVC merge mode.

[0060] The merge candidate list is different from the merge candidate list used in HEVC.

[0061] In VVC, both MMVD (Merge Mode with MV Difference) and CIIP (Composite Intra / Inter Prediction) modes can establish a list of merge candidates.

[0062] The MMVD mode can represent motion information associated with interprediction blocks by encoding a limited motion vector difference (MVd) in selected merge candidates. MMVD encoding is limited to four vector directions, eight amplitude values, and 1 / 4 luminance samples to 32 luminance samples, as shown in Figure 9. Because the MMVD mode provides an intermediate level of accuracy, motion information can be signaled by making an intermediate trade-off between rate cost and MV (motion vector) accuracy. The MMVD offset can also be signaled to the bitstream. The motion vector is then derived by adding the MV predictor to the MMVD offset.

[0063] CIIP predicts the current block of a video image by combining inter-prediction signals and intra-prediction signals. The inter-prediction signal in CIIP mode is derived using a prediction process similar to that applied to merge mode. The intra-prediction signal is derived according to the normal intra-prediction process with a planar mode. Planar prediction mode predicts blocks through a spatial interpolation process of the top of the block and adjacent reconstructed samples of the predicted block to its left. The intra and inter-prediction signals are then blended (combined) using a weighted average, where the weights are calculated based on the encoding modes of the top and adjacent blocks to the left, as follows: PCIIP=(Wmerge×Pmerge+Wintra×Pintra+2)≫2 Weight W merge and W intra The sum of these is 4, and these weights are constant throughout the current block.

[0064] In short, in VVC, the merge candidate list may contain spatial MVP candidates similar to those in HEVC, with only the two first candidates swapped. Candidate B1 is considered before candidate A1 while constructing the merge candidate list. The merge candidate list may also contain TMVPs, such as HEVC and HMVP candidates in VVC AMVP mode. Several HMVP candidates are inserted into the merge candidate list so that it reaches the maximum allowed number of MVP candidates (-1). The merge candidate list may further contain average candidates that form at most one pair, calculated as follows: Consider the two first merge candidates present in the merge candidate list and average their motion vectors. This average is calculated for each reference video image list L0 and L1, respectively. Thus, if both MVPs are bidirectional, the motion vectors associated with the two lists L0 and L1 are averaged. If a reference video image list has only one motion vector, that is taken as is, and a pair of candidates is formed. Finally, if the merge candidate list does not reach the maximum allowed number of MVP candidates, fill the merge candidate list with zero-motion vectors.

[0065] HEVC and VVC encode screen content using intra-block copy (IBC) prediction mode. IBC prediction mode is known to significantly improve the encoding efficiency of screen content material. Since IBC prediction mode is implemented as a block-level encoding mode, block matching (BM) is performed in the encoder to find the optimal block vector (or motion vector) for each block to be predicted. The block vector indicates the displacement from the block to be predicted in the video image to the reference block, which has already been reconstructed (decoded) within the video image. The block vector of the IBC prediction block for luminance samples has integer precision. The block vector of the IBC prediction block for saturation samples can also be rounded to integer precision. When merged with AMVR, IBC prediction mode can be switched between 1-pixel and 4-pixel motion vector precision. IBC prediction mode is considered a third prediction mode other than intra or inter-prediction mode.

[0066] At the CU level, the IBC prediction mode is signaled by a flag indicating that either IBC-AMVP mode or IBC-Skip / Merge mode is being used.

[0067] In IBC-skip / merge mode, the block vector for defining an IBC predicted block is indicated by a merge index in the merge candidate list. The merge index points to the block vector in the merge candidate list. The merge candidate list may include spatial candidates, HMVP candidates, and paired candidates. Obtaining HMVP (History-Based Motion Vector Prediction) candidate block vector predictors is the same as in conventional intermerge coding. HMVP includes a buffer of motion vector predictors, which is provided when an encoding unit encodes a given image in IBC mode. The HMVP buffer further includes a block vector buffer for encoding or decoding in IBC mode, providing candidates for predicting the block vector of the current encoding unit.

[0068] By averaging two IBC merge candidates, a new pair of IBC merge candidates can be formed. This means averaging two first block vector candidates in the constructed merge list to form a so-called pair of block vector prediction candidates for the block to be predicted. This pair of candidates is added to the IBC merge candidate list and placed after the HMVP candidates.

[0069] For HMVP, the block vector is inserted into the history buffer for future citation.

[0070] In IBC-AMVP mode, two block vector predictors are determined: one from the adjacent region to the left of the block to be predicted, and the other from the adjacent region above the block to be predicted (if an IBC is predicted). If either adjacent region is unavailable, a default block vector predictor is considered. The block vector predictor index is indicated by signaling a flag. In practice, since up to two block vector prediction candidates are considered in IBC AMVP mode, the flag is sufficient to identify the block vector prediction candidate used to encode the block vector information of the coding unit. The block vector difference is encoded in a similar manner to the motion vector difference of the intercoding unit.

[0071] Furthermore, in ECM, the IBC-TM merge mode is defined as an IBC prediction mode that is combined with template matching. The IBC-TM merge list for the IBC-TM merge mode is different from the list used for the IBC skip / merge mode. In the normal TM merge mode, candidates are selected by pruning based on the distance moved between candidates. Zero-movement candidates are replaced with (-W, 0), (0, -H), and (-W, -H)MV.

[0072] In IBC-TM merge mode, a template matching method is used to refine the candidates to be selected. The TM-merge flag signals whether or not to use the template matching merge IBC mode.

[0073] In IBC-TM AMVP mode, up to three candidates are selected from the IBC-TM merge list. The IBC-TM merge list is a list of block vector prediction candidates for predicting the block vector of the block to be predicted. It is constructed from the blocks surrounding the current block to be predicted, which have already been encoded and / or decoded in IBC encoding mode. Each of these candidates is subdivided according to the usual template matching method, and these candidates are sorted according to the resulting TM cost. The TM cost is calculated as the distortion between the top and left template region of the current block to be predicted (in its decoded and reconstructed state) and the corresponding top and left region around the candidate prediction block pointed to by the candidate block vector.

[0074] When used in IBC prediction mode, TM subdivision is performed at integer pixel positions, and in IBC-TM AMVP mode, TM subdivision is performed with integer precision or 4-pixel precision based on AMVR values. Subdivision is performed within the existing IBC reference region.

[0075] The IBC prediction mode cannot be used in conjunction with VVC interpretation tools such as CIIP and MMVD.

[0076] In VVC, unlike the HEVC Screen Content Encoding Extension, the current video image is not included in reference image list 0 for IBC prediction as one of the reference images. The block vector derivation process in IBC mode eliminates all adjacent blocks in intermode, and vice versa.

[0077] In VVC, the IBC prediction mode shares the same process as the normal MV merge mode, including paired merge candidates and a history-based motion predictor, but TMVP and zero vectors are not used because they are invalid for the IBC prediction mode.

[0078] Individual HMVP buffers (five candidates per buffer) are used for conventional MV and IBC prediction modes.

[0079] On the other hand, current IBC prediction tool designs have shown that, from various perspectives, IBC designs are better suited to graphic and screen video content than to natural video content.

[0080] This limits the compression performance improvements that can be obtained when using IBC predictive mode with video content captured by a camera.

[0081] The objective of the present invention is to adapt the normative design of the IBC encoding mode and to significantly improve performance when compressing natural video while maintaining encoding performance at least for screen content.

[0082] The problem that this invention solves is to improve the compression efficiency when enabling IBC prediction mode in video content captured by a camera by adapting the IBC prediction mode defined in VVC, while maintaining the current IBC prediction mode performance in at least screen content and graphic content.

[0083] The conventional solution to the problem to be solved involves including the currently encoded or decoded video image in a reference image buffer (a so-called decoded image buffer, DPB) and using it to predict the time of blocks in the current video image.

[0084] Therefore, performance may be improved when encoding natural sequences in IBC prediction mode compared to VVC.

[0085] However, IBC predictive mode may degrade performance with screen and graphic content because motion representation and compensation are adapted to natural content but not to screen content.

[0086] Taking the above circumstances into consideration, we design at least one exemplary embodiment of the present invention. [Overview of the Initiative]

[0087] The following section provides a basic understanding of several aspects of the present application by presenting a simplified overview of at least one exemplary embodiment. This overview is not a detailed overview of the exemplary embodiment. It does not identify any essential or important elements of the exemplary embodiment. The following overview merely presents several aspects of at least one exemplary embodiment in a simplified form as a prelude to the more detailed explanation provided in other parts of the document.

[0088] According to a first aspect of the present invention, a method for predicting blocks of a video image is provided, the method comprising the steps of signaling an intrablock copy mode type, the intrablock copy mode type indicating whether an intrablock copy prediction mode is set to predict video content captured by a camera, the intrablock copy prediction mode determining at least one block vector for predicting blocks of a video image from at least one reference block of a video image, the intrablock copy prediction mode setting to predict blocks of a video image if the intrablock copy mode type indicates that an intrablock copy prediction mode is set to predict video content captured by a camera, and deriving predicted blocks of blocks of a video image based on the set intrablock copy mode prediction mode.

[0089] In one exemplary embodiment, a block belongs to a slice of a video image and signals the type of intra-block copy mode to enter at the slice level.

[0090] In one exemplary embodiment, setting an intrablock copy prediction mode to predict video content captured by a camera further includes signaling a syntactic element (ibc_pred_idc_flag) indicating whether bidirectional prediction is permitted, and, if the syntactic element indicates that bidirectional prediction is permitted, signaling two block vectors such that the prediction of a block of video image is the average of these two block vectors.

[0091] In one exemplary embodiment, setting an intrablock copy prediction mode to predict video content captured by a camera involves signaling a syntactic element (mvp_l1_flag) to identify a block vector predictor for each block vector in a list of block vectors associated with decoded blocks adjacent to a block of video image, further including that the adjacent block belongs to the video image.

[0092] In one exemplary embodiment, at least one block vector is represented at a sub-pixel precision level.

[0093] In one exemplary embodiment, setting an intrablock copy prediction mode to predict video content captured by a camera further includes signaling at least one block vector difference calculated between a block vector and a reference block within the video image, wherein each block vector difference is signaled at a subpixel precision level.

[0094] In one exemplary embodiment, setting an intrablock copy prediction mode to predict video content captured by a camera further includes the step of encoding each block vector difference, wherein the encoding is limited to a certain vector direction and width.

[0095] In one exemplary embodiment, setting the intrablock copy prediction mode to predict video content captured by a camera further includes signaling a syntactic element (mmvd_merge_flag) indicating whether the encoding of the block vector difference is limited to a certain vector direction and width (step 310).

[0096] In one exemplary embodiment, setting an intrablock copy prediction mode to predict video content captured by a camera further includes signaling a syntactic element (intra_tmp_flag) to indicate whether to derive predicted blocks of video image blocks using intrablock copy prediction based on template matching, or whether to derive predicted blocks of video image blocks based on a first embodiment.

[0097] In an exemplary embodiment, the step of deriving predicted blocks of video image blocks based on a set intrablock copy mode prediction mode includes the steps of: deriving a first predicted block of video image blocks from a set intrablock copy mode; deriving a second predicted block of video image blocks; and blending the first predicted block and the second predicted block to derive predicted blocks of video image blocks.

[0098] In one exemplary embodiment, the second prediction block is derived based on motion-compensated prediction or intra-prediction of blocks in the video image.

[0099] According to a second aspect of the present invention, a method is provided for encoding blocks of a video image based on predicted blocks derived from the method of the first aspect.

[0100] A third aspect of the present invention provides a method for decoding blocks of a video image based on predicted blocks derived from the method of the first aspect.

[0101] According to a fourth aspect of the present application, a bitstream formatted to include encoded video image data obtained from the method of the first aspect is provided.

[0102] According to a fifth aspect of the present application, an apparatus is provided which includes means for carrying out one of the methods of the first, second, and / or third aspects.

[0103] According to the sixth aspect of the present application, when the program is executed by one or more processors, the present invention provides a computer program product that includes instructions causing one or more processors to execute the methods according to the first, second and / or third aspects.

[0104] According to the seventh aspect of the present application, a non-temporary storage medium is provided for carrying program code instructions for executing the methods according to the first, second and / or third aspects.

[0105] The specific properties of at least one embodiment in the exemplary embodiment, as well as other purposes, advantages, features, and applications of said at least one embodiment in the exemplary embodiment, will become apparent from the description given to the example in conjunction with the following drawings. [Brief explanation of the drawing]

[0106] Here, by exemplary means, we refer to the drawings of exemplary embodiments of the application. [Figure 1] This is an example of a coded tree unit related to HEVC. [Figure 2] This is an example of splitting the coding unit into prediction units based on HEVC. [Figure 3] This is an example of CTU partitioning related to VVC. [Figure 4]This is an example of a partitioning mode supported by multi-type tree partitioning related to VVC. [Figure 5] This is a schematic block diagram of 100 steps for a method of encoding a video image VP based on prior art. [Figure 6] This is a schematic block diagram of the steps of method 200 for decoding video image VP based on prior art. [Figure 7] This is a descriptive example for constructing an AMVP candidate list, defining the interpretation block of the current block of the current video image. [Figure 8] This is an example of a template matching method related to conventional technology. [Figure 9] This is an example of a limited motion vector difference related to the prior art. [Figure 10] This is a block diagram illustrating a method 300 for predicting blocks in a video image according to an exemplary embodiment. [Figure 11] This is a fifth exemplary embodiment of step 302 and an example of a method 400 for predicting blocks in a video image relating to the modified form thereof. [Figure 12] This is an exemplary block diagram of a system that realizes various embodiments and exemplary examples.

[0107] Similar or identical parts are represented by the same symbol. [Modes for carrying out the invention]

[0108] Hereinafter, at least one exemplary embodiment will be described more comprehensively with reference to the drawings, where an example of at least one exemplary embodiment is described. However, the exemplary embodiment can be carried out in many alternative forms and should not be construed as being limited to the example described herein. Therefore, it should be understood that the exemplary embodiment is not intended to be limited to any particular form disclosed. Rather, this application is intended to cover all modifications, equivalent substitutions and alternatives within the spirit and scope of this application.

[0109] At least one aspect of these embodiments generally relates to the encoding and decoding of video images, another aspect generally relates to the transmission of a bitstream to be provided or encoded, and one of the other aspects relates to the reception / access of a decoded bitstream.

[0110] At least one of these exemplary embodiments is described as encoding / decoding a video image, but it can also be extended to encoding / decoding a video image (image sequence) as each video image is encoded / decoded sequentially as described below.

[0111] Furthermore, at least one exemplary embodiment is not limited to the current version of the VVC. This at least one exemplary embodiment may be applied to existing or future extensions of the VVC and recommendations. Unless otherwise specified or technically excluded, each embodiment described herein may be used individually or in combination.

[0112] A pixel corresponds to the smallest display unit on a screen, and it may consist of one or more light sources (one for a monochrome screen, or three or more for a color screen).

[0113] A video image, also referred to as a frame or image frame, comprises at least one component (also called an image component or channel) determined by a particular image / video format, which specifies all information associated with pixel values ​​and all information used by a display unit and / or any other device to display and / or decode video image data associated with the video image.

[0114] A video image typically contains at least one component, which is represented in the form of an array of samples.

[0115] A monochrome video image contains a single component, while a color video image may contain three components.

[0116] For example, if the image / video format is the well-known (Y,Cb,Cr) format, a color video image may include a luminance component and two saturation components; or, if the image / video format is the well-known (R,G,B) format, a color video image may include three color components (one for red, one for green, and one for blue).

[0117] Each component of a video image may contain multiple samples relative to the number of pixels on the screen in which the video image is displayed. In a modified example, the number of samples in a component may be a multiple (or fraction) of the number of samples in other components of the same video image.

[0118] For example, if a video format includes a luminance component and two saturation components (e.g., a (Y,Cb,Cr) format), the saturation components may contain half the number of samples in width and / or height compared to the luminance component, depending on the color format being considered.

[0119] A sample is the smallest visual information unit of a component that makes up a video image. The sample value may be, for example, a luminance or saturation value or a color value in (R,G,B) format.

[0120] Pixel values ​​are the values ​​of screen pixels. For monochrome video images, a pixel value can be represented by a single sample, while for color video images, a pixel value can be represented by multiple collated samples. A collated sample associated with a pixel represents a sample that corresponds to the pixel's position on the screen.

[0121] Typically, a video image is viewed as a set of pixel values, with each pixel representing at least one sample.

[0122] A block of video images is a set of samples of one component of a video image. If the image / video format is a well-known (Y,Cb,Cr) format, at least one block of luminance samples or at least one block of saturation samples is considered; or if the image / video format is a well-known (R,G,B) format, at least one block of color samples is considered.

[0123] At least one exemplary embodiment is not limited to a specific image / video format.

[0124] Generally, the present application relates to a method for blocking video images, the method comprising the steps of: signaling an intrablock copy mode type, the type of which indicates whether an intrablock copy prediction mode is set to predict video content captured by a camera; determining a block vector which the intrablock copy prediction mode predicts blocks of video images from a reference block of video images; setting the intrablock copy prediction mode to predict blocks of video images if the type of which indicates that the intrablock copy prediction mode is set to predict video content captured by a camera; and deriving predicted blocks of video images based on the set intrablock copy mode prediction mode.

[0125] The present invention makes the intra-block copy (IBC) prediction mode more suitable for predicting video content captured by a camera than the IBC prediction mode specified in the VVC and ECM. The present invention allows switching between different settings of the IBC prediction mode for video encoding / decoding, one for use in predicting screen / graphic content and the other for predicting video content captured by a camera. The encoding efficiency of a block of video image related to the predictive encoding of a block of video image derived from the present invention is compared with the encoding efficiency of the same block in the IBC prediction mode specified in the VVC and ECM.

[0126] Other aspects and advantages of the present invention are described in the following specific exemplary embodiments with reference to the accompanying drawings.

[0127] Figure 10 is a block diagram of a method 300 for predicting blocks in a video image according to an exemplary embodiment.

[0128] Method 300 provides a prediction block of video image blocks. This prediction block can be used for selecting the prediction mode in Method 100, or for the prediction mode of the prediction process in Method 200.

[0129] Predictive information related to method 300 is signaled; that is, when method 300 is used in method 100, the predictive information is written into the bitstream, and when method 300 is used in method 200, the predictive information is analyzed from the bitstream.

[0130] In step 301, the intrablock copy mode type (abbreviated as IBC mode type) is signaled as prediction information. The IBC mode type indicates whether the IBC prediction mode is set to predict video content captured by the camera. The IBC prediction mode is used to determine at least one block vector for predicting blocks of video image from at least one (reconstructed) reference block of the video image.

[0131] In one exemplary embodiment of step 301, the IBC mode type is signaled at the slice level.

[0132] In the modified version, the IBC mode type is signaled only when the IBC prediction mode is enabled.

[0133] Table 1 shows an example of signaling the IBC prediction mode type as the flag sh_ibc_camera_content_flag within the slice header syntax defined by VVC, based on an exemplary embodiment.

[0134] [Table 1]

[0135] If the flag sh_ibc_camera_content_flag is false (=0), blocks of video images using IBC prediction mode in the corresponding slice encode the screen content using the IBC mode defined in VVC and ECM.

[0136] If the flag sh_ibc_camera_content_flag is true (=1), the video image block using the IBC prediction mode in the corresponding slice uses the prediction block derived from step 302 of method 300 for the video content captured by the camera. As previously stated, step 302 improves the prediction of the video content captured by the camera by adapting (setting) the IBC prediction mode defined in the VVC, thereby improving the efficiency of predictive encoding of the video content captured by the camera.

[0137] If the IBC mode type indicates that the IBC prediction mode is set to predict video content captured by the camera, then in step 302, the IBC prediction mode is set to predict video content captured by the camera, and in step 303, a predicted block is derived by predicting a block of video image based on the set IBC prediction mode.

[0138] In a first exemplary embodiment of step 302, setting the intrablock copy prediction mode to predict video content captured by the camera (step 302) further includes indicating whether bidirectional prediction is allowed by signaling the syntactic element ibc_pred_idc_flag as prediction information (step 304).

[0139] In a variation of the first exemplary embodiment of step 302, setting the intrablock copy prediction mode to predict video content captured by the camera (302), if the syntactic element ibc_pred_idc_flag indicates that bidirectional prediction is allowed, further includes signaling two block vectors as prediction information (305), and the predicted block of a block of video image may be the average of these two block vectors (step 303).

[0140] In a second exemplary embodiment of step 302, setting the intrablock copy prediction mode to predict video content captured by the camera (302) further includes identifying the block vector predictor for each block vector of the IBC prediction mode in a block vector list associated with blocks adjacent (decoded) to a block of the video image by signaling the syntactic element mvp_l1_flag as prediction information (306), wherein the adjacent (decoded) block belongs to the video image.

[0141] Table 2 shows the VVC syntax, modified based on the first and second exemplary embodiments and variations of step 302, relating to blocks of video images.

[0142] [Table 2]

[0143] In a third exemplary embodiment of step 302, at least one block vector determined by the IBC prediction mode can be shown using a subpixel resolution level such as AMVR in the interprediction mode of the VVC / ECM. Thus, a spatial interpolation filter similar to the spatial interpolation filter of the interprediction mode of the VVC applied to motion vector compensation can be applied to the at least one block vector.

[0144] In a variation of the third exemplary embodiment of step 302, setting the intrablock copy prediction mode to predict video content captured by the camera (302) further includes signaling the subpixel resolution level as prediction information (step 307).

[0145] In a fourth exemplary embodiment of step 302, setting an intrablock copy prediction mode to predict video content captured by a camera (302) further includes signaling at least one block vector difference as prediction information (step 308), the at least one block vector difference being calculated between a block vector determined by the IBC prediction mode and a reference block inside the video image.

[0146] In a variation of the fourth exemplary embodiment of step 302, each block vector difference can be signaled at a sub-pixel precision level, and a spatial interpolation filter similar to the spatial interpolation filter of the inter-prediction mode of the VVC applied to motion vector compensation can be applied.

[0147] In a variation of the fourth exemplary embodiment of step 302, setting an intrablock copy prediction mode to predict video content captured by a camera (302) further includes encoding a block vector difference (step 309), wherein the encoding is limited to several vector directions and widths.

[0148] For example, the block vector difference, like the motion vector difference encoded according to MMVD, is limited to four vector directions and eight width values, from 1 / 4 luminance sample to 32 luminance samples. The block vector offset can be applied to a block vector predictor to reconstruct the block vector in IBC prediction mode, which is the same as how MMVD, as defined in VVC, is applied to a motion vector predictor to reconstruct the motion vector.

[0149] In a variation of the fourth exemplary embodiment of step 302, when merge mode is enabled, setting the intrablock copy prediction mode to predict the video content captured by the camera (302) further includes signaling the syntax element mmvd_merge_flag as prediction information (step 310) to indicate whether the encoding of the block vector difference is limited to some vector direction and width.

[0150] In a variation of the fourth exemplary embodiment of step 302, setting the intrablock copy prediction mode to predict video content captured by a camera (302) further includes signaling the syntactic element mmvd_cand_flag (step 311) to indicate the merge candidate block vector index in the mmvd merge candidate list, which is used to derive the block vector of the block of the video image to be predicted. The mmvd merge candidate list is essentially a subset of the regular merge candidate list and consists of only two elements. Essentially, the first two merge candidates in the regular merge candidate list are used to form the mmvd merge candidate list. In practice, a single flag mmvd_cand_flag is needed to indicate which ID of the two mmvd merge candidates is used to derive the motion information of the current block.

[0151] In a variation of the fourth exemplary embodiment of step 302, setting the intrablock copy prediction mode to predict video content captured by the camera (302) further includes signaling two syntactic elements mmvd_distance_idx and mmvd_direction_idx (step 312) to indicate the block vector offset associated with the block vector difference.

[0152] Table 3 shows examples of VVC syntax modified based on the fourth exemplary embodiment of step 302 and its variations, relating to merged data.

[0153] [Table 3]

[0154] Figure 11 shows an example of a method 400 for predicting blocks in a video image based on the first, second, and fourth exemplary embodiments and their variations of step 302 described above.

[0155] An exemplary embodiment of step 302 acquires prediction information. This prediction information can be determined in the encoding method 100 and analyzed from the bitstream in the decoding method 200.

[0156] Based on the exemplary embodiment and variations of step 302, the prediction information may include syntactic elements ibc_pred_idc_flag, mvp_l1_flag, mmvd_merge_flag, mmvd_cand_flag, mmvd_distance_idx, mmvd_direction_idx, at least block vector difference and / or subpixel resolution levels.

[0157] Step 401 checks whether merge mode has been enabled.

[0158]

number

[0159]

number

[0160]

number

[0161] In step 404, method 400 checks whether the syntax element ibc_pred_idc_flag allows bidirectional prediction.

[0162] If permission is granted, step 404 is followed by step 412.

[0163] If permission is not granted, the process proceeds from step 404 to steps 405 and 406.

[0164]

number

[0165]

number

[0166] Step 406 is followed by step 412.

[0167]

number

[0168] In step 407, method 400 checks whether the syntax element mmvd_merge_flag indicates that the encoding (decoding) of the block vector difference is limited to certain vector directions and widths.

[0169]

number

[0170]

number

[0171] In step 409, the merge candidate block vector identified by the syntax element mmvd_cand_flag is obtained from the mmvd merge candidate list.

[0172]

number

[0173]

number

[0174] Step 411 is followed by Step 412.

[0175]

number

[0176]

number

[0177]

number

[0178] In the modified version, each block vector difference is encoded / decoded based on the syntax element mmvd_merge_flag. The encoding is limited to a few vector directions and widths.

[0179] In a fifth exemplary embodiment of step 302, setting the intrablock copy prediction mode to predict video content captured by the camera (302) further includes signaling the syntactic element intra_tmp_flag (step 313) to indicate whether or not to use intrablock copy prediction based on template matching (IBCTMP) to derive predicted blocks of video images.

[0180] Essentially, IBCTMP is similar to IBC prediction mode, but the reference region that predicts blocks in a video image is searched based on template matching (TM) rather than signaled through block vectors as in IBC prediction mode.

[0181] If the syntax element intra_tmp_flag is 1, the predicted blocks of the video image are derived using IBCTMP. Therefore, no information related to the block vectors is encoded in the bitstream; rather, it is retrieved synchronously by both the encoder and the decoder.

[0182] This search is based on template matching, similar to the template matching process performed specifically for screen content. Furthermore, because IBCTMP is used for content captured by a camera, the template matching searches not only for integer positions in reference blocks, but also for fractional spatial positions between luminance samples, similar to the template matching process used for interpretation.

[0183] If the syntax element intra_tmp_flag is 0, the IBC prediction mode set according to one of the embodiments and its variations in step 302, as described above, is used for the prediction block of the video image.

[0184] Table 4 shows the syntactic structures modified according to the second and sixth exemplary embodiments and their variations, based on the syntactic structures in Table 2.

[0185] [Table 4]

[0186] In an exemplary embodiment of step 303, method 300 further includes the steps of deriving an IBC prediction block for a block of video images from a set IBC prediction mode (step 314), deriving another prediction block for a block of video images (315), and deriving a prediction block for a block of video images (316) by blending the first and second prediction blocks.

[0187] In the modified example of step 303, the other prediction block is derived from the prediction of motion compensation for blocks in the video image.

[0188] The advantage of this exemplary embodiment is to provide a bidirectional prediction means for executing blocks of a video image based on a reference block of the current video image and a reconstructed block region of the current video image. This prediction mode further improves encoding efficiency based on the prior art.

[0189] In a variation of the exemplary embodiment in step 303, the other prediction block is derived from an intra-prediction of a block of video images.

[0190] For example, intra-prediction may be DC, planar, direct mode, horizontal and vertical angle prediction for VVC, or DIMD (decoder-side intra-mode derivation) or TIMD (template-based intra-mode derivation) for ECM. These encoding modes are described in the ECM file ("Description of the Algorithm of Extended Compression Model 4 (ECM4)", M. Coban, F. Le Leannec, K. Naser, J. Strom, Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29, 23rd Meeting, Teleconference, July 7-16, 2021, Document JVET-Y202-v2, https: / / jvet-experts.org / doc_end_user / documents / 25_Teleconference / wg11 / JVET-Y2025-v2.zip).

[0191] DC is an intra-prediction mode, which generates predictions using the average sample values ​​of the reference samples located to the left and above the block.

[0192] The planar mode is the weighted average of four reference sample values ​​(taken as an orthogonal projection of the sample and predicted in the vertex and left-side reconstruction regions).

[0193] Direct mode (DM) is a saturation intra-prediction mode and corresponds to an intra-prediction mode for collated reconstructed luminance samples.

[0194] The horizontal and vertical modes predict the rows and columns of the sample, respectively, using copies of the reconstructed sample located to the left and above, without interpolation.

[0195] In the modified example of step 303, the blend may be the same as in CIIP mode.

[0196] Since the intra predictor is an IBC predictor optimized for video content captured by the predictive camera, the exemplary embodiment of step 303 improves encoding efficiency compared to the CIIP mode in VVC.

[0197] In one variation of the exemplary embodiment of step 303, method 300 further includes the step of signaling a syntactic element regular_merge_flag to the bitstream (317). A syntactic element regular_merge_flag of 1 indicates that the prediction block of the video image block is derived based on one or a variation of the exemplary embodiment of step 302. A syntactic element regular_merge_flag of 0 indicates that the IBC prediction block is merged with the other prediction block of the video image.

[0198] In the modified example of the exemplary embodiment in step 303, the syntactic element regular_merge_flag is added to Table 5, and Table 5 is an example of VVC syntax related to merge data and modified based on the sixth exemplary embodiment of step 302.

[0199] Table 5 shows the syntax structure modified based on Table 3 and the exemplary embodiments and modifications of step 303.

[0200] [Table 5]

[0201] In the variation of step 303, if an IBC predicted block is determined, the block vector associated with the block in the video image is set as the first merge candidate in the merge candidate list (similar to the IBC skip / merge mode).

[0202] In another variation of step 303, the merge index can be signaled, and a block vector (similar to the IBC skip / merge mode) can be derived based on the signaled merge index.

[0203] In another variation of step 303, if the syntactic element ibc_pred_idc_flag indicates that bidirectional prediction is allowed, two block vectors are signaled to identify a specific block in the video image block to be predicted, and the IBC prediction block may be the average of these two block vectors.

[0204] Figure 12 is an exemplary schematic block diagram of System 600 that realizes various embodiments and exemplary examples.

[0205] System 600 may be incorporated as one or more devices including various components described below. In various exemplary embodiments, System 600 may be configured to realize one or more of the embodiments described herein.

[0206] Examples of devices that constitute all or part of System 600 may include personal computers, laptops, smartphones, tablets, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected home appliances, connected vehicles, and associated processing systems, head-mounted display devices (HMDs, X-ray glasses), projectors (beamers), "caves" (systems including multiple displays), servers, video encoders, video decoders, post-processors that process the output from the video decoders, pre-processors that provide input to the video encoders, web servers, video servers (e.g., broadcast servers, video broadcast servers, or network servers), still image or video cameras, encoding or decoding chips, or any other communication devices. The elements of System 600 can be implemented individually or in combination within a single integrated circuit (IC), multiple ICs, and / or separate components. For example, in at least one exemplary embodiment, the processing and encoder / decoder elements of System 600 may be distributed across multiple ICs and / or separate components. In various exemplary embodiments, System 600 may be communicatively coupled to other similar systems or electronic devices, for example, via a communication bus or dedicated input and / or output ports.

[0207] The system 600 may include at least one processor 610, which is configured to execute instructions loaded to realize each of the embodiments described herein. The processor 610 may include embedded memory, input / output interfaces, and various other circuits known in the art. The system 600 may include at least one memory 620 (e.g., a volatile memory device and / or a non-volatile memory device). The system 600 may include a storage device 640 containing non-volatile and / or volatile memory, including, but not limited to, electrically erasable programmable read-only memory (EEPROM), read-only memory (ROM), programmable read-only memory (PROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, magnetic disk drives and / or optical disk drives. In non-limiting examples, the storage device 640 may include an internal storage device, an attached storage device and / or a network-accessible storage device.

[0208] The system 600 may include, for example, an encoder / decoder module 630 configured to provide encoded / decoded video image data by processing the data. The encoder / decoder module 630 may include its own processor and memory. The encoder / decoder module 630 can represent one or more modules that may be included in the device to perform encoding and / or decoding functions. As is well known, the device may include one or both encoding and decoding modules. The encoder / decoder module 630 may also be implemented as a separate element of the system 600, or it may be incorporated into the processor 610 as a combination of hardware and software known to those skilled in the art.

[0209] Program code loaded into the processor 610 or encoder / decoder 630 to perform each embodiment described herein is stored in the storage device 640 and loaded into memory 620 to be executed by the processor 610. According to various exemplary embodiments, during the execution of the processes described herein, one or more of the processor 610, memory 620, storage device 640 and encoder / decoder module 630 may store one or more of various items. Such stored items include, but are not limited to, video image data, information data used for encoding / decoding video image data, bitstreams, matrices, variables, equations, formulas, operations and intermediate or final results of arithmetic logic processing.

[0210] In some exemplary embodiments, memory within the processor 610 and / or encoder / decoder module 630 may be used to store instructions and provide working memory for processing performed during encoding or decoding.

[0211] However, in other exemplary embodiments, memory outside the processing device (for example, the processing device may be a processor 610 or an encoder / decoder module 630) is used for one or more of these functions. The external memory may be memory 620 and / or storage device 640, and may be, for example, dynamic volatile memory and / or non-volatile flash memory. In some exemplary embodiments, external non-volatile flash memory may be used to store the television's operating system. In at least one exemplary embodiment, high-speed external dynamic volatile memory such as RAM can be used as working memory for video encoding and decoding operations such as, for example, MPEG-2 Part 2 (also known as ITU-T Recommendation H.262 and ISO / IEC 13818-2, and also called MPEG-2 video), AVC, HEVC, EVC, VVC, AV1, etc.

[0212] As shown in block 690, inputs to the elements of system 600 can be provided via various input devices. Such input devices may include, but are not limited to, (i) an RF section capable of receiving RF signals transmitted wirelessly, for example, by a broadcasting device; (ii) a composite input terminal; (iii) a USB input terminal; (iv) an HDMI® input terminal; and (v) a bus such as a CAN (Controller Area Network), CAN FD (Controller Area Network Flexible Data Rate), FlexRay (ISO 17458), or Ethernet (ISO / IEC 802-3) bus, as the present invention is implemented in the automotive field.

[0213] In various exemplary embodiments, the input device of block 690 may have associated input processing elements as known in the art. For example, the RF portion may be associated with elements necessary to (i) select a desired frequency (also called selecting a signal or limiting a signal to a frequency band), (ii) downconvert the selected signal, (iii) again band-limit it to a narrower frequency band to select a signal frequency band called a channel in a particular exemplary embodiment, (iv) demodulate the downconverted and band-limited signal, (v) perform error correction, and (vi) multiplex decouple in order to select a desired data packet stream. The RF portion of various exemplary embodiments may include one or more elements for performing these functions, such as a frequency selector, signal selector, band limiter, channel selector, filter, downconverter, demodulator, error corrector, and multiplex decoupler. The RF portion may also include a tuner that performs various functions, such as downconverting the received signal to a lower frequency (e.g., an intermediate frequency or a frequency close to the baseband) or the baseband.

[0214] In one embodiment of a set-top box, the RF section and its associated input processing elements can receive an RF signal transmitted via a wired (e.g., cable) medium. The RF section can then perform frequency selection to the desired frequency band by filtering, downconverting, and re-filtering.

[0215] In various exemplary embodiments, the order of the above (and other) elements is rearranged, some of these elements are removed, and / or other elements that perform similar or different functions are added.

[0216] Adding elements includes inserting elements between conventional elements, such as amplifiers or analog or digital converters. In various exemplary embodiments, the RF may include an antenna.

[0217] Furthermore, the USB and / or HDMI terminals may include corresponding interface processors to connect the system 600 to other electronic devices via USB and / or HDMI connections. When necessary, each aspect of input processing (e.g., Reed-Solomon error correction) can be implemented within a separate input processing IC or within the processor 610. Similarly, when necessary, each aspect of USB or HDMI interface processing can be implemented within a separate interface IC or within the processor 610. Demodulation, error correction, and multiplexed streams can be provided to various processing elements, including, for example, the processor 610 and the encoder / decoder 630, which are operated in combination with memory and storage elements to process the data stream and display it on an output device when necessary.

[0218] Various elements of system 600 can be provided within an integrated housing. Within the integrated housing, appropriate connection arrangements 690 can be used, for example, to interconnect each type of element and transmit data between them using internal buses (including I2C buses), wiring, and printed circuit boards known in the art.

[0219] System 600 may include a communication interface 650 to enable communication with other devices via a communication channel 651. The communication interface 650 may include, but is not limited to, transceivers for sending and receiving data on the communication channel 651. The communication interface 650 may include, but is not limited to, a modem or a network card, and the communication channel 651 can be implemented, for example, in a wired and / or wireless medium.

[0220] In various exemplary embodiments, data can be streamed to system 600 using a Wi-Fi network, such as IEEE 802.11. The Wi-Fi signals in these exemplary embodiments are receivable via a communication channel 651 and a communication interface 650 that are compatible with Wi-Fi communication. The communication channel 651 in these exemplary embodiments can typically be connected to an access point or router, which provides access to an external network, including the Internet, enabling streaming applications and other over-the-top communications.

[0221] Another exemplary embodiment may use a set-top box to provide data streamed to system 600, which distributes the data via an HDMI connection in input block 690.

[0222] Another exemplary embodiment may provide the system 600 with streamed data using the RF connection of input block 690.

[0223] The streamed data can be used by System 600 as a method for signaling information. The signaling information may include information on the number of pixels in bitstream B and / or video images and / or any encoding / decoding setting parameters.

[0224] Furthermore, signaling can be implemented in various ways. For example, in various exemplary embodiments, one or more syntactic elements, flags, etc., may be used to signal information to the corresponding decoder.

[0225] System 600 can provide output signals to various output devices, including a display 661, a speaker 671, and other peripheral devices 681. In various exemplary embodiments, the other peripheral devices 681 may include one or more of a standalone DVR, a disc player, a stereo system, a lighting system, and other devices that provide functionality based on the output of System 600.

[0226] In various exemplary embodiments, control signals are communicated between the system 600 and the display 661, speaker 671, or other peripheral devices 681 using signals such as AV.Link (Audio / Video Link), CEC (Consumer Electronic Control), or other communication protocols that enable control between devices with or without user intervention.

[0227] The output devices can be communicatively coupled to system 600 via dedicated connections through the corresponding interfaces 660, 670, and 680.

[0228] Optionally, the output device can be connected to the system 600 via the communication interface 650 using the communication channel 651. The display 661 and speaker 671 may be combined into a single unit along with other components of the system 600 in an electronic device (e.g., a television).

[0229] In various exemplary embodiments, the display interface 660 may include a display driver, such as a timing controller (TCon) chip.

[0230] For example, if the RF portion of the input terminal 690 is part of a separate set-top box, the display 661 and speaker 671 may be selectively configured separately from one or more of the other components. In various exemplary embodiments where the display 661 and speaker 671 are external components, output signals can be provided via dedicated output connections (including, for example, an HDMI port, a USB port, or a COMP output side).

[0231] Figures 1-12 illustrate various methods, each involving one or more steps or actions to achieve the method described. Unless a specific sequence of steps or actions is required for the precise operation of the method, the order and / or use of specific steps and / or actions can be modified or combined.

[0232] Several examples of block diagrams and / or operation flowcharts are described. Each block represents a portion of circuit elements, modules, or code containing one or more executable instructions for implementing a specified logical function. In other embodiments, the functions shown in a block do not necessarily have to be executed in the order indicated. For example, two blocks shown consecutively based on related functions may actually be executed almost simultaneously, or they may be executed in reverse order.

[0233] The embodiments and aspects described herein can be implemented, for example, as methods or processes, apparatus, computer programs, data flows, bitstreams, or signals. Even when described in the context of a single form of embodiment (for example, when described only as a method), embodiments of the described features may be implemented in other forms (for example, apparatus or computer programs).

[0234] The method can be implemented, for example, within a processor, which generally refers to a processing device including a computer, microprocessor, integrated circuit, or programmable logic device. The processor may further include communication devices.

[0235] Furthermore, the method can be implemented by instructions executed by a processor, and such instructions (and / or data values ​​generated by the embodiment) can be stored in a computer-readable storage medium. The computer-readable storage medium can be an embodiment of computer-readable program 54C1 having computer-readable program code implemented therein and executable by a computer. Considering the inherent ability to store information therein and the inherent ability to retrieve information therefrom, the computer-readable storage medium used herein can be considered a non-temporary storage medium. The computer-readable storage medium may include, but is not limited to, systems, apparatus or devices of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor, or any appropriate combination thereof. The following are more specific examples of computer-readable storage mediums to which this exemplary embodiment applies, but it should be noted that these are merely examples and not an exhaustive list, as will be easily understood by those skilled in the art. The computer-readable storage media mentioned above include, for example, portable computer floppy disks, hard disks, read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.

[0236] The instructions can form an application program that is specifically implemented on a readable medium.

[0237] For example, instructions can reside in hardware, firmware, software, or a combination of both. For instance, instructions can be found in an operating system, a standalone application, or a combination of both. Therefore, a processor may be characterized as a device comprising, for example, a device configured to execute a process, and a processor-readable medium (e.g., a storage device) containing instructions for executing the process. In addition to or instead of instructions, the processor-readable medium may store data values ​​generated by the embodiment.

[0238] The device can be implemented, for example, within appropriate hardware, software, and firmware. Examples of such devices include personal computers, laptops, smartphones, tablets, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected home appliances, head-mounted display devices (HMDs, X-ray glasses), projectors (beamers), "caves" (systems including multiple displays), servers, video encoders, video decoders, post-processors for processing the output from the video decoders, pre-processors for providing input to the video encoders, web servers, set-top boxes, and any other devices for processing video images or other communication devices. The device may be portable and mounted on a moving vehicle.

[0239] Computer software can be implemented by the processor 610, or by hardware, or by a combination of hardware and software. In non-limiting examples, exemplary embodiments can also be implemented by one or more integrated circuits. Memory 620 may be of any type suitable for the technical environment and can be implemented by any suitable data storage technology (non-limiting examples include, for example, optical memory devices, magnetic memory devices, semiconductor-based memory devices, fixed memory, and movable memory). Processor 610 may be of any type suitable for the technical environment and may include, non-limiting examples, one or more of a microprocessor, a general-purpose computer, a dedicated computer, and a processor based on a multi-core architecture.

[0240] As will be obvious to those skilled in the art, embodiments can generate signals formatted to carry information, for example, to be stored or transmitted. The information may include instructions for performing the method or data generated by one of the embodiments described. For example, a signal can be formatted to carry a bitstream of an exemplary embodiment described. This signal may be formatted, for example, as an electromagnetic wave (e.g., using the radio frequency portion of the spectrum) or as a baseband. The formatting may include encoding a data stream and modulating a carrier with the encoded data stream. The information carried by the signal may be, for example, analog or digital information. As is well known, signals can be transmitted over a variety of different wired or wireless links. Signals can be stored on a processor-readable medium.

[0241] The terms used herein are for illustrative purposes only and are not limiting. Unless otherwise indicated by the context, the singular forms “a,” “an,” and “the” as used herein are intended to include the plural forms as well. The terms “include / comprise” and / or “including / comprising” as used herein may specify the presence of a declared feature, integer, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof. Furthermore, when one element is said to “respond to,” “connected to,” or “associated with” another element, it may directly respond to the other element, or it may be associated with the other element, or there may be an intermediate element. In contrast, when one element is said to "directly respond to" or "directly connect to" another element, or to be "directly associated" with another element, there is no intermediate element.

[0242] For example, in the phrases "A / B", "A and / or B", and "at least one of A and B", the use of any one of the symbols / terms " / ", "and / or", and "at least one" is intended to include the selection of only the first listed option (A), or only the selection of only the second listed option (B), or the selection of two options (A and B). As further examples, in the phrases "A, B and / or C" and "at least one of A, B and C", such phrasing is intended to include the selection of only the first listed option (A), or only the selection of only the second listed option (B), or only the selection of only the third listed option (C), or only the selection of only the first and second listed options (A and B), or only the selection of only the first and third listed options (A and C), or only the selection of only the second and third listed options (B and C), or the selection of three options (A, B, and C). As is well known to those skilled in the art, it can be expanded to the number of listed items.

[0243] Various numerical values ​​can be used in this application. Certain values ​​may be used for illustrative purposes, and the embodiments described are not limited to these specific values.

[0244] The terms "first," "second," etc., may be used in this specification to describe various elements, but these elements are not limited by these terms. These terms are used solely to distinguish one element from another. For example, the first element may be called the second element, and similarly, the second element may be called the first element, as long as this does not deviate from the teachings of this application. No order is implied between the first and second elements.

[0245] The references to “an exemplary embodiment,” “an exemplary embodiment,” “one embodiment,” or “an embodiment,” and other variations are frequently used to indicate that certain features, structures, characteristics, etc. (described in conjunction with the exemplary embodiment) are included in at least one exemplary embodiment. Therefore, the appearance of the terms “in an exemplary embodiment,” “in an exemplary embodiment,” “in one embodiment,” or “in an embodiment,” and any variations thereof, throughout this application does not necessarily refer to the same exemplary embodiment.

[0246] Similarly, the “according to an exemplary example / embodiment” or “in an exemplary example / embodiment” and other variations cited herein are frequently used to indicate that a particular feature, structure, or characteristic (as described in conjunction with an exemplary example / embodiment) may be included in at least one exemplary example / embodiment. Therefore, the phrases “according to an exemplary example / embodiment” or “in an exemplary example / embodiment” appearing elsewhere in this Application do not necessarily refer to the same exemplary example / embodiment, nor are any single or alternative exemplary example / embodiment necessarily mutually exclusive with other exemplary examples / embodiments.

[0247] The reference numbers mentioned in the claims are for illustrative purposes only and do not limit the scope of the claims. Although not expressly described, any combination or subcombination of these exemplary embodiments / examples and modifications may be used.

[0248] When a drawing is presented as a flowchart, a corresponding block diagram of the device is also provided. Similarly, when a drawing is presented as a block diagram, a corresponding method / process flowchart is also provided.

[0249] Some diagrams include arrows on the communication path to indicate the main direction of communication, but please understand that communication may occur in the opposite direction to the depicted arrow.

[0250] Various embodiments relate to decoding. As used in this application, “decoding” includes all or part of the process performed on a received video image (which may include a received bitstream encoding one or more video images) for a final output that is suitable for further processing in the displayed or reconstructed video region. In various exemplary embodiments, this process includes one or more processes that are typically performed by a decoder. In various exemplary embodiments, for example, such a process may optionally include processes performed by a decoder of the various embodiments described herein.

[0251] As further examples, in one exemplary embodiment, “decoding” may refer only to inverse quantization; in another exemplary embodiment, “decoding” may refer only to entropy decoding; in yet another exemplary embodiment, “decoding” may refer only to differential decoding; and in yet another exemplary embodiment, “decoding” may refer to a combination of inverse quantization, entropy decoding, and differential decoding. In the context specifically described, it should be clear to those skilled in the art whether the term “decoding process” refers to a subset of operations or to a broader decoding process.

[0252] Various embodiments relate to encoding. Similar to the description of “decoding” above, “encoding” as used in this application may include all or part of the processes performed on an input video image to generate an output bitstream. In various exemplary embodiments, this process includes one or more processes typically performed by an encoder. In various exemplary embodiments, this process may further, or selectively, include processes performed by an encoder of the various embodiments described herein.

[0253] As further examples, in one exemplary embodiment, “encoding” may refer only to quantization; in another exemplary embodiment, “encoding” may refer only to entropy coding; in yet another exemplary embodiment, “encoding” may refer only to differential coding; and in yet another exemplary embodiment, “encoding” may refer to a combination of quantization, differential coding, and entropy coding. Based on the context specifically described, it is clear and will be well understood by those skilled in the art whether the term “encoding process” refers specifically to a subset of operations or to a broader encoding process.

[0254] Furthermore, this application refers to various forms of "acquisition" of information. Acquisition of information may include, for example, one or more of the following: estimation of information, calculation of information, prediction of information or retrieval of information from memory, processing of information, movement of information, copying of information, deletion of information, calculation of information, determination of information, prediction of information or estimation of information.

[0255] Furthermore, this application refers to the "reception" of various types of information. Reception of information may include, for example, one or more of the following: accessing information or receiving information from a communication network.

[0256] Furthermore, as used herein, the term “signal” specifically refers to indicating something to a corresponding decoder. For example, in some exemplary embodiments, an encoder signals specific information, such as encoded parameters or encoded video image data. This method allows the encoder and decoder to use the same parameters in exemplary embodiments. Thus, for example, the encoder can transmit (explicitly signal) specific parameters to the decoder, thereby allowing the decoder to use the same specific parameters. Conversely, if the decoder has specific parameters and other parameters, these are notified to and obtained by signaling (implicitly signaling) without transmission. Avoiding the transmission of actual functions results in bit savings in various exemplary embodiments. It should be understood that multiple signaling methods can be used. For example, in various exemplary embodiments, one or more syntactic elements, flags, etc., are used to signal information to the corresponding decoder. The above discussion concerns the verb form of the term “signal,” but the term “signal” may also be used as a noun herein.

[0257] While many embodiments have been described, it should be understood that various modifications are possible. For example, other embodiments can be generated by combining, supplementing, changing, or deleting elements from different implementations. Furthermore, as those skilled in the art will understand, the disclosed structures and processes can be replaced with other structures and processes, and the resulting embodiments will perform at least substantially the same functions as the disclosed implementation, achieve at least substantially the same results in at least substantially the same way. Accordingly, these and other embodiments are envisioned in this application.

[0258] This application claims priority to European Patent Application No. "22306003.9," filed on 5 July 2022, the entire contents of which are incorporated herein by reference.

Claims

1. A method for predicting blocks in a video image, which is performed by an encoder. - A step of signaling the type of intrablock copy mode, wherein the type of intrablock copy mode indicates whether an intrablock copy prediction mode is set to predict video content captured by a camera, and the intrablock copy prediction mode determines at least one block vector for predicting a block of video image from at least one reference block of video image, - If the Intrablock Copy Mode type indicates that the Intrablock Copy Prediction Mode is set to predict video content captured by the camera, - The steps of setting an intrablock copy prediction mode by signaling at least one additional syntactic element that indicates how blocks of video images captured by a camera should be predicted in order to predict blocks of video images captured by the camera, - The step of deriving predicted blocks of video images captured by the camera based on a set intrablock copy prediction mode, Setting the intrablock copy prediction mode to predict video content captured by the camera is, - Signal a syntactic element (ibc_pred_idc_flag) that indicates whether bidirectional prediction is permitted, and if the syntactic element indicates that bidirectional prediction is permitted, - Signaling two block vectors, including the prediction that the block of the video image captured by the camera is the average of the two block vectors, A method for predicting blockiness in video images.

2. The block belongs to the slice of the video image and signals the type of intrablock copy mode at the slice level. A method for predicting blocks in a video image according to claim 1.

3. Setting the intrablock copy prediction mode to predict video content captured by the camera is, The process involves signaling a syntactic element (mvp_l1_flag) to identify the block vector predictor for each block vector in a block vector list associated with a decoded block adjacent to a block of video image captured by the camera, and further including that the adjacent block belongs to the video image captured by the camera. A method for predicting blocks in a video image according to claim 1.

4. At least one block vector is represented at the sub-pixel precision level. A method for predicting blocks in a video image according to claim 1.

5. Setting the intrablock copy prediction mode to predict video content captured by the camera is, Signaling at least one block vector difference calculated between a block vector and a reference block inside a video image captured by the camera, further comprising signaling each block vector difference at a sub-pixel precision level. A method for predicting blocks in a video image according to claim 1.

6. Setting the intrablock copy prediction mode to predict video content captured by the camera is, Encoding each block vector difference, further comprising the encoding being limited to a certain number of vector directions and widths, A method for predicting blocks in a video image according to claim 5.

7. Setting the intrablock copy prediction mode to predict video content captured by the camera is, This further includes signaling a syntactic element (mmvd_merge_flag) to indicate whether the encoding of the block vector difference is limited to certain vector directions and widths, A method for predicting blocks in a video image according to claim 6,

8. Setting the intrablock copy prediction mode to predict video content captured by the camera is, The further includes signaling a syntactic element (intra_tmp_flag) to indicate whether to derive predicted blocks of video images captured by the camera using intra-block copy prediction based on template matching, or whether to derive predicted blocks of video images pursuant to claim 1. A method for predicting blocks in a video image according to claim 1.

9. The step of deriving predicted blocks of video images captured by the camera based on the configured intrablock copy prediction mode is: - A step of deriving a first predicted block of the video image captured by the camera from the configured intrablock copy prediction mode, - A step of deriving a second predicted block of the video image block captured by the camera, - The process includes the step of blending a first prediction block and a second prediction block to derive a prediction block of a block of video image captured by the camera, A method for predicting blocks in a video image according to claim 1.

10. The second prediction block is derived based on motion compensation prediction or intra-prediction of the block in the video image captured by the camera. A method for predicting blocks in a video image according to claim 9.

11. A method for predicting blocks in a video image, which is performed by a decoder, - A step of receiving the type of intrablock copy mode, the type of intrablock copy mode indicating whether the intrablock copy prediction mode is set to predict video content captured by the camera, and the step of determining at least one block vector for predicting a block of video image from at least one reference block of video image, - If the Intrablock Copy Mode type indicates that the Intrablock Copy Prediction Mode is set to predict video content captured by the camera, - A step of determining an intra-block copy prediction mode by receiving at least one additional syntactic element that instructs how blocks of video images captured by a camera are predicted to predict blocks of video images captured by the camera, - The step of deriving predicted blocks of video images captured by the camera based on the determined intrablock copy prediction mode, Determining the intrablock copy prediction mode to predict the video content captured by the camera is, -Receive a syntactic element (ibc_pred_idc_flag) indicating whether bidirectional prediction is permitted, and if the syntactic element indicates that bidirectional prediction is permitted, - Receiving two block vectors, and the predicted block of the video image captured by the camera is the average value of the two block vectors, A method for predicting blockiness in video images.

12. The block belongs to a slice of the video image and receives the type of intrablock copy mode at the slice level. A method for predicting blocks in a video image according to claim 11.

13. Determining an intrablock copy prediction mode to predict video content captured by a camera is: The process involves receiving a syntactic element (mvp_l1_flag), obtaining a block vector predictor for each block vector in a block vector list associated with a decoded block adjacent to a block of video image captured by the camera, and further including that the adjacent block belongs to the video image captured by the camera. A method for predicting blocks in a video image according to claim 11.

14. At least one block vector is represented at a sub-pixel precision level, A method for predicting blocks in a video image according to claim 11.

15. Determining an intrablock copy prediction mode to predict video content captured by a camera is: Receiving at least one block vector difference calculated between a block vector and a reference block inside a video image captured by the camera, further comprising receiving each block vector difference at a sub-pixel precision level. A method for predicting blocks in a video image according to claim 11.

16. Determining an intrablock copy prediction mode to predict video content captured by a camera is: Decoding each block vector difference, further comprising the decoding being limited to a certain number of vector directions and widths. A method for predicting blocks in a video image according to claim 15.

17. Determining an intrablock copy prediction mode to predict video content captured by a camera is: The process further includes receiving a syntactic element (mmvd_merge_flag) and determining whether the decoding of the block vector difference is limited to certain vector directions and widths. A method for predicting blocks in a video image according to claim 16,

18. Determining an intrablock copy prediction mode to predict video content captured by a camera is: The system further includes receiving a syntactic element (intra_tmp_flag) and determining whether to derive predicted blocks of video images captured by the camera using intra-block copy prediction based on template matching, or whether to derive predicted blocks of video images pursuant to claim 11. A method for predicting blocks in a video image according to claim 11.

19. The step of deriving predicted blocks of video images captured by the camera based on the determined intrablock copy prediction mode is: - A step of deriving a first predicted block of the video image captured by the camera from the determined intrablock copy prediction mode, - A step of deriving a second predicted block of the video image block captured by the camera, - The process includes the step of blending a first prediction block and a second prediction block to derive a prediction block of a block of video image captured by the camera, A method for predicting blocks in a video image according to claim 11.

20. The second prediction block is derived based on motion compensation prediction or intra prediction of the block of video image captured by the camera. A method for predicting blocks in a video image according to claim 19.

21. A method for encoding blocks of a video image, performed by an encoder, based on predicted blocks derived from the method of Claim 1.

22. A method for decoding blocks of a video image, performed by a decoder, based on predicted blocks derived from the method of claim 11.

23. An apparatus comprising means for carrying out the method according to any one of claims 1 to 22.

24. It is a computer program, If the computer program is executed by one or more processors, one or more processors are made to execute the method according to any one of claims 1 to 22. Computer program.

25. A non-temporary storage medium containing instructions for program code that performs the method according to any one of claims 1 to 22.

Images