Encoding / decoding video image data

Abstract

The present application relates to predicting a block of a video image comprising signaling an intra block copy mode type indicating whether an intra block copy prediction mode is configured to predict video content captured by a camera; when the intra block copy mode type indicates that the intra block copy prediction mode is configured to predict video content captured by the camera, the intra block copy prediction mode is configured to predict a video image block, and a prediction block of the video image block is derived from the configured intra block copy mode prediction mode.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based upon and claims the benefit of priority from European patent application No. “22306003.9” filed on July 5, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application generally relates to video image encoding and decoding. In particular, but not exclusively, the technical field of the present application relates to prediction of video image blocks based on intra-frame block replication. Background Art

[0004] This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of at least one exemplary embodiment of the present application described and / or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of various aspects of the present application. Therefore, it should be understood that these statements should be read in this light, and not as admissions of prior art.

[0005] 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 Generic Video Coding, ITU-T Recommendation H.266, https: / / www.itu.int / rec / T-REC-H.266-202008-I / en), low-level and high-level picture partitioning are provided to divide a video picture into picture regions, so-called coding tree units (CTUs), which for HEVC may typically have a size between 16×16 and 64×64 pixels, while for VVC the size of the coding tree unit (CTU) may be 32×32, 64×64 or 128×128 pixels.

[0006] The CTU partitioning of the video image forms a grid of CTUs of a fixed size, i.e., a CTU grid, in which the upper and left boundaries coincide spatially with the upper and left borders of the video image. The CTU grid represents the spatial partitioning of the video image.

[0007] In VVC and HEVC, the CTU size (CTU width and CTU height) of all CTUs of the 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 equal to 128 (CTU DW = CTU DH = 128). The default CTU size (height, width) is encoded into the bitstream, for example at the sequence level in a sequence parameter set (SPS).

[0008] The spatial position of a CTU in the CTU grid is determined by the CTU address ctuAddr, which defines the spatial position of the upper left corner of the CTU from the origin. Figure 1 As illustrated, a CTU address may define a spatial position from the upper left corner of a higher-level spatial structure S that contains the CTU.

[0009] A coding tree is associated with each CTU to determine the tree partitioning of the CTU.

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

[0011] Intra or inter coding mode is assigned at CU level. This means the same intra / inter coding mode is assigned to each PU of a CU, although the prediction parameters vary from PU to PU.

[0012] According to a quadtree called a transform tree, a CU can also be spatially partitioned into one or more transform units (TUs). A transform unit is a leaf of a transform tree. The spatial position of a TU in a video image is defined by a TU index tuIdx, which defines the spatial position from the upper left corner of the CU. Each TU is assigned some transform parameters. The transform type is assigned at the TU level, and a 2D separate transform is performed at the TU level during encoding or decoding of an image block.

[0013] The PU partition types that exist in HEVC are as follows: Figure 2As shown. They include square partitions (2N×2N and N×N), which are the only partitions used in both intra- and inter-prediction CUs; ​​symmetric non-square partitions (2N×N, N×2N, used only in inter-prediction CUs); and asymmetric partitions (used only in inter-prediction CUs). For example, PU type 2N×nU represents an asymmetric horizontal partition of a PU, where a smaller partition is located at the top of the PU. According to another example, PU type 2N×nL represents an asymmetric horizontal partition of a PU, where a smaller partition is located at the top of the PU.

[0014] like Figure 3 As shown, in VVC, the coding tree starts from the root node (i.e., CTU). Next, a quadtree (or quadtree) partitioning divides the root node into 4 nodes (solid lines) corresponding to 4 sub-blocks of equal size. Next, the quadtree (or quadtree) leaves can then be further partitioned by the so-called multi-type tree, which involves Figure 4 Binary or ternary segmentation of one of the 4 segmentation modes shown. These segmentation types are vertical and horizontal binary segmentation modes, denoted SBTV and SBTH; and vertical and horizontal ternary segmentation modes SPTTV and STTH.

[0015] In the case of a joint coding tree shared by luma and chroma components, the leaves of the coding tree of a CTU are CUs.

[0016] In contrast to HEVC, in VVC, in most cases, CU, PU, ​​and TU have equal sizes, which means that coding units are generally not partitioned into PUs or TUs except in some specific coding modes.

[0017] Figure 5 and Figure 6 An overview of video encoding / decoding methods used in current video standard compression systems (such as, for example, HEVC or VVC) is provided.

[0018] Figure 5 A schematic block diagram showing the steps of a method 100 for encoding a video image VP according to the prior art is shown.

[0019] In step 110, the video picture VP is partitioned into blocks of samples and the partition information data is signaled into the bitstream. Each block comprises samples of one component of the video picture VP. Thus, the blocks comprise samples defining each component of the video picture VP.

[0020] For example, in HEVC, a picture is divided into coding tree units (CTUs). Each CTU can be further subdivided using a quadtree partition, where each leaf of the quadtree represents a coding unit (CU). The partition information data may then include data describing the quadtree subdivision of the CTU and each CTU.

[0021] Then, each block of samples (block for short) may be a CU (if the CU includes a single PU) or a PU of the CU.

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

[0023] Intra prediction (step 120) uses intra prediction data. Intra prediction consists in predicting the current block with the help of intra prediction blocks based on already coded, decoded and reconstructed samples located around the current block (usually located at the top and left of the current block). Intra prediction is performed in the spatial domain.

[0024] In inter prediction mode, motion estimation (step 130) and motion compensation (135) are performed. Motion estimation searches for candidate reference blocks that are good predictors of the current block in one or more reference video images used to predictively encode the current video image. For example, a good predictor of the current block is a predictor that is similar to the current block. The output of the motion estimation step 130 is inter prediction data including motion information associated with the current block (usually one or more motion vectors and one or more reference video image indices) and other information for obtaining the same prediction block at the encoding / decoding side. Next, motion compensation (step 135) obtains a prediction block with the help of the (one or more) motion vectors and (one or more) reference video image indices determined by the motion estimation step 130. Basically, the block belonging to the selected reference video image and pointed to by the motion vector can be used as the prediction block of the current block. In addition, since the motion vectors are represented as fractions of integer pixel positions (this is called sub-pixel MV precision representation), motion compensation usually involves spatial interpolation of some reconstructed samples of the reference video image to calculate the prediction block.

[0025] The prediction information data is signaled into the bitstream.The prediction information may include prediction mode (intra or inter or skip), intra / inter prediction data and any other information used to obtain the same predicted CU at the decoding side.

[0026] The method 100 optimizes the rate-distortion trade-off to select a prediction mode (intra-frame or inter-frame prediction mode) by considering, for example, the encoding of a prediction residual block calculated by subtracting a candidate prediction block from a current block, and the signaling of the prediction information data required to determine the candidate prediction block at the decoding side.

[0027] Typically, the best prediction mode is given as the prediction mode of the best coding mode p* for the current block given by the following equation:

[0028]

[0029] Where P is the set of all candidate coding modes for the current block, p represents the candidate coding mode in the set, and RD cost (p) is the rate-distortion cost of candidate coding mode p, usually expressed as:

[0030] RD cost(p) =D(p)+λ.R(p)

[0031] D(p) is the distortion between the current block and the reconstructed block obtained after encoding / decoding the current block with candidate coding mode p, R(p) is the rate cost associated with encoding the current block with coding mode p, and λ is a Lagrangian parameter that represents the rate constraint for encoding the current block and is typically calculated based on the quantization parameter used to encode the current block.

[0032] The current block is usually encoded according to a prediction residual block PR. More precisely, the prediction residual block PR is calculated, for example, by subtracting the best prediction block from the current block. The prediction residual block PR is then transformed (step 140) by using, for example, a DCT (discrete cosine transform) or DST (discrete sine transform) type transform or any other suitable transform, and the obtained transform coefficient block is quantized (step 150).

[0033] In a variant, the method 100 may also skip the transform step 140 and apply quantization (step 150) directly to the prediction residual block PR according to a so-called transform skip coding mode.

[0034] The block of quantized transform coefficients (or the block of quantized prediction residuals) is entropy encoded into a bitstream (step 160).

[0035] Next, as part of the encoding loop, the quantized transform coefficient block (or quantized residual block) is dequantized (step 170) and inverse transformed (180) (or not inverse transformed), producing a decoded prediction residual block. The decoded prediction residual block and the prediction block are then combined, usually summed, which provides a reconstructed block.

[0036] Further information data may also be entropy encoded in step 160 to encode the current block of the video picture VP.

[0037] An in-loop filter (step 190) may be applied to the reconstructed image (including the reconstructed blocks) to reduce compression artifacts. After all image blocks are reconstructed, a loop filter may be applied. For example, they include a deblocking filter, a sample adaptive offset (SAO), or an adaptive loop filter.

[0038] The reconstructed block or the filtered reconstructed block forms a reference picture which can be stored into a decoded picture buffer (DPB) so that it can be used as a reference picture for encoding of the next current block of the video picture VP or the next video picture to be encoded.

[0039] Figure 6 A schematic block diagram showing the steps of a method 200 for decoding a video image VP according to the prior art is shown.

[0040] In step 210 , partition information data, prediction information data and quantized transform coefficient blocks (or quantized residual blocks) are obtained by entropy decoding the bit stream of the encoded video image data. For example, this bit stream is generated according to method 100 .

[0041] The other information data may also be entropy decoded to decode the current block of the video picture VP from the bitstream.

[0042] In step 220, the reconstructed image is divided into current blocks based on the partition information. Each current block is entropy decoded from the bitstream along a decoding loop (also referred to as "in-loop"). Each decoded current block is a quantized transform coefficient block or a quantized prediction residual block.

[0043] In step 230, the current block is dequantized and possibly inversely transformed (step 240) to obtain a decoded prediction residual block.

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

[0045] Next, the decoded prediction residual block and the prediction block are then combined, typically summed, which provides the reconstructed block.

[0046] In step 270, the in-loop filter may be applied to the reconstructed image (including the reconstructed block), and the reconstructed block or the filtered reconstructed block forms a reference image, which may be stored in a decoded picture buffer (DPB) as discussed above ( Figure 5 ).

[0047] exist Figure 5 Step 130 / 135 or Figure 6 In step 260, an inter prediction block is defined from inter prediction data associated with a current block (CU or PU of a CU) of the video image. This inter prediction data comprises motion information which can be represented (encoded) according to the so-called AMVP mode (Adaptive Motion Vector Prediction) or the so-called merge mode.

[0048] In HEVC, in AMVP mode, the motion information used to define the inter-frame prediction block is represented by up to 2 reference video image indexes, and the up to 2 reference video image indexes are respectively associated with up to 2 reference video image lists (usually represented as L0 and L1). The reference video image reference list L0 includes at least one reference video image, and the reference video image reference list L1 includes at least one reference video image. Each reference video image index is a temporal prediction relative to the current block. The motion information further includes up to 2 motion vectors, each motion vector is associated with a reference video image index of one of 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 vector, an AMVP (Adaptive Motion Vector Predictor) candidate is selected from the AMVP candidate list (constructed on the encoding and decoding side), and MVd is signaled to the bitstream. The AMVP candidate index of the AMVP candidate selected in the AMVP candidate list is also signaled in the bitstream.

[0049] Figure 7 An illustrative example for constructing an AMVP candidate list for defining an inter-frame prediction block for a current block of a current video picture is shown.

[0050] 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 the motion information associated with the inter-frame prediction block of the current block, if any, located at the left adjacent position A0, A1 of the current block; the second MVP candidate is derived from the motion information associated with the inter-frame prediction block of the current block, if any, located at the top adjacent position B0, B1 and B2 of the current block. A redundancy check is then performed between the derived spatial MVP candidates, i.e., repeated derived MVP candidates are discarded. The AMVP candidate list may further include a temporal MVP candidate, which is derived from the motion information associated with the co-located block (if any) at spatial position H or in other cases spatial position C in the reference video image. The temporal MVP candidate is scaled according to the temporal distance between the current video image and the reference video image. Finally, if the AMVP candidate list includes less than 2 MVP candidates, the AMVP candidate list is filled with zero motion vectors.

[0051] In HEVC, in merge mode, the motion information used to define the inter-frame prediction block is represented by a merge index that merges the MVP candidate list. Each merge index refers to the motion predictor information, which indicates which MVP is used to derive the motion information. The motion information is represented by a unidirectional or bidirectional temporal prediction type, up to 2 reference video picture indices, and up to 2 motion vectors, each motion vector is associated with a reference video picture index of one of the two reference video picture lists (L0 or L1).

[0052] No other information is signaled except the merge index. This means that the motion vector of the current block is set equal to the motion vector of the MVP candidate indicated by the merge index. Therefore, in contrast to merge mode, no MVd and reference picture index are signaled into the bitstream. Only the index of the selected merge candidate in the merge candidate list is also signaled in the bitstream.

[0053] Therefore, in contrast to AMVP mode, MVd and reference pictures are not signaled in merge mode. Only the merge index is signaled into the bitstream.

[0054] The combined MVP candidate list may include five spatial MVP candidates, which are Figure 7The current video image shown is derived. The first spatial MVP candidate is derived from the motion information associated with the inter-frame prediction block, if present, and is located at the left neighboring position A1; the second spatial MVP candidate is derived from the motion information associated with the inter-frame prediction block, if present, and is located at the upper neighboring position B1; the third spatial MVP candidate is derived from the motion information associated with the inter-frame prediction block, if present, and is located at the upper right neighboring position B0; the fourth spatial MVP candidate is derived from the motion information associated with the inter-frame prediction block, if present, and is located at the lower left neighboring position A0; the fifth spatial MVP candidate is derived from the above motion associated with the inter-frame prediction block, if present, and is located at the left neighboring position B2. Then a redundancy check is performed between the derived spatial MVPs, that is, the repeated derived MVP candidates are discarded. The merge candidate list may further include a temporal MVP candidate, named a TMVP candidate, which is derived from the motion information associated with the co-located block, if present, at position H in the reference video image, otherwise at the central spatial position "C". Then a redundancy check is performed between the derived spatial MVPs, that is, the repeated derived MVP candidates are discarded. Finally, when using the bidirectional temporal prediction type, if the merge candidate list includes less than 5 MVP candidates, a combined candidate is added to the merge candidate list. The combined candidate is derived from the motion information associated with one reference video picture list and relative to one MVP candidate already present in the merge candidate list, and the motion information is associated with another reference video picture list and relative to another MVP candidate already present in the merge candidate list. Finally, if the merge candidate list is still not full (5 merge candidates), the merge candidate list is filled with zero motion vectors.

[0055] In ECM (“Algorithmic Description of the Enhanced Compression Model 4 (ECM 4)”, M. Coban, F. Le Léannec, K. Naser, J. Joint Video Experts Team (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29, 23rd meeting, by teleconference, July 7-16, 2021, Document JVET-Y202-v2, https: / / jvet-experts.org / doc_end_user / documents / 25_Teleconference / wg11 / JVET-Y2025-v2.zip) states that the template matching (TM) method can be used to determine some MVP candidates in AMVP and merge modes. The TM method is a decoder-side motion vector refinement method. It refines the motion vector of a block by matching the template area above and to the left of the current block with the template in the search area of ​​the reference image, such as Figure 8 As shown. A better MV is searched around the initial MV of the current block, for example, in a [-8, +8]-pixel search range. A refined MV is obtained 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. The MVP candidate with the smallest template matching cost is selected and further refined.

[0056] Encoding motion information according to VVC can represent motion information more richly than HEVC encoding.

[0057] In VVC, motion representation can be provided according to AMVP mode or merge mode.

[0058] In VVC, in AMVP mode, the motion information used to define inter-frame prediction blocks is represented as in HEVC AMVP mode. If present, the AMVP candidate list may include spatial and temporal MVP candidates, as in HEVC. If present, the AMVP candidate list may further include 4 additional HMVP (history-based motion vector prediction) candidates. Finally, if the AMVP candidate list includes less than 2 MVP candidates, the AMVP candidate list is filled with zero motion vectors.

[0059] The HMVP candidates are derived from the previously encoded MVPs of adjacent or non-adjacent blocks related to the current block. To this end, the HMVP candidate table is maintained on both the encoder and decoder sides and updated in real time as a first-in-first-out (FIFO) buffer for MVP. There are up to 5 HMVP candidates in the table. After encoding a block, the table is updated by appending the associated motion information to the end of the table as a new HMVP candidate. The FIFO rule is applied to manage the table, in which, in addition to the basic FIFO mechanism, redundant candidates in the HMVP table are removed first instead of the first one. The table is reset at each CTU row to enable parallel processing.

[0060] AMVP mode uses the AMVR (Adaptive Motion Vector Resolution) algorithm. The AMVR tool allows MVd to be signaled at quarter-pixel, half-pixel, integer-pixel or 4-pixel luma sample resolution. This also allows bit savings when encoding the MVd information. In AMVR, the resolution of the motion vectors is selected at the block level.

[0061] Finally, the internal motion vector representation is implemented with 1 / 16 luma sample accuracy, instead of 1 / 4 luma sample accuracy in HEVC.

[0062] In VVC, in merge mode, the motion information used to define an inter-prediction block is represented the same as in HEVC merge mode.

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

[0064] In VVC, both MMVD (Merge mode with MV difference) mode and CIIP (Combined Intra / Inter Prediction) mode can establish a merge candidate list.

[0065] The MMVD mode allows encoding of limited motion vector differences (MVd) on selected merge candidates to represent motion information associated with inter-predicted blocks. MMVD encoding is limited to 4 vector directions and 8 magnitude values, from 1 / 4 luma samples to 32 luma samples, e.g. Fig. 9 As shown. The MMVD mode provides an intermediate level of accuracy, so an intermediate trade-off can be made between rate cost and MV (motion vector) accuracy to signal motion information. The MMVD offset can also be signaled into the bitstream. The motion vector is then derived by adding the MMVD offset to the MV predictor.

[0066] CIIP consists in predicting the current block of a video image by combining an inter prediction signal with an intra prediction signal. The inter prediction signal in CIIP mode is derived using the same prediction process as applied in the merge mode; and the intra prediction signal is derived by a conventional intra prediction process with a planar mode. The planar prediction mode consists in predicting a block by a spatial interpolation process between adjacent reconstructed samples of the prediction blocks located at the top and left of the block. The intra and inter prediction signals are then blended (combined) using a weighted average, where the calculation of the weight values ​​depends on the coding mode of the top and left neighboring blocks:

[0067] PCIIP=(Wmerge×Pmerge+Wintra×Pintra+2)>>2

[0068] Weight W merge and W intra The sum of is equal to 4, and these weights are constant throughout the current block.

[0069] In summary, in VVC, the merge candidate list may include spatial MVP candidates similar to HEVC, except that the two first candidates are swapped: candidate B1 is considered before candidate A1 during the construction of the merge candidate list. The merge candidate list may further include TMVP, similar to HEVC, HMVP candidates in VVC AMVP mode. Several HMVP candidates are inserted into the merge candidate list so that the merge candidate list reaches the maximum allowed number of MVP candidates (-1). The merge candidate list may also include up to 1 pairwise average candidate, calculated as follows: consider the two first merge candidates present in the merge candidate list and average their motion vectors. This average is calculated separately for each reference video image list L0 and L1. Therefore, if both MVPs are bidirectional, the motion vectors associated with the two lists L0 and L1 are averaged. If there is only one motion vector in the reference video image list, it is obtained as is to form a paired candidate. Finally, if the merge candidate list does not reach the maximum allowed number of MVP candidates, the merge candidate list is filled with zero motion vectors.

[0070] The intra-block copy (IBC) prediction mode is used in HEVC and VVC to encode screen content. It is well known that the IBC prediction mode significantly improves the coding efficiency of screen content materials. Since the IBC prediction mode is implemented as a block-level coding mode, block matching (BM) is performed at the encoder to find an optimal block vector (or motion vector) for each block to be predicted. The block vector indicates the displacement from the block to be predicted of the video image to the reference block, which has been reconstructed (decoded) inside the video image. The block vector of the IBC prediction block of the luminance sample has integer precision. The block vector of the IBC prediction block of the chrominance sample can also be rounded to integer precision. When combined with AMVR, the IBC prediction mode can switch between 1 pixel and 4 pixel motion vector precision. The IBC prediction mode is regarded as a third prediction mode in addition to the intra or inter prediction mode.

[0071] At the CU level, the IBC prediction mode is signaled with a flag indicating whether IBC-AMVP mode or IBC-Skip / Merge mode is used.

[0072] In IBC-skip / merge mode, the block vector used to define the IBC prediction block is represented by a merge index in the merge candidate list. The merge index is used to indicate the block vector in the merge candidate list. The merge candidate list may include spatial candidates, HMVP candidates and paired candidates. The acquisition of the HMVP (history-based motion vector prediction) candidate block vector predictor is similar to the classic inter-frame merge coding case. The HMVP contains a buffer of motion vector predictors, which is supplied when the coding unit is encoded in IBC mode in a given image. The HMVP buffer then includes a block vector buffer for providing candidates for predicting the block vector of the current coding unit for encoding or decoding in IBC mode.

[0073] By averaging two IBC merge candidates, a new paired IBC merge candidate can be generated. This means averaging the block vectors of the two first candidates in the merge list being constructed to form a so-called paired block vector prediction candidate for the block to be predicted. This paired candidate is added to the IBC merge candidate list after the HMVP candidate.

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

[0075] In IBC-AMVP mode, two block vector predictors are determined, one from the left neighbor of the block to be predicted and the other from the upper neighbor of the block to be predicted (if IBC is predicted). When either neighbor is not available, a default block vector predictor is considered. A flag is signaled to indicate the block vector predictor index. In practice, since at most 2 block vector prediction candidates are considered in IBC AMVP mode, the flag is sufficient to identify the block vector prediction candidate for encoding the block vector information of the coding unit. The block vector difference is encoded in the same way as the motion vector difference of the inter-frame coding unit.

[0076] In addition, in ECM, IBC-TM merge mode is defined as IBC prediction mode combined with template matching. The IBC-TM merge list involved in the IBC-TM merge mode is different from the list used by the IBC skip / merge mode. In the conventional TM merge mode, candidates are selected by pruning based on the motion distance between candidates. Zero motion candidates are replaced by (-W, 0), (0, -H), (-W, -H)MV.

[0077] In IBC-TM merge mode, the selected candidates are refined using a template matching method. The TM-merge flag is signaled to indicate whether to use template matching merge IBC mode.

[0078] In IBC-TM AMVP mode, up to 3 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 based on the blocks around the current block to be predicted, which have been encoded and / or decoded in the IBC coding mode. Each of these candidates is refined according to the commonly used template matching method and sorted according to their resulting TM cost. The TM cost is calculated as the distortion between the template area on the top and left side of the current block to be predicted (in its decoded and reconstructed state) and the corresponding top and left area around the candidate prediction block pointed to by the candidate block vector.

[0079] When used in IBC prediction mode, TM refinement is performed at integer pixel locations, and in IBC-TM AMVP mode, TM refinement is performed at integer precision or 4-pixel precision depending on the AMVR value. Refinement is performed within the existing IBC reference region.

[0080] The IBC prediction mode cannot be used in conjunction with VVC's inter-prediction tools such as CIIP and MMVD.

[0081] In VVC, unlike the HEVC screen content coding extension, the current video picture is not included as one of the reference pictures in the reference picture list 0 for IBC prediction. The block vector derivation process for IBC mode excludes all neighboring blocks in inter mode and vice versa.

[0082] In VVC, the IBC prediction mode shares the same process with the regular MV merge mode, including pairwise merge candidates and history-based motion predictor, but TMVP and zero vectors are not allowed because they are invalid for IBC prediction mode.

[0083] Separate HMVP buffers (5 candidates per buffer) are used for traditional MV and IBC prediction modes.

[0084] On the other hand, we observe that many aspects in the design of current IBC prediction tools make IBC designs more suitable for graphics and screen video content rather than natural video content.

[0085] This limits the compression performance improvement that can be obtained when using IBC prediction mode on video content captured by the camera.

[0086] The object of the present invention is to adapt the specification design of the IBC coding mode so that it at least maintains its coding performance for screen content and its performance is significantly improved when compressing natural video.

[0087] The problem solved by the present invention is to adapt the IBC prediction mode defined in VVC so that the compression efficiency is improved when the IBC prediction mode is activated on the video content captured by the camera, while at least maintaining the performance of the current IBC prediction mode on the screen content and the graphic content.

[0088] A prior art solution to the problem to be solved is to include the currently encoded or decoded video picture into a buffer of reference pictures (the so-called decoded picture buffer, DPB) for the temporal prediction of the current video picture block.

[0089] Then, the coding performance of the IBC prediction mode for natural sequences is likely to be improved compared to VVC.

[0090] However, the performance of IBC prediction mode may degrade on screen and graphic content because the motion representation and compensation are more adapted to natural content and less adapted to screen content.

[0091] In view of the above circumstances, at least one exemplary embodiment of the present application is designed. Summary of the invention

[0092] The following section presents a simplified summary of at least one exemplary embodiment in order to provide a basic understanding of some aspects of the present application. This summary is not an exhaustive overview of the exemplary embodiments. It is not intended to identify the key or important elements of the exemplary embodiments. The following summary only presents some aspects of at least one exemplary embodiment in a simplified form as a prelude to a more detailed description provided elsewhere in the document.

[0093] According to a first aspect of the present application, a method for predicting a video image block is provided, wherein the method comprises: signaling an intra block copy mode type, the intra block copy mode type indicating whether the intra block copy prediction mode is configured to predict video content captured by a camera, the intra block copy prediction mode determining at least one block vector for predicting the video image block from at least one reference block of a video image; when the intra block copy mode type indicates that the intra block copy prediction mode is configured to predict video content captured by a camera, configuring the intra block copy prediction mode to predict the video image block; and deriving a prediction block of the video image block according to the configured intra block copy mode prediction mode.

[0094] In an exemplary embodiment, the block belongs to a slice of a video picture and the type of intra block copy mode entered is signaled at the slice level.

[0095] In an exemplary embodiment, configuring an intra block copy prediction mode to predict video content captured by a camera further includes: signaling a syntax element (ibc_pred_idc_flag), the syntax element indicating whether bidirectional prediction is allowed, and if the syntax element indicates that bidirectional prediction is allowed; signaling two block vectors, the prediction of the video image block is the average of the two block vectors.

[0096] In an exemplary embodiment, configuring an intra block copy prediction mode to predict video content captured by a camera further includes signaling a syntax element (mvp_l1_flag) to identify a block vector predictor for each block vector in a list of block vectors associated with neighboring decoded blocks of a video image block, the neighboring blocks belonging to the video image.

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

[0098] In an exemplary embodiment, configuring an intra block 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 inside a video image, wherein each block vector difference is signaled using a sub-pixel level of precision.

[0099] In an exemplary embodiment, configuring the intra block copy prediction mode to predict video content captured by a camera further includes encoding each block vector difference, the encoding being limited to some vector directions and magnitudes.

[0100] In an exemplary embodiment, configuring the intra block copy prediction mode to predict video content captured by a camera further includes sending a signaling (step 310) syntax element (mmvd_merge_flag) to indicate whether the block vector difference encoding is limited to certain vector directions and magnitudes.

[0101] In an exemplary embodiment, configuring the intra block copy prediction mode to predict video content captured by a camera further includes signaling a syntax element (intra_tmp_flag) to indicate whether to derive a prediction block of the video image block using template matching based intra block copy prediction, or whether to derive a prediction block of the video image block according to the first aspect.

[0102] In an exemplary embodiment, deriving a prediction block of a video image block according to a configured intra block copy mode prediction mode includes: deriving a first prediction block of the video image block according to the configured intra block copy mode; deriving a second prediction block of the video image block; and deriving the prediction block of the video image block by blending the first prediction block and the second prediction block.

[0103] In an exemplary embodiment, the second prediction block is derived according to motion compensated prediction or intra prediction of the video image block.

[0104] According to a second aspect of the present application, there is provided a method for encoding a video image block based on a prediction block derived according to the method of the first aspect.

[0105] According to a third aspect of the present application, a method for decoding a video image block based on a prediction block derived according to the method of the first aspect is provided.

[0106] According to a fourth aspect of the present application, there is provided a bit stream formatted to include encoded video image data obtained by the method according to the first aspect.

[0107] According to a fifth aspect of the present application, a device is provided, comprising means for executing one of the methods according to the first, second and / or third aspects.

[0108] According to a sixth aspect of the present application, a computer program product is provided, which includes instructions that, when the program is executed by one or more processors, cause the one or more processors to execute the method according to the first, second and / or third aspect.

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

[0110] Specific properties of at least one embodiment of the exemplary embodiments and other objects, advantages, features and uses of at least one embodiment of the exemplary embodiments will become apparent from the following description of the examples in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0111] Reference will now be made, by way of example, to the accompanying drawings which show exemplary embodiments of the present application, and in which:

[0112] Figure 1 An example of a coding tree unit according to HEVC is shown;

[0113] Figure 2 An example of partitioning a coding unit into prediction units according to HEVC is shown;

[0114] Figure 3 An example of CTU partitioning according to VVC is shown;

[0115] Figure 4 An example of supported partitioning modes in multi-type tree partitioning according to VVC is shown;

[0116] Figure 5A schematic block diagram showing the steps of a method 100 for encoding a video image VP according to the prior art;

[0117] Figure 6 A schematic block diagram showing the steps of a method 200 for decoding a video image VP according to the prior art;

[0118] Figure 7 An illustrative example for constructing an AMVP candidate list for defining an inter-frame prediction block for a current block of a current video picture is shown;

[0119] Figure 8 An example of a template matching method according to the prior art is shown;

[0120] Fig. 9 An example of limited motion vector differences according to the prior art is shown;

[0121] Fig.10 Schematically shows a block diagram of a method 300 for predicting a video image block according to an exemplary embodiment;

[0122] Fig.11 An example of a method 400 for predicting a video image block according to the fifth exemplary embodiment of step 302 and its variants is shown; and

[0123] Fig.12 A schematic block diagram of an example of a system implementing various aspects and exemplary embodiments is illustrated.

[0124] Similar or identical elements are denoted by the same reference numerals. DETAILED DESCRIPTION

[0125] At least one of the exemplary embodiments will be described more fully below with reference to the accompanying drawings, wherein an example of at least one exemplary embodiment of the exemplary embodiments is depicted. However, the exemplary embodiments can be implemented in many alternative forms and should not be interpreted as being limited to the examples set forth herein. Thus, it should be understood that the exemplary embodiments are not intended to be limited to the specific forms disclosed. On the contrary, the present application is intended to cover all modifications, equivalents, and alternatives that fall within the spirit and scope of the present application.

[0126] At least one of these aspects generally relates to video image encoding and decoding, another aspect generally relates to transmitting a provided or encoded bitstream, and one of the other aspects relates to receiving / accessing a decoded bitstream.

[0127] At least one of these exemplary embodiments is described for encoding / decoding video images, but is extended to encoding / decoding video images (image sequences) in that each video image is sequentially encoded / decoded as described below.

[0128] In addition, at least one exemplary embodiment is not limited to the current version of VVC. The at least one exemplary embodiment may be applicable to existing or future developed VVC and proposed extensions. Unless otherwise specified or technically excluded, the various aspects described in this application may be used alone or in combination.

[0129] A pixel corresponds to the smallest display unit on the screen, which can be composed of one or more light sources (1 for a monochrome screen and 3 or more for a color screen).

[0130] A video image, also denoted as a frame or image frame, comprises at least one component (also referred to as an image component or channel) determined by a particular image / video format that specifies all information related to pixel values ​​and all information related to video image data that can be used by a display unit and / or any other device to display and / or decode said video image.

[0131] A video image comprises at least one component which is typically represented in the shape of an array of samples.

[0132] A monochrome video image includes a single component, while a color video image may include three components.

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

[0134] Each component of the video image may include a number of samples relative to the number of pixels of the screen on which the video image is intended to be displayed. In a variant, the number of samples included in a component may be a multiple (or fraction) of the number of samples included in another component of the same video image.

[0135] For example, in case the video format includes a luma component and two chroma components (such as a (Y, Cb, Cr) format), the chroma components may contain half the number of samples in width and / or height relative to the luma components, depending on the color format considered.

[0136] A sample is the smallest visual information unit that makes up a component of a video image. A sample value can be, for example, a brightness or chrominance value or a color value in (R, G, B) format.

[0137] The pixel value is the value of a screen pixel. For a monochrome video image, a pixel value can be represented by one sample, and for a color video image, a pixel value can be represented by multiple co-located samples. The co-located samples associated with a pixel refer to samples corresponding to the position of the pixel in the screen.

[0138] A video image is usually considered as a set of pixel values, with each pixel represented by at least one sample.

[0139] A block of a video image is a group of samples of a component of a video image. When the image / video format is the well-known (Y, Cb, Cr) format, a block of at least one luma sample or a block of at least one chroma sample may be considered, or when the image / video format is the well-known (R, G, B) format, a block of at least one color sample may be considered.

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

[0141] Generally speaking, the present application relates to a method for predicting a video image block, the method comprising signaling an intra block copy mode type, the intra block copy mode type indicating whether the intra block copy prediction mode is configured to predict video content captured by a camera, the intra block copy prediction mode determining a block vector for predicting the video image block from a reference block of a video image; when the intra block copy mode type indicates that the intra block copy prediction mode is configured to predict video content captured by a camera, configuring the intra block copy prediction mode to predict the video image block; and deriving a prediction block of the video image block according to the configured intra block copy mode prediction mode.

[0142] The present invention makes the intra-block copy (IBC) prediction mode more suitable for the prediction of the video content captured by the camera than the IBC prediction mode specified in VVC and ECM. The present invention enables video encoding / decoding switching between different configurations of IBC prediction modes, one for predicting the screen / graphics content and another for predicting the video content captured by the camera. The coding efficiency of a video image block involved in the predictive coding of the video image block based on the prediction block derived from the present invention is compared with the coding efficiency of the block according to the IBC prediction mode specified in VVC and ECM.

[0143] Other aspects and advantages of the present application will be described in the following specific exemplary embodiments with reference to the accompanying drawings.

[0144] Fig.10 A block diagram of a method 300 for predicting a video image block according to an exemplary embodiment is schematically shown.

[0145] The method 300 provides a prediction block for a video image block. The prediction block can be used for selecting a prediction mode in the method 100 or used as a prediction mode in the prediction process of the method 200.

[0146] The prediction information associated with the method 300 is signaled, that is, when the method 300 is used in the method 100 , the prediction information is written into the bitstream, and when the method 300 is used in the method 200 , the prediction information is parsed from the bitstream.

[0147] In step 301, an intra block copy mode type (IBC mode type for short) is signaled as prediction information. The IBC mode type indicates whether the IBC prediction mode is configured to predict video content captured by a camera. The IBC prediction mode determines at least one block vector for predicting a video image block from at least one (reconstructed) reference block of the video image.

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

[0149] In a variant, the IBC mode type is signaled only when the IBC prediction mode is activated.

[0150] Table 1 shows an example of signaling an IBC prediction mode type as a flag sh_ibc_camera_content_flag in a slice header syntax as defined by VVC according to an exemplary embodiment.

[0151]

[0152] Table 1

[0153] If the flag sh_ibc_camera_content_flag is equal to false (=0), the video image block using the IBC prediction mode in the corresponding slice adopts the IBC mode defined in VVC and ECM for screen content encoding.

[0154] If the flag sh_ibc_camera_content_flag is equal to true (= 1), the video image block using the IBC prediction mode in the corresponding slice adopts the prediction block derived from step 302 in method 300 for the video content captured by the camera. As described above, step 302 adapts (configures) the IBC prediction mode defined in VVC to improve the prediction of the video content captured by the camera, thereby improving the predictive coding efficiency of the video content captured by the camera.

[0155] When the IBC mode type indicates that the IBC prediction mode is configured to predict the video content captured by the camera, in step 302 the IBC prediction mode is configured to predict the video content captured by the camera, and in step 303, the prediction block is derived by predicting the video image block according to the configured IBC prediction mode.

[0156] In a first exemplary embodiment of step 302, configuring (step 302) the intra block copy prediction mode to predict the video content captured by the camera further comprises signaling (step 304) the syntax element ibc_pred_idc_flag as prediction information to indicate whether bi-directional prediction is allowed.

[0157] In a variant of the first exemplary embodiment of step 302, if the syntax element ibc_pred_idc_flag indicates that bidirectional prediction is allowed, configuring (302) an intra block copy prediction mode to predict video content captured by the camera further includes signaling (305) two block vectors as prediction information, and then the prediction block of the video image block can be the average of the two block vectors (step 303).

[0158] In a second exemplary embodiment of step 302, configuring (302) the intra block copy prediction mode to predict video content captured by the camera further includes signaling (306) the syntax element mvp_l1_flag as prediction information to identify a block vector predictor for each block vector of the IBC prediction mode in a list of block vectors associated with neighboring (decoded) blocks of the video image block, the neighboring (decoded) blocks belonging to the video image.

[0159] Table 2 shows the syntax of the VVC modified according to the first and second exemplary embodiments and their variants related to the video image block and according to step 302.

[0160]

[0161] Table 2

[0162] In a third exemplary embodiment of step 302, at least one block vector determined by the IBC prediction mode may be represented using a sub-pixel resolution level similar to AMVR in the inter-prediction mode of VVC / ECM. Thus, a spatial interpolation filter similar to the spatial interpolation filter applied to the inter-prediction mode of VVC for motion vector compensation may be applied to the at least one block vector.

[0163] In a variation of the third exemplary embodiment of step 302, configuring (302) the intra block copy prediction mode to predict video content captured by the camera further comprises signaling the sub-pixel resolution level as prediction information (step 307).

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

[0165] In a variation of the fourth exemplary embodiment of step 302, each block vector difference is signaled using a sub-pixel precision level and a spatial interpolation filter similar to that applied to the inter prediction mode of motion vector compensated VVC may be applied.

[0166] In a variation of the fourth exemplary embodiment of step 302, configuring (302) the intra block copy prediction mode to predict the video content captured by the camera further comprises encoding (step 309) the block vector differences, said encoding being limited to some vector directions and magnitudes.

[0167] For example, block vector differences are restricted to 4 vector directions and 8 magnitude values, from 1 / 4 luma sample to 32 luma samples, as with motion vector differences coded according to MMVD. Block vector offsets can be applied to the block vector predictor to reconstruct block vectors for IBC prediction mode, similar to how MMVD as defined in VVC is applied to the motion vector predictor to reconstruct motion vectors.

[0168] In a variation of the fourth exemplary embodiment of step 302, when merge mode is activated, configuring (302) an intra block copy prediction mode to predict video content captured by the camera further includes signaling (step 310) a syntax element mmvd_merge_flag as prediction information to indicate whether block vector difference encoding is limited to some vector directions and magnitudes.

[0169] In a variant of the fourth exemplary embodiment of step 302, configuring (302) the intra block copy prediction mode to predict the video content captured by the camera further includes signaling (step 311) a syntax element mmvd_cand_flag to indicate a merge candidate block vector index in the mmvd merge candidate list, which is used to derive the block vector of the video image block to be predicted. The mmvd merge candidate list is basically a subset of the regular merge candidate list, consisting of only two elements. Basically, the first two merge candidates in the regular merge candidate list are used to form the mmvd merge candidate list. In fact, 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.

[0170] In a fourth exemplary embodiment variation of step 302, configuring (302) an intra block copy prediction mode to predict video content captured by a camera comprises signaling (step 312) two syntax elements mmvd_distance_idx and mmvd_direction_idx to indicate a block vector offset associated with a block vector difference.

[0171] Table 3 is an example of VVC syntax associated with merged data and modified according to the fourth exemplary embodiment of step 302 and its variants.

[0172]

[0173] Table 3

[0174] Fig.11 An example of a method 400 of predicting a video image block according to the first, second and fourth exemplary embodiments of step 302 discussed above and variations thereof is shown.

[0175] According to an exemplary embodiment of step 302, prediction information is obtained. The prediction information may be determined at the encoding method 100 and parsed from the bitstream at the decoding method 200.

[0176] According to exemplary embodiments and variants of step 302 , the prediction information may include syntax elements ibc_pred_idc_flag, mvp_l1_flag, mmvd_merge_flag, mmvd_cand_flag, mmvd_distance_idx, mmvd_direction_idx, at least a block vector difference and / or a sub-pixel resolution level.

[0177] In step 401 , the method checks whether the merge mode is activated.

[0178] If not, then one or two block vectors are reconstructed in steps 402-406 and

[0179] In step 402, the first block of vector differences The prediction information is converted from the sub-pixel resolution level to the internal precision used for the block vector representation. This results in the first block vector difference

[0180] In step 403, by and the first block vector predictor obtained from the syntax element mvp_l1_flag Add to reconstruct the first block of vectors

[0181]

[0182] In step 404 , the method 400 checks whether the syntax element ibc_pred_idc_flag allows bi-directional prediction.

[0183] If not, step 404 is followed by step 412 .

[0184] If yes, step 404 is followed by step 405 and step 406 .

[0185] In step 405, the second block of vector difference (Prediction information) is converted from the sub-pixel resolution level to the internal precision used for block vector representation. This results in the second block vector difference

[0186] In step 406, the second block vector difference and the second block vector predictor Add to reconstruct the second block vector

[0187]

[0188] Step 406 is followed by step 412 .

[0189] If the merge mode is activated (step 401), one or two block vectors are reconstructed in steps 407-411 and

[0190] In step 407 , the method 400 checks whether the syntax element mmvd_merge_flag indicates that the (de)coding of block vector differences is limited to certain vector directions and magnitudes.

[0191] If not, in step 408, two block vectors are derived according to the merge mode and The two block vector merge candidates are indicated by the syntax element merge_idx.

[0192] If yes, then one or both blocks are reconstructed in steps 409-411 and

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

[0194] If you merge candidate block vectors using a single block vector Then, in steps 410 and 411, a single block vector predictor is derived In step 410, a single block vector offset is derived from the syntax elements mmvd_distance_idx and mmvd_direction_idx In step 411, the block vector is done by offsetting the block vector With block vector predictor Deduced by addition:

[0195]

[0196] If the candidate block vector is merged using two block vectors and Then two block vector predictors are derived in steps 410 and 411 In step 410, a single block vector offset is derived from the syntax elements mmvd_distance_idx and mmvd_direction_idx In step 411, the block vector is done by offsetting the block vector With block vector predictor The block vector derived by adding is done by offsetting the block vector With block vector predictor Deduced by addition:

[0197]

[0198] Step 411 is followed by step 412 .

[0199] In step 411, method 400 reconstructs a single block vector Or reconstruct the block vector from two The prediction block of the video image block is derived by mixing.

[0200] In the variant, the block vector offset The mirror value can be compared with the block vector predictor Add:

[0201] In a variant, a second block vector difference may be parsed from the bitstream and compared to the block vector predictor candidate Add.

[0202] In the variant, block vector offset is not used To reconstruct the block vector

[0203] In a variant, each block vector difference is encoded / decoded according to the syntax element mmvd_merge_flag. The encoding is limited to some vector directions and magnitudes.

[0204] In a fifth exemplary embodiment of step 302, configuring (302) the intra block copy prediction mode to predict video content captured by the camera further includes signaling (step 313) a syntax element intra_tmp_flag to indicate whether intra block copy prediction based on template matching (IBCTMP) is used to derive the prediction block for the video image block.

[0205] Basically, IBCTMP is similar to the IBC prediction mode, except that the reference area used to predict the video image block is based on a template matching (TM) search instead of being signaled through a block vector as in the IBC prediction mode.

[0206] If the syntax element intra_tmp_flag is equal to 1, the prediction block of the video picture is derived using IBCTMP. Therefore, no block vector related information is encoded in the bitstream. Rather, it is searched synchronously on both the encoder and decoder sides.

[0207] This search is based on template matching, as done in template matching processes dedicated to screen content. In addition, since IBCTMP is used for camera-captured content, template matching searches not only integer positions of reference blocks, but also fractional spatial positions between luma samples, as done in template matching in inter-frame prediction.

[0208] If the syntax element intra_tmp_flag is equal to 0, the IBC prediction mode configured according to one of the embodiments of step 302 and its variants is used for the prediction block of the video picture as described above.

[0209] Table 4 shows a syntax structure based on the syntax structure of Table 2 and modified according to the second and sixth exemplary embodiments and variations thereof.

[0210]

[0211] Table 4

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

[0213] In a variant of the exemplary embodiment of step 303, the further prediction block is derived from a motion compensated prediction of the video image block.

[0214] The advantage of this exemplary embodiment is that it provides a means to perform bidirectional prediction of video image blocks based on the reference block of the reference image of the current video image and the reconstructed block area of ​​the current video image. This prediction mode further improves the coding efficiency based on the prior art.

[0215] In a variant of the exemplary embodiment of step 303, the further prediction block is derived from an intra prediction of the video image block.

[0216] For example, intra prediction can be DC, planar, direct mode, horizontal and vertical angle prediction for VVC, DIMD (decoder-side intra mode derivation) or TIMD (template-based intra mode derivation) for ECM. These coding modes are described in the ECM document ("Algorithmic Description of Enhanced Compression Model 4 (ECM 4)", M. Coban, F. Le Léannec, K. Naser, J. Joint Video Experts Team (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29, 23rd meeting, by teleconference, July 7-16, 2021, Document JVET-Y2025-v2, https: / / jvet-experts.org / doc_end_user / documents / 25_Teleconference / wg11 / JVET-Y2025-v2.zip).

[0217] DC is an intra prediction mode that uses the mean sample value of the reference samples to the left and above the block to generate the prediction.

[0218] The planar mode is a weighted average of 4 reference sample values ​​(picked as orthogonal projections of the samples, predicted in the top and left reconstruction regions).

[0219] Direct mode (DM) is a chroma intra prediction mode that corresponds to the intra prediction mode for co-located reconstructed luma samples.

[0220] The horizontal and vertical modes use copies of the reconstructed samples to the left and above without interpolation to predict the rows and columns of samples, respectively.

[0221] In a variation of the exemplary embodiment of step 303 , the blending may be similar to a CIIP mode.

[0222] Compared to the CIIP mode in VVC, the exemplary embodiment of step 303 improves coding efficiency because the intra predictor is an IBC predictor optimized for predicting video content captured by a camera.

[0223] In a variant of the exemplary embodiment of step 303, the method 300 further comprises signaling 317 a syntax element regular_merge_flag into the bitstream. The syntax element regular_merge_flag is equal to 1 to indicate that the prediction block of the video image block is derived according to one of the exemplary embodiments or a variant of step 302. The syntax element regular_merge_flag is equal to 0 to indicate that the IBC prediction block is combined with the further prediction block of the video image.

[0224] In a variation of the exemplary embodiment of step 303 , a syntax element regular_merge_flag is added in Table 5, which is an example of VVC syntax related to merged data and modified according to the sixth exemplary embodiment of step 302 .

[0225] Table 5 shows a syntax structure modified according to Table 3 and according to the exemplary embodiment of step 303 and its variants.

[0226]

[0227] Table 5

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

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

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

[0231] Fig.12 A schematic block diagram illustrating an example of a system 600 implementing various aspects and exemplary embodiments is shown.

[0232] The system 600 may be embedded as one or more devices, including various components described below. In various exemplary embodiments, the system 600 may be configured to implement one or more aspects described in this application.

[0233] Examples of equipment that may constitute all or part of system 600 include personal computers, laptop computers, smart phones, tablet computers, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected household appliances, connected vehicles and their associated processing systems, head-mounted display devices (HMD, perspective glasses), projectors (projectors), "caves" (systems including multiple displays), servers, video encoders, video decoders, post-processors for processing outputs from video decoders, pre-processors for providing inputs to video encoders, web servers, video servers (e.g., broadcast servers, video-on-demand servers, or network servers), static or video cameras, encoding or decoding chips, or any other communication devices. The elements of system 600 may be implemented individually or in combination in a single integrated circuit (IC), multiple ICs, and / or discrete 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 discrete components. In various exemplary embodiments, system 600 may be coupled to other similar systems or other electronic devices via, for example, a communication bus or via dedicated input and / or output ports.

[0234] The system 600 may include at least one processor 610 configured to execute instructions loaded therein for implementing, for example, various aspects described in the present application. 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, which may include a non-volatile memory and / or a volatile memory, including but not limited to an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), a programmable read-only memory (PROM), a random access memory (RAM), a dynamic random access memory (DRAM), a static random access memory (SRAM), a flash memory, a disk drive, and / or an optical drive. As a non-limiting example, the storage device 640 may include an internal storage device, an attached storage device, and / or a network accessible storage device.

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

[0236] Program code to be loaded onto the processor 610 or the encoder / decoder 630 to perform various aspects described in the present application may be stored in the storage device 640 and subsequently loaded onto the memory 620 to be executed by the processor 610. According to various exemplary embodiments, during the execution of the processes described in the present application, one or more of the processor 610, the memory 620, the storage device 640, and the encoder / decoder module 630 may store one or more of various items. Such stored items may include, but are not limited to, video image data, information data for encoding / decoding video image data, bit streams, matrices, variables, and intermediate or final results of equations, formulas, operations, and operation logic processing.

[0237] In several exemplary embodiments, memory internal to the processor 610 and / or encoder / decoder module 630 may be used to store instructions and provide working memory for processes that may be performed during encoding or decoding.

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

[0239] As indicated in block 690, input to the elements of system 600 may be provided through various input devices. Such input devices include, but are not limited to, (i) an RF section that may receive an RF signal transmitted over the air, for example, by a broadcast device, (ii) a composite input terminal, (iii) a USB input terminal, (iv) an HDMI input terminal, (v) when the present disclosure is implemented in the automotive field, 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.

[0240] In various exemplary embodiments, the input device of block 690 has associated corresponding input processing elements, as known in the art. For example, the RF portion may be associated with elements necessary for: (i) selecting a desired frequency (also referred to as selecting a signal, or band-limiting a signal to a frequency band), (ii) down-converting the selected signal, (iii) band-limiting the frequency band again to a narrower frequency band to select a signal band that may be referred to as a channel in some exemplary embodiments, (iv) demodulating the down-converted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select a desired packet stream. The RF portion of various exemplary embodiments may include one or more elements that perform these functions, such as a frequency selector, a signal selector, a band limiter, a channel selector, a filter, a down-converter, a demodulator, an error corrector, and a demultiplexer. The RF portion may include a tuner that performs various of these functions, including, for example, down-converting a received signal to a lower frequency (e.g., an intermediate frequency or a near-baseband frequency) or a baseband.

[0241] In one set-top box embodiment, the RF section and its associated input processing elements can receive RF signals transmitted over a wired (e.g., cable) medium. The RF section can then perform frequency selection by filtering, down-converting, and filtering again to a desired frequency band.

[0242] Various exemplary embodiments rearrange the order of the above-described (and other) elements, remove some of these elements, and / or add other elements that perform similar or different functions.

[0243] Adding components may include inserting components between existing components, such as, for example, inserting an amplifier and an analog-to-digital converter.In various exemplary embodiments, the RF portion may include an antenna.

[0244] In addition, the USB and / or HDMI terminals may include corresponding interface processors for connecting the system 600 to other electronic devices via USB and / or HDMI connections. It should be understood that various aspects of input processing (e.g., Reed-Solomon error correction) may be implemented, for example, in a separate input processing IC or in the processor 610 when necessary. Similarly, various aspects of USB or HDMI interface processing may be implemented in a separate interface IC or in the processor 610 when necessary. The demodulated, error-corrected, and demultiplexed streams may be provided to various processing elements, including, for example, the processor 610 and the encoder / decoder 630, which operate in conjunction with the memory and storage elements to process the data streams for presentation on the output device when necessary.

[0245] The various elements of system 600 may be provided within an integrated housing. Within the integrated housing, the various elements may be interconnected and data transferred between them using a suitable connection arrangement 690, such as an internal bus (including an I2C bus), wiring, and printed circuit boards known in the art.

[0246] The system 600 may include a communication interface 650 that enables communication with other devices via a communication channel 651. The communication interface 650 may include, but is not limited to, a transceiver configured to send and receive data over 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 may be implemented, for example, within a wired and / or wireless medium.

[0247] In various exemplary embodiments, a Wi-Fi network such as IEEE 802.11 may be used to stream data to the system 600. The Wi-Fi signals of these exemplary embodiments may be received via a communication channel 651 suitable for Wi-Fi communications and a communication interface 650. The communication channel 651 of these exemplary embodiments may typically connect to an access point or router that provides access to external networks including the Internet to allow streaming applications and other over-the-top communications.

[0248] Other exemplary embodiments may provide streamed data to system 600 using a set top box that delivers the data through an HDMI connection to input block 690 .

[0249] Still other exemplary embodiments may provide streaming data to the system 600 using an RF connection to input block 690 .

[0250] The streamed data may be used as a means of signaling information used by the system 600. The signaling information may include the bitstream B and / or information such as the number of pixels of a video image and / or any encoding / decoding setting parameters.

[0251] It should be appreciated that signaling may be implemented in a variety of ways. For example, in various exemplary embodiments, one or more syntax elements, flags, etc. may be used to signal information to a corresponding decoder.

[0252] The system 600 may provide output signals to various output devices, including a display 661, speakers 671, and other peripherals 681. In various examples of the exemplary embodiments, the other peripherals 681 may include one or more of a stand-alone DVR, a disk player, a stereo system, a lighting system, and other devices that provide functionality based on the output of the system 600.

[0253] In various exemplary embodiments, control signals may be communicated between the system 600 and the display 661, speakers 671, or other peripheral devices 681 using signaling such as AV.Link (Audio / Video Link), CEC (Consumer Electronics Control), or other communication protocols that enable device-to-device control with or without user intervention.

[0254] Output devices may be communicatively coupled to system 600 via dedicated connections through respective interfaces 660 , 670 , and 680 .

[0255] Optionally, output devices may be connected to system 600 using communication channel 651 via communication interface 650. Display 661 and speaker 671 may be integrated into a single unit with other components of system 600 in an electronic device such as, for example, a television.

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

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

[0258] exist Figures 1 to 12 In the present invention, various methods are described herein, and each method includes one or more steps or actions to implement the described method. Unless a specific order of steps or actions is required for the correct operation of the method, the order and / or use of specific steps and / or actions can be modified or combined.

[0259] Some examples are described about block diagrams and / or operational flow charts. Each square block represents a portion of a circuit element, module or code, which includes one or more executable instructions for implementing (one or more) specified logical functions. It should also be noted that, in other embodiments, the (one or more) functions marked in the square block may not occur in the order indicated. For example, depending on the functions involved, two square blocks shown in succession can actually be executed substantially concurrently, or sometimes these square blocks can be executed in reverse order.

[0260] The embodiments and aspects described herein may be implemented in, for example, a method or process, an apparatus, a computer program, a data stream, a bit stream, or a signal. Even if only discussed in the context of a single form of embodiment (e.g., discussed only as a method), the embodiments of the features discussed may also be implemented in other forms (e.g., an apparatus or a computer program).

[0261] The method may be implemented in, for example, a processor, which generally refers to a processing device, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. The processor also includes a communication device.

[0262] In addition, the method can be implemented by instructions executed by a processor, and such instructions (and / or data values ​​generated by the implementation) can be stored on a computer-readable storage medium. The computer-readable storage medium can take the form of a computer-readable program product implemented in one or more computer-readable media and having a computer-readable program code implemented thereon that can be executed by a computer. Considering the inherent ability to store information therein and the inherent ability to provide information retrieval therefrom, the computer-readable storage medium used herein can be considered to be a non-transitory storage medium. The computer-readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or device, or any suitable combination of the foregoing. It should be recognized that although more specific examples of computer-readable storage media to which the present exemplary embodiment can be applied are provided below, as those of ordinary skill in the art will readily recognize, it is merely an illustrative and non-exhaustive list: portable computer floppy disk; hard disk; read-only memory (ROM); erasable programmable read-only memory (EPROM or flash memory); portable compact disk read-only memory (CD-ROM); optical storage device; magnetic storage device; or any suitable combination of the foregoing.

[0263] The instructions may form an application program tangibly embodied on a processor-readable medium.

[0264] For example, instructions may be in hardware, firmware, software, or a combination. For example, instructions may be found in an operating system, a separate application, or a combination of both. Thus, a processor may be characterized as, for example, a device configured to perform a process and a device including a processor-readable medium (such as a storage device) having instructions for performing the process. Additionally, in addition to or in lieu of instructions, a processor-readable medium may store data values ​​generated by an embodiment.

[0265] Device can be realized in suitable hardware, software and firmware for example.The example of such device comprises personal computer, laptop computer, smart phone, tablet computer, digital multimedia set-top box, digital television receiver, personal video recording system, connected household appliances, head-mounted display device (HMD, perspective glasses), projector (projector), "cave" (system including multiple displays), server, video encoder, video decoder, post-processor for processing the output from video decoder, pre-processor for providing input to video encoder, web server, set-top box, and any other equipment for processing video image, or other communication equipment.It should be clear that equipment can be mobile and even installed in a mobile vehicle.

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

[0267] As will be apparent to one of ordinary skill in the art, embodiments may generate various signals formatted to carry information that may be stored or transmitted, for example. The information may include, for example, instructions for executing a method or data generated by one of the described embodiments. For example, a signal may be formatted to carry a bit stream of the described exemplary embodiments. Such a signal may be formatted, for example, as an electromagnetic wave (e.g., using a radio frequency portion of a spectrum) or a baseband signal. Formatting may include, for example, 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 known, the signal may be transmitted over a variety of different wired or wireless links. The signal may be stored on a processor readable medium.

[0268] The terms used herein are only used to describe the purpose of specific exemplary embodiments and are not intended to be limited. As used herein, the singular "a / kind (a)", "an / kind (an)" and "the / said (the)" may also be intended to include plural forms, unless the context clearly indicates otherwise. It will be further understood that, when used in this specification, the terms "include / comprise" and / or "including / comprising" may specify the existence of stated, for example, features, integers, steps, operations, elements and / or components, but do not exclude the existence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups. Moreover, when an element is referred to as "response" or "connection" or "associated" to another element, it may directly respond or be connected to another element or be associated with another element, or there may be an intermediate element. On the contrary, when an element is referred to as "direct response" or "direct connection" to another element or "directly associated" with another element, there is no intermediate element.

[0269] It should be appreciated that use of any of the symbols / terms " / ", "and / or", and "at least one of" may be intended to encompass selection of only the first listed option (A), or only the second listed option (B), or both options (A and B), such as in the case of "A / B", "A and / or B", and "at least one of A and B". As a further example, in the case of "A, B, and / or C" and "at least one of A, B, and C", such wording is intended to encompass selection of only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed options (A and C), or only the second and third listed options (B and C), or all three options (A and B and C). This may be extended to as many items as listed, as will be apparent to one of ordinary skill in this and related arts.

[0270] Various numerical values ​​may be used in the present application. Specific values ​​may be used for example purposes and the described aspects are not limited to these specific values.

[0271] It will be understood that although the terms first, second, etc. can be used to describe various elements in this article, these elements are not limited by these terms. These terms are only used to distinguish one element from another element. For example, without departing from the teaching of this application, the first element can be referred to as the second element, and similarly, the second element can be referred to as the first element. There is no suggestion of sorting between the first element and the second element.

[0272] References to "an exemplary embodiment" or "exemplary embodiments" or "one implementation" or "implementation" and other variations thereof are frequently used to convey that a particular feature, structure, characteristic, etc. (described in conjunction with an exemplary embodiment / implementation) is included in at least one exemplary embodiment / implementation. Thus, the appearances of the phrases "in an exemplary embodiment" or "in an exemplary embodiment" or "in one implementation" or "in an implementation" and any other variations appearing in various places in this application are not necessarily all referring to the same exemplary embodiment.

[0273] Similarly, references herein to "according to an exemplary embodiment / example / implementation" or "in an exemplary embodiment / example / implementation" and other variations thereof are frequently used to convey that a particular feature, structure, or characteristic (described in conjunction with an exemplary embodiment / example / implementation) may be included in at least one exemplary embodiment / example / implementation. Therefore, the expressions "according to an exemplary embodiment / example / implementation" or "in an exemplary embodiment / example / implementation" appearing in various places in this application do not necessarily all refer to the same exemplary embodiment / example / implementation, nor are separate or alternative exemplary embodiments / examples / implementations necessarily mutually exclusive of other exemplary embodiments / examples / implementations.

[0274] Reference numerals appearing in the claims are for illustration purposes only and have no limiting effect on the scope of the claims.The present exemplary embodiments / examples and variants may be employed in any combination or sub-combination although not explicitly described.

[0275] When a figure is presented as a flow chart, it should be understood that it also provides a block diagram of the corresponding apparatus. Similarly, when a figure is presented as a block diagram, it should be understood that it also provides a flow chart of the corresponding method / process.

[0276] While some diagrams include arrows on communication paths to illustrate a primary direction of communication, it should be understood that communication can occur in the opposite direction to the depicted arrows.

[0277] Various embodiments relate to decoding. As used in this application, "decoding" may encompass, for example, all or part of a process performed on a received video image (which may include a received bitstream encoding one or more video images) to produce a final output suitable for display or further processing in a reconstructed video domain. In various exemplary embodiments, such a process includes one or more of the processes typically performed by a decoder. In various exemplary embodiments, for example, such a process also or alternatively includes a process performed by a decoder of the various embodiments described in this application.

[0278] As a further example, in one exemplary embodiment, "decoding" may refer only to dequantization, in one exemplary embodiment, "decoding" may refer to entropy decoding, in another exemplary embodiment, "decoding" may refer only to differential decoding, and in another exemplary embodiment, "decoding" may refer to a combination of dequantization, entropy decoding, and differential decoding. Whether the phrase "decoding process" may be intended to specifically refer to a subset of operations, or to generally refer to a broader decoding process will be clear, and is believed to be well understood by those skilled in the art, based on the context of the particular description.

[0279] Various embodiments are all related to encoding. In a manner similar to the above discussion about "decoding", "encoding" as used in this application can cover, for example, all or part of a process performed on an input video image to produce an output bit stream. In various exemplary embodiments, such a process includes one or more of the processes typically performed by an encoder. In various exemplary embodiments, such a process also includes or optionally includes a process performed by an encoder of the various embodiments described in this application.

[0280] As a further example, in one exemplary embodiment, "encoding" may refer only to quantization, in one exemplary embodiment, "encoding" may refer only to entropy coding, in another exemplary embodiment, "encoding" may refer only to differential coding, and in another exemplary embodiment, "encoding" may refer to a combination of quantization, differential coding, and entropy coding. Based on the context of the particular description, whether the phrase "encoding process" may be intended to specifically refer to a subset of operations, or to generally refer to a broader encoding process will be clear and is believed to be well understood by those skilled in the art.

[0281] Additionally, the present application may refer to "obtaining" various information. Obtaining information may include, for example, one or more of estimating information, calculating information, predicting information, or retrieving information from a memory, processing information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0282] Additionally, this application may refer to "receiving" various information. Receiving information may include, for example, one or more of accessing the information or receiving the information from a communication network.

[0283] Moreover, as used herein, the word "signal" especially refers to indicating something to a corresponding decoder, etc. For example, in some exemplary embodiments, the encoder signals specific information, such as encoding parameters or encoded video image data. In this way, in exemplary embodiments, the same parameter can be used on the encoder side and the decoder side. Therefore, for example, the encoder can transmit (explicit signaling) specific parameters to the decoder so that the decoder can use the same specific parameters. On the contrary, if the decoder already has specific parameters and other parameters, signaling can be used without transmission (implicit signaling) to simply allow the decoder to know and select specific parameters. By avoiding the transmission of any actual function, bit saving is achieved in various exemplary embodiments. It should be recognized that signaling can be completed in a variety of ways. For example, in various exemplary embodiments, one or more syntax elements, flags, etc. are used to signal information to the corresponding decoder. Although the verb form of the word "signal" is mentioned above, the word "signal" can also be used as a noun in this article.

[0284] A number of embodiments have been described. However, it should be understood that various modifications may be made. For example, elements of different embodiments may be combined, supplemented, modified, or removed to produce other embodiments. In addition, it will be understood by those of ordinary skill that other structures and processes may replace the disclosed structures and processes, and that the resulting embodiments will perform at least substantially the same (one or more) functions in at least substantially the same (one or more) manners to achieve at least substantially the same (one or more) results as the disclosed embodiments. Thus, the present application contemplates these and other embodiments.

Claims

1. A method for predicting a video image block, wherein the method comprises: - signalling (301) an intra block copy mode type, the intra block copy mode type indicating whether an intra block copy prediction mode is configured to predict video content captured by a camera, the intra block copy prediction mode determining at least one block vector for predicting a video image block from at least one reference block of the video image; - when the Intra Block Copy Mode Type indicates that the Intra Block Copy prediction mode is configured to predict video content captured by the camera, - configuring (302) an intra block copy prediction mode to predict a video image block; and - deriving (303) a prediction block for the video image block according to the configured intra block copy mode prediction mode.

2. The method of claim 1, wherein the block belongs to a slice of the video picture, the intra block copy mode type being signaled (301) at slice level.

3. The method of claim 1 or 2, configuring (302) an intra block copy prediction mode to predict video content captured by a camera, further comprising: - signaling (304) a syntax element (ibc_pred_idc_flag) indicating whether bi-prediction is allowed, and if the syntax element indicates that bi-prediction is allowed; - signalling (305) two block vectors, the prediction of the video image block being the average of the two block vectors.

4. The method of claims 1 to 3, wherein configuring (302) an intra block copy prediction mode to predict video content captured by a camera further comprises signaling (306) a syntax element (mvp_l1_flag) to identify a block vector predictor for each block vector in a list of block vectors associated with neighboring decoded blocks of a video image block, the neighboring blocks belonging to the video image.

5. The method of one of claims 1 to 4, wherein at least one block vector is represented at a sub-pixel precision level.

6. The method of one of claims 1 to 5, wherein configuring (302) an intra block copy prediction mode to predict video content captured by a camera further comprises signaling (308) at least one block vector difference calculated between a block vector and a reference block inside a video image, and wherein each block vector difference is signaled using a sub-pixel precision level.

7. The method of claim 6, wherein configuring (302) an intra block copy prediction mode to predict video content captured by a camera further comprises encoding (309) each block vector difference, the encoding being limited to some vector directions and magnitudes.

8. The method of claim 7, wherein configuring (302) an intra block copy prediction mode to predict video content captured by a camera further comprises signaling (step 310) a syntax element (mmvd_merge_flag) to indicate whether block vector difference coding is limited to certain vector directions and magnitudes.

9. The method of claim 1 or 2, wherein configuring (302) an intra block copy prediction mode to predict video content captured by a camera further comprises signaling (313) a syntax element (intra_tmp_flag) to indicate whether a prediction block for a video image block is derived using template matching based intra block copy prediction or whether a prediction block for a video image block is derived according to one of claims 1 to 11.

10. The method of claim 1 or 2, wherein deriving (303) a prediction block of a video image block according to a configured intra block copy mode prediction mode comprises: - deriving (314) a first prediction block of the video image block according to the configured intra block copy prediction mode; - deriving (315) a second prediction block for the video image block; as well as - deriving (316) a prediction block for the video image block by blending the first prediction block and the second prediction block.

11. The method of claim 10, wherein the second prediction block is derived based on motion compensation prediction or intra prediction of the video image block.

12. Method for encoding a video image block based on a prediction block, the prediction block being derived according to a method according to one of claims 1 to 11.

13. Method for decoding a video image block based on a prediction block, the prediction block being derived according to a method according to one of claims 1 to 11.

14. A bit stream formatted to include coded video image data obtained according to the method of one of claims 1 to 11.

15. An apparatus comprising means for performing the method of any one of claims 1 to 13.

16. A computer program product comprising instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 13.

17. A non-transitory storage medium carrying program code instructions for executing the method of any one of claims 1 to 13.

Images