GB2539212A

GB2539212A - Handling of non-correct block vectors generated for intra block copy coding mode

Info

Publication number: GB2539212A
Application number: GB1509936.9A
Authority: GB
Inventors: Gisquet Christophe; Laroche Guillaume; Onno Patrice
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2015-06-08
Filing date: 2015-06-08
Publication date: 2016-12-14
Also published as: GB201509936D0

Abstract

Decoding a block of pixels in a current image using an Intra Block Copy mode in which the current block is predicted from a predictor block in the current image as indicated by a vector associated to the current block. The decoding comprises generating a list of vector predictor candidates; obtaining an index from the bitstream indicating a vector predictor from the list; obtaining a vector from the vector predictor; determining whether or not the obtained vector meets a predetermined criterion 1223; and, obtaining a predictor block in the current image using either the obtained vector or another interpreted vector, depending on the determination step. Preferably the predetermined criterion is that the obtained vector is null, defines an area outside the causal area or the current image, or defined an area that is Inter predicted from another image. Preferably, if the predetermined criterion is met, the vector is modified in a way which may include subtracting the block size from the first component of the vector or setting the first component to some fixed real negative multiplier of the block size. In embodiments the candidate lists are the conventional AMVP 1202 or Merge 1201 candidate list. A corresponding encoding claim is included.

Description

HANDLING OF NON-CORRECT BLOCK VECTORS GENERATED FOR INTRA BLOCK COPY

CODING MODE

FIELD OF THE INVENTION

The present invention is related to video coding and decoding. More precisely, embodiments of the present invention concern the encoding and decoding of block vectors in Intra Block Copy (IBC) mode presented in the scope of the Screen Content Coding (SCC) Extension of the High Efficiency Video Coding (HEVC: ISO/IEC 23008-2 MPEG-H Part 2/ ITU-T H.265) international standard.

More particularly, IBC mode provides that a block of pixels of a current image is encoded using a predictor block belonging to the same current image and indicated by a vector associated (usually in a bitstream) with the block of pixels.

BACKGROUND OF THE INVENTION

When encoding an image in a video sequence, the image is recursively split, thus creating a plurality of splitting levels. For instance, the image is first divided into slices (or tiles), each slice forming a data structure that can be decoded independently from other slices of the same image, in terms of entropy coding, signal prediction, and residual signal reconstruction. This division defines a slice level.

Then, each slice may be divided into coding entities of pixels of equal size referred to as Coding Tree Block (CTB), thus defining a CTB level. The size of a Coding Tree Block is typically 64 by 64 pixels.

Each Coding Tree Block may then be broken down into a hierarchical tree of smaller blocks which size may vary and which are the actual blocks of pixels to encode. These smaller blocks to encode are referred to as Coding Unit (CU), thus defining a CU level.

The encoding of a particular Coding Unit is typically predictive. This means that a predictor block is first determined. Next, the difference between the predictor block and the Coding Unit is calculated. This difference is called the residue or residual block. Next, this residue is compressed.

Usually, the compression of the residue includes a DCT transform followed by a quantization. The encoding is thus said to be lossy, meaning that information is lost in the encoding process. The decoded block of pixels is not exactly the same as the original Coding Unit. Typically the loss of information comes from the quantization applied to the residue before entropy coding. This quantization allows a higher compression rate at the price of the loss of accuracy.

The encoding may also be lossless, meaning that the residue is not quantized. This kind of encoding allows retrieving the exact copy of the original samples of the Coding Unit. The lossless encoding is obtained at the expense of compression rate which is much smaller compared to a lossy compression.

In practice, the prediction is operated on one or more Prediction Units (PUs) that split the Coding Unit. To be noted that the Coding Unit is the basic unit for which a prediction mode is selected or defined. It means that the PU or PUs forming the CU are all predicted using the prediction mode selected for the whole CU.

The actual encoded information of the Coding Unit is made of some information to indicate the way of determining the predictor block and the compressed residue. Best predictor blocks are blocks as similar as possible to the PUs in order to get a small residue that could be efficiently compressed.

The coding mode is defined based on the method used to determine the predictor block for the predictive encoding method of a Coding Unit.

A first main prediction-based coding mode is referred to as INTRA mode. According to INTRA mode, the predictor block is built based on the value of pixels immediately surrounding the Coding Unit within the current image. It is worth noting that the predictor block is not a block of the current image but a mere construction of a virtual block. A direction is used to determine which pixels of the border are actually used to build the predictor block and how they are used. The idea behind INTRA mode is that, due to the general coherence of natural images, the pixels immediately surrounding the Coding Unit are likely to be similar to pixels of the current Coding Unit. Therefore, it is possible to get a good prediction of the value of pixels of the Coding Unit using a predictor block based on these surrounding pixels.

Conventional INTRA coding defines a plurality of modes: planar mode, DC mode and 32 directional modes (including a horizontal mode and a vertical mode).

A second main prediction-based coding mode is referred to as INTER mode. According to INTER mode, the predictor block is a block taken from another image, known as reference image. The idea behind the INTER mode is that successive images in a sequence are generally very similar. The main difference comes typically from a motion between these images due to the scrolling of the camera or due to moving objects in the scene. The predictor block is determined by a vector giving its location in a reference image relatively to the location of the Coding Unit within the current image. This vector is referred to as a motion vector. According to this mode, referred to as the Inter mode, the encoding of such Coding Unit using this mode comprises motion information comprising the motion vector and the compressed residue.

Variations of the INTER coding have been introduced in HEVC. In particular, in order to further improve the coding efficiency, a motion vector competition mechanism, referred to as Advanced Motion Vector Prediction (AMVP) is provided. For AMVP, the best motion vector predictor for the current block is selected from a set or list (or AMVP candidate list) of vector predictor candidates and the index of the selected candidate is transmitted together with an index of the reference list and with a motion vector residue to the decoder.

Another variation is known as the Merge mode which consists in predicting the whole motion information to reduce the transmitted data. In the Merge mode, a single predictor index identifying a vector predictor within a set (or Merge candidate list) of vector predictor candidates is transmitted to the decoder by the encoder, in addition to the compressed block residue. No vector residue is transmitted. On the other end, the decoder is able to build the same list of vector predictor candidates and to reconstruct the motion information using the transmitted predictor index. Another variation of the INTER coding is the Skip Merge mode in which, compared to the Merge mode, no block residue is transmitted in the bitstream.

Other coding modes have been progressively introduced in HEVC, for instance, the Intra Block Copy (IBC) coding mode and the Palette coding mode.

When applied to a Coding Unit in the current image, the Intra Block Copy (IBC) mode proposes to use a predictor block taken from the causal area of the current image being reconstructed.

The causal area is usually made of the part of the current image already reconstructed. Indeed, the causal principle is the principle that states that all information to decode a particular Coding Unit must be based on already reconstructed Coding Units. This is because the encoder and the decoder must have the same level of knowledge about the image when processing the Coding Unit.

In details, at the encoder, the whole information is available. In particular, to encode a given Coding Unit, it would be possible to use, as reference information for prediction, any information from the entire current image or from all decoded and available other images in the sequence. At the decoder, things are very different. The decoding of the current images is typically done by decoding sequentially all the Coding Units. The order of decoding follows typically a raster scan order, namely beginning in the upper left of the image, progressing from left to right and from top to bottom. It comes that when decoding a given Coding Unit, only the part of the current image located up or left to the current Coding Unit has already been decoded. This is the only available information for the decoding of the current Coding Unit. This has to be taken into account at the encoder.

In the particular situation of the IBC mode, the predictor block should pertain to the part of the image that is available at the decoder.

The predictor block is located using a block vector (BV). In other words, the block vector gives the location of the block predictor in the current image relatively to the location of the Coding Unit in the same current image.

It comes that the block vector is quite similar to the motion vector of the INTER mode, except the former refers to the same current image while the latter refers to a reference image distinct from the current image.

As a consequence, it has been proposed to align the encoding of the IBC mode with the encoding of the INTER mode, in particular to take advantage of the coding efficiency of the Inter-AMVP and Merge and Merge Skip modes. Thus, the block vector determined in IBC mode can be predicted and encoded using a list of vector predictor candidates according to either AMVP or Merge or Merge Skip modes. By reusing the existing modes, no deep modification of the HEVC standard is required to include the IBC mode. To complete the alignment, the current image is added to the list of images to which the encoder and decoder can refer for prediction: use of IBC will therefore be indicated by specifying its corresponding reference index into the list of reference images.

However, it has been found that the AMVP or Merge or Merge Skip modes are not fully adapted to the IBC mode. For instance, the block predictor in the IBC mode is restricted to a subpart of the current image corresponding to the causal area, while the former modes may use a block predictor in any part of the reference image. It turns that the predictor candidates as provided in the AMVP or Merge or Merge Skip modes may not be adapted to the IBC mode.

This situation may reduce, and especially not optimize, coding efficiency using the IBC mode. However, it is sought to keep the conventional building mechanism for the AMVP and Merge candidate lists, to avoid deep modifications of the HEVC standard.

The present invention seeks to alleviate this not-optimized situation, with a view to overcome one or more of the foregoing drawbacks.

SUMMARY OF THE INVENTION

Embodiments of the invention at the decoder are directed to a method of decoding a block of pixels in a current image, using a predictor block belonging to the same current image and indicated by a vector associated with the block of pixels (i.e. the IBC mode), the method comprising the following steps: generating a list of vector predictor candidates; obtaining, from a bitstream encoding the block of pixels, a predictor index identifying one of the vector predictor candidates; obtaining a vector from the identified vector predictor candidate; and determining whether or not the obtained vector meets a predetermined criterion; obtaining a predictor block in the current image using either the obtained vector or another vector, depending on the outcome of the determining step; and generating the block of pixels using the obtained predictor block The predetermined criterion may for instance be related to the causal area of the current image being reconstructed.

The invention thus provides a way to handle vectors that are not adapted to the IBC mode due to inappropriate predictor candidates. Indeed, such un-adapted vectors cannot be used if resulting from invalid candidates (e.g. pointing outside the causal area). This results in wasted bits, thus coding efficiency loss, as said candidates can be specified by the syntax, but not allowed to be selected by the encoder.

On the other hand, adapted vectors can be used to build the predictor block and thus to reconstruct the current Coding Unit.

One may note that the obtained vector is the identified vector predictor candidate in the Merge and Merge Skip modes (because no vector residue is used).

Correspondingly, a decoding device for decoding a block of pixels in a current image, using a predictor block belonging to the same current image and indicated by a vector associated with the block of pixels (i.e. the IBC mode), the decoding device comprising at least one microprocessor configured for carrying out the steps of: generating a list of vector predictor candidates; obtaining, from a bitstream encoding the block of pixels, a predictor index identifying one of the vector predictor candidates; obtaining a vector from the identified vector predictor candidate; and determining whether or not the obtained vector meets a predetermined criterion; obtaining a predictor block in the current image using either the obtained vector or another vector, depending on the outcome of the determining step; and generating the block of pixels using the obtained predictor block.

The decoding device has the same advantages as the decoding method defined above.

Optional features of these embodiments are defined in appended claims. Some of these features are explained here below with reference to a method, and can be transposed into system features dedicated to a device according to embodiments of the invention.

In embodiments, the predetermined criterion is a function of components of the obtained vector and/or a function of the block of pixels, for instance a function of the block size N. As an example, such information may help to define the causal area, and thus may help to identify the un-adapted vectors. Again, the obtained vector is the identified vector predictor candidate in the Merge and Merge Skip cases (because no vector residue is used).

In embodiments, the predetermined criterion is at least one from: the obtained vector identifies a predictor block that does not belong to the causal area of the current image (i.e. the part of the current image already reconstructed); the obtained vector identifies a predictor block that is at least partly outside the current image; the obtained vector identifies a predictor block that includes at least one pixel predicted from another image; and the obtained vector is a null or zero vector.

These various criteria may overlap. For instance the null vector identifies the current block of pixels, which clearly does not belong to the causal area. Therefore, using one or the other of these criteria may simplify the processing at the decoder.

In embodiments, the method may further comprise if the obtained vector meets the predetermined criterion, modifying the obtained vector into a modified vector to be used as the other vector to obtain the predictor block.

This approach substantially improves coding efficiency. This is because new vectors can be indirectly used. To do so, the encoder may specify a vector predictor candidate of the list that will result in a non-adapted vector. Both the encoder and decoder may know that in such situation, an appropriate modification of the vector can be conducted to obtain such a new vector.

In a particular embodiment, the modified vector depends on at least one property of the block of pixels, for instance depends on the block size N or its position within the current image. This may help obtaining a modified vector well adapted to the size of the current block, for instance by identifying a neighboring block of the causal area.

In another particular embodiment, modifying the obtained vector into the modified vector includes one from: subtracting N from a first component of the obtained vector while the other component remains unchanged or is set to 0, NxN being the size of the block of pixels; setting a first component of the modified vector to -N while the other component of the obtained vector remains unchanged or is set to 0, NxN being the size of the block of pixels; setting a first component of the modified vector to -round(a.N) while the other component of the obtained vector remains unchanged or is set to 0, NxN being the size of the block of pixels, and a being a real number above or equal to 1, and round() being a rounding operator.

More generally, and in the preferred embodiments pertaining to IBC, as the size of a pixel block may be NxM, the value N used above for the subtracting or setting step may be replaced by max(N,M).

All these approaches help having a modified vector belonging to the causal area.

In a variant, both components of the obtained vector can be modified in the same way or using different approach as defined above.

According to a specific feature, the first component corresponds to the component having the greatest absolute value in the obtained vector.

Note that two modified vectors could be generated, for instance (-N,O) and (0,-N) in case there are two invalid candidates in the vector candidate list.

In embodiments, the method further comprises, if the obtained vector is a null or zero vector, setting the modified vector to (-N, 0), NxN being the size of the block of pixels.

In embodiments, the method further comprises, if both components of the obtained vector are above -N (i.e. belonging to]-N, 0011), setting the modified vector to (0, -N), NxN being the size of the block of pixels.

The inventors have found that the block predictors located at (-N, 0) and (0, -N) usually provide the best results in term of coding efficiency. The above provisions thus make it possible to use these block predictors although the AMVP or Merge lists of vector predictor candidates does not allow it in an efficient way (i.e. without high coding costs).

In embodiments, the block of pixels is encoded using the Infra Block Copy mode of HEVC.

Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a device, causes the device to perform any method as defined above.

The non-transitory computer-readable medium may have features and advantages that are analogous to those set out above and below in relation to the method and device, in particular that of improving the handling of the Infra Block Copy mode.

Yet another aspect of the invention relates to a device comprising means adapted for carrying out each step of any method as defined above.

Yet other aspects of the invention relate to a method of decoding a block of pixels in a current image, using a predictor block belonging to the same current image and indicated by a vector associated with the block of pixels, substantially as herein described with reference to, and as shown in, Figure 12 of the accompanying drawings.

At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates the HEVC encoder architecture; Figure 2 illustrates the HEVC decoder architecture; Figure 3 illustrates the neighbouring positions blocks used to generate motion vector predictors in AMVP and Merge of HEVC; Figure 4 illustrates the derivation process of motion vector predictors in AMVP; Figure 5 illustrates the derivation process of motion candidates in Merge; Figure 6 illustrates the coding structure used in HEVC; Figure 7 illustrates the Coding Tree Block splitting in Coding Units and the scan order decoding of these Coding Unit; Figure 8 illustrates the concept of the causal area; Figure 9 illustrates the Intra Block Copy search area; Figure 10 schematizes the current INTER scheme, from vector prediction to block compensation generating a block predictor, including the case of Intra Block Copy; Figure 11 illustrates prior art modifying the scheme of Figure 10; Figure 12 illustrates an adaptation of the scheme of Figure 10 according to embodiments of the invention; Figure 13 is a high-level representation of an encoder algorithm featuring the Intra Block Copy as well as other screen content coding methods; Figure 14 is the same representation with modifications related to embodiments of the invention; Figure 15 illustrates an Intra Block Copy search algorithm embedding parts according to embodiments of the invention; and Figure 16 is a schematic block diagram of a computing device for implementation of one or more embodiments of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION Figure 1 illustrates the HEVC encoder architecture. In the video encoder, an original sequence 101 is divided into blocks of pixels 102. A coding mode is then affected to each block. There are two families of coding modes typically used in HEVC: the modes based on spatial prediction (INTRA modes) 103 and the modes based on temporal prediction (INTER, Bidir, Skip modes) based on motion estimation 104 and motion compensation 105.

An INTRA Coding Unit is generally predicted from the encoded pixels at its causal boundary by a process called INTRA prediction.

Temporal prediction of INTER coding mode first consists in finding in a previous or future frame called the reference frame 116 the reference area which is the closest to the Coding Unit in a motion estimation step 104. The reference frames can be organized in one or more reference lists. For instance, HEVC defines two lists, LO and L1. This reference area constitutes the predictor block. In the case of Bidir temporal prediction, two predictor blocks, each indicated by its own motion information, can be merged into a final predictor block which is the actual reference area. Next this Coding Unit is predicted using the predictor block to compute the residue in a motion compensation step 105.

In both cases, spatial and temporal prediction, a residual is computed by subtracting the Coding Unit from the original predictor block.

In the INTRA prediction, a prediction direction is encoded. In the temporal prediction, at least one motion vector is encoded. However, in order to further reduce the bitrate cost related to motion vector encoding, a motion vector is not directly encoded. Indeed, assuming that motion is homogeneous, it is particularly interesting to encode a motion vector as a difference between this motion vector, and a motion vector in its surrounding. In H.264/AVC coding standard for instance, motion vectors are encoded with respect to a median vector computed between three blocks located above and on the left of the current block. Only a difference, also called residual motion vector, computed between the median vector and the current block motion vector is encoded in the bitstream. This is processed in module "Mv prediction and coding" 117. The value of each encoded vector is stored in the motion vector field 118. The neighbouring motion vectors, used for the prediction, are extracted from the motion vector field 118.

Then, the mode optimizing the rate distortion performance is selected in module 106, for example using a Lambda-based criterion such as D-G..R, where D is the distortion, a. a Lambda or Lagrangian coefficient and R the rate). In order to further reduce the redundancies, a transform, typically a DCT, is applied to the residual block in module 107, and a quantization is applied to the coefficients in module 108. The quantized block of coefficients is then entropy coded in module 109 and the result is inserted in the bitstream 110.

The encoder then performs a decoding of the encoded frame for the future motion estimation in modules 111 to 116. This is a decoding loop at the encoder. These steps allow the encoder and the decoder to have the same reference frames. To reconstruct the coded frame, the residual is inverse quantized in module 111 and inverse transformed in module 112 in order to provide the "reconstructed" residual in the pixel domain. According to the encoding mode (INTER or INTRA), this residual is added to the INTER predictor 114 or to the INTRA predictor 113.

Then, this first reconstruction is filtered in module 115 by one or several kinds of post filtering. These post filters are integrated in the decoding loop. It means that they need to be applied on the reconstructed frame at the encoder and decoder in order to use the same reference frames at the encoder and decoder. The aim of this post filtering is to remove compression artefacts.

For example, H.264/AVC uses a deblocking filter. This filter can remove blocking artefacts due to the DCT quantization of residual and to block motion compensation. In the current HEVC standard, three types of loop filters are used: deblocking filter, sample adaptive offset (SAO) and adaptive loop filter (ALF).

The principle of an HEVC decoder is represented in Figure 2. The video stream 201 is first entropy decoded in a module 202. The residual data are then inverse quantized in a module 203 and inverse transformed in a module 204 to obtain pixel values forming a residue. The mode data are also entropy decoded and in function of the mode, an INTRA type decoding or an INTER type decoding is performed. In the case of INTRA mode, the INTRA prediction direction is decoded from the bitstream. The prediction direction is then used to locate the reference area 205. If the mode is INTER, the motion information is decoded from the bitstream 202. This is composed of the reference frame index and the motion vector residual. The motion vector predictor is added to the motion vector residual to obtain the motion vector 210. The motion vector is then used to locate the reference area in the reference frame 206. The reference area is added to the residue to reconstruct the decoded frame. Note that the motion vector field data 211 is updated with the decoded motion vector in order to be used for the prediction of the next decoded motion vectors. This first reconstruction of the decoded frame is then post filtered 207 with exactly the same post filter as used at encoder side. The output of the decoder is the de-compressed video 209.

As introduced above, a conventional video codec according to HEVC exploits both spatial and temporal correlation between pixels thanks to INTRA and INTER coding modes. The INTRA coding modes exploit spatial correlation of the pixels in the current frame to provide spatial prediction. The INTER coding modes exploit temporal correlation between pixels of the current frame and previous encoded/decoded frames to provide temporal prediction.

The current design of HEVC uses three different INTER coding modes: the Inter mode, the Merge mode and the Merge Skip mode. The main difference between these modes is the data signalling in the bitstream.

In the Inter mode, all data are explicitly signalled in the bitstream for the concerned Coding Unit, meaning that the texture or block residue is coded and inserted in the bitstream, and all data for the motion information are also coded and inserted in the bitstream. The motion information includes the direction type (uni or bi-directional), the list index (if needed), the related reference frame indexes, and the motion vector value.

Note that, in current version of HEVC, the motion vector value is predicted by a motion vector predictor selected from the AMVP candidate list (see block 117 in Figure 1). The choice by the encoder of the vector predictor in the list is based on a competition between the several vector candidates with a rate distortion criterion, in order to find the best motion vector predictor. An index corresponding to the best vector predictor is inserted in the bitstream.

The motion vector residual (mvd) for each component is coded and inserted in the bitstream followed by the predictor index mvp_10_flag or mvp_11_flag, related to respectively the LO and L1 reference image lists.

Also note that HEVC provides motion estimation with a precision of a quarter-pixel (also known as Q-pel motion or Qpel motion). It means that a quarter of the distance between pixels may be used as the motion vector precision for motion estimation and motion compensation in video compression schemes. Though higher precision motion vectors take more bits to encode, they can sometimes result in more efficient compression overall, by increasing the quality of the prediction signal. In the description below, the Qpel resolution or integer pixel resolution may be indifferently used. Where appropriate, a vector or a residue may require to be scaled to the appropriate resolution.

The decoder can derive the same set of predictor candidates and uses the best one according to the decoded index.

In the Merge mode, the texture residue is coded and inserted in the bitstream; and only a predictor index is coded and inserted in the bitstream regarding the motion information. It means that no motion vector residual, direction type, list or reference frame index is coded.

Prediction of all these motion parameters is thus provided through the predictor index, meaning that they are derived from the predictor index. Note that a competition between the several vector candidates of the Merge list is also conducted with a rate distortion criterion to find the best motion vector (In the Merge mode, the vector predictor is the vector itself since no motion vector residual is provided).

In the Merge Skip mode, no information is transmitted to the decoder side except the "mode" (i.e. Merge Skip using a flag) and a predictor index determined using the same rate distortion competition as above. It is the same processing as the Merge mode except that no texture residual is coded or transmitted, meaning that the pixel values of a Merge Skip block are the pixel values of the block predictor.

For the remainder of the description, reference to the INTER mode means reference to any of Inter (AMVP) mode, Merge mode or Merge Skip mode. Thus, a CU is coded in INTER means that its coding mode is Inter or Merge or Merge Skip mode. Except for the Merge Skip mode, a texture residue is transmitted in the bitstream.

The design of the derivation of the AMVP and Merge vector predictor candidates (to form the AMVP and Merge lists) play a crucial role to achieve the best coding efficiency without large impact on complexity. In HEVC, two motion vector derivations are used: one for the Inter mode, known as the Advanced Motion Vector Prediction (AMVP) process and described below with reference to Figure 4; and one for the Merge modes, known as the Merge derivation process and described below with reference to Figure 5.

Beforehand, Figure 3 illustrates spatial and temporal blocks that can be used to generate motion vector predictors in Advanced Motion Vector Prediction (AMVP) and Merge modes of HEVC.

Figure 4 shows simplified steps of the process of the AMVP predictor set derivation. In the current HEVC design, the maximum number of motion vector predictor candidates for the AMVP is equal to two. The related candidate list is built using a reference list LX, X being 0 or 1, and an index into this list (thus indicating a reference image REF), which are transmitted by the encoder in the bitstream and decoded by the decoder before building the list and thus determining the motion vector residual. If the slice is said to be a P-slice, only one reference list, LO, exists, and is thus not transmitted, as it can be inferred by the decoder.

Two vector predictors, i.e. the two spatial motion vectors of the AMVP mode, are chosen from among the motion vectors associated with the top blocks BO-B2 (i.e. the motion vectors used when encoding these blocks) and with the left blocks AO-A1 including the top corner blocks and left corner block, and one vector predictor is chosen from among the motion vectors associated with the bottom right block H and with the centre block 'Center' of the block collocated to the current block in another image (for instance the previous or next image) as represented in Figure 3.

As shown in Figure 4, a first step aims at selecting a first spatial predictor candidate ("Cand 1", 406) from among the motion vectors (if any) associated with the bottom left blocks AO and Al in the current image as shown in Figure 3. To that end, these blocks AO and Al are successively selected (400, 402) one after the other, in the given order, when evaluating each of several conditions (404). The following conditions are thus successively evaluated for the two blocks (404) in the given order. The first block, AO or Al, for which one of the successively considered conditions is fulfilled is thus set as the left predictor candidate: -the motion vector associated with the tested block AO or Al references the same reference list LX and the same reference image REF as the ones indicated in the received bitstream; -the motion vector associated with the tested block AO or Al references the other reference list than the one indicated in the bitstream and the same reference image REF as the one indicated in the bitstream; -the scaled motion vector associated with the tested block AO or Al references the same reference list as the one indicated in the bitstream and a different reference image to the one indicated in the bitstream; or -the scaled motion vector associated with the tested block AO or Al references the other reference list than the one indicated in the bitstream and a different reference image to the one indicated in the bitstream.

If no block fulfils the conditions, the left predictor candidate ("Cand 1") is considered as being unavailable. In this case, it indicates that blocks AO and Al were INTRA coded and/or those blocks do not exist (e.g. due to image edge).

A next step aims at selecting a second spatial predictor ("Cand 2", 416) from among the motion vectors (if any) associated with the above right block BO, above block B1 and left above block B2 in the current image, as shown in Figure 3. To that end, these blocks BO-B2 are successively selected (408, 410, 412) one after the other, in the given order, and, for each selected block, the above mentioned conditions are evaluated (414) in the given order. The first block for which the conditions are fulfilled is thus set as the above predictor candidate.

Again, if none of the blocks BO-B2 fulfils the conditions, the above predictor candidate ("Cand 2") is considered as being unavailable. In this case, it indicates that blocks BO-B2 were INTRA coded and/or those blocks do not exist (e.g. due to image edge).

In a next step (418), the two left and above predictor candidates, if both are available, are compared one to the other to remove one of them if they are equal (i.e. same motion vector values, same reference list, same reference index and the same direction type). If only one spatial predictor candidate is available, the algorithm is looking for a temporal predictor in a following step.

The temporal motion predictor ("Cand 3", 426) is derived as follows: the motion vector (if any) associated with the bottom right (H, 420) position of the collocated block in a previous frame is first considered in the availability check module 422. If it does not exist or if the motion vector is not available, the centre of the collocated block (Centre, 424) is selected to check whether it is associated with a motion vector. These temporal positions (Centre and H) are shown in Figure 3. In any case, a scaling step 423 is applied on those candidates to match the temporal distance between the current frame and the selected reference frame in the reference list. The motion predictor is then added to the set of predictor candidates.

Next, the number (Nb_Cand) of predictor candidates thus obtained is compared (428) to the maximum number (Max Cand) of predictor candidates for the AMVP candidate list. As mentioned above, the maximum number (Max Cand) of motion vector predictor candidates that the derivation process of AMVP needs to generate is two in the current version of HEVC standard.

If this maximum number is reached, the final list or set of AMVP predictor candidates (432) is built. Otherwise, a zero or null vector is added (430) to the list as another vector predictor candidate. The zero or null vector is a motion vector equal to (0,0).

As illustrated in Figure 4, the final list or set of AMVP predictor candidates (432) may be built from a subset of spatial motion predictors (400 to 412) and from a subset of temporal motion predictors (420, 424).

Turning now to the Merge derivation process, a motion predictor candidate of the Merge mode or of the Merge Skip mode represents all the required motion information: direction, list, reference frame index, and motion vectors. An indexed list of several motion vector predictor candidates is generated by the Merge derivation process. In the current HEVC design the maximum number of motion vector predictor candidates for both Merge modes is equal to five (four spatial candidates and one temporal candidate).

Figure 5 is a schematic of a motion vector derivation process of the Merge modes. In a first step of the derivation process, five block positions in the current image are considered (500 to 508). These positions are the spatial positions shown in Figure 3 with references Al, Bl, BO, A0, and B2.

In a next step, the availability of spatial motion vectors associated with these five blocks A0-Al, B0-B2 is checked and at most five motion vectors are selected (510). A predictor is considered as available if it exists, i.e. if the block is not INTRA coded but INTER coded. Therefore, selecting the motion vectors corresponding to the five blocks as vector predictor candidates is done according to the following conditions: if the "left" Al motion vector (500) is available (510), i.e. if it exists and if this block is not INTRA coded, the motion vector of the "left" block is selected and used as a first candidate in the list of Merge spatial candidates (514); if the "above" B1 motion vector (502) is available (510), the "above" motion vector candidate is compared to the "left" Al motion vector already in the list (512), if it exists. If B1 motion vector is equal to Al motion vector, B1 is not added to the list of spatial candidates (514). On the contrary, if B1 motion vector is not equal to Al motion vector, B1 is added to the list of spatial candidates (514); if the "above right" BO motion vector (504) is available (510), the motion vector of the "above right" is compared to B1 motion vector (512). If BO motion vector is equal to B1 motion vector, BO motion vector is not added to the list of spatial candidates (514). On the contrary, if BO motion vector is not equal to B1 motion vector, BO motion vector is added to the list of spatial candidates (514); if the "below left" AO motion vector (506) is available (510), the motion vector of the "below left" is compared to Al motion vector (512). If AO motion vector is equal to Al motion vector, AO motion vector is not added to the list of spatial candidates (514). On the contrary, if AO motion vector is not equal to Al motion vector, AO motion vector is added to the list of spatial candidates (514); and if the list of spatial candidates doesn't contain four candidates, the availability of "above left" B2 motion vector (508) is checked (510). If it is available, it is compared to Al motion vector and to B1 motion vector. If B2 motion vector is equal to Al motion vector or to B1 motion vector, B2 motion vector is not added to the list of spatial candidates (514). On the contrary, if B2 motion vector is not equal to Al motion vector or to B1 motion vector, B2 motion vector is added to the list of spatial candidates (514).

At the end of steps 510-514, the Merge list of spatial candidates comprises up to four vector predictor candidates.

For the temporal candidate of the Merge list, two positions can be used: the bottom right position of the block collocated to the current block in a previous or next image (516, denoted H in Figure 3) and the centre of the collocated block (518). These positions are shown in Figure 3.

As for the AMVP motion vector derivation process (Figure 4), a first step aims at checking (520) the availability of the block at the H position. Next, if it is not available, the availability of the block at the centre position is checked (520). If at least one motion vector associated with these two blocks is available, the temporal motion vector (the one associated with H in priority) can be scaled (522), if needed, to the reference frame having index 0, for both list LO and Ll (two reference frame lists containing zero, one or more reference frames), in order to create a temporal candidate (524) which is added to the list of Merge motion vector predictor candidates. The temporal predictor candidate is positioned after the spatial predictor candidates in the Merge list.

Next, if the number (Nb_Cand) of candidates is strictly less (526) than the maximum number of candidates (Max Cand; that value is signalled in the bitstream slice header and is equal to five in the current HEVC design) and if the current frame is of the B type, combined candidates are generated (528).

Combined candidates are generated based on available candidates of the Merge candidate list. It mainly consists in combining the motion vector of one candidate of the list LO with the motion vector of one candidate of list LI, resulting in a new bi-directional candidate having for LO the LO motion information from one candidate in the merge list, and for L1 the L1 motion information of another candidate.

If the number (Nb Cand) of candidates remains strictly less (530) than the maximum number of candidates (Max Cand), zero motion candidates are generated (532) until the number of candidates of the Merge candidate list reaches the maximum number Max Cand of candidates.

At the end of this process, the Merge candidate list has been built (534). As illustrated in Figure 5, the Merge candidate list may be built (534) from a subset of spatial vector candidates (500 to 508) and from a subset of temporal vector candidates (516, 518).

Figure 6 illustrates the coding structure used in HEVC. The original video sequence 601 is a succession of digital images "images i". As is known per se, a digital image is represented by one or more matrices the coefficients of which represent pixels, the one or more matrices usally corresponding to the colour components, namely Red, Green or Blue in RGB colour space, or Luma, and two Chromas in YUV (Y, Cb, Cr) colour space.

The images 602 are divided into slices 603. A slice is a part of the image or the entire image. In HEVC these slices are divided into non-overlapping Coding Tree Blocks (CTB) 604, generally blocks of size 64 pixels x 64 pixels. Each CTB may in its turn be iteratively divided into smaller variable size Coding Units (CUs) 605 using a quadtree decomposition. They can range from a maximum CU size given the CTB (for instance 64x64 pixels, corresponding to CU depth 0) to a minimum CU size (8x8 pixels which corresponds to the maximum CU depth).

CUs are constituted of two sub units: Prediction Unit(s) (PU) and Transform Unit(s) (TU) of maximum size equal to the CU's size.

Prediction Unit corresponds to the partition of the CU for prediction of pixels values. Each CU can be further partitioned into a maximum of four square Partition Units or two rectangular Partition Units 606.

Transform units are used to represent the elementary units that are spatially transformed with DCT. A CU can be partitioned into TUs based on a quadtree representation 607. Variants within the skills of the man skilled in the art may rely on transform units that are based on other transforms, for instance DST, or may rely on block units which have not been transformed at all.

The coding units are the elementary coding elements, i.e. they are the basic units for which a prediction mode is selected, i.e. for which a choice between INTER-and INTRAprediction is done. It means that all PUs forming the CU are predicted using the same prediction mode selected for the whole CU.

This recursive breakdown of the video sequence into PUs and TUs makes it possible to define parameters at various levels (sequence level, frame level, slice/tile level, CTB level, CU level, and so on). These parameters are syntax elements provided in the bitstream at appropriate locations.

Each slice as defined above is embedded in one NAL (standing for Network Abstraction Layer) unit. Some coding parameters of the video sequence are stored in dedicated NAL units called parameter sets. In HEVC and H.264/AVC two kinds of parameter sets NAL units are employed.

First, the Sequence Parameter Set (SPS) NAL unit that gathers all parameters that are unchanged during the whole video sequence. Typically, it handles the coding profile, the size of the video frames and other parameters.

Secondly, Picture Parameter Sets (PPS) codes the different values that may change from one frame to another. HEVC include also Video Parameter Set (VPS) which contains parameters describing the overall structure of the stream.

Figure 7 illustrates a splitting of a Coding Tree Block into Coding Units and an exemplary scan order to sequentially process of these Coding Units. In the HEVC standard, the block structure is organized by Coding Tree Blocks (CTBs). A frame contains several non-overlapped and square Coding Tree Block. The size of a Coding Tree Block can be equal to 64pixelsx64pixels to 16x16. This size is determined at sequence level. The most efficient size, in terms of coding efficiency, is the largest one: 64x64. Note that all Coding Tree Blocks have the same size except for the image border, meaning that they are arranged in rows. The size of the boundary CTBs is adapted according to the amount of remaining pixels.

Each Coding Tree Block contains one or more square Coding Units (CU). The Coding Tree Block is split based on a quad-tree structure into several Coding Units. The processing (coding or decoding) order of each Coding Unit in the Coding Tree Block follows the quad-tree structure based on a raster scan order. Figure 7 shows an example of the processing order of Coding Units in one Coding Tree Block. In this figure, the number in each Coding Unit gives the processing order of each corresponding Coding Unit of this Coding Tree Block.

The Infra Block Copy (IBC) mode is an additional mode for Screen Content Coding (SCC) extension of HEVC. This prediction method is particularly well suited for extremely repetitive patterns. In particular, it is known to help coding graphical elements such as glyphs (i.e., the graphical representation of a character) or traditional GUI elements, which are very difficult to code using traditional intra prediction methods.

In short, when using IBC mode, a block of pixels in a current image is encoded using a predictor block belonging to the same current image and indicated by a vector associated with the block of pixels. To do so, the signaling of the encoded data (texture residue if any, vector, vector residual if any) can be made as any of the three INTER submodes, i.e. Inter (AMVP) mode, Merge mode and Merge Skip mode.

The difference between IBC mode and the three INTER submodes is that the reference frame is the current image in the case of IBC. Thus, using the conventional signalling of INTER mode, the IBC mode can be detected by simply checking the reference index for a given list LO or L1, and deducing this is Infra Block Copy if this is the last frame in that list.

Another way to detect the IBC mode may consist in comparing the Picture Order Counts of the current and reference frames: if they are equal, it means Intra Block Copy mode is used.

Figure 8 illustrates how this Intra Block Copy (IBC) prediction mode works.

For example, this IBC mode may replace the whole INTRA prediction mode in the encoder or decoder illustrated in Figure 1 or Figure 2.

As shown in Figure 8, at a high-level, an image is divided into Coding Units that are encoded in raster scan order. Thus, when coding block 801, all the blocks of area 803 have already been encoded, and can be considered as available to the encoder (because they will be available in a similar manner at the decoder when following the same processing). Area 803 is called the causal area of the Coding Unit 801.

Once Coding Unit 801 has been encoded, it belongs to the causal area for the next Coding Unit. This next Coding Unit, as well as all the next ones, belongs to area 804 illustrated as doted area, and cannot be used for coding the current Coding Unit 801, because they will not be available at the decoder upon decoding the current Coding Unit.

It is worth noting that the causal area is constituted by reconstructed blocks to mirror the behaviour at the decoder. The information used to encode a given Coding Unit is not the original blocks of the image, as this information is not available during decoding. The only information available at decoding is the reconstructed version of the blocks of pixels in the causal area, namely the decoded version of these blocks. For this reason, at the encoder, previously encoded blocks of the causal area are decoded (through the decoding loop 111-116 of Figure 1) to provide this reconstructed version of these blocks.

Intra Block Copy mode works by signalling a block 802 in the causal area, a copy of which should be used to produce a prediction of current Coding Unit 801 without calculating a residue. For example, block 802 may be found by using a matching algorithm. In the HEVC SCC Extension, this block is indicated by a block vector 805 which is transmitted in the bitstream.

The block vector 805 is the difference in coordinates between a particular point of the current Coding Unit 801 and the equivalent point in the predictor block 802.

Put in a simple way, the motion vector difference coding consists, for a value d, in coding whether d is zero, and if not, its sign and its magnitude minus 1. In HEVC motion vector difference coding interleaves the x (abscissa) and y (ordinate) components of the vector.

In the current design of HEVC, as IBC is signalled as an Inter mode, each IBC CU can be split into one or 2 PUs as shown in Figure 6. For the smallest CU size, 8x8, and for INTRA coding modes, the CU can be also split into 4 PUs of 4x4 pixels each. For INTER modes, the NxN partition is not available. It means that the 4x4 block size can't be used for them.

There are three types of IBC block vector estimation in the current reference software of the HEVC SCC extension.

The first one is the classical IBC search and it corresponds to a dedicated block matching algorithm.

The second one is based on the so-called Hash search algorithm.

Two search ranges are also defined. As shown in Figure 9, for a current image 901, the two CTBs search range corresponds to the left CTB 903 and to the blocks of the current CTB 902 already encoded. The blocks of the current CTB already encoded are depicted in dotted area in Figure 9. The full frame search corresponds to all the CTBs already encoded 904.

Finally, the third one is a cache-based search, where previously interesting positions are evaluated. Those previous positions are accumulated during the recursive analysis of an area of pixels, as illustrated below for instance by step 1517 of Figure 15.

As mentioned above, the IBC block vector can be signalled using the signalling of the INTER mode, namely the signalling of Inter-AMVP or Merge or Merge Skip modes in which vector predictor candidates are used.

Figure 10 is a high-level view of how the INTER modes are handled jointly with IBC mode from a decoder point of view.

At step 1000, it is tested whether the current block of pixels (either a CU or a PU) is Merge (including Merge Skip) or Inter. Merge Skip is handled identically to Merge at this stage, and thus the distinction not made in such a case.

If the block is Merge coded (including Merge Skip), a list of Merge predictor candidates is generated (as explained above with reference to Figure 5), and a vector candidate is selected among them (its index in this list being signalled in the bitstream received by the decoder) at step 1001.

Otherwise (if the block is Inter coded), the so-called AMVP candidate list is generated and a vector predictor candidate is selected from it at step 1002.

Both steps 1001 and 1002 generate a list of vector predictor candidates and select one vector predictor candidate using a predictor index (already mentioned above as reference index) obtained from the bitstream.

In both cases, this ends the stage of vector prediction, resulting in a vector predictor to be obtained. These lists can be used indiscriminately for both INTER (Inter and Merge) and IBC modes, the distinction being achieved by checking whether the reference frame is the current one.

Next to the stage of vector prediction, the stage of vector computation is conducted to obtain a vector from the identified vector predictor candidate.

In case the block of pixels is Merge coded, the vector predictor obtained at step 1001 is the actual motion vector (because no vector residue is provided).

Otherwise, the block of pixels is AMVP coded and further processing is required to compute the final vector. In this case, step 1010 occurs in which it is checked whether or not the current block is coded using IBC.

If it is not the case, step 1011 computes the final vector by adding a vector residual decoded from the bitstream received.

Otherwise (output Yes at step 1010), the residual decoded from the bitstream is scaled to have integer pixel precision if appropriate, and is added to the vector predictor obtained at step 1002. This is step 1012 which generates the final vector.

This concludes the step of computing the vector used during block compensation (including motion compensation for INTER coding), which is the next stage.

During the block compensation stage, step 1020 consists to check whether or not the block is IBC coded.

If it is not, step 1021 occurs during which the motion vector used for INTER coding is scaled into the appropriate pixel resolution. This is a particular process called adaptive motion vector resolution (AMVR), where signalling at the SPS level, and optionally at the slice header level, indicates whether the Merge, Merge Skip and Inter modes use quarter-pixel precision. Indeed, in Screen Content, motion is often in integer units (e.g. a graphical element being dragged, or scrolling), contrary to natural content. This process therefore allows using motion vector residuals of lesser magnitude, therefore saving bits. The design of this tool only modifies the motion compensation process (as shown here) and has been accepted as a minor modification of the HEVC v1 (core) specifications. If the motion vector is in integer pixel precision, as signalled in the SPS or slice level, it is scaled to be in quarter pixel precision so as to make it compatible with step 1022.

In any case, step 1022 occurs, receiving as inputs one or two sets made of a vector in quarter pixel precision (as expected in HEVC v1 specifications) and of a reference frame index. It can be seen that steps 1020 and 1021 allow Intra Block Copy, Merge, Merge Skip and Inter modes to reuse the same prediction block generation of step 1022. Indeed, the vector used in Intra Block Copy is always computed to be in quarter pixel precision (as seen from step 1012).

Step 1022 thus consists in obtaining the predictor block (either in the current image for IBC, or in a reference image for INTER mode) using the obtained vector. The predictor block may then be used to generate the current block of pixels to be decoded.

As proposed in this Figure, the same AMVP and Merge candidate lists are used for IBC mode, mainly to reduce implementation costs.

However, as AMVP and Merge are dedicated to natural content and temporal prediction of blocks of pixels, the corresponding AMVP and Merge candidate lists generated at steps 1001 and 1002 include candidates that prove to be unusable or inefficient for IBC. For instance, unusable or inefficient candidates may result from the temporal scaling of step 423 or 522, the combined predictors 528, the zero candidates 430 or 532. A consequence is a lower coding efficiency.

To overcome this situation, prior art proposes modifications to these AMVP and Merge lists used for IBC, as illustrated in Figure 11. This figure is made based on Figure 10.

Therefore, steps 1100 to 1102 and 1110 to 1122 are identical to respectively steps 1000 to 1002 and 1010 to 1022.

Steps 1103 to 1105 have been added during the prediction stage to generate a different Merge or AMVP candidate list if IBC is used: the IBC Merge and IBC AMVP lists generated at steps 1104 and 1106 for IBC mode differ respectively from the lists generated at steps 1101 and 1102 for the INTER modes.

This prior art solution is not satisfactory since it modifies a core process that is complex in HEVC SCC specifications.

In this context, a solution according to the invention provides to determine whether or not the obtained vector meets a predetermined criterion; and to use either the vector obtained for IBC mode at the end of the vector computation stage or another vector, depending on the outcome of the determining step, to obtaining the predictor block from the current image, based on which the block of pixels is generated.

In addition, when another vector is used, the vector obtained for IBC mode at the end of the vector computation stage may be interpreted to deduce a modified vector to be used for IBC decoding the current block of pixels. Such deduction may be performed through modification of the obtained vector.

This is summarized through Figure 12. Again, this figure is made based on Figure 10, resulting in steps 1200 to 1222 to be strictly identical to respectively steps 1000 to 1022.

Embodiments of the invention provide the additional step 1223, after step 1220 in case of IBC (test 1220). Additional step 1223 "interprets" the block vector obtained through the vector computation stage for IBC mode. The goal of this additional step is to compensate the inefficiencies of steps 1001 and 1002 forming the candidate lists, while not requiring substantive changes in HEVC SCC Extension. Therefore, embodiments of additional step 1223 should achieve a good trade-off between coding efficiency and complexity.

Step 1223 can be embodied in two steps: a first sub-step to determine whether or not the block vector obtained through the vector computation stage is to be modified, and a second sub-step to determine how its value has to be modified if appropriate.

The first sub-step is based on the predetermined criterion introduced above.

Various embodiments can be implemented.

The predetermined criterion may for example be to determine whether this vector is valid. To do so, the predetermined criterion may be a function of components of the obtained vector and/or a function of the block of pixels.

For instance, for a pixel block of size NxN, the resulting block predictor obtained in step 1223 should be in the causal area. A corresponding check may be based on the coordinates BVx and BVy of the block vector BV obtained.

Using components BVx and BVy expressed in integer coordinates (Note that this integer pixel precision is used for the simplicity of explanation, as instead quarter pixel precision is used elsewhere), the check may consist in determining whether BVx > -N and BVy > -N, in which case the resulting block predictor overlaps the block being decoded (and thus is not entirely in the causal area).

In a variant, the check may consist in determining whether the obtained vector is a null or zero vector, or not (i.e. the components BVx and BVy of block vector BV are equal to 0, or not). This catches sufficiently issues, at a much decreased complexity, as it is much simpler to test a value for 0, rather than whether BVx > -N and BVy > -N.

In a variant to determining the belonging of the block predictor to the causal area, it may also be determined that the block predictor identified by the block vector is "valid", for instance whether it is at least partly outside the current image or not; or whether it is includes at least one pixel predicted from another image or not. Indeed, when using the Constrained Intra Prediction, said predictor block may rely on pixels coded by INTER modes, which would not be appropriate for BC.

Other embodiments may determine whether the block vector obtained is correct or not, for instance useful or not (and not only "valid"). For instance, referring back to element 606 of Figure 6, it can be seen that the block vector for the second partition of either Nx2N or 2NxN partitioning should differ from the first partition one. Otherwise this would actually be a 2Nx2N partitioning. Thus, two partitions Nx2N or 2NxN cannot have the same block vector.

The second sub-step of modifying the obtained block vector may also be conducted according to various embodiments, where the modified vector may then be used to obtain a predictor block in the current image in order to generate the block of pixels using the obtained predictor block.

In general, the modified vector may depend on at least one property of the block of pixels, such as the block size N. In the following, we refer to a block of size NxN, but as this can be applied to a PU of size LxM contained in a CU of size NxN, it is understood, that in such a case, the predictor block will be of size LxM and the constraint be based on the size of the CU, NxN. This is the preferred embodiment for IBC, due to the constraint in SCC that a PU shall not rely on any PU of the current CU.

For instance, the actual modification of the block vector may consists in subtracting N from a first component of the obtained vector, e.g. BVx, while the other component, e.g. BVy, remains unchanged or is set to 0, NxN being the size of the block of pixels.

In a variant, it may consist in setting a first component of the modified vector, e.g. BVx, to -N while the other component of the obtained vector, e.g. BVy, remains unchanged or is set to 0, NxN being the size of the block of pixels.

Preferably, the modified vector is set to (-N, 0) or (0, -N) to obtain the best coding efficiency / complexity trade-off.

In yet other embodiments, it may consist in setting a first component of the modified vector, e.g. BVx, to -round(a.N) while the other component of the obtained vector, e.g. BVy, remains unchanged or is set to 0, NxN being the size of the block of pixels, and a being a real number above or equal to 1, and round() being a rounding operator. Note that with the Qpel precision, the component should be set to -round(4a.N).

In yet another embodiment, the first component, e.g. BVx, may be set to -R, R being a strictly positive integer such as 16, 24 or 32. Ideally, R is a power of 2 that matches a block size.

While the examples above used BVx as the first component, the operations on BVy and BVx can be swapped, e.g. BVy is set to -round(aN) and BVx is set to 0. To decide which component should be modified (the other unchanged or set to 0), embodiments provide that the first component (to be modified) corresponds to the component having the greatest absolute value in the obtained vector. In other words, the decision to apply the operations on (BVy, BVx) or on (BVx, BVy) depends on values BVx and BVy. An example of this is, if the absolute value of BVy is greater than BVx, then BV is set to (0,-N), otherwise it is set to (-N, 0).

One will understand that the same behaviour is applied at the encoder when deciding which vector candidate of the Merge or AMVP candidate list is to be selected (based on a rate distortion criterion for instance).

Figure 13 illustrates a process at the encoder, dedicated to the coding of screen content such as graphical interfaces or documents, at an intermediate level, as known by the man skilled in the art.

At step 1300, the current block is initialized by selecting an initial CU size. This size may depend on coding parameters such as the maximum block size or the image dimensions (that may enforce specific sizes on the right and bottom borders of the image).

Next, at step 1301, inter-frame prediction analysis is performed. This may include evaluating different prediction mechanisms such as Merge Skip, Merge or Inter modes, and possibly how to partition the current CU, by minimizing a coding cost. This coding cost can be computed from a distortion and an estimated rate for the CU for a given coding mode, such as is the case with a Lagrangian cost. In any case, the coding cost for the Inter mode is obtained. Next, at step 1330, Merge IBC mode is evaluated, for instance using a ratedistortion-optimized evaluation of the Merge IBC candidates. Indeed, as IBC is signalled as an INTER mode, it is worthwhile to evaluate those Merge candidates before checking whether the block is Merge Skip. This includes testing Merge candidates that would be interpreted according to step 1223.

In a particular embodiment, these specific Merge candidates are not evaluated at this point, as the runtime vs. coding efficiency trade-off is likely to be bad and other coding modes may be evaluated at very lower costs while providing no or very few loss of coding efficiency. Rather, they can be evaluated at a later point during the process, and thus steps 1530 and 1531 are modified by an embodiment of the invention, as will be detailed when describing Figure 15.

Next, at step 1302, the best coding mode is compared to the Merge Skip mode (i.e. neither texture nor motion vector residual is transmitted). This may include IBC if the corresponding reference frame of the related Merge candidate is the current image.

In case the Merge Skip mode is selected, the current CU has been completely analysed and the processing ends at step 1316. This allows bypassing the analysis of several modes and thus accelerates the whole processing.

Otherwise, inter prediction may not be good enough to encode the current CU, and thus several other modes are to be tested. In particular, IBC Inter (AMVP) mode is evaluated using a fast evaluation process (step 1320) and optionally a more conventional process (steps 1304-1308). Intra mode is also evaluated at step 1303. Yet other modes can be evaluated if needed at step 1310.

Back to the output "No" of test 1302, if the CU has texture residual, then steps 1320 and 1321 occur.

First, at step 1320, a fast IBC analysis is performed using preferred BVs. These preferred BVs are further described below with reference to Figure 15. In addition, information gathered during the fast IBC analysis may be reused for accelerating analysis, e.g. to skip parts (such as the coding rate estimation) or completely terminate the analysis, in particular during step 1306.

In an embodiment of step 1320, reused information may be the distortion measurement: if the distortion is above a threshold that depends on the CU size, the preferred BVs are unlikely to be selected for IBC, and thus their coding rate is not evaluated.

Next, at step 1321, if the fast evaluation has fully completed and the CU has no texture residual, then some intra mode evaluations can be skipped. In the preferred embodiment, this means the processing can skip to step 1310, although another embodiment is to skip some of the modes evaluated during step 1310 (in the Figure, all the modes evaluated during step 1310 are skipped).

Next to step 1321 when the CU has a texture residual, step 1303 consists for the intra prediction module to select the best classical intra prediction mode by minimizing the coding cost of the CU. Typically, angular prediction modes, DC or planar modes are evaluated here, as well as any additional coding parameters, e.g. transform skipping, cross-component prediction and so on.

Next, step 1304 starts the evaluation of the screen-content specific modes, by selecting the first partitioning for the IBC mode), e.g. 2Nx2N. Usually, the other partitioning 2NxN and Nx2N are only evaluated if the CU size is 8x8.

Before evaluating the partitioning, step 1305 first checks whether or not the current best intra coding mode cost (including any IBC partitioning evaluated at this point through the loop 1305-1308) is high enough to continue evaluation. This is typically done by checking the best intra coding cost against a threshold that may depend on the modes and partitioning tested so far. If the cost is low enough, classical IBC evaluation is finished and processing continues at step 1310.

Otherwise, the partitioning is evaluated by finding the best coding cost for each IBC partition. This is step 1306. In particular, step 1306 evaluates whether Infra Block Copy can solely be used for the current partitioning (either 2NxN or Nx2N), or whether a mixed Inter/IBC coding should be used. Whether IBC or INTER, a partition may be signalled as either Merge or Inter, meaning that the candidates of the Merge or AMVP candidate list are tested.

Next, the next IBC partitioning is selected at step 1307. If the last partitioning has been evaluated (step 1308), the process goes to step 1310. Otherwise, it loops back to step 1305.

At step 1310, other mode, such as e.g. the palette mode, can be evaluated for competition.

Next, at step 1311, it is evaluated whether or not a subCU analysis must be performed. Indeed, the current coding cost may not be good enough, and it may be beneficial to further split the current CU size into sub-CUs that are analysed successively. If it is not the case, the process ends at step 1316. A typical condition triggering not to do subCU analysis is when the best mode for the current CU is the Merge Skip mode.

The subCU analysis includes step 1312 in which the subCU analysis is initialized by selecting the first sub-CU. Next, in step 1313, it is checked whether or not to continue the analysis with the selected sub-CU. If it is not the case, the coding of the sub-CUs is finished, and their total coding cost allows deducing if coding sub-CUs is the best coding mode (compared to coding the CU without further split). The processing therefore ends at step 1316. If the sub-CU exists, step 1314 evaluates its coding mode. It is basically a recursive coding, corresponding to Figure 13 with step 1300 starting with the sub-CU as initial CU.

Now that the current sub-CU has been evaluated, the next sub-CU is selected at step 1315, and the process loops back to step 1313.

The fast evaluation works as long as good BVs for predictors are provided. However, conventional INTER search methods are not as effective as desired. To improve the situation, a caching system is put in place: the BVs selected during the occurrences of step 1306 of Figure 13 for a given PU can be reused for either a different partitioning or during step 1314 (and more specifically when step 1306 occurs again). These selected BVs are stored in a cache system in which previous good BVs are stored without duplicate to reduce memory usage and reduce redundant operations when retrieving and evaluating BVs.

Figure 14 illustrates the same process as Figure 13, but adapted to the present invention. Steps 1400 to 1404, 1406 to 1408, and 1410 to 1430 are strictly identical to respectively steps 1300 to 1304 and steps 1310 to 1330.

An adaptation starts at step 1405. This step determines whether or not the IBC search should be conducted with only BVs stored in cache memory, as is further detailed on Figure 15. This is because this cache-based search is relatively cheap complexity-wise, and also allows better evaluation for mixed Inter/IBC coding to be obtained, which occurs at step 1406 along the evaluation of IBC-only partitions.

After having introduced the cache system, Figure 15 now illustrates how the cache system is used and what is occurring during step 1306/1406.

There are basically five types of evaluation performed: cached BVs evaluation (steps 1504 to 1510), 1D search (step 1511), 2D search (1513), hash search (step 1516) and Merge candidate evaluation (steps 1531 to 1533). In addition, when evaluating a BV, a number of best BVs for the current PU are accumulated. This is done, firstly because the evaluation is only performed on the first component, and the comparison of the coding cost of the accumulated BVs is refined by taking into account chroma only for those, secondly because these are then added to the cache of BVs (step 1517).

Step 1500 initialises the IBC evaluation. Next, step 1501 initializes the CU evaluation by selecting a first partition from among the partitions (PUs shown in Figure 6) forming the current Coding Unit. Next, the BV predictors for the current partition are determined at step 1502. This step may consist to obtain the AMVP candidate list. Next, step 1503 consists to set the search parameters. Typically, the search parameters enforce the causal requirements for the predictor, as well as restrain the search area to e.g. the slice or tile. In addition, the search parameters may set different search windows for different CUs or partitioning: for instance, 16x16 CUs can search all of the causal area of the frame during step 1511, while 8x8 CUs will have be restricted to the 2-CTB-wide area of Figure 9.

Next, step 1504 sets the initial preferred BVs which can be used for fast IBC evaluation 1420. As an example, the initial preferred BVs may include the BV predictors of step 1502 (i.e. the AMVP candidate list) supplemented with the Merge candidate list.

Next, cache BV evaluation starts. As mentioned, CU of size 64x64 to 32x32 will ideally retrieve the cached BVs from their neighbours. For an 8x8 sub-CU of 2Nx2N partitioning, it consists in retrieving the cache BVs found when analysing its corresponding 16x16 CU. For an 8x8 sub-CU of different partitioning, the cached BVs for the previous partitioning can be retrieved. Step 1505 then adds the BVs of neighbouring CUs.

In an embodiment related to the implementation of an interpretation of the block vector (i.e. when the decoder implements step 1223), e.g. depending on whether it is (0, 0), this (0, 0) BV is added to the list of preferred BVs formed at step 1504. In the preferred embodiment, this only happens when the block size is 16x16 or greater: indeed, (0, 0) is not always a good candidate, but if it is, then it should be in the cache by the time block sizes below 16x16 are evaluated. This allows speeding up the evaluation of the interpreted BV.

Now that the list of unique BVs has been built, the first BV of the list is selected at step 1506. Step 1507 then evaluates the current By, i.e. the coding cost of using the BV to encode the current partition of the CU using the AMVP prediction. Next it is tested whether or not a BV has not yet been evaluated at step 1508, in which case the next cached BV is selected at step 1509 before looping back to step 1507.

Once all the cached BV have been evaluated, step 1510 checks whether or not a fast evaluation is occurring, i.e. step 1420 is running. If it is the case, the PU has been evaluated and the process continues to step 1518. Otherwise the process goes to step 1511.

At step 1511, a 1D search is performed. the BVs having the same ordinate or the same abscissa as the top-left corner of the PU within the search area are evaluated, i.e. their coding cost is computed. This is followed by step 1512: if a good BV has not been found, then a 2D search is performed at step 1513. Otherwise, the 2D search is skipped directly to step 1515. The 2D search can use any techniques to scan the search area. One such technique is to first scan BVs of even ordinates, then BVs of odd ordinates and, first even abscissae, then odd abscissae.

Next, step 1515 checks whether or not a hash-based search must be performed, i.e. if the CU is 8x8 and its partitioning is 2Nx2N (in which case this is the first and only PU of the CU). If it is the case, then the hash search is performed at step 1516. Otherwise, the process continues to step 1517.

At this point, a number of best BVs have been found, possibly originating from steps 1504 to 1509. These best BVs are then stored in the cache for current CU only if they are not already present. This means that each block vector stored in the cache memory is stored once and only once. At the end of step 1517, the cache has been updated, and the best BV has been determined. This best BV will be coded using the Inter (AMVP) signalling of the INTER mode, and thus its overall coding cost can be deduced.

Next to step 1517, step 1530 checks whether or not a distortion evaluation of the Merge candidates should be performed. Indeed, as IBC is signalled through INTER modes, the IBC block vector can be signalled as either Merge or Inter. While Inter has been basically evaluated by the previous steps, Merge evaluation need to be checked against each Merge candidate of the list (e.g. as generated during step 1001 of Figure 10). In the prior art, this is only performed if the partitioning is not 2Nx2N: indeed these candidates should have already been fully evaluated during steps 1330 or 1430 of respectively Figure 13 and Figure 14. However, in a particular embodiment, the check of block vector candidates that would be "interpreted" as in step 1223 of Figure 12 in order to perform the evaluation of steps 1330 or 1430, may be deferred to this step 1531. Consequently, in this embodiment, partitioning 2Nx2N is always tested, contrary to prior art which never tests it here, and thus directly goes to step 1518.

If the Merge candidates are evaluated for encoding the current partition, it is made at step 1531. This step may consist in measuring the distortion between the predictor block and the current block, and in measuring the coding cost of the candidate vector (i.e. of its index in the Merge candidate list).

In an embodiment, this step additionally applies step 1223, so as to evaluate the actual predictor block.

Thus, at the end of step 1531, the best Merge candidate has been determined, based on its coding cost. This coding cost is compared at step 1532 to the Inter coding cost. If Inter is a best coding mode, then the process continues to step 1518. Otherwise, the best coding mode for the current partition is set to Merge at step 1533.

Steps 1531-1533 thus make it possible to decide whether the current partition is Merge coded (to specify it to the decoder using the bitstream) or not, and in the affirmative, to decide which Merge candidate is the best one (so to specify it to the decoder using the bitstream).

As previously mentioned, the distortion of a CU during a particular analysis can be reused. Step 1518 performs this in two ways.

First, if this is fast evaluation, the current sum of the best distortions for each partition splitting the current CU is compared to a threshold depending on the CU size: if it is too high, the fast evaluation is interrupted and any rate evaluation is not performed by going directly to step 1522 where the process ends. This is done mostly in reference to Figure 13 or 14, where it may cause a CU with no residual and with low quality at step 1321/1421, to skip directly from step 1311/1411 to step 1316/1416 without doing the necessary sub-CU analysis. In the case it is not aborted, then step 1519 checks whether there is any partition left. If there is, the next partition is selected at step 1520 before the evaluation loops back to step 1502. If there is no partition left, the PUs have all been evaluated, and the rate estimation for the whole CU can occur (step 1521), so as to determine the coding cost and thus determine if the current partitioning is the best for the CU.

Figure 16 is a schematic block diagram of a computing device 1600 for implementation of one or more embodiments of the invention. The computing device 1600 may be a device such as a micro-computer, a workstation or a light portable device. The computing device 1600 comprises a communication bus connected to: - a central processing unit 1601, such as a microprocessor, denoted CPU; - a random access memory 1602, denoted RAM, for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method according to embodiments of the invention, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example; -a read only memory 1603, denoted ROM, for storing computer programs for implementing embodiments of the invention; - a network interface 1604 is typically connected to a communication network over which digital data to be processed are transmitted or received. The network interface 1604 can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data packets are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU 1601; -a user interface 1605 may be used for receiving inputs from a user or to display information to a user; -a hard disk 1606 denoted HD may be provided as a mass storage device; -an I/O module 1607 may be used for receiving/sending data from/to external devices such as a video source or display.

The executable code may be stored either in read only memory 1603, on the hard disk 1606 or on a removable digital medium such as for example a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface 1604, in order to be stored in one of the storage means of the communication device 1600, such as the hard disk 1606, before being executed.

The central processing unit 1601 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 1601 is capable of executing instructions from main RAM memory 1602 relating to a software application after those instructions have been loaded from the program ROM 1603 or the hard-disc (HD) 1606 for example. Such a software application, when executed by the CPU 1601, causes the steps of the flowcharts shown in Figures 4, 5, 12, 14 and 15 to be performed.

Any step of the algorithms shown in these Figures may be implemented in software by execution of a set of instructions or program by a programmable computing machine, such as a PC ("Personal Computer"), a DSP ("Digital Signal Processor") or a microcontroller; or else implemented in hardware by a machine or a dedicated component, such as an FPGA ("Field-Programmable Gate Array') or an ASIC ("Application-Specific Integrated Circuit").

Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

CLAIMS1. A method of decoding a block of pixels in a current image, using a predictor block belonging to the same current image and indicated by a vector associated with the block of pixels, the method comprising the following steps: generating a list of vector predictor candidates; obtaining, from a bitstream encoding the block of pixels, a predictor index identifying one of the vector predictor candidates; obtaining a vector from the identified vector predictor candidate; and determining whether or not the obtained vector meets a predetermined criterion; obtaining a predictor block in the current image using either the obtained vector or another vector, depending on the outcome of the determining step; and generating the block of pixels using the obtained predictor block.
2. The method of Claim 1, wherein the predetermined criterion is a function of components of the obtained vector and/or a function of the block of pixels.
3. The method of Claim 1, wherein the predetermined criterion is at least one from: the obtained vector identifies a predictor block that does not belong to the causal area of the current image; the obtained vector identifies a predictor block that is at least partly outside the current image; the obtained vector identifies a predictor block that includes at least one pixel predicted from another image; and the obtained vector is a null or zero vector.
4. The method of Claim 1, further comprising, if the obtained vector meets the predetermined criterion, modifying the obtained vector into a modified vector to be used as the other vector to obtain the predictor block.
5. The method of Claim 4, wherein the modified vector depends on at least one property of the block of pixels.
6. The method of Claim 4, wherein modifying the obtained vector into the modified vector includes one from: subtracting N from a first component of the obtained vector while the other component remains unchanged or is set to 0, NxN being the size of the block of pixels; setting a first component of the modified vector to -N while the other component of the obtained vector remains unchanged or is set to 0, NxN being the size of the block of pixels; setting a first component of the modified vector to -round(a.N) while the other component of the obtained vector remains unchanged or is set to 0, NxN being the size of the block of pixels, and a being a real number above or equal to 1, and round() being a rounding operator.
7. The method of Claim 6, wherein the first component corresponds to the component having the greatest absolute value in the obtained vector.
8. The method of Claim 4, further comprising, if the obtained vector is a null or zero vector, setting the modified vector to (-N, 0), NxN being the size of the block of pixels.
9. The method of Claim 4, further comprising, if both components of the obtained vector are above -N, setting the modified vector to (ft -N), NxN being the size of the block of pixels.
10. The method of Claim 1, the block of pixels being encoded using the Infra Block Copy mode of HEVC.
11. A decoding device for decoding a block of pixels in a current image, using a predictor block belonging to the same current image and indicated by a vector associated with the block of pixels, the decoding device comprising at least one microprocessor configured for carrying out the steps of: generating a list of vector predictor candidates; obtaining, from a bitstream encoding the block of pixels, a predictor index identifying one of the vector predictor candidates; obtaining a vector from the identified vector predictor candidate; and determining whether or not the obtained vector meets a predetermined criterion; obtaining a predictor block in the current image using either the obtained vector or another vector, depending on the outcome of the determining step; and generating the block of pixels using the obtained predictor block.
12. A device comprising means adapted for carrying out each step of the decoding method of any of Claims 1 to 10.
13. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a device, causes the device to perform the decoding method of any of Claims 1 to 10.
14. A method of decoding a block of pixels in a current image, using a predictor block belonging to the same current image and indicated by a vector associated with the block of pixels, substantially as herein described with reference to, and as shown in, Figure 12 of the accompanying drawings.