Block or motion vector encoding and decoding

Abstract

A decoding method is disclosed. First, a prefix part is decoded (S200) for each component of a vector difference. For each non-zero component, information is decoded (S202) that indicates whether a suffix part is predicted for the component. For each non-zero component, a suffix part is obtained (S204) based on the information decoded for the component. The vector difference is finally obtained (S206) from the prefix part and the suffix part.

Description

[0001] BLOCK OR MOTION VECTOR ENCODING AND DECODING

[0002] CROSS REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of European Application No. 23306413.8, filed on August 24, 2023 which is incorporated herein by reference in its entirety.

[0004] TECHNICAL FIELD

[0005] At least one of the present examples generally relates to a method and an apparatus for encoding (decoding respectively) a vector, e.g. a block vector or a motion vector.

[0006] BACKGROUND

[0007] To achieve high compression efficiency, image and video coding schemes usually employ prediction and transform to leverage spatial and temporal redundancy in the video content. Generally, intra or inter prediction is used to exploit the intra or inter picture correlation, then the differences between the original block and the predicted block, often denoted as prediction errors or prediction residuals, are transformed, quantized, and entropy coded. To reconstruct the video, the compressed data are decoded by inverse processes corresponding to the entropy coding, quantization, transform, and prediction.

[0008] SUMMARY

[0009] In one implementation, a prefix part is decoded for each component of a vector difference.

[0010] Information indicating whether a suffix part is predicted or not may be decoded for each component. A suffix part may be obtained, e.g. decoded or predicted, based on the information decoded for the component. In another implementation, in case both components are non-zero, information (e.g. a flag) may be decoded that indicates whether suffix parts of both components are predicted or not and the suffix part of each component may be obtained, e.g. decoded or predicted, based on the decoded information. In case only one component is non-zero or both are non-zero and at least one suffix part cannot be predicted, information may be decoded (e.g. for each non-zero component) that indicates whether a suffix part is predicted or not for this component and the suffix part is obtained for this component, e.g. decoded or predicted, based on the decoded information.

[0011] A vector difference may finally be obtained from the prefix and suffix parts and used to reconstruct a picture block.

[0012] BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1 illustrates a block diagram of a system within which aspects of the present embodiments may be implemented;

[0014] FIG. 2 illustrates a block diagram of an embodiment of a video encoder;

[0015] FIG. 3 illustrates a block diagram of an embodiment of a video decoder;

[0016] FIG. 4 depicts a current block predicted from a reference block identified by a block vector;

[0017] FIG. 5 represents a reference region of Intra Block Copy (IBC) mode;

[0018] FIG. 6 illustrates examples of the reference area(s) for encoding and / or decoding a Coding Tree Unit (CTU) ;

[0019] FIG. 7 illustrates examples of locations of Block Vector Predictor (BVP) candidates that may be used for the replacement of zero vector in IBC Merge / AMVP (Advanced Motion Vector Prediction) list(s);

[0020] FIG. 8 illustrates a clustering of BVP candidates based on L2 distance and Template Matching (TM) cost;

[0021] FIG. 9 illustrates an intra template matching (IntraTMP) search area;

[0022] FIG. 10 illustrates the use of IntraTMP (Intra Template Matching prediction) block vector for an IBC block ;

[0023] FIG. 11 illustrates BV predictive coding ;

[0024] FIG. 12 illustrates the process of template matching in a given search area ;

[0025] FIG. 13 depicts a flowchart of an encoding method according to a first example ;

[0026] FIG. 14A depicts a flowchart of a decoding method according to an example ;

[0027] FIG. 14B depicts a flowchart of a suffix part obtention according to an example ;

[0028] FIG. 15 depicts a flowchart of an encoding method according to a second example ; and

[0029] FIG. 16 depicts a flowchart of a decoding method according to another example. DETAILED DESCRIPTION

[0030] This application describes a variety of aspects, including tools, features, embodiments, models, approaches, etc. Many of these aspects are described with specificity and, at least to show the individual characteristics, are often described in a manner that may sound limiting. However, this is for purposes of clarity in description, and does not limit the application or scope of those aspects. Indeed, all of the different aspects can be combined and interchanged to provide further aspects. Moreover, the aspects can be combined and interchanged with aspects described in earlier filings as well.

[0031] The aspects described and contemplated in this application can be implemented in many different forms. FIGs. 1, 2 and 3 below provide some embodiments, but other embodiments are contemplated and the discussion of FIGs. 1, 2 and 3 does not limit the breadth of the implementations. At least one of the aspects generally relates to video encoding and decoding, and at least one other aspect generally relates to transmitting a bitstream generated or encoded. These and other aspects can be implemented as a method, an apparatus, a computer readable storage medium having stored thereon instructions for encoding or decoding video data according to any of the methods described, and / or a computer readable storage medium having stored thereon a bitstream generated according to any of the methods described.

[0032] In the present application, the terms “reconstructed” and “decoded” may be used interchangeably, the terms “encoded” or “coded” may be used interchangeably, the terms “pixel” and “sample” may be used interchangeably and the terms “image,” “picture” and “frame” may be used interchangeably. Usually, but not necessarily, the term “reconstructed” is used at the encoder side while “decoded” is used at the decoder side.

[0033] Various methods are described herein, and each of the methods comprises one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for proper operation of the method, the order and / or use of specific steps and / or actions may be modified or combined. Additionally, terms such as “first”, “second”, etc. may be used in various embodiments to modify an element, component, step, operation, etc., such as, for example, a “first decoding” and a “second decoding”. Use of such terms does not imply an ordering to the modified operations unless specifically required. So, in this example, the first decoding need not be performed before the second decoding, and may occur, for example, before, during, or in an overlapping time period with the second decoding.

[0034] For the sake of clarity, satisfying, failing to satisfy a condition and configuring condition parameter(s) are described throughout embodiments described herein as relative to a threshold (e.g. greater, or lower than), a (e.g. threshold) value, configuring the (e.g. threshold) value, etc.). For example, satisfying a condition may be described as being above a (e.g. threshold) value, and failing to satisfy a condition (e.g. performance criteria) may be described as being below a (e.g. threshold) value. Embodiments described herein are not limited to thresholdbased conditions. Any kind of other condition and parameter(s) (such as e.g. belonging or not belonging to a range of values) may be applicable to embodiments described herein.

[0035] The present aspects are not limited to ECM, VVC or HEVC, and can be applied, for example, to other standards and recommendations, whether pre-existing or future-developed, and extensions of any such standards and recommendations (including VVC and HEVC). Unless indicated otherwise, or technically precluded, the aspects described in this application can be used individually or in combination.

[0036] FIG. 1 illustrates a block diagram of an example of a system in which various aspects and embodiments can be implemented. System 100 may be embodied as a device including the various components described below and is configured to perform one or more of the aspects described in this application. Examples of such devices, include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set top boxes, digital television receivers, personal video recording systems, connected home appliances, and servers. Elements of system 100, singly or in combination, may be embodied in a single integrated circuit, multiple ICs, and / or discrete components. For example, in at least one embodiment, the processing and encoder / decoder elements of system 100 are distributed across multiple ICs and / or discrete components. In various embodiments, the system 100 is communicatively coupled to other systems, or to other electronic devices, via, for example, a communications bus or through dedicated input and / or output ports. In various embodiments, the system 100 is configured to implement one or more of the aspects described in this application.

[0037] The system 100 includes at least one processor 110 configured to execute instructions loaded therein for implementing, for example, the various aspects described in this application. Processor 110 may include embedded memory, input output interface, and various other circuitries as known in the art. The system 100 includes at least one memory 120 (e.g. a volatile memory device, and / or a non-volatile memory device). System 100 includes a storage device 140, which may include non-volatile memory and / or volatile memory, including, but not limited to, EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic disk drive, and / or optical disk drive. The storage device 140 may include an internal storage device, an attached storage device, and / or a network accessible storage device, as non-limiting examples.

[0038] System 100 includes an encoder / decoder module 130 configured, for example, to process data to provide an encoded video or decoded video, and the encoder / decoder module 130 may include its own processor and memory. The encoder / decoder module 130 represents module(s) that may be included in a device to perform the encoding and / or decoding functions. As is known, a device may include one or both of the encoding and decoding modules. Additionally, encoder / decoder module 130 may be implemented as a separate element of system 100 or may be incorporated within processor 110 as a combination of hardware and software as known to those skilled in the art.

[0039] Program code to be loaded onto processor 110 or encoder / decoder 130 to perform the various aspects described in this application may be stored in storage device 140 and subsequently loaded onto memory 120 for execution by processor 110. In accordance with various embodiments, one or more of processor 110, memory 120, storage device 140, and encoder / decoder module 130 may store one or more of various items during the performance of the processes described in this application. Such stored items may include, but are not limited to, the input video, the decoded video or portions of the decoded video, the bitstream, matrices, variables, and intermediate or final results from the processing of equations, formulas, operations, and operational logic.

[0040] In some embodiments, memory inside of the processor 110 and / or the encoder / decoder module 130 is used to store instructions and to provide working memory for processing that is needed during encoding or decoding. In other embodiments, however, a memory external to the processing device (for example, the processing device may be either the processor 110 or the encoder / decoder module 130) is used for one or more of these functions. The external memory may be the memory 120 and / or the storage device 140, for example, a dynamic volatile memory and / or a non-volatile flash memory. In several embodiments, an external non-volatile flash memory is used to store the operating system of a television. In at least one embodiment, a fast external dynamic volatile memory such as a RAM is used as working memory for video coding and decoding operations, such as for MPEG-2, (MPEG refers to the Moving Picture Experts Group, MPEG-2 is also referred to as ISO / IEC 13818, and 13818-1 is also known as H.222, and 13818-2 is also known as H.262), HEVC (HEVC refers to High Efficiency Video Coding, also known as H.265 and MPEG-H Part 2), or VVC (Versatile Video Coding, a new standard being developed by JVET, the Joint Video Experts Team).

[0041] The input to the elements of system 100 may be provided through various input devices as indicated in block 105. Such input devices include, but are not limited to, (i) a radio frequency (RF) portion that receives an RF signal transmitted, for example, over the air by a broadcaster, (ii) a Component (COMP) input terminal (or a set of COMP input terminals), (iii) a Universal Serial Bus (USB) input terminal, and / or (iv) a High Definition Multimedia Interface (HDMI) input terminal. Other examples, not shown in FIG. 1, include composite video.

[0042] In various embodiments, the input devices of block 105 have associated respective input processing elements as known in the art. For example, the RF portion may be associated with elements suitable for (i) selecting a desired frequency (also referred to as selecting a signal, or band-limiting a signal to a band of frequencies), (ii) down converting the selected signal, (iii) band-limiting again to a narrower band of frequencies to select (for example) a signal frequency band which may be referred to as a channel in certain embodiments, (iv) demodulating the down converted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select the desired stream of data packets. The RF portion of various embodiments includes one or more elements to perform these functions, for example, frequency selectors, signal selectors, band-limiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers. The RF portion may include a tuner that performs various of these functions, including, for example, down converting the received signal to a lower frequency (for example, an intermediate frequency or a near-baseband frequency) or to baseband. In one set-top box embodiment, the RF portion and its associated input processing element receives an RF signal transmitted over a wired (for example, cable) medium, and performs frequency selection by filtering, down converting, and filtering again to a desired frequency band. Various embodiments rearrange the order of the above-described (and other) elements, remove some of these elements, and / or add other elements performing similar or different functions. Adding elements may include inserting elements in between existing elements, for example, inserting amplifiers and an analog-to-digital converter. In various embodiments, the RF portion includes an antenna. Additionally, the USB and / or HDMI terminals may include respective interface processors for connecting system 100 to other electronic devices across USB and / or HDMI connections. It is to be understood that various aspects of input processing, for example, Reed-Solomon error correction, may be implemented, for example, within a separate input processing IC or within processor 110 as necessary. Similarly, aspects of USB or HDMI interface processing may be implemented within separate interface ICs or within processor 110 as necessary. The demodulated, error corrected, and demultiplexed stream is provided to various processing elements, including, for example, processor 110, and encoder / decoder 130 operating in combination with the memory and storage elements to process the datastream as necessary for presentation on an output device.

[0043] Various elements of system 100 may be provided within an integrated housing, Within the integrated housing, the various elements may be interconnected and transmit data therebetween using suitable connection arrangement 115, for example, an internal bus as known in the art, including the I2C bus, wiring, and printed circuit boards.

[0044] The system 100 includes communication interface 150 that enables communication with other devices via communication channel 190. The communication interface 150 may include, but is not limited to, a transceiver configured to transmit and to receive data over communication channel 190. The communication interface 150 may include, but is not limited to, a modem or network card and the communication channel 190 may be implemented, for example, within a wired and / or a wireless medium.

[0045] Data is streamed to the system 100, in various embodiments, using a Wi-Fi network such as IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers). The Wi-Fi signal of these embodiments is received over the communications channel 190 and the communications interface 150 which are adapted for Wi-Fi communications. The communications channel 190 of these embodiments is typically connected to an access point or router that provides access to outside networks including the Internet for allowing streaming applications and other over-the-top communications. Other embodiments provide streamed data to the system 100 using a set-top box that delivers the data over the HDMI connection of the input block 105. Still other embodiments provide streamed data to the system 100 using the RF connection of the input block 105. As indicated above, various embodiments provide data in a non-streaming manner. Additionally, various embodiments use wireless networks other than Wi-Fi, for example a cellular network or a Bluetooth network. The system 100 may provide an output signal to various output devices, including a display 165, speakers 175, and other peripheral devices 185. The display 165 of various embodiments includes one or more of, for example, a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. The display 165 can be for a television, a tablet, a laptop, a cell phone (mobile phone), or other device. The display 165 can also be integrated with other components (for example, as in a smart phone), or separate (for example, an external monitor for a laptop). The other peripheral devices 185 include, in various examples of embodiments, one or more of a stand-alone digital video disc (or digital versatile disc) (DVR, for both terms), a disk player, a stereo system, and / or a lighting system. Various embodiments use one or more peripheral devices 185 that provide a function based on the output of the system 100. For example, a disk player performs the function of playing the output of the system 100.

[0046] In various embodiments, control signals are communicated between the system 100 and the display 165, speakers 175, or other peripheral devices 185 using signaling such as AV. Link, CEC, or other communications protocols that enable device-to-device control with or without user intervention. The output devices may be communicatively coupled to system 100 via dedicated connections through respective interfaces 160, 170, and 180. Alternatively, the output devices may be connected to system 100 using the communications channel 190 via the communications interface 150. The display 165 and speakers 175 may be integrated in a single unit with the other components of system 100 in an electronic device, for example, a television. In various embodiments, the display interface 160 includes a display driver, for example, a timing controller (T Con) chip.

[0047] The display 165 and speaker 175 may alternatively be separate from one or more of the other components, for example, if the RF portion of input 105 is part of a separate set-top box. In various embodiments in which the display 165 and speakers 175 are external components, the output signal may be provided via dedicated output connections, including, for example, HDMI ports, USB ports, or COMP outputs.

[0048] The embodiments can be carried out by computer software implemented by the processor 110 or by hardware, or by a combination of hardware and software. As a non-limiting example, the embodiments can be implemented by one or more integrated circuits. The memory 120 can be of any type appropriate to the technical environment and can 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. The processor 110 can be of any type appropriate to the technical environment, and can encompass one or more of microprocessors, general purpose computers, special purpose computers, and processors based on a multi-core architecture, as non-limiting examples.

[0049] FIG. 2 illustrates an example video encoder 200, such as a VVC (Versatile Video Coding) encoder. FIG. 2 may also illustrate an encoder in which improvements are made to the VVC standard or an encoder employing technologies similar to VVC.

[0050] Before being encoded, the video sequence may go through pre-encoding processing (201), for example, applying a color transform to the input color picture (e.g. conversion from RGB 4:4:4 to YCbCr 4:2:0), or performing a remapping of the input picture components in order to get a signal distribution more resilient to compression (for instance using a histogram equalization of one of the color components). Metadata can be associated with the preprocessing and attached to the bitstream.

[0051] In the encoder 200, a picture is encoded by the encoder elements as described below. The picture to be encoded is partitioned (202) and processed in units of, for example, CUs (Coding Units). Each unit is encoded using, for example, either an intra or inter mode. When a unit is encoded in an intra mode, it performs intra prediction (260), e.g. using an intra-prediction tool such as Decoder Side Intra Mode Derivation (DIMD). In an inter mode, motion estimation (275) and compensation (270) are performed. The encoder decides (205) which one of the intra mode or inter mode to use for encoding the unit, and indicates the intra / inter decision by, for example, a prediction mode flag. Prediction residuals are calculated, for example, by subtracting (210) the predicted block (a.k.a. prediction block) from the original image block.

[0052] The prediction residuals are then transformed (225) into transform coefficients c (a.k.a prediction residual transform coefficients) which are quantized (230) into quantization indexes cq(a.k.a transform coefficient levels or quantized transform coefficients on the encoder side). The quantization levels (a.k.a quantization indexes) cq. as well as motion vectors and other syntax elements such as the picture partitioning information, are entropy coded (245) to output a bitstream. The encoder can skip the transform and apply quantization directly to the non-transformed residual signal. The encoder can bypass both transform and quantization, i.e. the residual is coded directly without the application of the transform or quantization processes. The encoder decodes an encoded block to provide a reference for further predictions. The quantized transform coefficients are de-quantized (240) (a.k.a. scaled) and inverse transformed (250) to decode prediction residuals. Combining (255) the decoded prediction residuals and the predicted block, an image block is reconstructed. In-loop filters (265) are applied to the reconstructed picture to perform, for example, deblocking / SAO (Sample Adaptive Offset) / ALF (Adaptive Loop Filter) filtering to reduce encoding artifacts. The filtered image is stored in a reference picture buffer (280). In-loop filters (265) are thus used to enhance reconstructed images before storing them in the reference picture buffer (280). Inloop filters form a whole family. Among them, deblocking filters (DBF) aim at reducing blocking artifacts occurring along block boundaries. Deblocking filters are usually designed to improve subjective quality, that is, the noticeability of such coding errors by the human psycho visual system. In usual video coding standards such as HEVC and VVC, deblocking filters are predetermined based on coding information (such as prediction modes, motion vectors, transform coefficients) and on local variations across block boundaries. On the other hand, adaptive loop filters (ALF) are learnt at encoder side in order to minimize a mean squared error with respect to source images, then the learned filter weights are encoded into the bitstream. Adaptive loop filters are usually applied at CTU-level, while deblocking filters are applied along block borders.

[0053] FIG. 3 illustrates a block diagram of an example video decoder 300. In the decoder 300, a bitstream is decoded by the decoder elements as described below. Video decoder 300 generally performs a decoding pass reciprocal to the encoding pass as described in FIG. 2. The encoder 200 also generally performs video decoding as part of encoding video data.

[0054] In particular, the input of the decoder includes a video bitstream, which can be generated by video encoder 200. The bitstream is first entropy decoded (330) to obtain quantization levels cq(a.k.a. transform coefficient levels or quantization levels on the decoder side), prediction modes, motion vectors, and other coded information. The picture partition information indicates how the picture is partitioned. The decoder may therefore divide (335) the picture according to the decoded picture partitioning information. The quantization levels cqare dequantized (340) into reconstructed transform coefficients cr. De-quantization is also named scaling. The reconstructed transform coefficients crare inverse transformed (350) to obtain the prediction residuals. Combining (355) the prediction residuals and the predicted block (a.k.a. prediction block), an image block is reconstructed. The predicted block can be obtained (370) from intra prediction (360) or motion-compensated prediction (i.e. inter prediction) (375). Inloop filters (365) are applied to the reconstructed image. The filtered image is stored at a reference picture buffer (380). Note that, for a given picture, the contents of the reference picture buffer 380 on the decoder 300 side is identical to the contents of the reference picture buffer 280 on the encoder 200 side for the same picture.

[0055] The decoded picture can further go through post-decoding processing (385), for example, an inverse color transform (e.g. conversion from YCbCr 4:2:0 to RGB 4:4:4) or an inverse remapping performing the inverse of the remapping process performed in the pre-encoding processing (201). The post-decoding processing can use metadata derived in the pre-encoding processing and signaled in the bitstream.

[0056] HEVC, VVC, ECM (acronym of Enhanced Compression Model) developed by JVET use Intra Block Copy (IBC). IBC is a tool that may be used for both screen content coding, and for natural content, e.g. in ECM. An IBC-coded coding unit (CU) may be treated as separate prediction mode other than intra or inter prediction modes (as in VVC) or may be considered as part of inter mode (e.g. as in HEVC). Hence, in VVC and ECM, IBC is an independent coding mode, having its own vector coding engine as compared with the motion vector coding schemes in inter mode. Note that, previously in HEVC, since both IBC and inter mode share the concept of vectors representing displaced blocks, the unified design of IBC and inter mode is used, which is no longer the case in VVC and ECM. In any case, IBC prediction is performed from reconstructed samples before in-loop filtering.

[0057] IBC is a predictive coding technology that explores the similarity, e.g. repeating patterns, within the same picture. In this mode, a current picture block (a.k.a CU) is predicted by an already reconstructed reference block within the same picture (reference samples are derived from inside the reconstructed part of current picture). The offset from the current block to its reference block is referred as a block vector (BV) or displacement vector, i.e. a vector that indicates the displacement from the current block to a reference block. If IBC is used by one particular CU, the CU is represented with a BV as well as the residual signal of that CU, which is the approach similar to an inter mode in inter-frame motion estimation. Merge mode and skip mode may also be performed in IBC.

[0058] Since IBC mode is implemented as a block level coding mode, block matching (BM) may be performed at the encoder to find an optimal BV for each CU. The luma block vector of an IBC- coded CU may be in integer precision (for example for simplicity reasons). The chroma block vector may round to integer precision as well. The IBC mode can switch between 1-pel and 4- pel motion vector precisions, for example when combined with Adaptive Motion Vector Resolution (AMVR). In an example, the IBC mode may be applicable to certain CUs (e.g. the CUs with both width and height smaller than or equal to 64 luma samples). IBC is known as intra picture block compensation or current picture referencing (CPR).

[0059] In an example, all the reconstructed part of the current picture may be used as IBC reference region (a.k.a IBC search range) for the current block coded in IBC mode. However, to enable hardware support, some constraints may be imposed on the full-frame based IBC solution to make its implementation friendly.

[0060] FIG. 4 depicts an image part wherein a current CU (a.k.a current block) of width w and height h is predicted from a reference block selected in an IBC reference region and identified by a block vector. IBC reference region in HEVC Screen Content Coding extension (HEVC-SCC) is shown in FIG. 4, where the white area is the not yet decoded (a.k.a reconstructed) region of the current decoded picture. The grey area is the already reconstructed part. The solid line LI in this area forms the border of the available IBC reference region (a.k.a IBC search range). The line L2, which is right next to the border may be excluded from the search range when the video format is 4:2:0. The part of the reconstructed area that is not inside the border enclosed by line LI may be excluded from the IBC reference region for parallel processing consideration.

[0061] A more constrained reference region may be used, for example, to limit memory consumption and / or decoder complexity. As an example, the IBC reference region (a.k.a IBC search range) may be limited to the current coding tree unit (CTU) only. In another example, when efficient memory handling (memory reuse) is used, some of the reference samples from the left CTU can be used for IBC mode. In a particular example, in order to limit memory consumption, the largest block size in IBC mode may be limited to 64x64.

[0062] Thus, to limit memory consumption and decoder complexity, the IBC (e.g. as in VVC) may allow the IBC reference region to include only the region of current CTU and some region(s) of the left CTU. FIG. 5 represents a reference region of IBC mode, where each block represents 64x64 luma sample unit. On this figure, each cross identifies a block from the left CTU that is excluded from the available IBC reference region. The grey blocks without a cross belong to the IBC reference region. Depending on the current CU location within the current CTU, the following may apply to define the IBC reference region. If current block (a.k.a current CU) falls into the top-left block (e.g. 64x64 block) of the current CTU, then in addition to the already reconstructed samples in the current CTU, it can also refer to the reference samples in the bottom-right blocks (e.g. 64x64 blocks) of the left CTU, using IBC mode. The current block can also refer to the reference samples in the bottom-left 64x64 block of the left CTU and the reference samples in the top-right block (e.g. 64x64 block) of the left CTU, using IBC mode.

[0063] If current block falls into the top-right block (e.g. 64x64 block) of the current CTU, then in addition to the already reconstructed samples in the current CTU, if luma location (0, 64) relative to the current CTU has not yet been reconstructed, the current block can also refer to the reference samples in the bottom-left block (e.g. 64x64 block) and bottom-right block (e.g. 64x64 block) of the left CTU, using IBC mode; otherwise, the current block can also refer to reference samples in bottom-right block (e.g. 64x64 block) of the left CTU.

[0064] If current block falls into the bottom-left block (e.g. 64x64 block) of the current CTU, then in addition to the already reconstructed samples in the current CTU, if luma location (64, 0) relative to the current CTU has not yet been reconstructed, the current block can also refer to the reference samples in the top-right block (e.g. 64x64 block) and bottom-right block (e.g. 64x64 block) of the left CTU, using IBC mode. Otherwise, the current block can also refer to the reference samples in the bottom-right block (e.g. 64x64 block) of the left CTU, using IBC mode. If current block falls into the bottom-right block (e.g. 64x64 block) of the current CTU, it can only refer to the already reconstructed samples in the current CTU, using IBC mode.

[0065] One or more examples (e.g., example restrictions) herein may allow the IBC mode to be implemented using local on-chip memory (or memories) for hardware implementations.

[0066] In some examples, the reference region for IBC may be extended to two CTU rows above the CTU being processed by the encoder and / or the decoder. FIG. 6 illustrates examples of the reference area(s) for encoding and / or decoding CTU (m,n). For CTU (m,n) to be encoded (decoded respectively), the reference area(s) may include CTUs with index (m-2,n-2)... (W,n- 2),(0,n-l)... (W,n-l),(0,n)... (m,n), where W denotes the maximum horizontal index within the current tile, slice or picture. The per-sample block vector search (or referred to as the local search) range may be limited to [-(C « 1), C » 2] horizontally and [-C, C » 2] vertically e.g. to adapt to the reference area extension, where C denotes the CTU size and » is a right shift operator and « is a left shift operator. IBC mode may be signaled at a CU level, (e.g. with a flag). IBC mode may be signaled as IBC advanced motion vector prediction (AMVP) mode or IBC skip / merge mode in one or more examples herein. In examples, IBC mode may be signaled as IBC skip / merge mode, where a merge candidate index may be used to indicate which of the block vectors in a list derived from neighboring candidate IBC coded blocks is used to predict the current block. A merge list may include (e.g. consist of) spatial, history-based motion vector predictor (HMVP), and pairwise candidates. A simplified merge candidate list with 2 spatial neighboring blocks’ BV and 5 HMVPs may be used. Up to 6 candidates may be used in the list. The first two entries of the same predictor list may also be used for non-merge BV prediction mode.

[0067] In some examples, IBC mode may be signaled as IBC AMVP mode, where a block vector difference (BVD) may be encoded (decoded respectively) in a similar or same way as a motion vector difference (MVD). The block vector prediction method may use multiple (e.g. two) candidates as predictors, which are selected from the merge list based on a minimum cost (e.g. if IBC coded). In an example, the block vector prediction method may use two candidates as predictors, one from left neighbor and one from above neighbor (e.g. if IBC coded). A default block vector may be used as a predictor, for example, if one or more of the candidates (e.g. neighbor(s)) are not available. An indication (e.g. a flag) may be signaled to indicate a block vector predictor index.

[0068] In examples, IBC merge / AMVP list construction may be modified, as one or more of the following. An IBC merge / AMVP candidate may be inserted into the IBC merge / AMVP candidate list, if and / or only if the IBC merge / AMVP candidate is valid. One or more of aboveright, bottom-left, and / or above-left spatial candidates and / or one pairwise average candidate may be added into the IBC merge / AMVP candidate list. Template based adaptive reordering (e.g. adaptive re-ordering of merge candidates based on template (ARMC-TM)) may be applied to the IBC merge list.

[0069] The HMVP table size for IBC may be increased to 25 entries. After one or more IBC merge candidates (e.g. up to 20 IBC merge candidates) are derived with full pruning, they may be reordered together. After reordering, the first candidates (e.g. the first 6 candidates) with the lowest template matching costs may be selected as the final candidates in the IBC merge list.

[0070] The candidates from zero vectors (e.g. the ones used to pad the IBC Merge / AMVP list for example in the case where the list is not complete) may be replaced with a set of block vector prediction (BVP) candidates located in the IBC reference region. In examples, a zero vector may be invalid as a block vector in IBC merge mode (e.g. consequently it is discarded as BVP in the IBC candidate list).

[0071] FIG. 7 illustrates an example showing locations of BVP candidates that may be used for the replacement of zero vector in the IBC Merge / AMVP list(s). As depicted in FIG. 7, three candidates are located on the nearest comers of the reference region delimited by a dotted line, and three additional candidates are determined in the middle of the three sub-regions (A, B, and C), whose coordinates may be determined by the width, and the height of the current block and AX and AY parameters.

[0072] A clustering of the BVP candidates may be applied when both BV candidate components (horizontal and vertical projections of the vector, BVx and BVy) are non-zero, e.g. during the IBC AMVP list construction. FIG. 8 illustrates the clustering based on L2 distance and TM cost. In examples, clustering may be applied if there are more than 2 valid BV candidates and up to 6 candidates. The clustering radius may be defined as

[0073] Radius = og2(cbWidth ■ cbHeight) » M1N_CU_S1ZE) where cbWidth and cbHeight are the width and height of the current block (a.k.a as CU), MIN_CU_SIZE is minimal allowed CU size and » is a right shift operator.

[0074] The clustering method may be applied in the candidate list order, and the candidates assigned to a group may be removed from the list for the subsequent clusters. In a group (e.g. each group), the BVP with a lowest TM cost is selected as the representative candidate of that group. Finally, the representative candidates of the two first groups may be chosen as the candidates for the IBC AMVP list.

[0075] Furthermore, if one of BV candidate components is zero or block is coded in reconstruction- reordered IBC (RRIBC), a flag may be signaled to indicate this case with a directional flag indicating horizontal or vertical component is non-zero. Instead of usual IBC AMVP list, two new BVP candidates may be derived, and the sign of the non-zero BV component may be derived at decoder side. The AMVP BVPO may be set to the nearest valid location to the current block (-cbWidth or -cbHeight), so the non-zero BVD is always negative, pointing to the left for a BV with a zero vertical component or to the above for a BV with a zero horizontal component. Likewise, the AMVP BVP1 may be set to the farthest position from the current block in the valid reference region, that is the left boundary or the top boundary of the IBC search region. Consequently, if the BVP1 is selected, the BVD is always positive, pointing to the right for BV with a zero vertical component or to the bottom for BV with a zero horizontal component.

[0076] The optimal IBC AMVP index may be signaled, which allows obtaining (e.g. deriving) the sign of the non-zero BVD component at the decoder side. The absolute magnitude of non-zero BVD component may be further signaled. In RRIBC, the direction of the flipping mode may be derived from the signaled directional flag.

[0077] IBC may be used with template matching. In some examples, template matching (TM) based motion search and / or refinement may be applied to IBC, e.g. for both IBC merge mode and IBC AMVP mode.

[0078] An IBC-TM merge mode may be used. An IBC-TM merge mode may involve a merge candidate list for BV prediction, different from the one used by a regular IBC merge mode. The candidates may be selected according to a pruning method with motion distance(s) between the candidates (e.g. as in the regular TM merge mode). The zero motion candidates may have been replaced by block vectors, for example, at (-W, 0), (0, -H), (-W, -H).

[0079] In the IBC-TM merge mode, selected candidates may be refined with the template matching, e.g. prior to RDO (Rate Distortion Optimization) or decoding process. The IBC-TM merge mode may be in competition with regular IBC merge mode. A TM-merge indication (e.g. the TM-merge flag) may be signaled to indicate the template matching merge IBC mode.

[0080] In an IBC-TM AMVP mode, one or more (e.g. up to 3) candidates may be selected from the IBC-TM merge list. Those candidates (e.g. each of those candidates) may be refined (e.g. according to the usual template matching method) and may be sorted, for example, according to their resulting TM costs. For example, one or more (e.g. only 2) first one(s) may be considered in the block vector estimation process.

[0081] TM refinement, for example, when used for IBC, may be performed at integer pel precision, and, in an IBC-TM AMVP mode, it is performed at integer or 4-pel precision, for example, depending on the AMVR value. The refinement may be done within the IBC reference area (e.g. the existing IBC reference area).

[0082] TM refinement, for example, for both IBC-TM merge and AMVP modes is quite simple since IBC block vectors may be constrained (i) to be integer and (ii) within a reference region. In IBC-TM merge mode, some (e.g. all) refinements may be performed at integer precision, and in IBC-TM AMVP mode, they may be performed either at integer or 4-pel precision depending on the AMVR value. Such a refinement accesses only to samples without interpolation. In both cases, the refined block vectors and the used template in each refinement step may respect the constraint of the IBC reference region.

[0083] FIG. 9 illustrates an intra template matching (IntraTMP) search area. IntraTMP is a special intra prediction mode that copies the best prediction block from the reconstructed part of the current frame, whose L-shaped template matches the current template. For a predefined search range, the encoder searches for the most similar template to the current template in a reconstructed part of the current frame and uses the corresponding block as a prediction block. The encoder then signals the usage of this mode, and the same prediction operation is performed at the decoder side. Thus, IntraTMP thus does not require transmitting a BVD to the decoder in order to find the prediction block.

[0084] The prediction signal may be generated by matching a L-shaped causal neighbor of the current block with another block in a (e.g. predefined search area), as shown by example in FIG. 9. The search area may include several regions (e.g. four regions). A first region R1 may indicate the current CTU, a second region R2 may indicate the top-left CTU, a third region R3 may indicate the above CTU, and a fourth region R4 may indicate the left CTU. Sum of absolute differences (SAD) may be used as a cost function. Within a region (e.g. each) region, the decoder may search for the template that has the least SAD with respect to the current one and use its corresponding block as a prediction block. The dimensions of (e.g. all) regions (SearchRange w, SearchRange h) may be set proportional to the block dimension (BlkW, BlkH), for example, to have a fixed number of SAD comparisons per pixel. In an example, SearchRange w = a * BlkW and SearchRange h = a * BlkH, where ‘a’ is a constant that controls the gain / complexity trade-off. In some examples, ‘a’ may be equal to 5.

[0085] The intra template matching tool may be enabled for CUs with a size less than or equal to 64 in width and height. The maximum CU size for intra template matching may be configurable. The Intra template matching prediction mode may be signaled at a CU level through a (e.g, dedicated) flag.

[0086] Although both modes IBC and IntraTMP create a prediction block by using reference blocks from the current frame, IntraTMP does not require encoding of a BV in order to create the prediction block at the decoder side. However, the BV derived from the IntraTMP may be used for IBC. The stored IntraTMP BV of the neighbouring blocks along with IBC BV may be used as spatial BV candidates in IBC candidate list construction. A current IBC block can use both IBC BV and IntraTMP BV of neighbouring blocks as BV candidate for IBC BV candidate list as depicted on FIG. 10. IntraTMP block vectors are added to IBC block vector candidate list as spatial candidates.

[0087] IBC mode may interact with other coding tools, such as pairwise merge candidate, historybased motion vector predictor (HMVP), combined intra / inter prediction mode (CIIP), merge mode with motion vector difference (MMVD), and geometric partitioning mode (GPM). For example, IBC may be used with pairwise merge candidate and HMVP. A new pairwise IBC merge candidate may be generated, for example, by averaging (e.g. two) IBC merge candidates. IBC motion may be inserted into a history buffer for future referencing, e.g. for HMVP. In some examples, IBC may not be used in combination with an affine motion inter tool. IBC may be used in combination with combined inter-intra prediction (CIIP), MMVD, and / or geometric partitioning mode (GPM). In some examples, IBC may not be allowed for chroma coding blocks, e.g. if / when a DUAL TREE partition is used. In some examples, IBC may be used with the inter prediction enhancement tool called LIC (Local Illumination Compensation).

[0088] The current picture may not be included as a reference picture in the reference picture list 0 for IBC prediction, for example. The derivation process of block vectors for IBC mode may exclude (e.g. all) neighboring blocks in inter mode and vice versa.

[0089] The following IBC functionality may be applied. IBC may share the (e.g. same) process as in (e.g. regular) MV merge, including with pairwise merge candidate and history-based motion predictor, but may disallow temporal motion vector prediction (TMVP) and zero vector, e.g. because they are invalid for IBC mode. A separate HMVP buffer (e.g. five (5) candidates each) may be used for (e.g. conventional) MV and IBC. Block vector constraints may be implemented, e.g. in the form of a bitstream conformance constraint, e.g. so that the encoder ensures that invalid vectors are not present in the bitstream. Merge mode may not be used, for example, if the merge candidate is invalid (e.g. out of range or zero (0)). A bitstream conformance constraint may be expressed, for example, in terms of a virtual buffer.

[0090] IBC may be handled as inter mode, for example, for deblocking. AMVR may not use quarter- pel, for example, if the current block is coded using IBC prediction mode. AMVR may be signaled (e.g. only) to indicate whether MV is inter-pel or 4 integer-pel, for example, if the current block is coded using IBC prediction mode. The number of IBC merge candidates may be signaled in the slice header, for example, separately from the numbers of regular, subblock, and / or geometric merge candidates.

[0091] Bi-predictive IBC may be implemented, e.g. to enhance the coding performance of IBC for natural and screen content. IBC may generate prediction samples with only one BV, i.e. uni- predictive IBC, but the prediction accuracy of IBC may still be improved. In some examples, IBC with several (e.g. two, i.e. bi-predictive IBC) BVs may be used besides uni -predictive IBC.

[0092] For example, a first method (Method 1) may include an IBC BVP-merge mode. A second method (Method 2) may include a Bi-predictive IBC merge mode.

[0093] Method 1 may derive the two (e.g. required) BVs from IBC block vector prediction (BVP) mode (also referred to as IBC AMVP herein) and IBC merge mode (e.g. similar to the MV derivation of AMVP-merge mode that combines an AMVP motion vector predictor for a reference list and an inter merge candidate for the other reference list) to form a bi-predicted inter CU. Two different indices for the IBC BVP mode and the IBC merge candidate (different from the AMVP-merge mode) may be signaled from the encoder to the decoder, respectively, taken from IBC AMVP candidate list and IBC merge candidate list.

[0094] Method 2 may derive the two (e.g. required) BVs from the IBC merge candidate list, for example, by utilizing two different IBC merge indices. The two indices may be signaled from the encoder to the decoder. The target of the bi-predictive IBC merge mode may be, for example, IBC-regular merge, IBC merge mode with block vector difference (IBC-MBVD), and IBC geometric partitioning mode (IBC-GPM), which may be enabled for screen content (e.g. by default). Bi-predictive IBC-MBVD may be enabled in natural and screen content, while bi-predictive IBC-GPM may be enabled (e.g. only) in screen content.

[0095] The methods (e.g. method 1 and method 2) may be implemented based on one or more of the following. The methods may reuse the IBC merge candidate list construction scheme for uni- predictive IBC merge mode. The methods may use BV refinement. For example, the methods may enable the IBC with template matching. The methods may use compensation. For example, the methods may generate final IBC prediction samples with a simple (1:1) average of bi-predictive IBC samples. The methods may store the two BVs in BV storage, e.g. if / when the bi-predictive IBC is enabled. The methods may use signaling. For example, a control flag of bi-predictive IBC may be signaled at a slice level in I slice (e.g. not signaled in B and P slices). Reconstructed-Reordered IBC may be disabled, for example, if / when the bi-predictive IBC is enabled. The methods may be enabled in chroma component blocks of the single tree.

[0096] BV may be explicitly encoded as illustrated on FIG. 11, e.g. if / when IBC AMVP mode is used. The BV coding may use the similar processes specified for inter prediction but may use rules for predictor candidate list construction different from the ones used in the inter prediction. The (e.g. optimal) IBC AMVP may be selected during competing scheme with other candidates. Once an encoder chooses a final predictor, its index may be signaled. In an example, a block vector predictor (BVP) may be chosen by the encoder and a block vector difference (BVD) relative to the selected BVP may be signaled in addition. The absolute magnitude of non-zero BVD components, here component referring to the x and y projection of the vector in 2- dimensional may be handled separately. For the simplicity reason, BVDx and BVDy refer to the absolute value of vector components, and sign is out of consideration in the present document. On the decoder side, block vector data may be reconstructed. In an example, BV is equal to the sum of the BVP used for a given CU and its associated BVD.

[0097] In some examples, once BVD to be encoded is obtained, specific coding scheme may apply. The absolute values BVDx and BVDy may be coded using Exponential Golomb code. The encoder side pseudo code for BVD encoding may be as follows.

[0098] BVDx = BVDx < 0 ? -BVDx : BVDx;

[0099] BVDy = BVDy < 0 ? - BVDy : BVDy;

[0100] GrOx flag = BVDx > 0;

[0101] GrOy flag = BVDy > 0; if (rribcFlipType != 2) m_B inEncoder. encodeBin( GrOx flag, Ctx::Bvd(HOR_BVD_CTX_OFFSET)); if (rribcFlipType != 1) m_B inEncoder. encodeBin( GrOy flag, Ctx::Bvd(VER_BVD_CTX_OFFSET)); if( Gr0x_flag) xWriteBvdContext(BVDx - 1, NUM HOR BVD CTX, HOR BVD CTX OFFSET, BVD CODING GOLOMB ORDER); m_BinEncoder.encodeBinEP( (BVDx < 0) ); if( GrOy_flag) xWriteBvdContext(BVDy -1, NUM VER BVD CTX, VER BVD CTX OFFSET, BVD CODING GOLOMB ORDER); m_BinEncoder.encodeBinEP( (BVDy < 0) );

[0102] In the above pseudo-code, for each vector component a flag indicating if absolute value is greater than 0, e.g. Gr0x_flag and GrOy_flag, is written first and only if true, remaining absolute value minus 1, e.g. BVDx-1 and BVDy-1, and sign are encoded. xWriteBvdContext is function to write vector magnitude minus one, e.g. BVDx-1 and BVDy- 1, using Exponential-Golomb code. It may first write prefix bins followed by writing suffix bins. First 5 prefix bins are context coded after which remaining bins (if exist) may be coded with equal probability (EP) mode. Suffix bins may be coded with equal probability (EP mode). BVD CODING GOLOMB ORDER may be set to 1 (first order Exponential-Golomb code), NUM HOR BVD CTX and NUM VER BVD CTX may be set to 5 meaning up to 5 bins of the prefix part may be context coded, HOR BVD CTX OFFSET and VER BVD CTX OFFSET are offsets to select appropriate context model.

[0103] Decoder side reassembles the same order of operations, however instead of encoding and writing the bins it reads and decode bins. The decoder side pseudo code for BVD decoding may be as follows.

[0104] BVDx = 0, BVDy = 0, GrOx flag = 0, GrOy flag = 0 ; if (rribcFlipType != 2)

[0105] GrOx flag = m_BinDecoder.decodeBin(Ctx::Bvd(HOR_BVD_CTX_OFFSET));

[0106] BVDx = GrOx flag; if (rribcFlipType != 1)

[0107] GrOy flag = m_BinDecoder.decodeBin(Ctx::Bvd(VER_BVD_CTX_OFFSET));

[0108] BVDy = GrOy flag ; if( GrOx_flag)

[0109] BVDx += xReadBvdContext(NUM_HOR_BVD_CTX, HOR BVD CTX OFFSET, BVD CODING GOLOMB ORDER); if (m_B inDecoder. decodeBinEP())

[0110] BVDx = - BVDx; if( GrOy_flag)

[0111] BVDy += xReadBvdContext(NUM_VER_BVD_CTX, VER BVD CTX OFFSET, BVD CODING GOLOMB ORDER); if (m_B inDecoder. decodeBinEP())

[0112] BVDy = - BVDy;

[0113] Exponential-Golomb codes of k-th order (EGk) codes represent a symbol as two parts, where the first part is a prefix, and the second part is a suffix. In EGk code, the code word size increases exponentially. For each bit in the prefix part, the number of the codes in the suffix part may double. Every code word comprises a unary code to represent the prefix part, followed by fixed length code for suffix part.

[0114] A symbol L to encode is first associated with (e.g. mapped to) an index set represented with its index value, which may be given by an index function e.g., p(L) = [log2L * 2~k+ 1)]. The index function p(L) may be coded using p(L) + 1 bits with unary code. Index function maps from integers L to an index which is also an integer. In that sense integers are partitioned into the sets (called index sets) according to the index they map onto, and which is defined with index function p L). Note that the index of the set (and not the prefix value itself) is coded with unary code which represents the first part of the EGk code word. The prefix value may be obtained from the index set using for example the following formula : prefix(L) = 2p(L)+k— 2k. Integers may then be encoded as their index, plus suffix part that represents their rank in the index set. The index set may thus be ordered, e.g. natural ordering may be used in EGk code. The rank (e.g. suffix) may be determined from the equation given with suf fix (L) = L + 2k(l — 2p(L)The rank (e.g. suffix) may be coded as fixed length representation of a length p(L) + k, where k is the order of the Exponential-Golomb code. A fixed length part can be observed as a binary representation using the p(L) + k least significant bits. Thus, suffix value itself may be coded with fix length binary representation. It represents the second part of the EGk codeword which is concatenated to the first part of the EGk codeword.

[0115] In an example, the order of EG code is set to 1 (k=l). Example of partitioning into index sets with its prefix value and suffix values is given in Table 1.

[0116] Table 1 - EG1 code with the index sets, prefix and suffix values

[0117] At last, a symbol L is given as L=prefix(L)+suffix(L).

[0118] Instead of explicitly encoding BVD, BVD may be at least partially (e.g. its suffix part) predicted. In some examples, template matching (TM) approach may be used which defines a set of hypotheses and selects the hypothesis that minimizes a cost function as a final output for further analysis. It is an encoder and decoder-side derivation method that may be used to deduct information of the current CU, e.g. by finding the closest match between a template of the current CU (e.g. top and / or left neighboring area of the current CU) and the template of a block (e.g. of same size as the current CU template) in a predefined reference region (a.k.a. search region). The cost may be measured (e.g. calculated) for some (e.g. all) hypotheses. The decoder (the encoder respectively) may search for the template that has the smallest sum of absolute differences (SAD) and may use its corresponding block as a prediction block. In the context of BVD coding, the predicted BVD is taken from the hypothesis with the smallest cost (from the prediction block). If the prediction of the BVD corresponds to the true BVD (e.g. the true BVD is the one calculated by the conventional encoder search process implemented in IBC mode), the prediction is marked as correct, and a (e.g. dedicated) syntax element (e.g. flag) may be set to 1 indicating that the predicted BVD matches the true BVD. If the predicted BVD (a.k.a. matching BVD) is the same as the current one, prediction is true the encoder then signals the usage of this mode. In this latter case, the same prediction operation may be performed at the decoder side. Otherwise, flag may be set to 0. The values of the syntax elements are only examples. Other values may be used. The flag may be signaled at CU level for each non-zero BVD. Herein, the flag is referred as “valid_bvd_pred_flag”.

[0119] In some examples, encoder-side method may comprise the following steps. A BVD of the current CU (the true BVD) is obtained (e.g. found) by using standard encoder search procedure implemented in the IBC mode. A reference block is obtained (e.g. found) by using TM in a (e.g. predefined) search area (e.g. search region), e.g. if / when at least one of the vector components of the true BVD is non-zero. The flag valid_bvd_pred_flag is initialized, for example to 0. The BVD (called the predicted BVD) is obtained (e.g. taken) from the reference block. In an example, a BV is obtained (e.g. derived BV) from the reference block and the predicted BVD is obtained by subtracting the BVP from the obtained (e.g. derived BV). The BVP is for example the same as the one used for obtaining the true BVD. The true BVD and predicted BVD are then compared, e.g. the x and y components of the vectors are compared. In some examples, only non-zero components of true BVD are considered (i.e. compared). This means that if the true vector has one zero and one non-zero component, only non-zero component of the true BVD is compared with the corresponding component of the predicted BVD. The correct prediction is in this way obtained by comparing only non-zero component of the true and predicted BVDs.

[0120] In an example, the comparison of the components is further illustrated as indicated below. TrueBVD(BVDx-t, BVDy-t) is true BVD with horizontal and vertical vector components given by BVDx-t and BVDy-t, respectively. PredBVD(BVDx-p, BVDy-p) is predicted BVD with horizontal and vertical vector components given by BVDx-p and BVDy-p, respectively.

[0121] If BVDx-t and BVDy-t are non-zero, comparison is marked as correct only if

[0122] BVDx-t == BVDx-p and BVDy-t == BVDy-p.

[0123] If BVDx-t is zero and BVDy-t is non-zero, comparison is marked as correct if only

[0124] BVDy-t == BVDy-p.

[0125] If BVDx-t is non-zero and BVDy-t is zero, comparison is marked as correct if only BVDx-t == BVDx-p.

[0126] If BVDx-t and BVDy-t are both zero, comparison is not done.

[0127] In the case where at least one component of the true BVD is non-zero and comparison is marked as correct, e.g. see previous example, valid_bvd_pred_flag is set to 1 indicating that BVD suffix is predicted, otherwise valid_bvd_pred_flag is set to 0 indicating that BVD suffix is present (e.g. signaled / encoded) in the bitstream.

[0128] The prefix parts for x and y components of the true BVD are encoded, e.g. only for non-zero vector component. Then, valid_bvd_pred_flag is encoded, e.g. only if at least one component of the true BVD is non-zero. In the case where, valid_bvd_pred_flag is equal to 0, the suffix part for x component and the suffix part for y component of the true BVD are encoded, e.g. only for non-zero vector component.

[0129] Decoder side method may use the same sequence of operations to reassemble BVD. In some examples, decoder-side method may comprise the following steps. First, prefix parts for x and y components are decoded, e.g. only for non-zero vector component. The flag valid_bvd_pred_flag is initialized, for example to 0.

[0130] The syntax element valid_bvd_pred_flag indicating whether BVD suffix is predicted or not, e.g. if / when at least one vector component is non-zero. In the case where valid_bvd_pred_flag is equal to 1, a reference block is obtained (e.g. found) by using TM in a (e.g. predefined) search area. The BVD (the predicted BVD) is obtained (e.g. taken) from the reference block, e.g. in the same way as on the encoder side. The suffix part is obtained from the predicted BVD for x and y components, e.g. only for non-zero vector component. Otherwise (valid_bvd_pred_flag is equal to 0), the suffix part may be directly decoded from the bitstream for x and y components, e.g. only for non-zero vector component.

[0131] In some examples, BVD suffix may be obtained (e.g. derived BV) using template matching search in a search range (a.k.a. search area or search region) that depends on the BVD prefix from a current prefix to a next prefix value. This may ensure that the true BVD is inside the search area. For example, if the BVD prefix is equal to 6, then the next prefix value is 14 as defined in Table 1, so the search range is from 6 to 14. However, there is no guaranty that the true BVD will be correctly predicted by the template matching, e.g. no guarantee that minimal TM cost will be for the template that correspond to the true BVD. The suffix values may not go outside of the existed suffix value range due to the search range defined based on the prefix, hence in the given example suffix value can be from 0 to 7. This is illustrated on FIG. 12. In some examples, the prediction may be done only for the non-zero magnitude of the vector components. Non-zero vector component is indicated by a flag, e.g. GrOx_flag and GrOy_flag, that is encoded at the beginning of the BVD coding process, e.g. see BV encoding and decoding pseudo-codes. If / when the magnitude of the vector component is non-zero, it is indicated in the bitstream by encoding a greater than zero flag. This may apply to some (e.g. all) examples disclosed in the following.

[0132] In the above examples, the correct prediction is signaled, through a (e.g. dedicated) flag valid_bvd_pred_flag, only if at least one component is non-zero and non-zero components of a true BVD match the prediction (weather the prediction is correct or not is explained previously). In such a case, valid_bvd_pred_flag is set to 1. Otherwise, if non-zero BVD components are not predicted correctly or both components are zero, valid_bvd_pred_flag is set to 0. If valid_bvd_pred_flag is equal to 1, suffix values for non-zero BVD components (suffix BVDx and suffix BVDy) are predicted and not encoded in the bitstream. In the above examples, vector components are not predicted individually. It can be beneficial to predict vector components individually. To this aim, two new syntax elements (e.g. dedicated flags) may be signaled indicating the correct prediction or not is observed per vector component. For example, suffix BVDx may be explicitly encoded into the bitstream while suffix BVDy may be predicted by TM. Hence, in an example, vector components (projections on the x-axis and y-axis) are predicted independently. The same template matching process may be used. The independent prediction may be signaled by two new flags, e.g. valid_bvd_x_pred_flag and valid_bvd_y_pred_flag.

[0133] In the following examples, some (e.g. all) flags (e.g. valid_bvd_pred_flag, valid_bvd_x_pred_flag, valid_bvd_y_pred_flag) are initialized to 0 before starting the process. If / when a flag is not used or not encoded into the bitstream it is assumed to be 0. In the following examples, the values of the flags are only provided as examples. In other examples, different value may be used.

[0134] FIG. 13 depicts a flowchart of an encoding method according to a first example. In this example, global (e.g. joint) prediction and valid_bvd_pred_flag are omitted. Independent prediction of vector components is performed. The same TM method as in the previous examples may be used. The predicted BVD is compared with true BVD in the following manner. In some examples, the method may be performed only if true BVD amplitude is nonzero. At SI 00, a BVD is obtained (e.g. found) for a picture block (e.g. a current CU), e.g. by using standard encoder search procedure implemented in the IBC mode, e.g. as illustrated by FIG. 11. This BVD is referred to as the true BVD in the following.

[0135] At SI 02, a reference block is obtained (e.g. found), e.g. by using template matching (TM) in a (e.g. predefined) search area (a.k.a. search region). In an example, S102 is executed only in the case where at least one of the vector components of the true BVD is non-zero, i.e. if / when either BVDx or BVDy is non-zero or both are non-zero.

[0136] At SI 04, a BVD, noted BVDTM, is obtained (e.g. derived or taken) from the reference block obtained at SI 02, e.g. only in the case where at least one of the vector components of the true BVD is non-zero. BVDTM is referred to as the predicted BVD in the following. In an example, a BV is obtained (e.g. derived) from the reference block and the predicted BVDTM is obtained by subtracting BVP from the obtained (e.g. derived) BV. The BVP is for example the same as the one used for obtaining the true BVD.

[0137] At SI 06, a prefix part is encoded for each (e.g. for each non-zero) component of the block vector difference, namely of the true BVD. In an example, a prefix part for component x, e.g. if non-zero, is encoded and a prefix part for component y, e.g. if non-zero, is encoded.

[0138] At SI 08, information (e.g. a flag) is encoded for each (e.g. for each non-zero) component of the BVD that indicates whether a suffix part is predicted (i.e. is not encoded) or not predicted (i.e. is encoded / signaled in the bitstream) for this component based on a comparison of true BVD and BVDTM.

[0139] As an example, if / when true BVDx is non-zero, true BVDx and predicted BVDx are compared and if they are equal (e.g, the same) valid_bvd_x_pred_flag is set to 1 indicating that BVDx suffix is predicted, i.e. not encoded. Otherwise, valid_bvd_x_pred_flag is set to 0 indicating that BVDx suffix is present (e.g. encoded and thus not predicted) in the bitstream. If / when BVDy is non-zero, true BVDy and predicted BVDy are compared and if they are equal (e.g. the same) valid_bvd_y_pred_flag is set to 1 indicating that BVDy suffix is predicted. Otherwise, valid_bvd_y_pred_flag is set to 0 indicating that BVDy suffix is present (e.g. encoded and thus not predicted) in the bitstream. valid_bvd_x_pred_flag and valid_bvd_y_pred_flag are encoded in the bitstream, e.g. only for each non-zero component. The values of the flags may be different than above. For example, valid_bvd_x_pred_flag (valid_bvd_y_pred_flag respectively) may be set to 1 to indicate that BVDx suffix (BVDy suffix respectively) is encoded in the bitstream and valid_bvd_x_pred_flag (valid_bvd_y_pred_flag respectively) may be set to 0 to indicate that BVDx suffix (BVDy suffix respectively) is predicted.

[0140] At SI 10, a suffix part is encoded for each component for which the information indicates the suffix part is not predicted (i.e. is encoded) for this component. As an example, if / when valid_bvd_x_pred_flag is equal to 0, a suffix part is encoded for component x and if / when valid_bvd_y_pred_flag is equal to 0, a suffix part is encoded for component y.

[0141] In this embodiment, valid_bvd_pred_flag is not used. Prediction is done, and, in some examples, the flags valid_bvd_x_pred_flag and valid_bvd_y_pred_flag are encoded only for non-zero component. A flag (e.g. Gr0x_flag and GrOy_flag) may be encoded first, e.g, for each component, to indicate whether the component is non-zero or not. If the flag is 1, the component is non-zero and the amplitude is to be encoded, e.g. its prefix and possibly suffix if not predicted. If the flag is 0, it means the component (e.g. BVDx / BVDy) is zero, and no more encoding is needed for that particular component.

[0142] FIG. 14A depicts a flowchart of a decoding method according to an example.

[0143] At S200, a prefix part is decoded for each (e.g. for each non-zero) component of a block vector difference.

[0144] At S202, information is decoded for each (e.g. for each non-zero) component that indicates whether a suffix part is predicted or not for this component. Said otherwise, a first information (e.g. a first flag) is decoded for a first component that indicates whether a suffix part is predicted or not for this first component and a second information (e.g. a second flag) is decoded for a second component that indicates whether a suffix part is predicted or not for this second component. In an example, valid_bvd_x_pred_flag is decoded (e.g. if / when true BVDx is nonzero) that indicates whether BVDx suffix is predicted or not and valid_bvd_y_pred_flag is decoded (e.g. if / when true BVDy is non-zero) that indicates whether BVDy suffix is predicted or not. If not predicted, then the suffix part is signaled in the bitstream.

[0145] At S204, a suffix part is obtained for each (e.g. for each non-zero) component based on the information decoded at S202 for the component. Said otherwise, in the case where the information indicates that the suffix part is not predicted then the suffix part is decoded (S204- 1) from the bitstream, otherwise the suffix part is predicted (S204-2 and S204-3) as detailed on FIG. 14B for one component. Predicting the suffix part may be done as on the encoder side and comprises obtaining (S204-2) a reference block by using template matching (TM) in a (e.g. predefined) search area and obtaining (e.g. deriving or taking) a BVD, noted BVDTM, from the reference block (S204-3). In an example, a BV is obtained (e.g. derived) from the reference block and the predicted BVD is obtained by subtracting BVP from the obtained (e.g. derived) BV. The BVP is for example the same as the one used for obtaining the true BVD. The suffix part, for the considered component, is finally obtained (e.g. predicted) from BVDTM (S204-4). Said otherwise, BVDTMX=prefix_ BVDTMx+suffix_ BVDTMx, and the predicted suffix part is thus suffix_ BVDTM x. The same apply to the y component. If suffix parts of both components are predicted then S204-2 is operated only once since the same BVDTM is used for both components.

[0146] As an example, if / when valid_bvd_x_pred_flag==l or valid_bvd_y_pred_flag==l (or both), the reference block is obtained by using TM in the predefined search area. If / when valid_bvd_x_pred_flag==l, BVDTM is taken from the reference block (predicted BVD). The suffix part is finally obtained (e.g. taken) from the predicted BVDTM for x component. Otherwise (i.e. valid_bvd_x_pred_flag==O), the suffix part is decoded (e.g. directly) from the bitstream for x component. In an example, decoding the suffix part for x component occurs only for non-zero BVDx magnitude. If / when valid_bvd_y_pred_flag==l, BVDTM is taken from the reference block (predicted BVD). The suffix part is finally obtained (e.g. taken) from the predicted BVDTM for y component. Otherwise (i.e. valid_bvd_y_pred_flag==O), the suffix part is decoded (e.g. directly) from the bitstream for y component. In an example, decoding the suffix part for y component occurs only for non-zero BVDy magnitude.

[0147] A flag (e.g. GrOx_flag and GrOy_flag) may be decoded first, e.g, for each component, to indicate whether the component is non-zero or not. If the flag is 1, the component is non-zero and the amplitude is to be decoded, e.g. its prefix and possibly suffix if not predicted. If the flag is 0, it means the component (e.g. BVDx / BVDy) is zero, and no more decoding is needed for that particular component.

[0148] At S206, the BVD is obtained from the prefix and suffix parts obtained for each component.

[0149] A picture block (e.g. a current CU) may finally be reconstructed using the BVD. For example, a block vector BV is obtained by adding the BVD to BVP. The picture block is thus reconstructed from the reference block identified by BV.

[0150] FIG. 15 depicts a flowchart of an encoding method according to a second example. In the second example, valid_bvd_pred_flag is used along with two new (e.g. dedicated) flags used for individual BVD component suffix prediction. valid_bvd_pred_flag may be encoded first, followed by valid_bvd_x_pred_flag and valid_bvd_y_pred_flag when applicable. At S300, a BVD is obtained (e.g. found) for a picture block (e.g. a current CU), e.g. by using standard encoder search procedure implemented in the IBC mode, e.g. as illustrated by FIG. 11. This BVD is referred to as the true BVD in the following.

[0151] At S302, a reference block is obtained (e.g. found), e.g. by using template matching (TM) in a (e.g. predefined) search area (a.k.a. search region). In an example, S302 is executed only in the case where at least one of the vector components of the true BVD is non-zero, i.e. if either BVDx or BVDy is non-zero or both are non-zero.

[0152] At S304, a BVD, noted BVDTM, is obtained (e.g. derived or taken) from the reference block obtained at S302, e.g. only in the case where at least one of the vector components of the true BVD is non-zero. BVDTM is referred to as the predicted BVD in the following. In an example, a BV is obtained (e.g. derived) from the reference block and the predicted BVDTM is obtained by subtracting BVP from the obtained (e.g. derived) BV. The BVP is for example the same as the one used for obtaining the true BVD.

[0153] At S306, a prefix part is encoded for each (e.g. for each non-zero) component of the block vector difference, namely of the true BVD. In an example, a prefix part for component x, e.g. if non-zero, is encoded and a prefix part for component y, e.g. if non-zero, is encoded.

[0154] At S308, in the case where components BVDx and BVDy are both non-zero (S308-1), information (e.g. a single flag) is encoded that indicates for both components whether their suffix parts are predicted or not based on a comparison of BVD and BVDTM. In the case where information indicates that suffix parts of both components are predicted, then no more information is encoded for BVDx and BVDy.

[0155] In the case where both components are non-zero and the information at S308-1 indicates that at least one suffix part among the suffix parts of BVDx and BVDy cannot be predicted correctly (e.g. BVDx can be predicted correctly from the BVDTM but BVDy cannot be predicted correctly from BVDTM or vice versa) or in the case where only one component is non-zero, information (e.g. a flag) is encoded (S308-2) for the non-zero component(s) that indicates whether the suffix part is predicted or not for this component. The value of the information is based on a comparison of the non-zero component of BVD with the corresponding component of BVDTM.

[0156] In an example, if / when true BVDx is non-zero and true BVDy is non-zero, true BVD and predicted BVD are compared, e.g. x and y component of the vectors are compared. If / when both vector components are the same, e.g. comparison / prediction is marked as correct, valid_bvd_pred_flag is set to 1 indicating that BVD suffix parts are predicted for both components. Otherwise, valid_bvd_pred_flag is set to 0 indicating that BVD suffix may be present in the bitstream, e.g. whether suffix is present in the bitstream depends on the further comparison. valid_bvd_pred_flag is also set to 0 if at least one vector component of the true BVD is zero, and in the next step comparison is done on a per-component basis.

[0157] If / when valid_bvd_pred_flag==O and if true BVDx is non-zero, true BVDx and predicted BVDx are compared.

[0158] If / when true BVDx and predicted BVDx are the same, valid_bvd_x_pred_flag is set to 1 indicating that BVDx suffix is predicted, otherwise, valid_bvd_x_pred_flag is set to 0 indicating that BVDx suffix is present in the bitstream, i.e. not predicted. valid_bvd_x_pred_flag is also set to 0 if true BVDx is zero.

[0159] If / when valid_bvd_pred_flag==O and valid_bvd_x_pred_flag==O and if / when true BVDy is non-zero, true BVDy and predicted BVDy are compared. If / when true BVDy and predicted BVDy are the same, valid_bvd_y_pred_flag is set to 1 indicating that BVDy suffix is predicted, otherwise, valid_bvd_y_pred_flag is set to 0 indicating that BVDy suffix is present in the bitstream, i.e. not predicted. valid_bvd_y_pred_flag is also set to 0 if true BVDy is zero.

[0160] If / when BVDx and BVDy are both non-zero, valid_bvd_pred_flag is encoded, otherwise (i.e. if at least one of the components is zero), valid_bvd_pred_flag is not encoded (e.g. encoding valid_bvd_pred_flag is skipped).

[0161] If / when valid_bvd_pred_flag==O and if / when BVDx is non-zero, valid_bvd_x_pred_flag is encoded, otherwise (i.e. BVDx is zero), valid_bvd_x_pred_flag is not encoded (e.g. encoding valid_bvd_x_pred_flag is skipped).

[0162] If / when valid_bvd_pred_flag==O, and if / when valid_bvd_x_pred_flag==O and if / when BVDy is non-zero, valid_bvd_y_pred_flag is encoded, otherwise valid_bvd_y_pred_flag is not encoded (e.g. encoding valid_bvd_y_pred_flag is skipped).

[0163] At S310, a suffix part is encoded for each component for which the information indicates a suffix part is not predicted for said component.

[0164] If / when BVDx is non-zero and valid_bvd_pred_flag==O and valid_bvd_x_pred_flag==O, suffix part for component x is encoded. If / when BVDy is non-zero and valid_bvd_pred_flag==O and valid_bvd_y_pred_flag==O, suffix part for component y is encoded.

[0165] In this example, valid_bvd_pred_flag is thus encoded only in the case where both BVDx and BVDy are non-zero. If at least one component is of zero magnitude, valid_bvd_pred_flag may be skipped (e.g. not encoded into the bitstream) and the non-zero component suffix prediction can be handled with other flags, valid_bvd_x_pred_flag or valid_bvd_y_pred_flag depending on the component to be considered.

[0166] In this example, valid_bvd_x_pred_flag and valid_bvd_y_pred_flag may be encoded only if / when valid_bvd_pred_flag is equal to 0. valid_bvd_pred_flag==l means that both suffix parts for BVDx and BVDy are correctly predicted. Signalling only valid_bvd_pred_flag (when equal to 1) represents the optimal signaling overhead since there is no need to send additional flags, valid_bvd_x_pred_flag and valid_bvd_y_pred_flag. Indeed, in this case, they provide no additional information.

[0167] When flag, e.g. valid_bvd_pred_flag, valid_bvd_x_pred_flag or valid_bvd_y_pred_flag, is not encoded its value is assumed to be 0.

[0168] Table 2 illustrates example of possible combination of flags, where “X” indicate that the flag is not encoded (and thus not decoded).

[0169] Table 2 - Possible combinations of flag values

[0170] In the above example, valid_bvd_x_pred_flag is encoded before valid_bvd_y_pred_flag. However, valid_bvd_y_pred_flag is encoded only if valid_bvd_x_pred_flag is equal to 0. Indeed, the case where both flags are 1 is equivalent to the case where valid_bvd_pred_flag is equal to 1. Since valid_bvd_pred_flag is encoded (and thus decoded) first, situation when both other flags are 1 is not permitted. Therefore, bits are saved. Thus, if valid_bvd_x_pred_flag==l, another flag valid_bvd_y_pred_flag is implicitly deducted to be 0. However, this is by convention and in another example, valid_bvd_y_pred_flag may be encoded before valid_bvd_x_pred_flag in which case valid_bvd_x_pred_flag is encoded only if valid_bvd_y_pred_flag==O. Note that the examples in the table above (Table 2) illustrate the case where both components are non-zero. Some other examples may be possible when at least one component is zero.

[0171] FIG. 16 depicts a flowchart of a decoding method according to an example.

[0172] At S400, a prefix part is decoded for each component of a block vector difference, e.g. only for non-zero BVD magnitude.

[0173] At S402, in the case where components BVDx and BVDy are both non-zero (S402-1), information (e.g. a single flag such as valid_bvd_pred_flag) is decoded that indicates for both components whether their suffix parts are predicted or not. In the case where information indicates that suffix parts of both components are predicted (e.g. valid_bvd_pred_flag==l), then the method continues at S404.

[0174] In the case where both components are non-zero but the information at S402-1 indicates that at least one suffix part among the suffix parts of BVDx and BVDy cannot be predicted correctly (e.g. valid_bvd_pred_flag==O) or in the case where one (e.g. only one component) is non-zero, information (e.g. a flag) is decoded (S402-2) for the non-zero component(s) that indicates whether a suffix part is predicted or not for this component.

[0175] At S404, a suffix part is obtained for each (e.g. for each non-zero) component based on the information decoded at S402. Said otherwise, in the case where the information indicates that the suffix part is not predicted then the suffix part is decoded from the bitstream, otherwise the suffix part is predicted as illustrated by FIG. 14B. Predicting the suffix part is done as on the encoder side and comprises obtaining a reference block by using template matching (TM) in a (e.g. predefined) search area and obtaining (e.g. deriving or taking) a BVD, noted BVDTM, from the reference block. In an example, a BV is obtained (e.g. derived) from the reference block and the predicted BVD is obtained by subtracting BVP from the obtained (e.g. derived) BV. The BVP is for example the same as the one used for obtaining the true BVD. The suffix part is finally obtained from BVDTM.

[0176] In an example, if / when true BVDx and true BVDy are both non-zero, valid_bvd_pred_flag is decoded that indicates whether both BVDx suffix and BVDy suffix are predicted or not (if not predicted then further steps are required to obtain information if they are predicted or present in the bitstream), else set valid_bvd_pred_flag=O (only one component is non zero, or both are zero, thus valid_bvd_pred_flag is not decoded). If / when valid_bvd_pred_flag is equal to 1, the reference block is obtained by using TM in the predefined search area. BVDTM is taken from the reference block (predicted BVD). The suffix part is finally obtained (e.g. taken) from the predicted BVDTM for both x and y components.

[0177] Otherwise (i.e. , if / when valid_bvd_pred_flag is equal to 0 and at least one component is nonzero), further steps are required.

[0178] If / when BVDx is non-zero, valid_bvd_x_pred_flag is decoded that indicates whether BVDx suffix is present or not (and thus predicted). Else set valid_bvd_x_pred_flag=O.

[0179] If / when BVDy is non-zero and if valid_bvd_x_pred_flag is equal to 0, valid_bvd_y_pred_flag is decoded that indicates whether BVDy suffix is present or not (and thus predicted). Else set valid_bvd_y_pred_flag=O.

[0180] If BVDx is non-zero and valid_bvd_pred_flag==O and valid_bvd_x_pred_flag==O, the suffix part for component x is decoded. Otherwise, a reference block is obtained by using TM in a (e.g. predefined) search area. BVDTM is taken from the reference block (predicted BVD). The suffix part is finally obtained (e.g. taken) from the predicted BVDTM for x component.

[0181] If BVDy is non-zero and valid_bvd_pred_flag==O and valid_bvd_y_pred_flag==O, the suffix part for component y is decoded. Otherwise, a reference block is obtained by using TM a the (e.g. predefined) search area. BVDTM is taken from the reference block (predicted BVD). The suffix part is finally obtained (e.g. taken) from the predicted BVDTM for y component.

[0182] At S406, the BVD is obtained from the prefix and suffix parts obtained for each component.

[0183] A picture block (e.g. a current CU) may finally be reconstructed using the BVD. For example, a block vector BV is obtained by adding the BVD to BVP. The picture block is thus reconstructed from the reference block identified by BV.

[0184] In other examples applicable to the methods of FIGs 15 and 16, the use of valid_bvd_pred_flag may be conditioned to additional constraints. In an example, the use of the flag may be conditioned based on the prefix value of BVDx and BVDy components.

[0185] In one variant, valid_bvd_pred_flag may be (e.g. is only) used (e.g. encoded / decoded) if both prefix BVDx and prefix BVDy are higher than or equal to a predefined value BVD PREFIX MIN SIZE, e.g. BVD PREFIX MIN SIZE may be set to any prefix value indicated in Table 1. In second variant, valid_bvd_pred_flag may be (e.g. is only) used (e.g. encoded / decoded) if at least one prefix BVDx or prefix BVDy is higher than or equal to the predefined value BVD PREFIX MIN SIZE.

[0186] In a third variant, valid_bvd_pred_flag may be (e.g. is only) used (e.g. encoded / decoded) if prefix BVDx is higher than or equal to a predefined value BVD PREFIX MIN SIZE X and prefix BVDy is higher than or equal to a predefined value BVD PREFIX MIN SIZE Y. In an example, e.g. BVD PREFIX MIN SIZE X and BVD PREFIX MIN SIZE Y can be set to any prefix value indicated in Table 1 and BVD PREFIX MIN SIZE X may be or may not be equal to the BVD PREFIX MIN SIZE Y.

[0187] In a fourth variant, valid_bvd_pred_flag may be (e.g. is only) used (e.g., encoded / decoded) if the sum of both prefix (e.g. prefix BVDx and prefix BVDy) is higher than or equal to the predefined value BVD PREFIX MIN SIZE.

[0188] In other examples applicable to the methods of FIGs 13 to 16, the use of valid_bvd_x_pred_flag and valid_bvd_y_pred_flag may be conditioned to additional constraints.

[0189] In one variant, valid_bvd_x_pred_flag may be (e.g. is only) used (e.g. encoded / decoded) if prefix BVDx is higher or equal than a predefined value BVD PREFIX MIN SIZE X.

[0190] In another variant, valid_bvd_y_pred_flag may be (e.g. is only) used (e.g. encoded / decoded) if prefix BVDy is higher than or equal to a predefined value BVD PREFIX MIN SIZE Y.

[0191] The present aspects are not limited to ECM, VVC or HEVC, and can be applied, for example, to other standards and recommendations, and extensions of any such standards and recommendations. Unless indicated otherwise, or technically precluded, the aspects described in this application can be used individually or in combination.

[0192] Various numeric values are used in the present application. The specific values are for example purposes and the aspects described are not limited to these specific values.

[0193] Note that syntax elements as used herein, such as terms in equations and algorithms, signal (e.g. flag) labels / names, etc., such as valid_bvd_pred_flag, valid_bvd_x_pred_flag, valid_bvd_y_pred_flag and so on, are descriptive terms. As such, they do not preclude the use of other syntax element names.

[0194] Various implementations involve decoding. “Decoding”, as used in this application, can encompass all or part of the processes performed, for example, on a received encoded sequence in order to produce a final output suitable for display. In various embodiments, such processes include one or more of the processes typically performed by a decoder, for example, entropy decoding, inverse quantization, inverse transformation, and differential decoding. In various embodiments, such processes also, or alternatively, include processes performed by a decoder of various implementations described in this application, for example, decode a block vector difference.

[0195] As further examples, in one embodiment “decoding” refers only to entropy decoding, in another embodiment “decoding” refers only to differential decoding, and in another embodiment “decoding” refers to a combination of entropy decoding and differential decoding, and in another embodiment “decoding” refers to the whole reconstructing picture process including entropy decoding. Whether the phrase “decoding process” is intended to refer specifically to a subset of operations or generally to the broader decoding process will be clear based on the context of the specific descriptions and is believed to be well understood by those skilled in the art.

[0196] Various implementations involve encoding. In an analogous way to the above discussion about “decoding”, “encoding” as used in this application can encompass all or part of the processes performed, for example, on an input video sequence in order to produce an encoded bitstream. In various embodiments, such processes include one or more of the processes typically performed by an encoder, for example, partitioning, differential encoding, transformation, quantization, and entropy encoding. In various embodiments, such processes also, or alternatively, include processes performed by an encoder of various implementations described in this application, for example, encode a block vector difference.

[0197] As further examples, in one embodiment “encoding” refers only to entropy encoding, in another embodiment “encoding” refers only to differential encoding, and in another embodiment “encoding” refers to a combination of differential encoding and entropy encoding. Whether the phrase “encoding process” is intended to refer specifically to a subset of operations or generally to the broader encoding process will be clear based on the context of the specific descriptions and is believed to be well understood by those skilled in the art.

[0198] This disclosure has described various pieces of information, such as for example syntax, that can be transmitted or stored, for example. This information can be packaged or arranged in a variety of manners, including for example manners common in video standards such as putting the information into an SPS, a PPS, a NAL unit, a header (for example, a NAL unit header, or a slice header), or an SEI message. Other manners are also available, including for example manners common for system level or application level standards such as putting the information into one or more of the following: a. SDP (session description protocol), a format for describing multimedia communication sessions for the purposes of session announcement and session invitation, for example as described in RFCs and used in conjunction with RTP (Real-time Transport Protocol) transmission. b. DASH MPD (Media Presentation Description) Descriptors, for example as used in DASH and transmitted over HTTP, a Descriptor is associated with a Representation or collection of Representations to provide additional characteristic to the content Representation. c. RTP header extensions, for example as used during RTP streaming. d. ISO Base Media File Format, for example as used in OMAF and using boxes which are object-oriented building blocks defined by a unique type identifier and length also known as 'atoms' in some specifications. e. HLS (HTTP live Streaming) manifest transmitted over HTTP. A manifest can be associated, for example, to a version or collection of versions of a content to provide characteristics of the version or collection of versions.

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

[0200] Some embodiments may refer to rate distortion optimization. In particular, during the encoding process, the balance or trade-off between the rate and distortion is usually considered, often given the constraints of computational complexity. The rate distortion optimization is usually formulated as minimizing a rate distortion function, which is a weighted sum of the rate and of the distortion. There are different approaches to solve the rate distortion optimization problem. For example, the approaches may be based on an extensive testing of all encoding options, including all considered modes or coding parameters values, with a complete evaluation of their coding cost and related distortion of the reconstructed signal after coding and decoding. Faster approaches may also be used, to save encoding complexity, in particular with computation of an approximated distortion based on the prediction or the prediction residual signal, not the reconstructed one. Mix of these two approaches can also be used, such as by using an approximated distortion for only some of the possible encoding options, and a complete distortion for other encoding options. Other approaches only evaluate a subset of the possible encoding options. More generally, many approaches employ any of a variety of techniques to perform the optimization, but the optimization is not necessarily a complete evaluation of both the coding cost and related distortion.

[0201] The implementations and aspects described herein can be implemented in, for example, a method or a process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method), the implementation of features discussed can also be implemented in other forms (for example, an apparatus or program). An apparatus can be implemented in, for example, appropriate hardware, software, and firmware. The methods can be implemented in, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, such as, for example, computers, cell phones, portable / personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end-users.

[0202] Reference to “one embodiment” or “an embodiment” or “one implementation” or “an implementation”, as well as other variations thereof, means that a particular feature, structure, characteristic, and so forth described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrase “in one embodiment” or “in an embodiment” or “in one implementation” or “in an implementation”, as well any other variations, appearing in various places throughout this application are not necessarily all referring to the same embodiment.

[0203] Additionally, this application may refer to “determining” various pieces of information. Determining the information can include one or more of, for example, estimating the information, calculating the information, predicting the information, or retrieving the information from memory.

[0204] Further, this application may refer to “accessing” various pieces of information. Accessing the information can include one or more of, for example, receiving the information, retrieving the information (for example, from memory), storing the information, moving the information, copying the information, calculating the information, determining the information, predicting the information, or estimating the information.

[0205] Additionally, this application may refer to “receiving” various pieces of information. Receiving is, as with “accessing”, intended to be a broad term. Receiving the information can include one or more of, for example, accessing the information, or retrieving the information (for example, from memory). Further, “receiving” is typically involved, in one way or another, during operations such as, for example, storing the information, processing the information, transmitting the information, moving the information, copying the information, erasing the information, calculating the information, determining the information, predicting the information, or estimating the information.

[0206] It is to be appreciated that the use of any of the following “and / or”, and “at least one of’, for example, in the cases of “A / B”, “A and / or B” and “at least one of A and B”, is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B). As a further example, in the cases of “A, B, and / or C” and “at least one of A, B, and C”, such phrasing is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and the second listed options (A and B) only, or the selection of the first and third listed options (A and C) only, or the selection of the second and third listed options (B and C) only, or the selection of all three options (A and B and C). This may be extended, as is clear to one of ordinary skill in this and related arts, for as many items as are listed.

[0207] Also, as used herein, the word “signal” refers to, among other things, indicating something to a corresponding decoder. For example, in certain embodiments the encoder signals whether suffix part of BVD is present or not in the bitstream and thus whether it has to be decoded or predicted. In this way, in an embodiment the same parameter is used at both the encoder side and the decoder side. Thus, for example, an encoder can transmit (explicit signaling) a particular parameter to the decoder so that the decoder can use the same particular parameter. Conversely, if the decoder already has the particular parameter as well as others, then signaling can be used without transmitting (implicit signaling) to simply allow the decoder to know and select the particular parameter. By avoiding transmission of any actual functions, a bit savings is realized in various embodiments. It is to be appreciated that signaling can be accomplished in a variety of ways. For example, one or more syntax elements, flags, and so forth are used to signal information to a corresponding decoder in various embodiments. While the preceding relates to the verb form of the word “signal”, the word “signal” can also be used herein as a noun.

[0208] As will be evident to one of ordinary skill in the art, implementations can produce a variety of signals formatted to carry information that can be, for example, stored or transmitted. The information can include, for example, instructions for performing a method, or data produced by one of the described implementations. For example, a signal can be formatted to carry the bitstream of a described embodiment. Such a signal can be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal. The formatting can include, for example, encoding a data stream and modulating a carrier with the encoded data stream. The information that the signal carries can be, for example, analog or digital information. The signal can be transmitted over a variety of different wired or wireless links, as is known. The signal can be stored on a processor-readable medium.

[0209] Many examples are described herein. Features of examples may be provided alone or in any combination, across various claim categories and types. Further, examples may include one or more of the features, devices, or aspects described herein, alone or in any combination, across various claim categories and types. For example, features described herein may be implemented in a bitstream or signal that includes information generated as described herein. The information may allow a decoder to decode a bitstream and / or an encoder to encode a bitstream, according to any of the embodiments described. For example, features described herein may be implemented by creating and / or transmitting and / or receiving and / or decoding a bitstream or signal. For example, features described herein may be implemented by a method, process, apparatus, medium storing instructions, medium storing data, or signal. For example, features described herein may be implemented by a TV, set-top box, cell phone, tablet, or other electronic device that performs decoding (encoding respectively). The TV, set-top box, cell phone, tablet, or other electronic device may display (e.g. using a monitor, screen, or other type of display) a resulting image (e.g., an image from residual reconstruction of the video bitstream). The TV, set-top box, cell phone, tablet, or other electronic device may receive a signal including an encoded image and perform decoding.

[0210] A number of embodiments has been described above. Features of these embodiments can be provided alone or in any combination, across various claim categories and types. A decoding method is disclosed that comprises : decoding a prefix part for each (e.g. for each non-zero) component of a vector difference ; decoding, for each (e.g, for each non-zero) component, information indicating whether a suffix part is predicted for said component ; obtaining, for each (e.g, for each non-zero) component, a suffix part based on the information decoded for said component ; and obtaining the vector difference from the prefix part and the suffix part.

[0211] A decoding method is disclosed that comprises : decoding a prefix part for each (e.g. for each non-zero) component of a vector difference ; decoding information indicating whether suffix parts of both components are predicted responsive to determining that both components are non-zero ; decoding, for each (e.g, for each non-zero) component, information indicating whether a suffix part is predicted for said component responsive to determining that one (e.g. only one) component is non zero or that said decoded information indicates that at least one suffix part is not (e.g. cannot be predicted) predicted; and obtaining the suffix part for each (e.g, for each non-zero) component based on the decoded information; obtaining the vector difference from the prefix part and the suffix part.

[0212] A decoding method is disclosed that comprises : decoding a prefix part for each (e.g. for each non-zero) component of a vector difference ; in case both components are non-zero, decoding information indicating whether suffix parts of both components are predicted ; in case one component (e.g. only one) is non zero or said decoded information indicates that at least one suffix part is not predicted, decoding, for each (e.g. for each non-zero) component, information indicating whether a suffix part is predicted for said component; obtaining the suffix part for the components (e.g. for each non zero component) based on the decoded information; and obtaining the vector difference from the prefix part and the suffix part.

[0213] An encoding method is disclosed that comprises: obtaining a vector difference for a picture block; obtaining a reference block by template matching ; obtaining a predicted vector difference from the reference block ; encoding a prefix part for each (e.g. for each non-zero) component of the vector difference ; encoding, for each (e.g. for each non-zero) component, information indicating whether a suffix part is predicted for said component based on a comparison of the vector difference and the predicted vector difference; and encoding a suffix part for each component for which the information indicates the suffix part is not predicted.

[0214] An encoding method is disclosed that comprises: obtaining a vector difference for a picture block; obtaining a reference block by template matching ; obtaining a predicted vector difference from the reference block ; encoding) a prefix part for each component of the vector difference ; encoding information indicating whether suffix parts of both components are predicted responsive to determining that both components are non-zero; encoding, for each (e.g. for each non-zero) component, information indicating whether a suffix part is predicted for said component responsive to determining that one (e.g. only one) component is non-zero or that said information indicates that at least one suffix part is not predicted; and encoding a suffix part for each component for which the information indicates the suffix part is not predicted.

[0215] An encoding method is disclosed that comprises: obtaining a vector difference for a picture block; obtaining a reference block by template matching ; obtaining a predicted vector difference from the reference block ; encoding a prefix part for each component of the vector difference ; in case both components are non-zero, encoding (S308-1) information indicating whether suffix parts of both components are predicted ; in case one (e.g. only one) component is non-zero or said information indicates that at least one suffix part is not predicted, encoding, for each (e.g. for each non-zero) component, information indicating whether a suffix part is predicted for said component ; and encoding a suffix part for each component for which the information indicates the suffix part is not predicted.

[0216] In an example, the vector difference is a motion vector difference or a block vector difference.

[0217] In an example, obtaining a suffix part based on the decoded information comprises for a component: predicting the suffix part in the case where the decoded information indicates the suffix part is not signaled; and decoding the suffix part otherwise.

[0218] In an example, predicting the suffix part comprises: obtaining a reference block by template matching; obtaining a predicted vector difference from said reference block; and obtaining the suffix part from the predicted vector difference.

[0219] In an example, obtaining a predicted vector difference from said reference block comprises subtracting a vector predictor from a vector identifying the reference block.

[0220] In an example, the vector predictor is obtained by decoding (encoding respectively) an index identifying the vector predictor in a list of candidate vectors.

[0221] In an example, said information indicating whether suffix parts of both components are predicted is decoded (encoded respectively) only in the case where prefix parts of both components are higher than a value.

[0222] In an example, said information indicating whether suffix parts of both components are predicted is decoded (encoded respectively) only in the case where at least one prefix part of the components is higher than a value.

[0223] In an example, said information indicating whether suffix parts of both components are predicted is decoded (encoded respectively) only in the case where a prefix part of a first component is higher than a first value and a prefix part of a second component is higher than a second value. In an example, said information indicating whether suffix parts of both components are predicted is decoded (encoded respectively) only in the case where a sum of prefix parts of both components is higher than a value.

[0224] In an example, information indicating whether a suffix part is predicted for the component is decoded (encoded respectively) only in the case where a prefix part of said component is higher than a value.

[0225] A decoding apparatus is disclosed that comprises one or more processors and at least one memory coupled to said one or more processors, wherein said one or more processors are configured to perform the any one of the decoding methods.

[0226] An encoding apparatus is disclosed that comprises one or more processors and at least one memory coupled to said one or more processors, wherein said one or more processors are configured to perform the any one of the encoding methods.

[0227] A computer program is disclosed that comprises program code instructions for implementing any one of the encoding or decoding methods when executed by a processor.

Claims

CLAIMS1. A decoding method comprising: decoding (S200) a prefix part for each non-zero component of a vector difference; decoding (S202), for each non-zero component, information indicating whether a suffix part is predicted for said component; obtaining (S204), for each non-zero component, a suffix part based on the information decoded for said component; and obtaining (S206) the vector difference from the prefix part and the suffix part.

2. A decoding method comprising: decoding (S400) a prefix part for each non-zero component of a vector difference; in case both components are non-zero, decoding (S402-1) information indicating whether suffix parts of both components are predicted; in case one component is non zero or said decoded information indicates that at least one suffix part is not predicted, decoding (S402-2), for each non-zero component, information indicating whether a suffix part is predicted for said component; and obtaining (S404) the suffix part for said component based on the decoded information; and obtaining (S406) the vector difference from the prefix part and the suffix part.

3. The method of claim 1 or 2, wherein the vector difference is a motion vector difference or a block vector difference.

4. The method of any one of claims 1 to 3, wherein obtaining a suffix part based on the decoded information comprises for a component: predicting the suffix part in the case where the decoded information indicates the suffix part is not signaled; and decoding the suffix part otherwise.

5. The method of claim 4, wherein predicting the suffix part comprises: obtaining a reference block by template matching; obtaining a predicted vector difference from said reference block; and obtaining the suffix part from the predicted vector difference.

6. The method of claim 5, wherein obtaining a predicted vector difference from said reference block comprises subtracting a vector predictor from a vector identifying the reference block.

7. The method of claim 6, wherein the vector predictor is obtained by decoding an index identifying the vector predictor in a list of candidate vectors.

8. The method of claim 2, wherein said information indicating whether suffix parts of both components are predicted is decoded only in the case where prefix parts of both components are higher than a value.

9. The method of claim 2, wherein said information indicating whether suffix parts of both components are predicted is decoded only in the case where at least one prefix part of the components is higher than a value.

10. The method of claim 2, wherein said information indicating whether suffix parts of both components are predicted is decoded only in the case where a prefix part of a first component is higher than a first value and a prefix part of a second component is higher than a second value.

11. The method of claim 2, wherein said information indicating whether suffix parts of both components are predicted is decoded only in the case where a sum of prefix parts of both components is higher than a value.

12. The method of claim 1 or 2, wherein information indicating whether a suffix part is predicted for a component is decoded only in the case where a prefix part of said component is higher than a value.

13. An encoding method comprising: obtaining (SI 00) a vector difference for a picture block; obtaining (SI 02) a reference block by template matching; obtaining (SI 04) a predicted vector difference from the reference block; encoding (SI 06) a prefix part for each non-zero component of the vector difference; encoding (SI 08), for each non-zero component, information indicating whether a suffix part ispredicted for said component based on a comparison of the vector difference and the predicted vector difference; and encoding (S 110) a suffix part for each component for which the information indicates the suffix part is not predicted.

14. An encoding method comprising obtaining (S300) a vector difference for a picture block; obtaining (S302) a reference block by template matching; obtaining (S304) a predicted vector difference from the reference block; encoding (S306) a prefix part for each component of the vector difference; in case both components are non-zero, encoding (S308-1) information indicating whether suffix parts of both components are predicted; in case one component is non-zero or said information indicates that at least one suffix part is not predicted, encoding (S308-2), for each non-zero component, information indicating whether a suffix part is predicted for said component; and encoding (S310) a suffix part for each component for which the information indicates the suffix part is not predicted.

15. The method of claim 13 or 14, wherein the vector difference is a motion vector difference or a block vector difference.

16. The method of claim 13 or 14, wherein obtaining a predicted vector difference from said reference block comprises subtracting a vector predictor from a vector identifying the reference block.

17. The method of claim 14, wherein said information indicating whether suffix parts of both components are predicted is encoded only in the case where prefix parts of both components are higher than a value.

18. The method of claim 14, wherein said information indicating whether suffix parts of both components are predicted is encoded only in the case where at least one prefix part of the components is higher than a value.

19. The method of claim 14, wherein said information indicating whether suffix parts of both components are predicted is encoded only in the case where a prefix part of a first component is higher than a first value and a prefix part of a second component is higher than a second value.

20. The method of claim 14, wherein said information indicating whether suffix parts of both components are predicted is encoded only in the case where a sum of prefix parts of both component is higher than a value.

21. The method of claim 13 or 14, wherein information indicating whether a suffix part is predicted for the component is encoded only in the case where a prefix part of said component is higher than a value.

22. A decoding apparatus comprising one or more processors and at least one memory coupled to said one or more processors, wherein said one or more processors are configured to perform the method of any one of claims 1-12.

23. An encoding apparatus comprising one or more processors and at least one memory coupled to said one or more processors, wherein said one or more processors are configured to perform the method of any one of claims 13-21.

24. A computer program comprising program code instructions for implementing the method according to any one of claims 1-12 when executed by a processor.

25. A computer readable storage medium having stored thereon instructions for implementing the method of any one of claims 13-21.

Images