GB2527354A

GB2527354A - Method and apparatus for vector encoding in video coding and decoding

Info

Publication number: GB2527354A
Application number: GB1410984.7A
Authority: GB
Inventors: Guillaume Laroche; Christophe Gisquet; Patrice Onno
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-06-19
Filing date: 2014-06-19
Publication date: 2015-12-23
Also published as: GB201410984D0

Abstract

Pixel blocks forming an image (1201) are encoded (and/or subsequently decoded), each block being encoded according to one of a plurality of modes. Vectors (e.g. motion vectors, displacement vectors or block vectors) are encoded using at least two modes. One of a plurality of displacement vector coding methods (1203) (e.g. Exponential Golomb code) is selected. A pixel block is then encoded according to a first mode (1207) (e.g. Intra, Intra block copy or String Matching mode) using the selected method, while another pixel block is encoded according to a second mode (1206) (e.g. Inter mode) also using the selected method. Encoding resources are therefore shared by different prediction modes with no encoding performance reduction. Also disclosed is pixel block encoding (and/or subsequent decoding) wherein each block is encoded according to one of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vector. The vector is encoded based on the encoding of a syntax element corresponding to a displacement vector residual, wherein the encoding of the vector is realized according to a specific displacement vector encoding method for a given size of pixel block different to that used for other pixels block sizes.

Description

METHOD AND APPARATUS FOR VECTOR ENCODING IN VIDEO CODING

AND DECODING

The present invention concerns a method and a device for encoding or decoding vectors components in the process of encoding or decoding a video. It concerns more particularly the encoding and decoding of vector blocks in Intra Block Copy mode and Inter mode of HEVC Screen Content extension.

It applies more particularly to a mode of coding where a block of pixel is predictively encoded based on a predictor block pertaining to the same image.

This mode of encoding a block of pixel is generally referred to as INTRA Block Copy mode. It is considered as a tool candidate for the Screen content Extension of the High Efficiency Video Coding (HEVC: ISO/IEC 23008-2 MPEG-H Part 2! ITU-T H.265) international standard and now in the Screen Content extension of the same.

When encoding an image in a video sequence, the image is first divided into coding entities of pixels of equal size referred to as Coding Tree Block (CTB). The size of a Coding Tree Block is typically 64 by 64 pixels. Each Coding Tree Block may then be decomposed in a hierarchical tree of smaller blocks which size may vary and which are the actual blocks to encode. These smaller blocks to encode are referred to as Coding Unit (CU).

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. Next, this residue is compressed. 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 Coding Unit in order to get a small residue that could be efficiently compressed.

Encoding may be lossy, meaning that information is lost in the encoding process. The decoded block of pixel is not exactly the same as the original Coding Unit. Typically the loss of information comes from a quantization applied to the residue before entropy coding. This quantization allows a higher compression rate at the price of the loss of accuracy. Typically, high frequencies, namely the high level of details, are removed in the block.

Encoding may 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.

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 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 construction. 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.

A second coding mode is referred to as INTER mode. According to INTER mode, the predictor block is a block of another 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, the encoding of such Coding Unit using this mode comprises motion information comprising the motion vector and the compressed residue.

We focus in this document on a third coding mode called INTRA Block Copy mode. According to the INTRA Block Copy mode, the block predictor is an actual block of the current image. A block vector is used to locate the predictor block. This block vector gives the location in the current image of the predictor block relatively to the location of the Coding Unit in the same current image. It comes that this block vector shares some similarities with the motion vector of the INTER mode. It is sometime called motion vector by analogy. As there could not be a motion within an image, strictly speaking, and for the sake of clarity, in this document motion vector always refer to the INTER mode while block vector is used for the INTRA Block Copy mode.

The invention also concerns other INTRA modes like, for example, the String Matching mode. An example of the later is a method that copies non-rectangular runs of pixels from a position, said position being encoded as a displacement and predicted. This is why the notion of block of pixels is not restrained to rectangular blocks of pixels in this document. A block of pixels may have any particular form and in particular the non-rectangular runs of pixels used in the String Matching mode.

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. At encoding, the whole information may be considered as available. Namely, to encode a given Coding Unit it would be possible to use any information from the entire current images or from all decoded and available other images in the sequence. At decoding, things are different. The decoding of the current images is typically done by decoding sequentially all Coding Unit. 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 come 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 encoding. For example, a predictor block in INTRA Block Copy mode, should pertain to the part of the image that will be available at decoding.

In INTRA Block Copy mode, the block vector is encoded using the regular motion vector difference (MVD) coding. This encoding consists, for a component of the vector, in coding whether this component is zero, and if not, to encode its sign and its magnitude. Both components corresponding to the vertical and horizontal directions are encoded that way in a so called MVD syntax element. The MVD syntax element comprises both components MVDx and MVDy of the two dimensional block vector.

In HEVC, several methods are used to code the different syntax elements, for example block residuals, information on predictor blocks (motion vectors, INTRA prediction directions! block vectors, etc.). HEVC uses several types of entropy coding like the Context based Adaptive Binary Arithmetic Coding (CABAC), Exponential Golomb, Golomb-rice Code, or simple binary representation called Fixed Length Coding. Most of the time, a binary encoding process is performed to represent the different syntax element. This binary encoding process is also very specific and depends on the different syntax elements.

Both Golomb-Rice code and Exponential Golomb code are entropic codes using a given parameter called Golomb Order. Encoding a low value will be more efficient using a low Golomb Order while a higher value will be effectively encoded using a higher Golomb Order.

In Inter mode, motion vector residuals are typically encoded using Exponential Golomb code with a Golomb order value equal to 1. It appears that block vectors residuals have typically higher values in Intra Block Copy mode and therefore using the same encoding or the same Golomb Order for encoding block vector residuals may prove to be non-optimal.

Introducing specific Exponential Golomb encoding with higher Golomb Order for Intra Block Copy encoding may lead to add new encoding and decoding function in the encoder and the decoder. For hardware decoders in particular, this may prove to be costly.

Moreover, hardware decoders are dimensioned regarding bitstream parsing based on the worst case that occurs when the coding tree block is divided in the smallest coding units. Intra Block Copy mode contemplates coding units as small as 4x4 coding units when Inter mode contemplates only 4x8 or 8x4 blocks as the smallest coding unit. This leads to an increased need in parsing for Intra Block Copy mode degrading hardware decoders' performances.

The present invention has been devised to address one or more of the foregoing concerns.

According to a first aspect of the invention there is provided a method of decoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least two modes comprising the encoding of displacement vectors, the method comprising: selecting a displacement vector decoding method out of a plurality of displacement vector decoding method; and decoding a first block of pixels according to a first mode comprising the decoding of displacement vectors; and decoding a second block of pixels according to a second mode comprising the decoding of displacement vectors; wherein: the first and the second modes are using the selected displacement vector decoding method.

Accordingly, encoding resources may be shared by different prediction mode with no loss in encoding performance.

In an embodiment, the first mode is an INTRA mode.

In an embodiment, the first mode is the Intra Block Copy mode.

In an embodiment, the first mode is the String Matching mode.

In an embodiment, the second mode is the INTER mode.

In an embodiment, said plurality of displacement vector decoding method is based on the Exponential Golomb code using a plurality of Golomb orders.

In an embodiment, said plurality of displacement vector decoding method is based on the Exponential Golomb code and the Rice Golomb code, both using a plurality of Golomb orders.

In an embodiment, said plurality of Golomb Orders corresponds to values 1 and 4.

In an embodiment, the Golomb Order is received from the bitstream.

In an embodiment, said plurality of displacement vector decoding method is based on the Exponential Golomb code using a Golomb Order of 1 and the Rice Golomb code using Golomb Order greater than 1.

In an embodiment, the selection of a displacement vector decoding method consisting in selecting the Golomb Order, the selection being done at the slice or at the frame level, the Golomb order is initialized to 4 for the Intra frames and to 1 for the Inter frames.

In an embodiment, the selection of a displacement vector decoding method consisting in selecting the Golomb Order, the selection being done at the slice or at the frame level, the selection is done independently for Intra frames, P frames and B frames, the Golomb order is initialized to 4 for the Intra frames and to 1 for the P and B frames.

In an embodiment, the selection of a displacement vector decoding method consisting in selecting the Golomb Order, the Golomb order is determined according to a depth of a hierarchical frame ordering or hierarchical frame quality.

In an embodiment, the selection of a displacement vector decoding method consisting in selecting the Golomb Order, the selection being done at the Coding Unit or Prediction Unit level.

According to another aspect of the invention there is provided a method of encoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least two modes comprising the encoding of displacement vectors, the method comprising: selecting a displacement vector encoding method out of a plurality of displacement vector encoding method; and encoding a first block of pixels according to a first mode comprising the encoding of displacement vectors; and encoding a second block of pixels according to a second mode comprising the encoding of displacement vectors;

B

wherein: the first and the second modes are using the selected displacement vector encoding method.

In an embodiment, the first mode is an INTRA mode.

In an embodiment, the first mode is the Intra Block Copy mode.

In an embodiment, the first mode is the String Matching mode.

In an embodiment, the second mode is the INTER mode.

In an embodiment, said plurality of displacement vector encoding method is based on the Exponential Golomb code using a plurality of Golomb orders.

In an embodiment, said plurality of displacement vector encoding method is based on the Exponential Golomb code and the Rice Golomb code, both using a plurality of Golomb orders.

In an embodiment, the Golomb Order is transmitted in the bitstream.

In an embodiment, said plurality of displacement vector encoding method is based on the Exponential Golomb code using a Golomb Order of 1 and the Rice Golomb code using Golomb Order greater than 1.

In an embodiment, the selection of a displacement vector encoding method consisting in selecting the Golomb Order, the selection being done at the slice or at the frame level, the Golomb order is initialized to 4 for the Intra frames and to 1 for the Inter frames.

In an embodiment, the selection of a displacement vector encoding method consisting in selecting the Golomb Order, the selection being done at the slice or at the frame level, the selection is done independently for Intra frames, P frames and B frames, the Golomb order is initialized to 4 for the Intra frames and to 1 for the P and B frames.

In an embodiment, the selection of a displacement vector encoding method consisting in selecting the Golomb Order, the Golomb order is determined according to a depth of a hierarchical frame ordering or hierarchical frame quality.

In an embodiment, the selection of a displacement vector encoding method consisting in selecting the Golomb Order, the selection being done at the Coding Unit or Prediction Unit level.

According to another aspect of the invention there is provided a method of decoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vectors, the method comprising: decoding a displacement vector based on the decoding of a syntax element corresponding to a displacement vector residual; wherein: said decoding of a displacement vector is realized according to a specific displacement vector decoding method for a given size of block of pixels different of the one used for other sizes of block of pixels.

Accordingly the worst case parsing time for small blocks may be improved.

In an embodiment, said given size of block of pixels correspond to block of pixel of size NxN, N being a given positive integer.

In an embodiment, N is 4.

In an embodiment, the given size is the smallest block of pixels size considering one of the modes.

In an embodiment, said specific displacement vector decoding method comprises decoding only one component of said displacement vector from said syntax element.

Accordingly, the worst case parsing time is divided by two.

In an embodiment, the component decoded from the syntax element is the horizontal one.

In an embodiment, the component decoded from the syntax element is the vertical one.

In an embodiment, the component decoded from the syntax element is specified by a flag in the bitstream.

In an embodiment, said flag is the sign of the component decoded from the syntax element.

In an embodiment, the component decoded from the syntax element for a block of pixels of size 4x4 within a BxB block of pixels depends on the last displacement vector decoded for the first 4x4 block of pixels within said 8x8 block of pixels.

In an embodiment, two displacement vector components pertaining to two different displacement vectors are decoded from the same two dimensional syntax element.

Accordingly, the two dimension parsing function for the MVD syntax element may be used.

In an embodiment, the displacement vector component not decoded from the syntax element is set equal to a default value.

In an embodiment, the displacement vector component not decoded from the syntax element is set equal to 0.

In an embodiment, the displacement vector component not decoded from the syntax element is set equal to -N. where N is the size of the block of pixels.

In an embodiment, the displacement vector component not decoded from the syntax element is set equal to -2N, where N is the size of the block of pixels.

In an embodiment, the displacement vector component decoded from the syntax element is decoded based on the location of the block of pixels of size NxN within a block of pixels of size 2Nx2N.

According to another aspect of the invention there is provided a method of encoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vectors, the method comprising: encoding a displacement vector based on the encoding of a syntax element corresponding to a displacement vector residual; wherein: said encoding of a displacement vector is realized according to a specific displacement vector encoding method for a given size of block of pixels different of the one used for other sizes of block of pixels.

In an embodiment, N is 4.

According to another aspect of the invention there is provided a decodeur device for decoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least two modes comprising the encoding of displacement vectors, the device comprising: a selector for selecting a displacement vector decoding method out of a plurality of displacement vector decoding method; and a decoder for decoding a first block of pixels according to a first mode comprising the decoding of displacement vectors; and a decoder decoding a second block of pixels according to a second mode comprising the decoding of displacement vectors; wherein: the first and the second modes are using the selected displacement vector decoding method.

According to another aspect of the invention there is provided an encoder device for encoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least two modes comprising the encoding of displacement vectors, the device comprising: a selector for selecting a displacement vector encoding method out of a plurality of displacement vector encoding method; and an encoder for encoding a first block of pixels according to a first mode comprising the encoding of displacement vectors; and an encoder for encoding a second block of pixels according to a second mode comprising the encoding of displacement vectors; wherein: the first and the second modes are using the selected displacement vector encoding method.

According to another aspect of the invention there is provided a decoder device for decoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vectors, the device comprising: a decoder for decoding a displacement vector based on the decoding of a syntax element corresponding to a displacement vector residual; wherein: said decoding of a displacement vector is realized according to a specific displacement vector decoding method for a given size of block of pixels different of the one used for other sizes of block of pixels.

According to another aspect of the invention there is provided an encoder device for encoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vectors, the device comprising: an encoder for encoding a displacement vector based on the encoding of a syntax element corresponding to a displacement vector residual; wherein: said encoding of a displacement vector is realized according to a specific displacement vector encoding method for a given size of block of pixels different of the one used for other sizes of block of pixels.

According to another aspect of the invention there is provided a computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to the invention, when loaded into and executed by the programmable apparatus.

According to another aspect of the invention there is provided a computer-readable storage medium storing instructions of a computer program for implementing a method according to the invention.

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 floppy disk, 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.

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 neighboring 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 Level decomposition of Video frame; 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 illustrates the decoding of syntax element of a motion vector difference of HEVC; Figure 11 illustrates different coding method of vector residual of the Intra Block Copy mode and Inter mode; Figure 12 illustrates an embodiment of a decoding method of a motion vector residual or difference (MVD) of the Intra Block Copy mode and Inter mode in an embodiment of the current invention; Figure 13 illustrates the parsing of the vector residual; Figure 14 illustrates the decoding of syntax element of a motion vector difference of HEVC with the signal of one embodiment of the invention; Figure 15 illustrates the parsing of the vector residual of one embodiment of the invention; Figure 16 illustrates the parsing of the vector residual of one embodiment of the invention.

Figure 17 illustrates the 4 NxN PU of a 2Nx2N CU and its available causal area.

Figure 18 is a schematic block diagram of a computing device for implementation of one or more 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 or INTRA modes 103 and the modes based on temporal prediction or INTER 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 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. This reference area constitutes the predictor block. 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 3 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 neighboring 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. 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. 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 orto 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 encoded and decoded loop. It means that they need to be applied on the reconstructed frame at encoder and decoder side in order to use the same reference frame at encoder and decoder side. The aim of this post filtering is to remove compression artifacts.

In Figure 2, have been represented the principle of a decoder. 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. The mode data are also entropy decoded in function of the mode, an INTRA type decoding or an INTER type decoding is performed. In the case of INTRA mode, an INTRA predictor is determined in function of the INTRA prediction mode specified in the bitstream 205. If the mode is INTER, the motion information is extracted 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. 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.

This INTRA Block Copy coding mode is particularly well suited for extremely repetitive patterns. In particular, it is known to help coding graphical elements such as glyphs, the graphical representation of a character, or traditional GUI elements, which are very difficult to code using traditional INTRA prediction methods.

It is worth noting that prediction is based on coherence between neighbor Coding Units. This coherence may be geographic when considered within the current frame or temporal when considered across successive frames. This kind of coherence occurs in natural images. As INTRA Block Copy encoding mode is seen as a mode dedicated to text or symbolic images, predication is thought as useless for this kind of image. For instance, there is no reason to have two successive Coding Units in an image representing a text having good predictors close to each other. The first Coding Unit may be the part of letter "A", a good predictor block would therefore come from another A" in the text. While the next Coding Unit would be a "A" letter having a predictor block from another "A" in the text. There is no reason, a-priori, to have the two predictor blocks in the same neighborhood. This is why prior art does not contemplate introducing prediction in INTRA Block Copy encoding mode.

The current design of HEVC uses 3 different INTER modes: the Inter mode, the Merge mode and the Merge Skip mode. The main difference between these modes is the data signaling in the bitstream. For the Motion vector coding, the current HEVC standard includes a competitive based scheme for Motion vector prediction compared to its predecessors. It means that several candidates are competing with the rate distortion criterion at encoder side in order to find the best motion vector predictor or the best motion information for respectively the Inter or the Merge mode. An index corresponding to the best predictors or the best candidate of the motion information is inserted in the bitstream. The decoder can derive the same set of predictors or candidates and uses the best one according to the decoded index.

The design of the derivation of predictors and candidate is very important to achieve the best coding efficiency without large impact on complexity. In HEVC two motion vector derivations are used: one for Inter mode (Advanced Motion Vector Prediction (AMVP)) and one for Merge modes (Merge derivation process). The following describes these processes.

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 coding and decoding systems and Figure 4 shows simplified steps of the process of the AMVP predictor set derivation.

Two predictors, i.e. the two spatial motion vectors of the AMVP mode, are chosen among the top blocks and the left blocks including the top corner blocks and left corner block and one predictor is chosen among the bottom right block and center block of the collocated block as represented in Figure 3.

Turning to Figure 4, a first step aims at selecting a first spatial predictor (Cand 1, 406) among the bottom left blocks A0 and Al, that spatial positions are illustrated in Figure 3. To that end, these blocks are selected (400, 402) one after another, in the given order, and, for each selected block, following conditions are evaluated (404) in the given order, the first block for which conditions are fulfilled being set as a predictor: -the motion vector from the same reference list and the same reference image; -the motion vector from the other reference list and the same reference image; -the scaled motion vector from the same reference list and a different reference image; or -the scaled motion vector from the other reference list and a different reference image.

If no value is found, the left predictor is considered as being unavailable. In this case, it indicates that the related blocks were INTRA coded or those blocks do not exist.

A following step aims at selecting a second spatial predictor (Cand 2, 416) among the above right block BO, above block Bi, and left above block B2, that spatial positions are illustrated in Figure 3. To that end, these blocks are selected (408, 410, 412) one after another, 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 above mentioned conditions are fulfilled being set as a predictor.

Again, if no value is found, the top predictor is considered as being unavailable. In this case, it indicates that the related blocks were INTRA coded or those blocks do not exist.

In a next step (418), the two predictors, 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 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 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 predictor is not available, the center of the collocated block (Center, 424) is selected to be checked. These temporal positions (Center and H) are depicted in Figure 3.

The motion predictor value is then added to the set of predictors.

Next, the number of predictors (Nb_Cand) is compared (428) to the maximum number of predictors (Max_Cand). As mentioned above, the maximum number of predictors (MAX_Cand) of motion vector predictors 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 predictors (432) is built. Otherwise, a zero predictor is added (430) to the list.

The zero predictor is a motion vector equal to (0,0).

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

As mentioned above, a motion predictor candidate of Merge mode or of Merge Skip mode represents all the required motion information: direction, list, reference frame index, and motion vectors. An indexed list of several candidates is generated by a merge derivation process. In the current HEVC design the maximum number of candidates for both Merge modes is equal to five (4 spatial candidates and 1 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 are considered (500 to 508). These positions are the spatial positions depicted in Figure 3 with references Al, Bl, BO, A0, and 32. In a following step, the availability of the spatial motion vectors is checked and at most five motion vectors are selected (510). A predictor is considered as available if it exists and if the block is not INTRA coded. Therefore, selecting the motion vectors corresponding to the five blocks as 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 list of candidate (514); -if the "above" 31 motion vector (502) is available (510), the candidate "above" block motion vector is compared to "left" Al motion vector (512), if it exists. If Bi motion vector is equal to Al motion vector, Bl is not added to the list of spatial candidates (514). On the contrary, if Bl motion vector is not equal to Al motion vector, Bl 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 Bl motion vector (512). If BO motion vector is equal to Bl 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 Bi motion vector, BO motion vector is added to the list of spatial candidates (514); -if the "below left" A0 motion vector (506) is available (510), the motion vector of the "below left" is compared to Al motion vector (512). If A0 motion vector is equal to Al motion vector, A0 motion vector is not added to the list of spatial candidates (514). On the contrary, if AD motion vector is not equal to Al motion vector, AD 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 BI motion vector. If B2 motion vector is equal to Al motion vector or to Bl 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 Bl motion vector, B2 motion vector is added to the list of spatial candidates (514).

At the end of this stage, the list of spatial candidates comprises up to four candidates.

For the temporal candidate, two positions can be used: the bottom right position of the collocated block (516, denoted H in Figure 3) and the center of the collocated block (518). These positions are depicted in Figure 3.

As for the AMVP motion vector derivation process, 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 center position is checked (520). If at least one motion vector of these positions is available, the temporal motion vector can be scaled (522), if needed, to the reference frame having index 0, for both list LD and Ll, in order to create a temporal candidate (524) which is added to the list of Merge motion vector predictor candidates. It is positioned after the spatial candidates in the list. The lists [0 and [1 are 2 reference frame lists containing zero, one or more reference frames.

If the number (Nb_Cand) of candidates is strictly less (526) than the maximum number of candidates (Max_Cand that value is signaled in the bit-stream 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 list of Merge motion vector predictor candidates. It mainly consists in combining the motion vector of one candidate of the list [0 with the motion vector of one candidate of list Li.

If the number (Nb_Cand) of candidates remains strictly less (530) than the maximum number of candidates (Max_Gand), zero motion candidates are generated (532) until the number of candidates of the list of Merge motion vector predictor candidates reaches the maximum number of candidates.

At the end of this process, the list or set of Merge motion vector iO predictor candidates is built (534). As illustrated in Figure 5, the list or set of Merge motion vector predictor candidates is built (534) from a subset of spatial candidates (500 to 508) and from a subset of temporal candidates (516, 518).

Figure 6 shows the coding structure used in HEVC. According to HEVC and one of its previous predecessors, 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 images 602 are divided into slices 603. A slice is a pad 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. Coding units are the elementary coding elements and are constituted of two sub units which Prediction Unit (PU) and Transform Units (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 4 square Partition Units or 2 rectangular Partition Units 606. Transform units are used to represent the elementary units that are spatially transform with DCT. A CU can be partitioned in TU based on a quadtree representation 607.

Each slice is embedded in one NAL unit. In addition, the 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 the Coding Tree Block splitting in Coding Units and the scan order decoding of these Coding Units. In the HEVC standard, the block structure is organized by Coding Tree Block (CTB). A frame contains several non-overlapped and square Coding Tree Block. The size of a Coding Tree Block can be equal to 64x64 to 16x16. This size is determined at sequence level. The most efficient size, in term of coding efficiency, is the largest one: 64x64. Please note that all Coding Tree Block have the same size except for the image border. In that case, the size is adapted according to the amount of 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 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 decoding order of Coding Units. In this figure, the number in each Coding Unit gives the decoding order of each Coding Unit of this Coding Tree Block.

The Intra Block Copy (IBC) was added as an additional mode for Screen content coding 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.

Figure 8 illustrates how this Intra Block Copy prediction mode works. For example, this IBC prediction mode substitutes to the whole Intra prediction mode in the encoder or decoder illustrated in figure 1 or 2.

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 available to the encoder. Area 803 is called the causal area of the Coding Unit 801. Once Coding Unit 801 is encoded, it will belong 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. It is worth noting that the causal area is constituted by reconstructed blocks. The information used to encode a given Coding Unit is not the original blocks of the image for the reason that this information is not available at 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 encoding, previously encoded blocks of the causal area are decoded to provide this reconstructed version of these blocks.

INTRA Block Copy works by signaling a block 802 in the causal area which should be used to produce a prediction of block 801. For example, the block 502 may be found by using a matching algorithm. In the HEVC Screen content Extension, this block is indicated by a block vector 805, and is transmitted in the bitstream.

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

Although it would be possible to use subpixel accuracy as for INTER blocks, this displacement is typically in integer units of pixels, therefore not to require costly subpixel interpolation. This vector is coded in the simplest way currently, the vector is not predicted, and the coordinates are coded using HEVC regular motion vector difference (MVD) coding.

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 and y components of the vector.

In the current IBC design, each IBC CU can be split into one or 2 PUs as depicted in Figure 6. For the smallest CU size, 8x8, the CU can be also split into 4 PUs of 4x4 pixels each.

For Inter mode the NxN partition is not available. It means that the 4x4 block size can't be used for Inter mode. The following table summarizes the block size for both modes.

Block sizes IBC mode Inter mode 64x64 (2Nx2N) / / 64x32 (2NxN) I I 32x64(Nx2N) I I 32x32 (2Nx2N) .1.1 32x16(2NxN) I I 16x32(Nx2N) I I 16x16 (2Nx2N) I I 16x8(2NxN) I I 8x16(Nx2N) I I 8x8(2Nx2N) I I 8x4(2NxN) I I 4x8(Nx2N) I I 4x4(NxN) I In the current implementation of Intra Block Copy prediction mode, the search area depends on the blocks sizes. This is represented in the following

table:

Block size Full range search 2 CTBs range search (outside the 2CTB Other __________ area) ____________________ __________________ 64x64 ____________________ ___________________ No search 32x32 ____________________ ___________________ No search 16x16 Classical IBC search Classical IBC search ________________ 8x8 Hash-based Classical IBC search _________________ 4x8 ____________________ Classical IBC search _________________ 8x4 ____________________ Classical IBC search _________________ 4x4 ____________________ Classical IBC search _________________ Please note that the 2NxN and Nx2N PU sizes are tested only for 8x8 CUs in the current encoder implementation. These sizes are not depicted in this table. There are 2 types of Intra Block Copy block vector estimation. The first one is the classical IBC search and it corresponds to a dedicated block matching algorithm. The second one is based on the Hash search algorithm.

Two search ranges are also defined. As depicted in Figure 9, for a frame 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 current CTB already encoded are depicted in dotted area in Figure 9. The full frame search corresponds to all the CTBs already encoded 904.

In the Intra Block Copy mode the "block" vector is the difference in coordinates between a particular point in a block A to encode and the equivalent point in the predictor block D of Figure 8.

This block vector (BV) is itself predicted using the latest decoded block vector of the current Coding Tree Block. This vector predictor comes of course from the latest decoded Intra Block Copy block. Moreover, the block vector predictor is reset at the beginning of each Coding Tree Block by (N, 0) where N is the block size. Please note that other methods can be considered as for example the multiple last predictors with or without reset at Coding Tree Block level or at Coding Tree Block line. Moreover the left and the above vector can be also considered as the predictors for the current block. With these methods a predictor index is transmitted.

The vector residual, the difference between the current block vector and the predictor, is coded in the same way as the HEVC motion vector difference (MVD) coding of the Inter mode. The MVD coding consists, for a value d, in coding whether d is zero with a first flag, and if not, whether its absolute value (its magnitude) is 1 with a second flag. If its magnitude is not 1, then its magnitude minus 2 is then coded. In all case where the MVD is not zero, its sign is then coded. HEVC MVD coding interleaves for the x and y the aforementioned syntax elements components of the vector.

Figure 10 illustrates a known embodiment of a decoding process of the syntax element of this MVD, part of the step 210 in figure 2. The variable and flag referencing with [0]' are related to the MVDx component: the horizontal residual. And the variable and flag referencing with [1]' are related to the MVDy component: the vertical residual.

The process starts with step 1001. At step 1002, the first flag decoded is the abs_mvd_greatero_flag[0]. Then at step 1003, the abs_mvd_greatero_flag[1] flag is decoded. These flags specify whether the absolute value of a motion vector component MVDx, MVDy, difference is greater than 0 or not. In step 1004 it is tested if abs_mvd_greaterO_flag[0] is equal to 1. If true the abs_mvd_greaterl_flag[0] flag is decoded in step 1005.

In the same way, in step 1006 it is tested if abs_mvd_greatero_flag[1] is equal to 1. If true, the abs_mvd_greaterl_flag[1] flag is decoded in step 1007.

These flags specify whether the absolute values of a motion vector component differences MVDx, MVDy, are greater than 1 or not. If the flag abs_mvd_greatero_flag[0] and abs_mvd_greaterl_flag[0] are equal to 1 which is tested in steps 1008 and 1009 the absolute value minus 2 abs_mvd_minus2[0] is decoded in step 1010 and if abs_mvd_greatero_flag[0] is equal to 1 the mvd_sign_flag[0] is decoded in step 1011. mvd_sign_flag[0] specifies the sign of the residual of the horizontal component X. In the same way, the abs_mvd_minus2[1] and mvd_sign_flag[1] are extracted according to the value of the flags abs_mvd_greatero_flag[1] and abs_mvd_greaterl_flag[1] in steps 1012 to 1015. Then the process is ended in step 1016. The MVD value for the component / is obtained by the following formula: Mvd[i]= abs_mvd_greaterO_flag[i] * (abs_mvd_mirius2[iJ + 2) * (1 -2 * m vd_sign_flag[iJ) The syntax element abs_mvd_minus2 is coded with an exponential Golomb code with a Golomb order equal to 1.

One possible modification is to adapt the coding/decoding of the motion vector difference (MVD) for the Intra Block Copy mode by changing the Golornb order for coding the variable abs_mvd_minus2. To be adapted to Intra Block Copy signal this should be increased. In the document JCTVC-Q0031, it is recommended to set it to 3.

In the document JCTVC-Q0095, the motion vector difference MVD coding/decoding process is completely changed by using a new syntax. First the number of bits used to code the absolute value plus 1 is coded. Then this absolute value plus 1 is coded according to this number of bits followed by the sign of the current component.

Figures ha, hIb and hIc show different concepts for the current implementation and for the two prior art proposals. In this figure, "MVD decoding" is the process described in Figure 10. Of course, the corresponding coding methods are changed accordingly.

Figure 11.a shows a flow chart of the current method where the MVD is decoded in step 110Th from the bitstream llOOa whatever the mode type to give the residual vector 1102a. The golomb order used in the entropic encoding of displacement vectors is fixed and the same for all block encoding mode.

Figure 11.b shows a flow chart of the method mentioned in JCTVC-Q0031, which changes the Golomb order for the abs_mvd_minus2. In step 1101b it is tested if the prediction mode is Intra Block Copy mode. If true, in step 1105b, the Golomb order is set to the value 3 and the residual of block vector 1107b is decoded 1106b. If false, the Golomb order is set to the value 1 in step 1102b and the motion vector residual 1104b is decoded 1103b. This method consists in adapting the Golomb order depending on the prediction mode with one value dedicated to the Inter mode and another one to the Intra Block Copy mode.

Figure 11.c shows the flow chart for the second prior art method JCTVC-Q0095 which fully changes MVD decoding process into a BV residual decoding process in step 1112. This method consists in adapting the coding/decoding method depending on the prediction mode with a decoding mode dedicated to the Inter mode 1102c and another one to the Intra Block Copy mode 1106c.

In the methods of the prior art for the block vector residual coding, only one function is considered. Adopting a fixed Golomb order or any other encoding mode for the block vectors residual proves to be non-adapted as it does not fit all cases.

But adopting a different encoding mode for the block vectors of the Intra Block Copy prediction mode and for the motion vectors of the Inter mode proves to be costly in term of encoding and decoding resources. This is particularly true for hardware decoder where both decoding function need to be implemented in hardware. In an embodiment of the invention it is proposed to adopt an adaptive encoding of the block vectors depending on the context but also to use the same encoding scheme for coding units encoded with the Inter prediction mode.

Accordingly, both IBC blocks and Inter blocks are encoded using the same encoding mode for the block vectors and for the motion vectors.

It is proposed to adapt the encoding method used to encode the block vectors based on the context of the current block. This adaptation may be done at CU, CTB, Slice, Tile, Frame, or sequence level. It consists in selecting an encoding method out of a plurality of encoding methods for the encoding of block vectors residuals. Accordingly, the best suited encoding method may be chosen to achieve best encoding performances.

This adaptation is not done for a single block encoding mode but will apply to at least two different block encoding modes. For example, this adaptation may be applied to two different INTRA modes or one INTRA mode and the INTER mode. All these modes consider the encoding of some displacement vectors. A displacement vector is defined in this document as a generic term designing the block vectors in the Intra Block Copy mode or in the String Matching mode or in any other INTRA mode based on block vectors, but also the motion vectors in the INTER mode. In other words, it is proposed to adaptively select an entropic encoding method out of a plurality, the selected entropic encoding method being applied to the encoding of displacement vectors in at least two different block encoding modes.

In a preferred embodiment, at least one of the adaptations listed above is used simultaneously for both IBC and Inter modes. Namely, the selection of an encoding method to encode block vector residuals in Inter Block Copy mode and motion vector residuals in Inter mode is made conjointly. In the prior art, all proposals consist in changing IBC vector residual coding or adapt the coding for IBC mode only. But for screen content coding it is efficient to adapt the Golomb order also for Inter mode. Indeed, the value of the abs_mvd_minus2 is also generally larger, in average, for screen content than for natural content. To increase the coding efficiency, the vector residual for both modes can be adapted all together.

The Figure 13 illustrates an example of an embodiment according to the invention. The example is not limitative.

According to an embodiment of the invention, The same value of the Golomb order is set for decoding the Motion vector residual, whereas the data can be entropy decoded in function of at least two different modes, for example an INTRA type decoding (IBC) or an INTER type decoding.

These figures refer to Golomb order but other coding/decoding parameter may be considered, for example the flags abs_mvd_greaterl_flag can be removed or not for the MVD decoding process according to some statistics. Or 2 or more different vector residual coding methods can be considered as the classical MVD decoding or the proposed BV decoding method of JCTVC-00095.

Moreover, according to one embodiment of the invention, the Golomb order can be adapted or changed for each frame or portion or frames (each slice or CTB or CU or PU).

In Figure 12, all vector residuals for IBC or for Inter mode are decoded from the bit stream 1201 according to a same Golomb order 1202 to obtain the residual vectors 1204. This residual is decoded with the same decoding method for Inter or IBC modes (1205, 1205, 1207). The Golomb order (1202) have been adapted to the context (1211). This Golomb order can be extracted from the bitstream 1201 or set on the fly for both IBC and Inter modes or determined from statistics 1211. This adaption of the Golomb order can be at sequence, frame, slice, tile, CTB, CU or PU level. Please note that the Golomb order or parameters representing the Golomb Order value can be considered. In one embodiment, a flag is transmitted, and if its value is zero, the Golomb order is equal to 1 otherwise the Golomb order is equal to 4.

The adaptation of the Golomb order 1211 may be done according to statistics 1210 related to previous frames for instance. In that case the Golomb order can be extracted from the bitstream at frame level. During the encoding of each frame, the best Golomb order is determined by computing the relative rate cost for each possible Golomb order. The Golomb order which allows obtaining the smallest rate cost for the current frame is selected to be used for the next frame of the same type (Intra! Inter). This adaptation avoids a re-encoding of the slice or the frame but it gives smaller gains than a full RD selection of the best Golomb order.

In one embodiment, by considering the selection of the Golomb order at slice level or frame level, the Golomb order is initialized to 4 for the Intra frames and to 1 for the Inter frames. In another embodiment, the Golomb order is determined independently for Intra frame, P frame and B frame and the initial values are respectively 4, 1 and 1. In another embodiment, the Golomb order is determined according to a depth of a hierarchical frame ordering or hierarchical frame quality.

In one embodiment the Golomb order is determined on the fly PU by PU.

This Golomb order depends on the previous abs_mvd_minus2 and the previous Golomb order according of a defined formula.

In one embodiment, the selected Golomb order is the Golomb order which gives the best encoding results (RID estimations for example) for the previous frame.

In one embodiment the Exponential Golomb code is replaced by a Rice Golomb code when the Golomb order is greater than 1. This embodiment may be advantageous because the function used to decode a Rice Golomb code with an order greater than 1 is already implemented in the decoder. Indeed, this function is used in other cases, e.g. the transform coefficient syntax. While the function to decode an Exponential Golomb code with a Golomb order greater than 1 needs to be specifically added in the decoder.

In one embodiment, the use of the vector residual decoding adaptation for Inter mode can be shared with another mode or an additional mode to IBC.

For example, a hybrid mode combining the palette mode where pixels of the block are encoded based on a palette containing the actual value of the pixel, the index in the palette being encoded in the block instead of the actual pixel value. IBC mode can be also considered or a String Matching coding mode. An example of the later is a method that copies non-rectangular runs of pixels from a position, said position being encoded as a displacement and predicted.

In one embodiment, the use of the vector residual decoding adaptation for Intra block copy can be shared with another mode which is an Intra mode.

A general principle in hardware design is to attribute enough resources in terms of memory, number of operations so that each process is able to handle its worst scenario. When parsing the motion vector differences (MVD) at the decoder side, the worst case can be reached when all blocks have the smallest block size because it is the case where the maximum number of MVDs needs to be decoded. For the classical Inter mode, the worst case MVD parsing throughput for one CIB of 64x64 pixels is the parsing of 128 MVDs. Indeed, the minimum block size is 4x8 and 8x4 for unidirectional motion (1MV per PU) and 8x8 for bidirectional motion (2MVs per PU).

For Intra Block Copy mode, the minimum block size is 4x4. So the worst case parsing throughput is twice higher for Intra Block Copy mode than the classical Inter mode. This is even worsened in the average case because IBC block vectors residuals have a high magnitude on average. Indeed, the minimum block size is 4x4, which is half the minimum block size of Inter mode.

So for one CTB of 64x64 pixels with 4x4 IBC block size, 256 MVDs need to be decoded. So the current design increases by 2 times the required parsing throughput of the MVD parsing compared to the initial version or previous extensions of HEVC, where the IBC mode is not available. The invention embodiments below solve this issue by using the same worst case parsing throughput for Inter and IBC modes.

At encoder side, according to a preferred embodiment, the Golomb order is determined based on a non multipass encoding process.

Figure 13 shows the parsing of 4 MVDs corresponding to an 8x8 CU 1301 of four 4x4 PU: PU1, PU2, PU3, PU4. The detail 1302 of the related syntax elements parsing is also represented. It corresponds to the parsing of syntax elements shown in Figure 10. For each 4x4 PU, Pui, PU2, PU3, PU4, the MVD parsing 1303, 1304, 1305 and 1306 consists in decoding 1307, 1308, 1309 and 1310, two block vector components MVDx_i and MVDy_i.

In one embodiment of the invention, only the horizontal component is encoded and decoded for each 4x4 IBC PU. This is represented in Figure 14. It means that only abs_mvd_greatero_flag[0], abs_mvd_greaterl _flag[0], abs_mvd_minus2[0], mvd_sign_flag[O] can be parsed for the 4 4x4 PUs of an 8x8 IBC CU. The process start at step 1401. In step 1402 the flag abs_mvd_greatero_flag[0] is decoded. In step 1403 it is tested if abs_mvd_greatero_flag[O] is equal to 1. If true, in step 1404 the flag abs_mvd_greaterl_flag[0] is decoded. If true, in step 1405 it is tested if abs_mvd_greaterl_flag[0] is equal to 1. If true, in step 1406 abs_mvd_minus2[0] is decoded. In step 1407, the sign mvd_sign_flag[0] is decoded. The process stops in step 1408.

It is reminded that the MVD value for the component I' is obtained by the following formula: Mvd[i]= abs_mvd_greaterO_f/ag[i] * (abs_mvd_minus2[iJ + 2) * (1 -2 * m vd_sign_flag[iJ).

As depicted in Figure 15, this offers the possibility to divide by two the worst case parsing throughput of the MVD for IBC. This figure corresponds to Figure 13 where the second component (vertical component: MVDy) of each MVD has been suppressed. Yet it implies to implement a specific parsing function for the new 4x4 IBG PU at the decoder side. This is due to the fact that the typical MVD syntax element comprises the two components and is decoded using a parsing function dedicated to the parsing of the two components MVD syntax element.

In one embodiment] only the horizontal component is encoded and decoded for each 4x4 IBC PU but the horizontal components of the 4 4x4 Pus are interleaved in order to code only 2 MVD syntax elements as for Inter mode.

One consequence regarding the full frame search is that the full causal vertical or horizontal is explored.

Figure 16 shows this embodiment. In this example, the MVDx_1 and MVDx_2 of PU1 and PU2 are decoded jointly in the same two dimensional MVD syntax element parsing 1603. It means that MVDx_1 is decoded as the horizontal component and MVDx_2 as the vertical component in 1607. In the same way, the second MVD 1604 decoded contains MVDx_3 for the 3Id PU as the horizontal component and MVDx_4 for the 4th PU as the horizontal component in 1608. In this embodiment two encoded components pertaining to two different block vectors are encoded within the same two dimensional MVD syntax element. As for the first embodiment, this embodiment reduces by two the worst case MVD parsing for IBC and it avoids the use of specific new syntax element.

At the end of the proposed decoding, the value MVDy is not defined for the four PUs of an 8x8 IBC CU because it was not decoded. In one embodiment, the value MVDy is set equal to 0.

Different variants may be used for obtaining a value for the unavailable motion vector difference component (MVDx or MVD_y). For the sake of clarity, lets define the following notation. The decoded block vector By, having two components BVx and BVy is obtained from a predictor BVP having two components BVPx and BVPy by addition of the transmitted residual MVD having two components MVDx and MVDy. Namely BVx = BVPx + MVDx and BVy = BVPy + MVDy. In the current implementation, the IBC block vector predictor BVP is the last decoded By.

In one embodiment, MVDy is set equal to zero and the related vertical predictor BVPy is also set equal to 0. Consequently the block vector BV for a 4x4 PU is (BVPx + MVDx, 0). The same reasoning can be done for MVDx.

In one other embodiment, the vertical component BVPy is not changed.

Consequently the block vector for a 4x4 PU is (MVDx + BVPx, BVPy). Note that vertical component BVPy is the same for the four 4x4 PU of an 8x8 IBC CU.

The same reasoning can be done for MVDx.

In one other embodiment, the vertical component value of the last predictor, BVPy, is set equal to 0 for the 4x4 PU and it is reset to the last vertical component BVy of the last non 4x4 IBC block. The same reasoning can be done for MVDx.

In one embodiment, the 4x4 block residual vectors are coded or predicted in a different way than the other block sizes. For example, the 4x4 PU use the left or the above predictor and not the last predictor and the last predictor method is used for the other IBC block size. In one other embodiment, all IBC block size, except 4x4 uses multiple last predictors method, and the 4x4 PU used only one predictor. It means that a predictor index is transmitted for all sizes except for 4x4 PU.

In one embodiment, when only one component is coded per PU, the IBC block vectors are not predicted. It means that the BV value (either BVx or BVy) is directly coded as the MVD value (respectively MVDx or MVDy). In one embodiment, the 4x4 block vectors are not used to update the predictors list or the last predictor. In another embodiment, the predictor BVP for PU1 is the last block vector, whose BVy component is forced to 0. In a further embodiment, when the BVPx component of the predictor BVP is 0 or below the PU width (BVxc-N, with e.g. N=4) then the BVPx component is set to a default value, e.g. -N or -2N. In one embodiment, when the BVPy is not 0, the BVPx component is set equal to -12 (or -3N), and the BVPy component is set equal to 0.

The use of two interleaved Horizontal components can introduce a delay in the decoding of the following 4x4 IBC PU for some specific implementation.

Indeed, the last predictor is not available for the second PU before the parsing of the current MVD value as the value of MVDx_2 is decoded at the same time as MVDx_1. In one embodiment, to avoid any delay, the same block vector predictor is used for PU1 and PU2. In the same way the same block vector predictor is used for PU3 and PU4. In one embodiment, the block vector predictor for PU3 is the block vector of PU1 (its above PU) and the block vector predictor for PU4 is the block vector of PU2 (its above PU).

In one embodiment, the vertical MVDy component is coded and the horizontal component is not coded for 4x4 IBC PU. For this embodiment the same additional embodiment defined above can be used, with the X and Y components obviously swapped.

In one embodiment, the coding of the horizontal component MVDx or the vertical component MVDy is determined based on a flag extracted from the bitstream. This flag can be coded for each of the four 4x4 PUs. This flag can be signaled once for each 8x8 CU with 4 4x4 PU. This flag can also be transmitted at CTB, slice, tile, frame or sequence level.

Furthermore, it is possible to decide on a CU-basis to switch between the horizontal and the vertical dimensions. This is indicated by a CABAC-coded bit with a single context.

When a flag is transmitted to signal the MVD component decoded, the encoder can of course select the best component that needs to be transmitted based for example on the RD criterion.

One alternative to avoid the introduction of a new syntax element and using additional RID estimations at encoder side is to infer the use of the horizontal component or the vertical component. In one embodiment, if the last predictor for the first 4x4 PU has a horizontal component equal to 0 or below -N (with e.g. N=4) then the vertical component is coded for the four 4x4 IBC PUs.

In the same way, if the last predictor, for the 1st 4x4 PU, has a vertical component equal to 0 then the horizontal component is coded for the four 4x4 IBC PUs. In one embodiment if both components of the predictor are different from zero, the component with the greatest value (absolute value can be also considered) is coded for the following four 4x4 PUs. In another embodiment, if both components of the predictor are different to zero, the horizontal component x is coded.

In one embodiment, if the block vector predictor has a component equal to zero the other component is coded for the four 4x4 PUs. If both components of the predictor are different to 0, a flag indicating the coded component is decoded from the bitstream.

In one embodiment, the four 4x4 PU block vectors are not predicted and the sign of the block vector component decoded, mvd_sign_flag, indicates if the current decoded component is the horizontal or vertical component. Indeed, when only one component is used, it is not possible for this component to be positive due to the causal area available. Only the left block line is available or only the top block row. Consequently, the sign is systematically known to be negative. For this embodiment, the mvd_sign_flag signals whether the component decoded is the horizontal or the vertical one. Moreover, the block vector component is inferior to -N, so it is inferior to -4. As a consequence the component can be predicted by this value. So in a specific embodiment, when the decoded component MVDi value is between 0 to MAX_VALUE, it corresponds to the horizontal component of the current BV vector and it is obtained by the following formula: BVx = -MVDi -N And if the decoded component MVDi value is between -MAX_VALUE to - 1 it corresponds to the vertical component and it is obtained by the formula: BVy= MVDi-(N-1) Please note that N is replaced by 4 and N-i by 3 for 4x4 PU size.

For Intra Block Copy mode, in order to simplify the decoding process, it is recommended that a PU can't be predicted by a PU of the current CU. So to improve the coding efficiency the previous embodiment can take into account the PU position inside the CU, as it guarantees minimal values for BVx (or BVy) and thus allow transforming the BV value so as to encode elements of lower magnitude, thus more efficiently. Figure 17 shows the four related NxN PU of a 2Nx2N CU. Let us now detail various embodiments where this position is taken into account to change the BV value.

In one embodiment for PU1 when the decoded component MVDi value is between 0 to MAX_VALUE, it corresponds to the horizontal component of the current BV vector and it is obtained by the following formula: BVx = -MVDi -N And if the decoded component MVDi value is between -MAX_VALUE to - 1 it corresponds to the vertical component and it is obtained by the formula: BVy= MVDi-(N-1).

For PU2 when the decoded component MVDi value is between 0 to MAX_VALUE, it corresponds to the horizontal component of the current BV vector and it is obtained by the following formula: BVxMVDi_2N.

And if the decoded component MVDi value is between -MAX_VALUE to - 1 it corresponds to the vertical component and it is obtained by the formula: BVy= MVDi-(N-1).

For PU3 when the decoded component MVDi value is between 0 to MAX_VALUE, it corresponds to the horizontal component of the current BV vector and it is obtained by the following formula: BVx = -MVDi N. And if the decoded component MVDi value is between -MAX_VALUE to - 1 it corresponds to the vertical component and it is obtained by the formula: BVy MVDi-(2N-1).

For PU4 when the decoded component MVDi value is between 0 to MAX_VALUE, it corresponds to the horizontal component of the current BV vector and it is obtained by the following formula: BVx = -MVDi 2N.

And if the decoded component MVDi value is between -MAX_VALUE to - 1 it corresponds to the vertical component and it is obtained by the formula: BVy= MVDi-(2N-1).

It is worth noting that the ways of coding block vector components illustrated in Figure 17 may also apply to any embodiment of Intra Block Copy mode even outside the scope of the present invention.

In one embodiment, only the first 4x4 PU is not predicted and the direction, either vertical or horizontal, is inferred from the mvd_sign_flag as described above. And the three next 4x4 PUs are predicted as usual and the decoded components have the same direction as the first 4x4 PU. It means that the three last 4x4 PUs don't infer the component direction but only the first one.

It gives highest coding efficiency and doesn't need any new syntax element to signal the vertical or the horizontal direction.

In one embodiment, the direction signalization is signaled in the vector residual sign of the 4th PU of the current CU. As the previous embodiment this PU and the direction, either vertical or horizontal, is inferred from the mvd_sign_flag as described above. And the three previous 4x4 PUs are predicted as usual and the decoded components have the same direction as the fourth 4x4 PU. Indeed, for the fourth PU when the direction is inferred, the horizontal component can be predicted by 2N or the horizontal component by 2N-1. These values are higher than the values that can be used for the first PU.

In one embodiment, the proposed embodiments are applied for 8x4 and 4x8 block sizes or for all 2NxN and Nx2N possible block sizes.

At encoder side, when the 4x4 PU MVDs are restricted to only one component, some adaptations are needed. Of course it is not needed to test the whole square search area for each 4x4 PU and only the block line needs to be tested if the horizontal component is decodable or only the block row if the vertical component only is decodable. Yet this reduced search area decreases the coding efficiency and the run time. So to obtain the same efficiency/complexity compromise, in one embodiment, the search area is extended to the whole block line or block row according to the MVD coded.

Figure 18 is a schematic block diagram of a computing device 1800 for implementation of one or more embodiments of the invention. The computing device 1800 may be a device such as a micro-computer, a workstation or a light portable device. The computing device 1800 comprises a communication bus connected to: -a central processing unit 1801, such as a microprocessor, denoted CPU; -a random access memory 1802, 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 for encoding or decoding at least part of an image 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 1803, denoted ROM, for storing computer programs for implementing embodiments of the invention; -a network interface 1804 is typically connected to a communication network over which digital data to be processed are transmitted or received.

The network interface 1804 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 1801; -a user interface 1805 may be used for receiving inputs from a user or to display information to a user; -a hard disk 1806 denoted HD may be provided as a mass storage device; -an I/O module 1807 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 1803, on the hard disk 1806 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 1804, in order to be stored in one of the storage means of the communication device 1800, such as the hard disk 1806, before being executed.

The central processing unit 1801 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 1801 is capable of executing instructions from main RAM memory 1802 relating to a software application after those instructions have been loaded from the program ROM 1803 or the hard-disc (HD) 1806 for example. Such a software application, when executed by the CPU 1801, causes the steps of the flowcharts shown in Figures Ito 4 to be performed.

Any step of the algorithm shown in Figure 4,5, 10, 11, 12 and 14 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 an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least two modes comprising the encoding of displacement vectors, the method comprising: -selecting a displacement vector decoding method out of a plurality of displacement vector decoding method; and -decoding a first block of pixels according to a first mode comprising the decoding of displacement vectors; and -decoding a second block of pixels according to a second mode comprising the decoding of displacement vectors; wherein: -the first and the second modes are using the selected displacement vector decoding method.
2. The method of claim 1 wherein the first mode is an INTRA mode.
3. The method of claim 1 wherein the first mode is the Intra Block Copy mode.
4. The method of claim 1 wherein the first mode is the String Matching mode.
5. The method of anyone claims 1 to 4 wherein the second mode is the INTER mode.
6. The method of anyone claims 1 to 5, wherein said plurality of displacement vector decoding method is based on the Exponential Golomb code using a plurality of Golomb orders.
7. The method of anyone claims 1 to 5, wherein said plurality of displacement vector decoding method is based on the Exponential Golomb code and the Rice Golomb code, both using a plurality of Golomb orders.
8. The method of claim 6, wherein said plurality of Golomb Orders corresponds to values 1 and 4.
9. The method of anyone claims 6 to 8, wherein the Golomb Order is received from the bitstream.
10. The method of claim 7, wherein said plurality of displacement vector decoding method is based on the Exponential Golomb code using a Golomb Order of 1 and the Rice Golomb code using Golomb Order greater than 1.
11. The method of claim 6, wherein the selection of a displacement vector decoding method consisting in selecting the Golomb Order, the selection being done at the slice or at the frame level, the Golomb order is initialized to 4 for the Intra frames and to 1 for the Inter frames.
12.The method of claim 6, wherein the selection of a displacement vector decoding method consisting in selecting the Golomb Order, the selection being done at the slice or at the frame level, the selection is done independently for Intra frames, P frames and B frames, the Golomb order is initialized to 4 for the Intra frames and to 1 for the P and B frames.
13. The method of claim 6, wherein the selection of a displacement vector decoding method consisting in selecting the Golomb Order, the Golomb order is determined according to a depth of a hierarchical frame ordering or hierarchical frame quality.
14. The method of claim 6, wherein the selection of a displacement vector decoding method consisting in selecting the Golomb Order, the selection being done at the Coding Unit or Prediction Unit level.
15.A method of encoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least two modes comprising the encoding of displacement vectors, the method comprising: -selecting a displacement vector encoding method out of a plurality of displacement vector encoding method; and -encoding a first block of pixels according to a first mode comprising the encoding of displacement vectors; and -encoding a second block of pixels according to a second mode comprising the encoding of displacement vectors; wherein: -the first and the second modes are using the selected displacement vector encoding method.
16. The method of claim 15 wherein the first mode is an INTRA mode.
17.The method of claim 15 wherein the first mode is the Intra Block Copy mode.
18. The method of claim 15 wherein the first mode is the String Matching mode.
19. The method of anyone claims 15 to 18 wherein the second mode is the INTER mode.
20.The method of anyone claims 15 to 19, wherein said plurality of displacement vector encoding method is based on the Exponential Golomb code using a plurality of Golomb orders.
21.The method of anyone claims 15 to 19, wherein said plurality of displacement vector encoding method is based on the Exponential Golomb code and the Rice Golomb code, both using a plurality of Golomb orders.
22.The method of claim 20, wherein said plurality of Golomb Orders corresponds to values 1 and 4.
23. The method of anyone claims 20 to 22, wherein the Golomb Order is transmitted in the bitstream.
24. The method of claim 21, wherein said plurality of displacement vector encoding method is based on the Exponential Golomb code using a Golomb Order of 1 and the Rice Golomb code using Golomb Order greater than 1.
25.The method of claim 20, wherein the selection of a displacement vector encoding method consisting in selecting the Golomb Order, the selection being done at the slice or at the frame level, the Golomb order is initialized to 4 for the Intra frames and to 1 for the Inter frames.
26.The method of claim 20, wherein the selection of a displacement vector encoding method consisting in selecting the Golomb Order, the selection being done at the slice or at the frame level, the selection is done independently for Intra frames, P frames and B frames, the Golomb order is initialized to 4 for the Intra frames and to 1 for the P and B frames.
27.The method of claim 20, wherein the selection of a displacement vector encoding method consisting in selecting the Golomb Order, the Golomb order is determined according to a depth of a hierarchical frame ordering or hierarchical frame quality.
28.The method of claim 20, wherein the selection of a displacement vector encoding method consisting in selecting the Golomb Order, the selection being done at the Coding Unit or Prediction Unit level.
29.A method of decoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vectors, the method comprising: -decoding a displacement vector based on the decoding of a syntax element corresponding to a displacement vector residual; wherein: -said decoding of a displacement vector is realized according to a specific displacement vector decoding method for a given size of block of pixels different of the one used for other sizes of block of pixels.
30. The method of claim 29, wherein said given size of block of pixels correspond to block of pixel of size NxN, N being a given positive integer.
31. The method of claim 30, wherein N is 4.
32.The method of claim 30, wherein the given size is the smallest block of pixels size considering one of the modes.
33.The method of anyone claims 29 to 32, wherein said specific displacement vector decoding method comprises decoding only one component of said displacement vector from said syntax element.
34. The method of claim 33, wherein the component decoded from the syntax element is the horizontal one.
35. The method of claim 33, wherein the component decoded from the syntax element is the vertical one.
36. The method of claim 33, wherein the component decoded from the syntax element is specified by a flag in the bitstream.
37.The method of claim 36, wherein said flag is the sign of the component decoded from the syntax element.
38. The method of claim 33, wherein the component decoded from the syntax element for a block of pixels of size 4x4 within a 8x8 block of pixels depends on the last displacement vector decoded for the first 4x4 block of pixels within said 8x8 block of pixels.
39. The method of any one claims 33 to 38, wherein two displacement vector components pertaining to two different displacement vectors are decoded from the same two dimensional syntax element.
40. The method of any one claims 33 to 39, wherein the displacement vector component not decoded from the syntax element is set equal to a default value.
41.The method of claim 40, wherein the displacement vector component not decoded from the syntax element is set equal to 0.
42. The method of any one claims 33 to 39, wherein the displacement vector component not decoded from the syntax element is set equal to -N, where N is the size of the block of pixels.
43. The method of any one claims 33 to 39, wherein the displacement vector component not decoded from the syntax element is set equal to -2N, where N is the size of the block of pixels.
44. The method of any one claims 33 to 39, wherein the displacement vector component decoded from the syntax element is decoded based on the location of the block of pixels of size NxN within a block of pixels of size 2Nx2N.
45.A method of encoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vectors, the method comprising: -encoding a displacement vector based on the encoding of a syntax element corresponding to a displacement vector residual; wherein: -said encoding of a displacement vector is realized according to a specific displacement vector encoding method for a given size of block of pixels different of the one used for other sizes of block of pixels.
46. The method of claim 45, wherein said given size of block of pixels correspond to block of pixel of size NxN, N being a given positive integer.
47. The method of claim 46 wherein N is 4.
48. The method of claim 46, wherein the given size is the smallest block of pixels size considering one of the modes.
49.The method of anyone claims 45 to 48, wherein said specific displacement vector decoding method comprises decoding only one component of said displacement vector from said syntax element.
50. The method of claim 49, wherein the component decoded from the syntax element is the horizontal one.
51.The method of claim 49, wherein the component decoded from the syntax element is the vertical one.
52. The method of claim 49, wherein the component decoded from the syntax element is specified by a flag in the bitstream.
53.The method of claim 52, wherein said flag is the sign of the component decoded from the syntax element.
54. The method of claim 49, wherein the component decoded from the syntax element for a block of pixels of size 4x4 within a 8x8 block of pixels depends on the last displacement vector decoded for the first 4x4 block of pixels within said 8x8 block of pixels.
55. The method of any one claims 49 to 54, wherein two displacement vector components pertaining to two different displacement vectors are decoded from the same two dimensional syntax element.
56.A decodeur device for decoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least two modes comprising the encoding of displacement vectors, the device comprising: -a selector for selecting a displacement vector decoding method out of a plurality of displacement vector decoding method; and -a decoder for decoding a first block of pixels according to a first mode comprising the decoding of displacement vectors; and -a decoder decoding a second block of pixels according to a second mode comprising the decoding of displacement vectors; wherein: -the first and the second modes are using the selected displacement vector decoding method.
57.An encoder device for encoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least two modes comprising the encoding of displacement vectors, the device comprising: -a selector for selecting a displacement vector encoding method out of a plurality of displacement vector encoding method; and -an encoder for encoding a first block of pixels according to a first mode comprising the encoding of displacement vectors; and -an encoder for encoding a second block of pixels according to a second mode comprising the encoding of displacement vectors; wherein: -the first and the second modes are using the selected displacement vector encoding method.
58.A decoder device for decoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vectors, the device comprising: -a decoder for decoding a displacement vector based on the decoding of a syntax element corresponding to a displacement vector residual; wherein: -said decoding of a displacement vector is realized according to a specific displacement vector decoding method for a given size of block of pixels different of the one used for other sizes of block of pixels.
59.An encoder device for encoding an image comprising a plurality of blocks of pixels, each block of pixels being encoded according to a mode out of a plurality of modes, at least one mode comprising the encoding of a two dimensional displacement vectors, the device comprising: -an encoder for encoding a displacement vector based on the encoding of a syntax element corresponding to a displacement vector residual; wherein: -said encoding of a displacement vector is realized according to a specific displacement vector encoding method for a given size of block of pixels different of the one used for other sizes of block of pixels.
60.A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to any one of claims 1 to 55, when loaded into and executed by the programmable apparatus.
61.A computer-readable storage medium storing instructions of a computer program for implementing a method according to any one of claims 1 to 55.
62.A method of synchronisation substantially as hereinbefore described with reference to, and as shown in Figure 13 to 17.