Motion Vector Predictor Index Coding in Video Coding

Abstract

To provide: a method of encoding a motion vector predictor index, in particular a Merge index; and a decoding method and a decoding device.SOLUTION: An encoding method comprises generating a list of motion vector predictor candidates, in particular Merge candidates. The list includes an alternative temporal motion vector prediction (ATMVP) candidate. The method also comprises: selecting one of the motion vector predictor candidates in the list; generating a motion vector predictor index for the selected motion vector predictor candidate by using CABAC coding; and bypass-CABAC-coding one or more bits of the motion vector predictor index, e.g., CABAC-coding only the first bit of the motion vector predictor index by using a single context.SELECTED DRAWING: Figure 13

Description

[Technical field]

[0001] The present invention relates to video encoding and decoding. [Background technology]

[0002] Recently, the Joint Video Experts Team (JVET), a joint team formed by MPEG and the VCEG of ITU-T Study Group 16, began work on a new video coding standard called Versatile Video Coding (VVC). The goal of VVC is to provide significant improvements in compression performance over the existing HEVC standard (i.e., typically twice as much as before) and to be completed in 2020. Primary target applications and services include, but are not limited to, 360-degree and high dynamic range (HDR) video. Overall, the JVET evaluated responses from 32 parties using formal subjective testing conducted by an independent testing laboratory. Some proposals demonstrated compression efficiency gains, typically 40% or more, compared to using HEVC. Particular effectiveness was shown on ultra-high definition (UHD) video test material. Thus, we can expect compression efficiency gains well beyond the targeted 50% of the final standard.

[0003] The JVET Search Model (JEM) uses all the HEVC tools. An additional tool not present in HEVC is the use of "affine motion mode" when applying motion compensation. Motion compensation in HEVC is limited to translations, whereas in reality there are many types of motion, e.g. zoom in / out, rotations, perspective motion, and other irregular movements. When using affine motion mode, more complex transformations are applied to blocks to try to more accurately predict the form of such motion.

[0004] Another tool that is not present in HEVC is the use of Alternative Temporal Motion Vector Prediction (ATMVP). Alternative Temporal Motion Vector Prediction (ATMVP) is a specific motion compensation. Instead of considering only one motion information for the current block from the temporal reference frame, each motion information of the respectively located blocks is considered. This temporal motion vector prediction thus gives a partition of the current block with the associated motion information of each subblock. In the current VTM reference software, ATMVP is signaled as a merge candidate that is inserted into the list of merge candidates. When ATMVP is enabled at the SPS level, the maximum number of merge candidates is increased by 1. Thus, if this mode is disabled, 6 candidates are considered instead of 5. Summary of the Invention

[0005] These and other tools described below raise concerns regarding the coding efficiency and complexity of encoding the merge index used to signal which merge candidate is selected from a list of merge candidates. Thus, a solution to at least one of the above problems is desirable.

[0006] According to a first aspect of the present invention, there is provided a method for encoding a motion vector predictor index, the method comprising: generating a list of motion vector predictor candidates including an ATMVP candidate; selecting one of the motion vector predictor candidates in the list; generating a motion vector predictor index (merge index) for the selected motion vector predictor candidate using CABAC encoding; and one or more bits of the motion vector predictor index are bypass CABAC encoded.

[0007] In one embodiment, all bits except the first bit of the motion vector predictor index are bypass CABAC coded.

[0008] According to a second aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising the steps of: generating a list of motion vector predictor candidates including ATMVP candidates; a motion vector predictor index that is a candidate for a motion vector predictor in the list; a motion vector predictor index that is a candidate for a motion vector predictor in the list; and a motion vector predictor index that is a candidate for a motion vector predictor in the list.

[0009] In one embodiment, all bits except the first bit of the motion vector predictor index are bypass CABAC decoded.

[0010] According to a third aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates including an ATMVP candidate; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index (merge index) for the selected motion vector predictor candidate using CABAC encoding, and one or more bits of the motion vector predictor index are bypass CABAC encoded.

[0011] According to a fourth aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates including an ATMVP candidate; means for decoding the motion vector predictor index using CABAC decoding; and means for one or more bits of the motion vector predictor index being bypass CABAC decoded and using the decoded motion vector predictor index to identify one of the motion vector predictors in the list.

[0012] According to a fifth aspect of the present invention, there is provided a method for encoding a motion vector predictor index, the method comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein two or more bits of the motion vector predictor index share the same context.

[0013] In one embodiment, all bits of the motion vector predictor index share the same context.

[0014] According to a sixth aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; decoding the motion vector predictor index using CABAC decoding, where two or more bits of the motion vector predictor index share the same context; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0015] In one embodiment, all bits of the motion vector predictor index share the same context.

[0016] According to a seventh aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein two or more bits of the motion vector predictor index share the same context.

[0017] According to an eighth aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC decoding; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list, where two or more bits of the motion vector predictor index share the same context.

[0018] According to a ninth aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable of at least one bit of the motion vector predictor index of a current block depends on at least one motion vector predictor index neighboring the current block.

[0019] In one embodiment, at least one of said context variables of said motion vector predictor index depends on said respective motion vector predictor indexes of at least two neighboring blocks.

[0020] In another embodiment, a context variable of at least one bit of the motion vector predictor index depends on the motion vector predictor index of a left neighboring block to the left of the current block and the motion vector predictor index of an upper neighboring block above the current block.

[0021] In another embodiment, the left adjacent block is A2 and the above adjacent block is B3.

[0022] In another embodiment, the left adjacent block is A1 and the above adjacent block is B1.

[0023] In another embodiment, the context variable has three different possible values.

[0024] Another embodiment includes comparing an index value of a motion vector predictor index of at least one neighboring block and a motion vector predictor index of a current block, and setting the context variable based on a comparison result.

[0025] Another embodiment includes comparing a motion vector predictor index of at least one neighboring block with a parameter representing a bit position of the or said bits in the motion vector predictor index of the current block, and setting the context variable based on a comparison result.

[0026] Yet another embodiment includes performing a first comparison and comparing a motion vector predictor index of a first adjacent block with a parameter representing a bit position of the or said bit in the motion vector predictor index of the current block, performing a second comparison and comparing a motion vector predictor index of a second adjacent block with said parameter, and setting said context variable depending on results of the first and second comparisons.

[0027] According to a tenth aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; decoding the motion vector predictor index using CABAC decoding; a context variable of at least one bit of the motion vector predictor index of a current block depends on a motion vector predictor index of at least one block neighboring the current block; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0028] In one embodiment, a context variable of at least one bit of the motion vector predictor index depends on the motion vector predictor indexes of each of the at least two neighboring blocks.

[0029] In another embodiment, the context variable of at least one bit of the motion vector predictor index depends on the motion vector predictor index of the left neighboring block to the left of the current block and the motion vector predictor index of the upper neighboring block of the current block.

[0030] In another embodiment, the left adjacent block is A2 and the above adjacent block is B3. In another embodiment, the left adjacent block is A1 and the above adjacent block is B1. In another embodiment, the context variable has three different possible values.

[0031] Another embodiment comprises comparing a motion vector predictor index of at least one neighboring block with an index value of a motion vector predictor index of a current block, and setting said context variable depending on a comparison result.

[0032] Another embodiment includes comparing a motion vector predictor index of at least one neighboring block with a parameter representing a bit position of the or said bit in the motion vector predictor index of the current block, and setting said context variable depending on the comparison result.

[0033] Yet another embodiment includes performing a first comparison and comparing a motion vector predictor index of a first adjacent block with a parameter representing a bit position of the or said bit in the motion vector predictor index of the current block, performing a second comparison and comparing a motion vector predictor index of a second adjacent block with said parameter, and setting said context variable depending on results of the first and second comparisons.

[0034] According to an eleventh aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable of at least one bit of the motion vector predictor index of a current block depends on a motion vector predictor index of at least one block adjacent to the current block.

[0035] According to a twelfth aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC decoding; a context variable of at least one bit of the motion vector predictor index of a current block depends on a motion vector predictor index of at least one block neighboring the current block; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0036] According to a thirteenth aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable of at least one bit of the motion vector predictor index for a current block depends on a skip flag of the current block.

[0037] According to a fourteenth aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC coding, wherein a context variable of at least one bit of the motion vector predictor index of a current block depends on another parameter or a syntax element of the current block that is available prior to decoding of the motion vector predictor index.

[0038] According to a fifteenth aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC coding, wherein a context variable of at least one bit of the motion vector predictor index for a current block depends on another parameter or a syntax element of the current block that is an indication of a complexity of the current block.

[0039] According to a sixteenth aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; encoding the motion vector predictor index using CABAC encoding; a context variable of at least one bit of the motion vector predictor index of a current block depends on a skip flag of the current block; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0040] According to a seventeenth aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; encoding the motion vector predictor index using CABAC encoding; a context variable of at least one bit of the motion vector predictor index of a current block depends on another parameter or a syntax element of the current block that is available prior to decoding of the motion vector predictor index; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0041] According to an 18th aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; encoding the motion vector predictor index using CABAC encoding; a context variable of at least one bit of the motion vector predictor index of a current block depends on another parameter or a syntax element of the current block that is an indication of the complexity of the current block; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0042] According to a 19th aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding; and wherein a context variable of at least one bit of the motion vector predictor index for a current block depends on a skip flag of the current block.

[0043] According to a twentieth aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable of at least one bit of the motion vector predictor index of a current block depends on another parameter or a syntax element of the current block that is available prior to decoding of the motion vector predictor index.

[0044] According to a 21st aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding; and wherein a context variable of at least one bit of the motion vector predictor index for a current block depends on another parameter or a syntax element of the current block that is an indication of complexity of the current block.

[0045] According to a twenty-second aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC coding; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list, wherein a context variable of at least one bit of the motion vector predictor index for a current block depends on a skip flag of the current block.

[0046] According to a 23rd aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC coding; a context variable of at least one bit of the motion vector predictor index of a current block depends on another parameter or a syntax element of the current block that is available prior to decoding of the motion vector predictor index; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0047] According to a 24th aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC coding; a context variable of at least one bit of the motion vector predictor index of a current block depends on another parameter or a syntax element of the current block that is an indication of a complexity of the current block; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0048] According to a 25th aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable of at least one bit of the motion vector predictor index for a current block depends on if there is an affine motion vector predictor candidate in the list.

[0049] In one embodiment, a context variable depends on the position in said list of the first affine motion vector predictor candidate.

[0050] According to a 26th aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; decoding said motion vector predictor index using CABAC decoding; a context variable of at least one bit of said motion vector predictor index for a current block depending on if there are affine motion vector predictor candidates in the list; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0051] In one embodiment, a context variable depends on the position in said list of the first affine motion vector predictor candidate.

[0052] According to a 27th aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding; and a context variable of at least one bit of the motion vector predictor index for a current block depends on the affine motion vector predictor candidates, if any, in the list.

[0053] According to a 28th aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC decoding; and a context variable of at least one bit of the motion vector predictor index for a current block depending on whether there is an affine motion vector predictor candidate in the list; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0054] According to a twenty-ninth aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates including an affine motion vector predictor candidate; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable of at least one bit of the motion vector predictor index for a current block depends on an affine flag of the current block and / or of at least one block neighboring the current block.

[0055] According to a 30th aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates including an affine motion vector predictor candidate; decoding the motion vector predictor index using CABAC decoding; a context variable of at least one bit of the motion vector predictor index of a current block depends on an affine flag of the current block and / or of at least one block neighboring the current block; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0056] According to a thirty-first aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates including an affine motion vector predictor candidate; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable of at least one bit of the motion vector predictor index of a current block depends on an affine flag of the current block and / or of at least one block adjacent to the current block.

[0057] According to a 32nd aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates including an affine motion vector predictor candidate; means for decoding the motion vector predictor index using CABAC decoding; a context variable of at least one bit of the motion vector predictor index of a current block depends on an affine flag of the current block and / or of at least one block neighboring the current block; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0058] According to a thirty-third aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, and a context variable for at least one bit of the motion vector predictor index of a current block is derived from at least one context variable of a skip flag and an affine flag of the current block.

[0059] According to a 34th aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; decoding the motion vector predictor index using CABAC decoding, a context variable of at least one bit of the motion vector predictor index of a current block being derived from at least one context variable of a skip flag and an affine flag of the current block; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0060] According to a 35th aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable for at least one bit of the motion vector predictor index of a current block is derived from at least one context variable of a skip flag and an affine flag of the current block.

[0061] According to a 36th aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC decoding; a context variable of at least one bit of the motion vector predictor index of a current block is derived from at least one context variable of a skip flag and an affine flag of the current block; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0062] According to a 37th aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein a context variable of at least one bit of the motion vector predictor index for a current block has only two different possible values.

[0063] According to a 38th aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; decoding the motion vector predictor index using CABAC decoding, a context variable of at least one bit of the motion vector predictor index of a current block being derived from at least one context variable of a skip flag and an affine flag of the current block; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0064] According to a thirty-ninth aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding; and wherein a context variable of at least one bit of the motion vector predictor index for a current block has only two different possible values.

[0065] According to a fortieth aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC decoding; and a context variable of at least one bit of the motion vector predictor index of a current block has only two different possible values, and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0066] According to a forty-first aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates; selecting one of the motion vector predictor candidates in the list; generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding; and wherein the motion vector predictor index for a current block depends on affine motion vector predictor candidates in the list, if any.

[0067] In one embodiment, the motion vector predictor index is a merge index.

[0068] According to a forty-second aspect of the present invention, there is provided a method for decoding a motion vector predictor index, the method comprising: generating a list of motion vector predictor candidates; decoding the motion vector predictor index using CABAC decoding; and the motion vector predictor index for a current block depends on affine motion vector predictor candidates in the list, if any; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0069] In one embodiment, the motion vector predictor index is a merge index.

[0070] According to a forty-third aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein the motion vector predictor index for a current block depends on affine motion vector predictor candidates in the list, if any.

[0071] According to a forty-fourth aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates; means for decoding the motion vector predictor index using CABAC decoding; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list, the motion vector predictor index for a current block being dependent on affine motion vector predictor candidates, if any, in the list.

[0072] According to a 45th aspect of the present invention, there is provided a method for encoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates including an affine motion vector predictor candidate; selecting one of the motion vector predictor candidates in the list; and generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein the motion vector predictor index for a current block depends on an affine flag of the current block and / or at least one block neighboring the current block.

[0073] In one embodiment, the motion vector predictor index is a merge index.

[0074] According to a 46th aspect of the present invention, there is provided a method for decoding a motion vector predictor index, comprising: generating a list of motion vector predictor candidates including affine motion vector predictor candidates; decoding the motion vector predictor index using CABAC decoding, wherein the motion vector predictor index for a current block depends on an affine flag of the current block and / or at least one block neighboring the current block; and using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list.

[0075] In one embodiment, the motion vector predictor index is a merge index.

[0076] According to a 47th aspect of the present invention, there is provided an apparatus for encoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates including an affine motion vector predictor candidate; means for selecting one of the motion vector predictor candidates in the list; and means for generating a motion vector predictor index for the selected motion vector predictor candidate using CABAC encoding, wherein the motion vector predictor index for a current block depends on an affine flag of the current block and / or at least one block neighboring the current block.

[0077] According to a 48th aspect of the present invention, there is provided an apparatus for decoding a motion vector predictor index, comprising: means for generating a list of motion vector predictor candidates including an affine motion vector predictor candidate; means for decoding the motion vector predictor index using CABAC decoding; and means for using the decoded motion vector predictor index to identify one of the motion vector predictor candidates in the list, the motion vector predictor index for a current block depending on an affine flag of the current block and / or at least one block neighboring the current block.

[0078] Yet another aspect of the invention relates to a program which, when executed by a computer or a processor, causes the computer or processor to perform any of the methods of the previous aspects. The program may be provided on its own or may be carried on, by or in a carrier medium. The carrier medium may be non-transitory, for example a storage medium, in particular a computer-readable storage medium. The carrier medium may also be transitory, for example a signal or other transmission medium. The signal may be transmitted over any suitable network, including the Internet.

[0079] Yet another aspect of the invention relates to a camera comprising a device according to any of the device aspects above. In one embodiment, the camera further comprises zoom means. In one embodiment, the camera is adapted to indicate when said zoom means is operable and to communicate an affine mode in dependence on said indication that the zoom means is operational. In another embodiment, the camera further comprises pan means. In another embodiment, the camera is adapted to indicate when said pan means is operable and to transmit an affine mode in dependence on said indication that the pan means is operational.

[0080] According to yet another aspect of the invention there is provided a mobile device comprising a camera embodying any of the above camera aspects. In one embodiment the mobile device further comprises at least one position sensor adapted to sense a change in orientation of the mobile device. In one embodiment the mobile device is adapted to propagate the affine mode dependent on said sensing of a change in orientation of the mobile device. Further features of the invention are characterized by the other independent and dependent claims.

[0081] Any feature in one aspect of the invention may be applied to other aspects of the invention in any suitable combination. In particular, method aspects may be applied to apparatus aspects and vice versa. Furthermore, features implemented in hardware may be implemented in software and vice versa. Any references to software and hardware features in this specification should be interpreted accordingly. Any apparatus features as described herein may be provided as method features and vice versa. As used herein, means-plus-function features may alternatively be expressed in terms of their corresponding structures, such as a suitably programmed processor and associated memory. It should also be understood that specific combinations of the various features described and defined in any aspect of the invention may be implemented and / or provided and / or used independently. [Brief description of the drawings]

[0082] By way of example, reference is made to the following drawings:

[0083] [Figure 1] FIG. 1 is a diagram for explaining the coding structure used in HEVC. [Diagram 2] FIG. 2 is a block diagram that illustrates a schematic diagram of a data communications system in which one or more embodiments of the present invention may be implemented. [Diagram 3] FIG. 3 is a block diagram illustrating components of a processing device in which one or more embodiments of the present invention may be implemented. [Figure 4]FIG. 4 is a flow chart illustrating steps of an encoding method according to an embodiment of the invention. [Diagram 5] FIG. 5 is a flow chart illustrating steps of a decoding method according to an embodiment of the invention. [Figure 6a] FIG. 6(a) shows spatial and temporal blocks that may be used to generate a motion vector predictor. [Figure 6b] FIG. 6(b) shows spatial and temporal blocks that may be used to generate a motion vector predictor. [Figure 7] FIG. 7 shows simplified steps in the process of AMVP predictor setting derivation. [Figure 8] FIG. 8 is a schematic diagram of the motion vector derivation process in the merge mode. [Figure 9] FIG. 9 shows the division and temporal motion vector prediction of the current block. [Figure 10] Figure 10(a) shows the encoding of the merge index for HEVC or when ATMVP is not enabled at the SPS level, and Figure 10(b) shows the encoding of the merge index when ATMVP is enabled at the SPS level. [Figure 11] Figure 11(a) shows a simple affine motion field, and Figure 11(b) shows a more complex affine motion field. [Figure 12] FIG. 12 is a flow chart of a partial decoding process for some syntax elements related to coding modes. [Figure 13] FIG. 13 is a flowchart showing merging candidate derivation. [Figure 14] FIG. 14 is a flowchart showing the first embodiment of the present invention. [Figure 15] FIG. 15 is a flowchart of a partial decoding process of some syntax elements related to the encoding mode in the twelfth embodiment of the present invention. [Figure 16] FIG. 16 is a flowchart showing generation of a list of merging candidates in the twelfth embodiment of the present invention. [Figure 17]FIG. 17 is a block diagram for use in describing a CABAC encoder suitable for use in embodiments of the present invention. [Figure 18] FIG. 18 is a schematic block diagram of a computing device for implementing one or more embodiments of the present invention. [Figure 19] FIG. 19 is a schematic block diagram of a computing device. [Figure 20] FIG. 20 is a diagram showing a network camera system. [Figure 21] FIG. 21 is a diagram showing a smartphone. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0084] The embodiments of the invention described below relate to improving index encoding and decoding using CABAC. Before describing the embodiments, video encoding and decoding techniques and associated encoding and decoding units are described. Figure 1 relates to the encoding structure used in the High Efficiency Video Coding (HEVC) video standard. A video sequence 1 is composed of a sequence of digital images i. Each such digital image is represented by one or more matrices. The matrix coefficients represent pixels. The images 2 of the sequence can be divided into slices 3. A slice may in some instances constitute the entire image. These slices are divided into non-overlapping coding tree units (CTUs). A coding tree unit (CTU) is the basic processing unit of the High Efficiency Video Coding (HEVC) video standard and conceptually corresponds in structure to the macroblock unit used in some previous video standards. A CTU is sometimes also referred to as a maximum coding unit (LCU). A CTU has luma and chroma component parts, each of which is called a coding tree block (CTB). These different color components are not shown in Figure 1.

[0085] A CTU is typically of size 64 pixels by 64 pixels for HEVC, but for VVC the size may be 128 pixels by 128 pixels. Each CTU may in turn be iteratively divided into smaller variable-size coding units (CUs) 5 using a quadtree decomposition. A coding unit is a basic coding element and is composed of two types of subunits called a prediction unit and a transform unit. The maximum size of a PU or TU is equal to the CU size. A prediction unit corresponds to a partition of a CU for the prediction of pixel values. Various different partitions of a CU into PUs are possible, as shown by 606, including a partition into four square PUs and two different partitions into two rectangular PUs. A transform unit is a basic unit that is subject to spatial transformation using a DCT. A CU may be divided into TUs based on a quadtree representation 607.

[0086] Each slice is embedded in one Network Abstraction Layer (NAL) unit. Furthermore, the coding parameters of a video sequence are stored in a dedicated NAL unit called a parameter set. In HEVC and H.264 / AVC, two types of parameter set NAL units are used: first, the sequence parameter set (SPS) NAL unit, which collects all parameters that do not change during the entire video sequence. Typically, it handles coding profiles, video frame sizes, and other parameters. Second, the picture parameter set (PPS) NAL unit contains parameters that can change from one picture (or frame) of the sequence to another. HEVC also includes video parameter set (VPS) NAL units, which contain parameters that describe the overall structure of the bitstream. VPS is a new type of parameter set defined in HEVC and applies to all layers of the bitstream. A layer can contain multiple temporal sublayers, and all version 1 bitstreams are limited to a single layer. HEVC has specific layer extensions for scalability and multiview, which allow multiple layers to have a backward compatible version 1 base layer.

[0087] Fig. 2 illustrates a data communication system in which one or more embodiments of the present invention may be implemented. The data communication system includes a transmitting device, in this case a server 201, operable to transmit data packets of a data stream to a receiving device, in this case a client terminal 202, via a data communication network 200. The data communication network 200 may be a wide area network (WAN) or a local area network (LAN). Such a network may for example be a wireless network (Wifi / 802.11a or b or g), an Ethernet network, an Internet network, or a mixed network consisting of several different networks. In a particular embodiment of the present invention, the data communication system may be a digital television broadcasting system in which a server 201 transmits the same data content to several clients.

[0088] The data stream 204 provided by the server 201 may consist of multimedia data representing video and audio data. The audio and video data streams may in some embodiments of the invention be captured by the server 201 using a microphone and a camera, respectively. In some embodiments, the data streams may be stored on the server 201 or may be received by the server 201 from another data provider or may be generated at the server 201. The server 201 notably comprises an encoding unit for encoding the video and audio streams in order to provide a compressed bitstream for transmission, which is a more compact representation of the data presented as input to the encoding unit. In order to obtain a better ratio of the quality of the transmitted data to the amount of transmitted data, the compression of the video data may for example be according to the HEVC format or the H.264 / AVC format.

[0089] The client 202 receives the transmitted bitstream and decodes the reconstructed bitstream to reproduce the video image on a display device and the audio data through a loudspeaker. Although a streaming scenario is considered in the example of Fig. 2, it is understood that in some embodiments of the invention, data communication between the encoding and decoding units may be performed using a media storage device, such as, for example, an optical disk. In one or more embodiments of the invention, the video image is transmitted along with data representing a compensation offset for application to the reconstructed pixels of the image to provide filtered pixels in the final image.

[0090] 3 shows a schematic diagram of a processing device 300 adapted to carry out at least one embodiment of the present invention. The processing device 300 may be a device such as a microcomputer, a workstation or a light portable device. The device 300 comprises a communication bus 313 connected to: a central processing unit 311, such as a microprocessor, denoted CPU, a read-only memory 306, denoted ROM, for storing computer programs for carrying out the present invention, a random access memory 312, denoted RAM, for storing executable codes of the methods of the embodiments of the present invention and registers adapted to record variables and parameters necessary for carrying out the methods encoding sequences of digs, a communication interface 302 connected to a communication network 303 over which the digital data to be processed are transmitted or received.

[0091] Optionally, the device 300 may also include the following components: a data storage means 304, such as a hard disk, for storing computer programs for carrying out the methods of one or more embodiments of the present invention, and data used or generated during the carrying out of one or more embodiments of the present invention, a disk drive 305 for a disk 306, the disk drive configured to read data from the disk 306 or write data to said disk, a screen 309 for displaying data and / or providing a graphical user interface to a user by means of a keyboard 310 or any other indicating means. The device 300 may be connected to various peripherals, such as for example a digital camera 320 or a microphone 308, each connected to an input / output card (not shown) for providing multimedia data to the device 300.

[0092] The communication bus provides communication and interoperability between the various elements included in or connected to the device 300. The representation of the bus is not limiting, in particular the central processing unit is operable to communicate instructions to any element of the device 300, directly or by means of another element of the device 300. The disk 306 may be replaced by any information carrier, such as a compact disk (CD-ROM), rewritable or not, a ZIP disk or a memory card and in general terms, by an information storage means readable by a microcomputer or a microprocessor, integrated or not in the device, possibly removable, and adapted to store one or more programs whose execution enables the method of encoding a sequence of digital images and / or the method of decoding a bitstream according to the invention.

[0093] The executable code may be stored either in the read-only memory 306, in the hard disk 304 or in a removable digital medium such as for example the disk 306 as previously described. According to a variant, the executable code of the program may be received by means of the communication network 303, via the interface 302, in order to be stored in one of the storage means of the device 300 before being executed, such as the hard disk 304. The central processing unit 311 is adapted to control and direct the execution of instructions or parts of the software code of the program or programs according to the invention, instructions stored in one of the aforementioned storage means. At power-on, the program or programs stored in a non-volatile memory, for example on the hard disk 304 or on the read-only memory 306, are transferred to the random access memory 312, which then contains registers for storing the executable code of the program or programs and variables and parameters necessary to implement the invention.

[0094] In this embodiment, the device is a programmable device that uses software to implement the invention. Alternatively, however, the invention may be implemented in hardware (e.g. in the form of an application specific integrated circuit or ASIC). Figure 4 shows a block diagram of an encoding unit according to at least one embodiment of the invention. The encoding unit is represented by connected modules, each module adapted to implement at least one corresponding step of a method implementing at least one embodiment of encoding images of an image sequence according to one or more embodiments of the invention, for example in the form of program instructions to be executed by the CPU 311 of the device 300. An original sequence of digital images i0 to in401 is received as input by the encoding unit 400. Each digital image is represented by a set of samples known as pixels.

[0095] The bitstream 410 is the output by the encoder 400 after the implementation of the encoding process. The bitstream 410 comprises a number of coding units or slices, each slice comprising the slice comprising the encoded video data and a slice header for transmitting the coded values ​​of the coding parameters used to code the slice body. The input digital image i0 to in401 is divided into blocks of pixels by the module 402. The blocks correspond to image portions and may be of variable size (for example 4x4, 8x8, 16x16, 32x32, 64x64, 128x128 pixels, as well as several rectangular block sizes may be considered). A coding mode is selected for each input block. Two families of coding modes are provided, namely coding modes based on spatial predictive coding (intra prediction) and coding modes based on temporal prediction (inter coding, merge, skip). The possible coding modes are tested.

[0096] The module 403 performs an intra prediction process in which a given block to be coded is predicted by a predictor calculated from pixels in the neighborhood of said block to be coded. An indication of the selected intra predictor and the difference between the given block and its predictor are coded to provide a residual if intra coding is selected. The temporal prediction is performed by a motion estimation module 404 and a motion compensation module 405. First, a reference image is selected from the set of reference images 416, and a portion of the reference image, also called reference region or image portion, which is the region closest to the given block to be coded, is selected by the motion estimation module 404. The motion compensation module 405 then predicts the block to be coded using the selected region. The difference between the selected reference region and the given block, also called residual block, is calculated by the motion compensation module 405. The selected reference region is indicated by a motion vector.

[0097] Thus, in both cases (spatial and temporal prediction), the residual is calculated by subtracting the prediction from the original block. In intra prediction, implemented by module 403, the prediction direction is coded. In temporal prediction, at least one motion vector is coded. If inter prediction is selected, the motion vector and information for the residual block are coded. To further reduce the bit rate, assuming that the motion is homogenous, the motion vector is coded by a difference to a motion vector predictor. A motion vector predictor of the motion information predictor set is obtained from a motion vector field 418 by a motion vector prediction and coding module 417. The coding unit 400 further comprises a selection module 406 for coding mode selection by applying a coding cost criterion, such as a rate-distortion criterion. To further reduce redundancy, a transform (such as a DCT) is applied to the residual block by a transform module 407, and the resulting transformed data is quantized by a quantization module 408 and entropy coded by an entropy coding module 409. Finally, the coded residual block of the current block being coded is inserted into the bitstream 410.

[0098] The coding unit 400 also performs decoding of the coded image to generate reference images for motion estimation of subsequent images. This allows the coding unit and the decoding unit receiving the bitstream to have the same reference frame. The inverse quantization module 411 performs inverse quantization of the quantized data, followed by inverse transformation by the inverse transformation module 412. The backward intra prediction module 413 uses the prediction information to determine which predictor to use for a given block, and the backward motion compensation module 414 actually adds the residual obtained by the module 412 to a reference region obtained from a set of reference images 416. Then, post-filtering is applied by the module 415 to filter the frame of reconstructed pixels. In an embodiment of the present invention, a SAO loop filter is used, in which a compensation offset is added to the pixel values ​​of the reconstructed pixels of the reconstructed image.

[0099] Fig. 5 shows a block diagram of a decoding unit 60 that may be used to receive data from an encoding unit according to an embodiment of the present invention. The decoding unit is represented by connected modules, each module adapted to implement a corresponding step of a method implemented by the decoding unit 60, for example in the form of program instructions executed by the CPU 311 of the device 300. The decoding unit 60 receives a bitstream 61 containing coding units, each consisting of a header containing information about the coding parameters and a body containing the coded video data. As explained with respect to Fig. 4, the coded video data is entropy coded, and the index of the motion vector predictor is coded with a predefined number of bits for a given block. The received coded video data is entropy decoded by a module 62. The residual data is then inverse quantized by a module 63 and then an inverse transform is applied by a module 64 to obtain pixel values.

[0100] The mode data indicating the coding mode is also entropy decoded and, based on the mode, intra-type decoding or inter-type decoding is performed on the coded block of image data. In the case of intra mode, an intra predictor is determined by the intra inverse prediction module 65 based on the intra prediction mode specified in the bitstream. If the mode is inter, motion prediction information is extracted from the bitstream to find the reference region to be used by the encoder. The motion prediction information consists of a reference frame index and a motion vector residual. The motion vector predictor is added to the motion vector residual to obtain a motion vector by the motion vector decoding module 70.

[0101] The motion vector decoding module 70 applies motion vector decoding for each current block coded by motion prediction. For the current block, the index of the motion vector predictor is used by the module 66 to apply backward motion compensation once the actual value of the motion vector related to the current block that can be decoded is obtained. The reference image portion indicated by the decoded motion vector is extracted from the reference image 68 to apply the backward motion compensation 66. The motion vector field data 71 is updated with the decoded motion vector for use in the inverse prediction of the subsequent decoded motion vector. Finally, the decoded block is obtained. Post filtering is applied by the post filtering module 67. The decoded video signal 69 is finally provided by the decoding unit 60.

[0102] (CABAC) HEVC uses several kinds of entropy coding, such as Context-Adaptive Binary Arithmetic Coding (CABAC), Golomb-Rice coding, or a simple binary representation called fixed-length coding. In most cases, a binary coding process is performed to represent the different syntax elements. This binary coding process is also very specific and depends on the different syntax elements. Arithmetic coding represents syntax elements according to their current probability. CABAC is an extension of arithmetic coding that separates the probability of syntax elements depending on a "context" defined by a context variable. This corresponds to a conditional probability. The context variable can be derived from the current syntax values ​​of the already coded top-left block (A2 in Fig. 6b, as explained in more detail below) and the top-left block (B3 in Fig. 6b).

[0103] CABAC has been adopted as a reference part of the H.264 / AVC and H.265 / HEVC standards. In H.264 / AVC, it is one of two alternative methods of entropy coding. The other method specified in H.264 / AVC is a low-complexity entropy coding technique based on the use of a context-adaptive switching set of variable-length codes, the so-called Context-Adaptive Variable-Length Coding (CAVLC). Compared to CABAC, CAVLC offers reduced implementation costs at the expense of lower compression efficiency. For TV signals with standard or high definition resolution, CABAC typically offers 10 to 20% bitrate savings over CAVLC at the same target video quality. In HEVC, CABAC is the only entropy coding method. Figure 17 shows the main blocks of the CABAC encoder.

[0104] Input syntax elements that are non-binary values ​​are binarized by a binarizer 1701. The coding strategy of CABAC is based on the exploration that highly efficient coding of syntax element values ​​in hybrid block-based video coders, such as components of motion vector differences or transform coefficient level values, can be achieved by using a binarization scheme as a kind of pre-processing unit for the subsequent stages of context modeling and binary arithmetic coding. In general, a binarization scheme defines a unique mapping of syntax element values ​​into sequences of binary decisions, so-called bins, which can also be interpreted in terms of a binary code tree. The design of the binarization scheme in CABAC is based on a small number of elementary prototypes whose structure allows for online computation and which are adapted to some suitable model probability distributions.

[0105] Each bin can be processed in one of two basic ways, depending on the setting of switch 1702. When the switch is in the "normal" setting, the bin is provided to a context modeller 1703 and a normal coding engine 1704. When the switch is in the "bypass" setting, the context modeller is bypassed and the bin is provided to a bypass coding engine 1705. Another switch 1706 has similar "normal" and "bypass" settings as switch 1702, so that the bins coded by the applicable one of coding engines 1704 and 1705 can form a bitstream as the output of the CABAC coding unit.

[0106] By decomposing each syntax element value into a sequence of bins, the further processing of each bin value in CABAC depends on the associated coding mode decision, which can be selected as either normal or bypass mode. The latter is selected for bins associated with code information, or for lower significant bins that are assumed to be uniformly distributed, and consequently, all regular binary arithmetic coding processing is simply bypassed. In normal coding mode, each bin value is coded by using a normal binary arithmetic coding engine, where the associated probability model is determined either by a fixed selection without any context modeling, or adaptively selected depending on the associated context model. As an important design decision, the latter case is generally applied only to the most frequently observed bins, while the other, less frequently observed bins are usually processed using a joint, typically zero-order probability model. Thus, CABAC allows selective context modeling at the sub-symbol level, thereby providing an efficient means to exploit inter-symbol redundancy with significantly reduced overall modeling or training costs. For a particular choice of context model, four basic design types are used in CABAC, two of which apply to coding only at the transform coefficient level: The design of these four prototypes is based on a priori knowledge of the typical characteristics of the source data to be modeled, and it reflects the objective of finding a good compromise between the competing objectives of avoiding unnecessary modeling cost overhead and exploiting statistical dependencies to a large extent.

[0107] At the lowest level of processing in CABAC, each bin value enters a binary arithmetic coding unit in either normal or bypass coding modes. For the latter, a fast branch of the coding engine with significantly reduced complexity is used, while for the former coding modes, the coding of a given bin value depends on the actual state of the associated adaptive probability model (the term chosen for the table-based binary arithmetic coding engine in CABAC) which is passed along with the bin value to the M-coder.

[0108] HEVC uses three different inter modes: inter mode, merge mode, and merge skip mode. The main difference between these modes is the data signaling in the bitstream. For motion vector coding, the current HEVC standard includes a contention-based scheme for motion vector prediction, which did not exist in previous versions of the standard. This means that several candidates are competing with the distortion rate criterion at the encoder side to find the best motion vector predictor or best motion information for each inter or merge mode. An index corresponding to the best candidate for the best predictor or 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 composited index. In the screen content extension of HEVC, a new coding tool called intra block copy is signaled as any of those three inter modes, and the difference between IBC and the equivalent inter mode is done by checking if the reference frame is the current one. This can be implemented, for example, by checking the reference index of list L0 and inferring that if this is the last frame in that list, this is an intra block copy. Another way to implement is comparing the current picture order count with the reference frame: if they are equal, then this is an intra block copy.

[0109] The design of predictor and candidate derivation is important to achieve the best coding efficiency without disproportionately affecting the complexity. In HEVC, two motion vector derivations are used, one for inter mode (Advanced Motion Vector Prediction (AMVP)) and one for merge mode (merge derivation process). These processes are described below. Figure 6a and Figure 6b show spatial and temporal blocks that can be used to generate motion vector predictors in Advanced Motion Vector Prediction (AMVP) and merge modes of the HEVC encoding and decoding system, and Figure 7 shows simplified steps of the process of AMVP predictor set derivation.

[0110] Two predictors, i.e., two spatial motion vectors in AMVP mode, are selected from the top block (indicated by the letter "B") and the left block (indicated by the letter "A"), including the top corner block (block B2) and the left corner block (block A0), and one predictor is selected from the bottom right block (H) and the center block (center) of the blocks arranged as shown in Figure 6a. Table 1 below outlines the nomenclature used when referring to blocks in terms relative to the current block, as shown in Figures 6a and 6b. This nomenclature is used as a shorthand notation, but it should be understood that other labeling systems may be used, especially in future versions of the standard.

[0111] [Table 1]

[0112] It should be noted that the "current block" may be variable in size, e.g., 4x4, 16x16, 32x32, 64x64, 128x128, or any size in between. The dimensions of the block are preferably a factor of two (i.e., 2^n x 2^m, where n and m are positive integers), as this results in a more efficient use of bits when using binary encoding. The current block does not have to be square, but this is often the preferred embodiment for encoding complexity. Referring to Figure 7, the first step aims to select a first spatial predictor (candidate 1, 706) from among the bottom left blocks A0 and A1, whose spatial location is shown in Figure 6. To that end, these blocks are selected one after the other in a predefined order (700, 702), and for each selected block, the following conditions are evaluated in a predefined order (704), and the first block for which the conditions are satisfied is set as the predictor, i.e., motion vector from the same reference list and same reference picture, motion vector from the same reference picture with the other reference list, scaled motion vector from the same reference list and a different reference picture, or scaled motion vector from the other reference list and a different reference picture.

[0113] If no value is found, the left predictor is considered to be unavailable. In this case, it indicates that the relevant blocks are intra-coded or do not exist. The next step aims to select a second spatial predictor (candidate 2, 716) from among the top right block B0, the top block B1, and the top left block B2, whose spatial positions are shown in Fig. 6. For that purpose, these blocks are selected one after the other in a predetermined order (708, 710, 712), and for each selected block, the above conditions are evaluated in a predetermined order (714), and the first block for which the above conditions are satisfied is set as the predictor.

[0114] Again, if no value is found, the upper predictor is considered unavailable. In this case, it indicates that the relevant block is intra-coded or that they do not exist. In the next step (718), the two predictors are compared with each other if both are available, in order to eliminate one of them if they are equal (i.e., same motion vector value, same reference list, same reference index, and same direction type). If only one spatial predictor is available, the algorithm looks for a temporal predictor in the next step. The temporal motion predictor (Candidate 3, 726) is derived as follows: the bottom right (H, 720) position of the located block in the previous frame is first considered in the availability check module 722. If it does not exist or if the motion vector predictor is not available, the center (Center, 724) of the located block is selected to be checked. These temporal positions (Center and H) are shown in FIG. 6. In either case, scaling 723 is applied to those candidates so that the temporal distance between the current frame and the first frame matches that of the reference list.

[0115] The motion predictor value is then added to the set of predictors. The number of predictors (Nb_Cand) is then compared (728) to the maximum number of predictors (Max_Cand). As mentioned above, the maximum number of motion vector predictors that the AMVP derivation process needs to generate (Max_Cand) is 2 in the current version of the HEVC standard. If this maximum number is reached, a final list or set of AMVP predictors (732) is constructed. If not, a zero predictor is added (730) to the list. A zero predictor is a motion vector equal to (0,0). As shown in FIG. 7, the final list or set of AMVP predictors (732) is constructed from a subset of spatial motion predictors (700-712) and a subset of temporal motion predictors (720, 724).

[0116] As mentioned above, a motion predictor candidate for merge or merge skip mode represents all the necessary motion information: direction, list, reference frame index and motion vector. An indexed list of multiple candidates is generated by the merge derivation process. In the current HEVC design, the maximum number of candidates for both merge modes is equal to 5 (4 spatial candidates and 1 temporal candidate). Figure 8 is a schematic diagram of the motion vector derivation process for merge mode. In the first step of the derivation process, five block positions are considered (800-808). These positions are the spatial positions shown in Figure 3 with the references A1, B1, B0, A0 and B2. In the next step, the availability of spatial motion vectors is checked and at most five motion vectors are selected (810). If it exists and if the block is not intra-coded, the predictor is considered to be available. Thus, the selection of the motion vectors corresponding to the five blocks as candidates is done according to the following conditions, namely:

[0117] If the "left" A1 motion vector (800) is available (810), i.e. if it exists and this block is not intra-coded, the "left" block motion vector is selected and used as the first candidate in the candidate list (814); if the "top" B1 motion vector (802) is available (810), the candidate "top" block motion vector is compared to the "left" A1 motion vector, if it exists (812). If the B1 motion vector is equal to the A1 motion vector, B1 is not added to the list of spatial candidates (814). Conversely, if the B1 motion vector is not equal to the A1 motion vector, B1 is added to the list of spatial candidates (814); if the "top right" B0 motion vector (804) is available (810), the "top right" motion vector is compared to the B1 motion vector (812). If the B0 motion vector is equal to the B1 motion vector, the B0 motion vector is not added to the list of spatial candidates (814). Conversely, if the B0 motion vector is not equal to the B1 motion vector, then the B0 motion vector is added to the list of spatial candidates (814);

[0118] If the "bottom left" A0 motion vector (806) is available (810), the "bottom left" motion vector is compared with the A1 motion vector (812). If the A0 motion vector is equal to the A1 motion vector, the A0 motion vector is not added to the list of spatial candidates (814). Conversely, if the A0 motion vector is not equal to the A1 motion vector, the A0 motion vector is added to the list of spatial candidates (814), and if the list of spatial candidates does not contain four candidates, the availability of the "top left" B2 motion vector (808) is checked (810). If available, it is compared with the A1 and B1 motion vectors. If the B2 motion vector is equal to the A1 or B1 motion vector, the B2 motion vector is not added to the list of spatial candidates (814). Conversely, if the B2 motion vector is not equal to the A1 or B1 motion vector, the B2 motion vector is added to the list of spatial candidates (814).

[0119] At the end of this stage, the list of spatial candidates contains up to four candidates. For temporal candidates, two positions can be used: the bottom right position of the located block (816, indicated by H in FIG. 6) and the center of the located block (818). These positions are shown in FIG. 6. For the AMVP motion vector derivation process, the first step aims to check the availability of a block in the H position (820). Then, if it is not available, the availability of a block in the center position is checked (820). If at least one motion vector of these positions is available, the temporal motion vector can be scaled (822) to the reference frame with index 0, if necessary, for both lists L0 and L1, to create a temporal candidate (824) that is added to the list of merge motion vector predictor candidates. It is placed after the spatial candidate in the list. Lists L0 and L1 are two reference frame lists that contain zero, one or more reference frames.

[0120] If the number of candidates (Nb_Cand) is strictly less than the maximum number of candidates (826) (the value Max_Cand is signaled in the bitstream slice header and is equal to 5 in the current HEVC design) and if the current frame is of type B, a combined candidate is generated (828). The combined candidate is generated based on the available candidates of the list of merge motion vector predictor candidates. It mainly consists of combining the motion vector of one candidate of list L0 with the motion vector of one candidate of list L1. If the number of candidates (Nb_Cand) remains strictly less than the maximum number of candidates (Max_Cand) (830), zero motion candidates are generated (832) until the number of candidates of the merge motion vector predictor candidate list reaches the maximum number of candidates.

[0121] At the end of this process, a list or set of merge motion vector predictor candidates is constructed (834). As shown in Figure 8, the list or set of merge motion vector predictor candidates is constructed (834) from a subset of spatial candidates (800-808) and a subset of temporal candidates (816, 818).

[0122] (Alternative Temporal Motion Vector Prediction (ATMVP)) Alternative Temporal Motion Vector Prediction (ATMVP) is a specific motion compensation. Instead of considering only one motion information for the current block from the temporal reference frame, each motion information of the respectively located blocks is considered. This temporal motion vector prediction thus gives the partition of the current block together with the associated motion information of each sub-block as shown in Figure 9. In the current VTM reference software, ATMVP is conveyed as a merge candidate inserted in the list of merge candidates. When ATMVP is enabled at the SPS level, the maximum number of merge candidates is increased by one. Thus, 6 candidates are considered instead of 5 when this mode is disabled.

[0123] Furthermore, when this prediction is enabled at the SPS level, all bins of the merge index become context coded by CABAC. While in HEVC or when ATMVP is not enabled at the SPS level, only the first bin is a coded context and the remaining bins are bypass coded contexts. Figure 10(a) shows the coding of the merge index for HEVC or when ATMVP is not enabled at the SPS level. This corresponds to unary maximal coding. Furthermore, the first bit is CABAC coded and the other bits are bypass CABAC coded. Figure 10(b) shows the coding of the merge index when ATMVP is enabled at the SPS level. Furthermore, all bits are CABAC coded (from the first to the fifth bit). Note that each index has its own context, in other words, their probabilities are separated.

[0124] (Affine mode) In HEVC, only the translational motion model is applied for motion compensated prediction (MCP). Meanwhile, in the real world, there are many types of motion, e.g. zoom in / zoom out, rotation, perspective motion, and other irregular motions. In JEM, a simplified affine transformation motion compensated prediction is applied, and the general principle of the affine mode is described below based on an extract from document JVET-G1001 presented at the JVET Conference in Turin on July 13-21, 2017. This entire document is incorporated herein by reference, as it describes other algorithms used in JEM. As shown in Figure 11(a), the affine motion field of a block is described by two control point motion vectors. The motion vector field (MVF) of a block is described by the following equation:

[0125]

number

[0126] Here, (v 0x , v 0y ) is the motion vector of the control point in the upper left corner, and (v 1x , v 1y ) is the motion vector of the control point in the upper right corner. To further simplify the motion compensation prediction, sub-block-based affine transformation prediction is applied. The sub-block size is derived as in Equation 2, where MvPre is the motion vector fractional precision (1 / 16 in JEM), and (v2x, v2y) is the motion vector of the bottom-left control point calculated according to Equation 1.

[0127]

number

[0128] After being derived by Equation 2, M and N may be adjusted downwards, if necessary, to be divisors of w and h, respectively. To derive the motion vectors of each M×N subblock, the motion vector of the center sample of each subblock is calculated according to Equation 1 and rounded up to 1 / 16 fractional precision, as shown in FIG. 6a. Then, a motion compensation interpolation filter is applied to generate a prediction of each subblock with the derived motion vector. Affine mode is a motion compensation mode as an inter mode (AMVP, merge, merge skip). Its principle is to generate one motion information per pixel according to two or three neighboring motion information. In the current VTM reference software, the affine mode derives one motion information per 4×4 block, as shown in FIG. 11(a). This mode is available for AMVP and both merge modes are enabled by a flag. This flag is CABAC coded. In one embodiment, the context depends on the sum of the affine flags of the left block (position A2 in FIG. 6b) and the top-left block (position B3 in FIG. 6b).

[0129] Thus, in JEM, there can be three context variables (0, 1 or 2) for the affine flag given by the following formula: Ctx = IsAffine(A2) + IsAffine(B3) Here, IsAffine(block) is a function that returns 0 if the block is not an affine block and 1 if the block is affine.

[0130] (Affine merge candidate derivation) In JEM, the affine merge mode (merge or merge skip) is derived from the first neighboring block that is affine between blocks at positions A1, B1, B0, A0, B2. These positions are shown in Figures 6a and 6b. However, how the affine parameters are derived is not fully defined, and the present invention aims to improve at least in this respect.

[0131] (Affine Merge Transfer) FIG. 12 is a flow chart of a partial decoding process of some syntax elements related to coding modes. In this figure, the skip flag (1201), prediction mode (1211), merge flag (1203), merge index (1208), and affine flag (1207) may be decoded. For all CUs in an inter slice, the skip flag is decoded (1201). If the CU is not skip (1202), the pred mode (prediction mode) is decoded (1211). This syntax element indicates whether the current CU is in inter or intra mode. Note that if the CU is skip (1202), its current mode is inter mode. For a CU (1212), the CU is coded in AMVP or in merge mode. If the CU is inter (1212), the merge flag is decoded (1203). If the CU is a merge (1204) or a skip (1202), it is verified whether the affine flag (1206) needs to be decoded (1205). If the current CU is a 2Nx2N CU, which means that the height and width of the CU must be equal in the current VVC, then this flag is decoded.

[0132] Furthermore, at least one neighboring CU A1 or B1 or B0 or ​​A0 or B2 must be coded in affine mode (merge or AMVP). Finally, the current CU must not be a 4x4 CU, and by default CU 4x4 is disabled in the VTM reference software. If this condition (1205) is false, it is ensured that the current CU is coded in classical merge or merge skip mode, and the merge index is decoded (1208). If the affine flag (1206) is set equal to 1 (1207), the CU is a merge affine or merge skip affine CU, and the merge index (1208) does not need to be decoded. Otherwise, the current CU is a classical (basic) merge or merge skip CU, and the merge index candidate (1208) is decoded. Otherwise, the current CU is a classical (basic) merge or merge skip CU, and the merge index candidate (1208) is decoded. In this specification, "signaling" may refer to the insertion into or extraction from the bitstream of one or more syntax elements that represent the enabling or disabling of mode or other information.

[0133] (Merge candidate derivation) Figure 13 is a flow chart showing the merge candidate derivation. This derivation builds on the HEVC merge list derivation shown in Figure 8. The main changes compared to HEVC are the addition of ATMVP candidates (1319, 1321, 1323), the full overlap check of candidates (1320, 1325), and the new order of the candidates. The ATMVP prediction is set as a special candidate since it represents some motion information of the current CU. The value of the first subblock (top left) is compared with the temporal candidate, and the temporal candidate is not added to the merge list if they are equal (1320). The ATMVP candidate is not compared with other spatial candidates. Contrary to the temporal candidate, which is compared with each spatial candidate already in the list (1325), it is not added to the merge candidate list if it is an overlap candidate.

[0134] When a spatial candidate is added to the list, it is compared with other spatial candidates in the list which is not the case in the final version of HEVC (1310). In the current VTM version, the list of merge candidates is set as the following order, as it is determined to provide the best results across the coding test conditions: A1 B1 B0 A0 ·ATMVP B2 ·Temporal ·combination ·Zero_MV

[0135] It is important to note that spatial candidates B2 are set after the ATMVP candidates. Furthermore, if ATMVP is enabled at the slice level, the maximum number of candidate lists is 6 instead of 5. Note that embodiments may be combined unless otherwise stated, e.g., certain combinations of embodiments may improve coding efficiency at the expense of increased complexity, which may be acceptable in certain usage scenarios.

[0136] (First embodiment) As mentioned above, in the current VTM reference software, ATMVP is conveyed as a merge candidate inserted into the list of merge candidates. ATMVP can be enabled or disabled for the entire sequence (at the SPS level). If ATMVP is disabled, the maximum number of merge candidates is 5. If ATMVP is enabled, the maximum number of merge candidates is increased by one, from 5 to 6. At the encoder, the merge candidate list is generated using the method of Figure 13. One merge candidate is selected from the list of merge candidates based on, for example, a rate-distortion criterion.

[0137] In the current VTM reference software, the merge index is encoded differently depending on whether ATMVP is enabled or disabled. Figure 10(a) shows the encoding of the merge index when ATMVP is not enabled at the SPS level. The five merge candidates, i.e., Cand0, Cand1, Cand2, Cand3, and Cand4, are encoded as 0, 10, 110, 1110, and 1111, respectively. This corresponds to unary maximal encoding. Furthermore, the first bit is encoded by CABAC using a single context, and the other bits are bypass encoded. Figure 10(b) shows the encoding of the merge index when ATMVP is enabled. The six merge candidates, i.e., Cand0, Cand1, Cand2, Cand3, Cand4, and Cand5, are encoded as 0, 10, 110, 1110, 11110, and 11111, respectively. In this case, all bits of the merge index (from the first to the fifth bits) are context encoded by CABAC. Each bit has its own context and there are separate probability models for different bits.

[0138] In the first embodiment of the present invention, as shown in FIG. 14, if the list of merge candidates includes ATMVP as a merge candidate (e.g., ATMVP is enabled at the SPS level), the encoding of the merge index is modified so that only the first bit of the merge index is encoded by CABAC using a single context. The context is set in the same way in the current VTM reference software when ATMVP is not enabled at the SPS level. The other bits (2nd to 5th bits) are bypass encoded. If the list of merge candidates does not include ATMVP as a merge candidate (e.g., ATMVP is not enabled at the SPS level), there are five merge candidates. Only the first bit of the merge index is encoded by CABAC using a single context. The context is set in the same way in the current VTM reference software when ATMVP is not enabled at the SPS level. The other bits (2nd to 4th bits) are bypass encoded.

[0139] The decoder generates the same merge candidate list as the encoder. This can be achieved by using the method of Fig. 13. If ATMVP is not included as a merge candidate in the list of merge candidates (e.g., ATMVP is not enabled at SPS level), there are five merge candidates. Only the first bit of the merge index is decoded by CABAC using a single context. The other bits (bits 2 to 4) are bypass coded. Contrary to the current reference software, if ATMVP is included as a merge candidate in the list of merge candidates (e.g., ATMVP is enabled at SPS level), only the first bit of the merge index is decoded by CABAC using a single context in decoding the merge index. The other bits (bits 2 to 5) are bypass coded. The decoded merge index is used to identify the merge candidate selected by the encoder from the list of merge candidates.

[0140] The advantage of this embodiment compared to the VTM2.0 reference software is the merge index decoding and reduced complexity of the decoder design (and encoder design) without impacting the coding efficiency. Indeed, with this embodiment, only one CABAC state is needed for the merge index instead of five for the current VTM merge index coding / decoding. Furthermore, it reduces the worst case complexity since other bits are bypassed CABAC coded which reduces the number of operations compared to CABAC coding all bits.

[0141] Second embodiment In the second embodiment, all bits of the merge index are CABAC coded, but they all share the same context. In this case, there may be a single context as in the first embodiment, shared between the bits. As a result, if the merge candidate list includes ATMVP as a merge candidate (e.g., ATMVP is enabled at the SPS level), only one context is used, compared to 5 in the VTM2.0 reference software. The advantage of this embodiment compared to the VTM2.0 reference software is the merge index decoding and reduced complexity of the decoder design (and encoder design) without impacting the coding efficiency. Alternatively, as described below in connection with the third to fifteenth embodiments, the context variables may be shared between the bits, such that more than one context is available, but the current context is shared by the bits.

[0142] If ATMVP is disabled, the same context is still used for all bits. This embodiment and all subsequent embodiments may be applied even if ATMVP is not an available mode or is disabled. In a variation of the second embodiment, any two or more bits of the merge index are CABAC coded and share the same context. The other bits of the merge index are bypass coded. For example, the first N bits of the merge index may be CABAC coded, where N is 2 or more.

[0143] Third embodiment In the first embodiment, the first bit of the merge index was CABAC coded using a single context. In the third embodiment, the context variable of the bit of the merge index depends on the value of the merge index of the neighboring block. This estimates one or more contexts for the target bit, with each context corresponding to a different value of the context variable. The neighboring block may be any block already decoded, such that its merge index is available to the decoder by the time the current block is being decoded. For example, the neighboring block may be any of the blocks A0, A1, A2, B0, B1, B2, and B3 shown in FIG. 6b.

[0144] In a first variant, only the first bit is CABAC coded using this context variable. In a second variant, the first N bits of the merge index, where N is 2 or more, are CABAC coded and a context variable is shared between those N bits. In a third variant, any N bits of the merge index, where N is 2 or more, are CABAC coded and a context variable is shared between those N bits. In a fourth variant, the first N bits of the merge index, where N is 2 or more, are CABAC coded and N context variables are used for those N bits. Assuming that the context variable has K values, KxN CABAC states are used. For example, in this embodiment, with one adjacent block, the context variable can advantageously have two values, e.g. 0 and 1. That is, 2N CABAC states are used. In a fifth variant, any N bits of the merge index, where N is 2 or more, are adaptive PM coded and N context variables are used for those N bits. Similar modifications are applicable to the fourth to sixteenth embodiments described below.

[0145] (Fourth embodiment) In the fourth embodiment, the context variable for the bits of the merge index depends on the respective values ​​of the merge index of two or more adjacent blocks. For example, the first adjacent block may be the left block A0, A1 or A2, and the second adjacent block may be the top block B0, B1, B2 or B3. The manner in which the two or more merge index values ​​are combined is not particularly limited. An example is given below. The context variable can conveniently have three different values, for example 0, 1 and 2, in this case, since there are two adjacent blocks. Thus, if the fourth variant described in connection with the third embodiment is applied to this embodiment with three different values, K is 3 instead of 2. That is, 3N CABAC states are used.

[0146] Fifth embodiment In the fifth embodiment, the context variable of a bit of a merge index depends on the respective values ​​of the merge indexes of neighboring blocks A2 and B3.

[0147] Sixth embodiment In the sixth embodiment, the context variable of a bit of a merge index depends on the respective values ​​of the merge index of the neighboring blocks A1 and B1. An advantage of this variant is the alignment with the merge candidate derivation.

[0148] Seventh embodiment In the seventh embodiment, the context variable for the bit having bit position idx_num in the merge index of the current block is obtained according to the following formula: ctxIdx = (Merge_index_left == idx_num) + (Merge_index_up == idx_num), where Merge_index_left is the merge index of the left block, Merge_index_up is the merge index of the upper block, and the symbol == is the equality symbol. If there are six merge candidates, for example, 0 <= idx_num <= 5. The left block may be block A1 and the upper block may be block B1 (as in the sixth embodiment). Alternatively, the left block may be block A2 and the upper block may be block B3 (as in the fifth embodiment). If the merge index of the left block is equal to idx_num, then the formula (Merge_index_left == idx_num) is equal to 1. Table 2 below shows the result of this formula (Merge_index_left == idx_num).

[0149] [Table 2]

[0150] Of course, the table of the formula (Merge_index_up == idx_num) is the same. The unary maximum code of each merge index value and the relative bit position of each bit are given in Table 3 below. This Table 3 corresponds to Figure 10(b).

[0151] [Table 3]

[0152] If the left block is not a merge block or an affine merge block, the left block is considered unavailable. Similar conditions apply for the top block. For example, if only the first bit is CABAC coded, the context variable ctxIdx is set equal to 0 if the left and top blocks do not have a merge index or if the left block merge index is not the first index (i.e., not 0) and the top block merge index is not the first index (i.e., not 0), 1 if one but not the other of the left and top blocks has its merge index equal to the first index, and 2 if the merge index for each of the left and top blocks is equal to the first index. More generally, for a target bit at position idx_num to be CABAC coded, the context variable ctxIdx is set to 0 if the left and top blocks have no merge index or if the left block merge index is not the ith index (where i=idx_num) and the top block merge index is not the ith index, 1 if one but not the other of the left and top blocks has a merge index equal to the ith index, 2 if for each of the left and top blocks the merge index is equal to the ith index, where the ith index means the first index for i=0, the second index for i=1, etc.

[0153] Eighth embodiment In the eighth embodiment, the context variable of the bit having the bit position idx_num in the merge index of the current block is obtained according to the following formula: Ctx = (Merge_index_left > idx_num) + (Merge_index_up > idx_num), where Merge_index_left is the merge index for the left block, Merge_index_up is the merge index for the top block, and the symbol > means "greater than". If there are six merge candidates, for example, 0 <= idx_num <= 5. The left block may be block A1 and the top block may be block B1 (as in the fifth embodiment). Alternatively, the left block may be block A2 and the top block may be block B3 (as in the sixth embodiment). If the merge index of the left block is greater than idx_num, the formula (Merge_index_left > idx_num) is equal to 1. If the left block is not a merge block or an affine merge block, the left block is considered unavailable. A similar condition applies for the top block. Table 4 below gives the result of this formula (Merge_index_left > idx_num).

[0154] [Table 4]

[0155] For example, if only the first bit is CABAC coded, the context variable ctxIdx is set equal to 0 if the left and top blocks have merge indices or if the left block merge index is less than or equal to the first index (i.e., non-zero) and the top block merge index is less than or equal to the first index (i.e., non-zero), 1 if one but not the other of the left and top blocks has a merge index greater than the first index, 2 if for each of the left and top blocks the merge index is greater than the first index. More generally, for a target bit at position idx_num to be CABAC coded, the context variable ctxIdx is set equal to 0 if the left and top blocks do not have merge indices or if the left block merge index is less than the i-th index (where i=idx_num) and the top block merge index is less than or equal to the i-th index, 1 if one but not the other of the left and top blocks has its merge index greater than the i-th index, 2 if for each of the left and top blocks the merge index is greater than the i-th index. The eighth embodiment provides a further improvement in coding efficiency over the seventh embodiment.

[0156] Ninth embodiment In the fourth to eighth embodiments, the context variable of the bit of the merge index of the current block depends on the respective values ​​of the merge index of the two or more neighboring blocks. In the ninth embodiment, the context variable of the bit of the merge index of the current block depends on the respective merge flag of the two or more neighboring blocks. For example, the first neighboring block may be the left block A0, A1 or A2, and the second neighboring block may be the top block B0, B1, B2 or B3. The merge flag is set to 1 if the block is coded using the merge mode, and is set to 0 for another mode such as skip mode or affine merge mode. Note that in VMT2.0, affine merge is a separate mode from the basic or "classical" merge mode. The affine merge mode may be signaled using a dedicated affine flag. Alternatively, the merge candidate list may include affine merge candidates, in which case the affine merge mode may be selected and signaled using the merge index.

[0157] The context variable is then set to 0 if neither the left nor the top neighboring block has its merge flag set to 1, 1 if one but not the other of the left and right neighboring blocks has its merge flag set to 1, and 2 if each of the left and top neighboring blocks has its merge flag set to 1. This simple measure achieves improved coding efficiency over VTM2.0. Another advantage is the lower complexity, since compared to the seventh and eighth embodiments, only the merge flags and not the merge indexes of the neighboring blocks need to be checked. In a variant, the context variable for the bit of the merge index of the current block depends on the merge flag of a single neighboring block.

[0158] Tenth embodiment In the third to ninth embodiments, the context variable for the merge index bit of the current block depends on the merge index value or merge flag of one or more neighboring blocks. In the tenth embodiment, the context variable for the merge index bit of the current block depends on the value of the skip flag for the current block (current coding unit, or CU). The skip flag is equal to 1 if the current block uses the merge skip mode, and equal to 0 otherwise. The skip flag is a first example of another variable or syntax element that has already been decoded or parsed for the current block. This other variable or syntax element is preferably an indication of the complexity of the motion information in the current block. Since the occurrence of the merge index value depends on the complexity of the motion information, a variable or syntax element such as the skip flag generally correlates with the merge index value.

[0159] More specifically, the merge skip mode is generally chosen for static scenes or scenes with constant motion. As a result, the merge index value is generally lower in the merge skip mode than in the classical merge mode used to code the inter prediction including block residuals. This generally occurs for more complex motion. However, the choice between these modes is often also related to quantization and / or RD criteria. This simple measure offers improved coding efficiency over VTM2.0. It is also very easy to implement, since it does not involve checking neighboring blocks or merge index values. In a first variant, the context variable of the bit of the merge index of the current block is simply set equal to the skip flag of the current block. The bit may be the first bit only. The other bits are bypass coded as in the first embodiment. In a second variant, all bits of the merge index are CABAC coded, each of them having its own context variable depending on the merge flag. This requires 10 probability states in the case that there are 5 CABAC coded bits in the merge index (corresponding to 6 merge candidates).

[0160] In a third variant, in order to limit the number of states, only N bits of the merge index are CABAC coded, where N is 2 or more, e.g., the first N bits. This requires 2N states. For example, if the first two bits are CABAC coded, four states are required. In general, instead of the skip flag, it is possible to use any other variable or syntax element that has already been decoded or analyzed for the current block and is an indicator of the complexity of the motion information in the current block.

[0161] Eleventh embodiment The eleventh embodiment relates to the affine merge propagation described above with reference to Fig. 11(a), Fig. 11(b) and Fig. 12. In the eleventh embodiment, the context variable of the CABAC coded bit of the merge index of the current block (current CU) depends on the affine merge candidate, if any, in the list of merge candidates. This bit may be only the first bit of the merge index or the first N bits, where N is 2 or more or any N bits. The other bits are bypass coded. Affine prediction is designed to compensate for complex motion. Therefore, the merge index for complex motion generally has a higher value than less complex motion. If the first affine merge candidate is far down the list, or if there is no affine merge candidate at all, the merge index of the current CU will likely have a small value. Therefore, it is advantageous that the context variable depends on the presence and / or position of at least one affine merge candidate in the list.

[0162] For example, the context variables may be set as follows: 1 if A1 is affine 2 if B1 is affine 3 if B0 is affine 4 if A0 is affine 5 if B2 is affine 0 if the neighboring block is not affine When the merge index of the current block is decoded or parsed, the affine flags of the merge candidates at these positions have already been checked. Therefore, no further memory accesses are required to derive the context of the merge index of the current block. This embodiment provides improved coding efficiency over VTM2.0. Since step 1205 already involves checking the neighboring CU affine modes, no additional memory accesses are required.

[0163] In a first variant, in order to limit the number of states, the context variables may be set as follows: 0 if the neighboring block is not affine or if A1 or B1 is affine, 1 if B0, A0, or B2 is affine. In a second variant, to limit the number of states, the context variables may be set as follows: 0 if the neighboring block is not affine, 1 if A1 or B1 is affine, 2 if B0, A0 or B2 is affine. In a third variation, the context variable may be set equal to: 1 if A1 is affine, 2 if B1 is affine, 3 if B0 is affine, 4 if A0 or B2 is affine, 0 if the neighboring block is not affine.

[0164] Note that these locations are already checked when the merge index is decoded or parsed, since the affine flag decoding depends on these locations, so no additional memory accesses are required to derive the merge index context that is coded after the affine flag.

[0165] Twelfth embodiment In the twelfth embodiment, signaling the affine mode includes inserting the affine mode as a candidate motion predictor. In an example of the twelfth embodiment, the affine merge (and merge skip) is signaled as a merge candidate. In that case, modules 1205, 1206, and 1207 of FIG. 12 are removed. In addition, the maximum possible number of merge candidates is incremented so as not to affect the coding efficiency of the merge mode. For example, in the current VTM version, this value is set equal to 6, so that when this embodiment is applied to the current version of the VTM, the value becomes 7. The advantage is a simplified design of the syntax elements of the merge mode, since fewer syntax elements need to be decoded. In some circumstances, coding efficiency may be observed.

[0166] Two possibilities for implementing this example are described here: the affine merge index always has the same position in the list, whatever the values ​​of the other merge MVs. The position of the candidate motion predictor indicates the confidence of its being selected, and the higher it is placed in the list (lower index value), the more likely the motion vector predictor is to be selected. In the first example, the affine merge index always has the same position in the list of merge candidates. This means having a fixed merge idx value. For example, this value may be set equal to 5, since the affine merge mode should represent complex motion that is not the most probable content. An additional advantage of this embodiment is that if the current block is parsed (only decoding / reading syntax elements, not decoding the data itself), the current block may be set as an affine block. Thus, the value may be used to determine the CABAC context of the affine flag used for AMVP. Thus, the conditional probability should be improved for this affine flag, and the coding efficiency should be better.

[0167] In the second example, an affine merge candidate is derived together with other merge candidates. In this example, a new affine merge candidate is added to the list of merge candidates. Figure 18 shows this example. Compared to Figure 13, the affine candidate is the first affine neighboring block A1, B1, B0, A0, B2 (1917). If the same condition as 1205 in Figure 12 is valid (1927), a motion vector field generated with affine parameters is generated to obtain affine candidates (1929). The list of initial candidates can have 4, 5, 6, or 7 candidates according to the use of ATMVP, temporal, and affine candidates. The order among all these candidates is important since the more likely candidates should be processed first to ensure that they are more likely to make the cut of motion vector candidates, and the preferred order is as follows, i.e., A1 B1 B0 A0 Affine Merge ATMVP B2 temporal combination Zero_MV

[0168] It is important to note that the affine merge is before the ATMVP mode, but after the four main neighboring blocks. The advantage of placing the affine merge before the ATMVP candidate, compared to placing it after the ATMVP and the temporal predictor, is the coding efficiency gain. This coding efficiency gain depends on the GOP (Group of Pictures) structure and the quantization parameter (QP) settings of each picture in the GOP. However, for the most used GOPs and QP settings, this order gives an increase in coding efficiency. A further advantage of this solution is the clean design of the merge and merge skip, both for syntax and derivation. Furthermore, the affine candidate merge index can be changed according to the availability or value (duplicate check) of the previous candidate in the list. Thus, an efficient signaling is obtained. In a further example, the affine merge index is variable according to one or several conditions.

[0169] For example, the merge index or the position in the list associated with the affine candidate varies depending on the criteria. The principle is to set a low value for the merge index corresponding to the affine merge if the affine merge has a high probability of being selected (a high value if there is a low probability of being selected). In the twelfth embodiment, the affine merge candidates have a merge index value. To improve the coding efficiency of the merge index, it is useful to make the context variable of the bits of the merge index dependent on the affine flags of the neighboring blocks and / or the current block. For example, the context variable may be determined using the following formula: ctxIdx = IsAffine(A1)+ IsAffine(B1)+ IsAffine(B0)+ IsAffine(A0)+ IsAffine(B2) The resulting context values ​​can have values ​​0, 1, 2, 3, or 4. The affine flag increases coding efficiency.

[0170] In a first variant, to include fewer neighboring blocks, ctxIdx = IsAffine(A1) + IsAffine(B1). The resulting context value may have the value 0, 1, or 2. In a second variant, also include fewer neighboring blocks, ctxIdx = IsAffine(A2) + IsAffine(B3). Again, the resulting context value may have the value 0, 1, or 2. In a third variant, do not include neighboring blocks, ctxIdx = IsAffine(current block). The resulting context value may have the value 0 or 1. Figure 16 is a flowchart of a partial encoding process of some syntax elements related to a coding mode with the third variant. In this figure, the skip flag (1601), the prediction mode (1611), the merge flag (1603), the merge index (1608), and the affine flag (1606) may be decoded. This flowchart is similar to that of Figure 12 described above, and therefore a detailed description will be omitted. The difference is that there is a merge index for the affine merge flag, which is not the case in VTM2.0: in VTM2.0, the affine flag of the current block cannot be used to get the context of the merge index, since it always has the same value "0".

[0171] Thirteenth embodiment In the tenth embodiment, the context variable for the bit of the merge index of the current block depended on the value of the skip flag for the current block (current coding unit, or CU). Instead of directly using the skip flag value to derive the context variable for the target bit of the merge index in the thirteenth embodiment, the context value for the target bit is derived from the context variable for the skip flag of the current CU. This is possible because the skip flag itself is CABAC coded and therefore has a context variable. Preferably, the context variable for the target bit of the merge index of the current CU is set equal to (copied from) the context variable for the skip flag of the current CU. The target bit may be only the first bit. The other bits are bypass coded as in the first embodiment.

[0172] The context variable of the skip flag of the current CU is derived in the manner specified in VTM2.0. The advantage of this embodiment compared to the VTM2.0 reference software is the merge index decoding and the reduced complexity of the decoder design (and the encoder design) without affecting the coding efficiency. Indeed, in this embodiment, at a minimum, only one CABAC state is needed for the merge index, instead of five for the current VTM merge index coding / decoding. Furthermore, it reduces the worst-case complexity, since other bits are bypassed CABAC coded, which reduces the number of operations compared to coding all bits with CABAC.

[0173] Fourteenth embodiment In the thirteenth embodiment, the context value of the target bit was derived from the context variable of the skip flag of the current CU. In the fourteenth embodiment, the context value of the target bit is derived from the context variable of the affine flag of the current CU. This is possible because the affine flag itself is CABAC coded and therefore has a context variable. Preferably, the context variable for the target bit of the merge index of the current CU is set equal to (copied from) the context variable for the affine flag of the current CU. The target bit may be only the first bit. The other bits are bypass coded as in the first embodiment. The context variable of the affine flag of the current CU is derived in the manner specified in VTM2.0. The advantage of this embodiment compared to the VTM2.0 reference software is the reduced complexity of the merge index decoding and the decoder design (and the encoder design) without affecting the coding efficiency. Indeed, in this embodiment, at a minimum, only one CABAC state is needed for the merge index, instead of five for the current VTM merge index coding / decoding. Furthermore, it reduces the worst-case complexity since other bits are CABAC bypass coded, which reduces the number of operations compared to coding all bits with CABAC.

[0174] Fifteenth embodiment In some of the above embodiments, the context variables had more than two values, e.g., three values ​​0, 1, and 2. However, to reduce complexity and to reduce the number of states to be processed, it is possible to limit the number of allowed context variable values ​​to two, e.g., 0 and 1. This can be achieved, for example, by changing any initial context variables that have a value of 2 to 1. In practice, this simplification has no or only limited impact on coding efficiency.

[0175] (Combination of embodiments) Any two or more of the above-mentioned embodiments may be combined. The above description has focused on encoding and decoding of a merge index. For example, a first embodiment includes generating a list of merge candidates including an ATMVP candidate, selecting one of the merge candidates in the list, and generating a merge index for the selected merge candidate using CABAC encoding, where one or more bits of the merge index are bypass CABAC encoded. In principle, the present invention may be applied to modes other than a merge mode, including generating a list of motion vector predictor (MVP) candidates, selecting one of the MVP candidates in the list, and generating an index for the selected MVP candidate. Thus, the present invention is not limited to a merge mode, and the index to be coded or decoded is not limited to a merge index. For example, in the development of VVC, it is considered that the techniques of the above-mentioned embodiments may be applied to be extended to modes other than a merge mode, such as the AMVP mode of HEVC or its equivalent in VVC. The appended claims should be interpreted accordingly.

[0176] (Implementation of an embodiment of the present invention) Fig. 20 is a schematic block diagram of a computing device 2000 for implementing one or more embodiments of the present invention. The computing device 2000 may be a device such as a microcomputer, a workstation, or a light portable device. The computing device 2000 comprises a central processing unit (CPU) 2001, such as a microprocessor, with a communication bus connected to: a random access memory (RAM) 2002 for storing executable code of the method of the present invention embodiments and registers adapted for recording variables and parameters required for implementing the method for encoding or decoding at least a part of an image according to the present invention, the memory capacity of which may be extended, for example, by an optional RAM connected to an expansion port; a read only memory (ROM) 2003 for storing a computer program for implementing the embodiment of the present invention; a network interface (NET) 2004 typically connected to a communication network over which the digital data to be processed are transmitted or received; the network interface (NET) 2004 may be a single network interface or may consist of a set of different network interfaces (e.g. wired and wireless interfaces, or different types of wired or wireless interfaces).

[0177] Data packets are written to the network interface for transmission or read from the network interface for reception under the control of a software application executing on the CPU 2001, a user interface (UI) 2005 may be used to receive input from a user or to display information to a user, a hard disk (HD) 2006 may be provided as a mass storage device, an input / output module (IO) 2007 may be used to receive / send data from / to an external device such as a video source or a display. The executable code may be stored either in the ROM 2003, in the HD 2006 or on a removable digital medium such as a disk. According to a variant, the executable code of the program may be received by means of a communication network, via the NET 2004, to be stored in one of the storage means of the communication device 2000, such as the HD 2006, before being executed. The CPU 2001 is adapted to control and direct the execution of instructions or parts of a program or software code of a program according to an embodiment of the invention, the instructions being stored in one of the aforementioned storage means. After power-on, the CPU 2001 can execute instructions for software applications, for example from the main RAM memory 2002 after these instructions have been loaded from the program ROM 2003 or the HD 2006. Such software applications, when executed by the CPU 2001, cause the steps of the method according to the present invention to be performed.

[0178] It is also understood that according to other embodiments of the invention, a decoding unit according to the aforementioned embodiment is provided in a user terminal such as a computer, a mobile phone (cell phone), a tablet or any other kind of device (e.g. a display device) capable of providing / displaying content to a user. According to yet another embodiment, an encoding unit according to the aforementioned embodiment is provided in an image capture device that also comprises a camera, a video camera or a network camera (e.g. a closed circuit television or a video surveillance camera) that captures and provides content for the encoding unit to encode. Two such examples are provided below with reference to figures 20 and 21.

[0179] FIG. 20 is a diagram showing a network camera system 2100 including a network camera 2102 and a client device 2104. The network camera 2102 includes an imaging unit 2106, an encoding unit 2108, a communication unit 2110, and a control unit 2112. The network camera 2102 and the client device 2104 are interconnected so as to be able to communicate with each other via a network 200. The imaging unit 2106 includes a lens and an imaging element (e.g., a charge-coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS)), captures an image of a subject, and generates image data based on the image. The image may be a still image or a video image. The imaging unit may also include zoom means and / or pan means adapted to zoom or pan (either optically or digitally), respectively. The encoding unit 2108 encodes the image data using the encoding method described in the first to fifth embodiments. The encoding unit 2108 uses at least one of the encoding methods described in the first to fifth embodiments. For another example, the encoding unit 2108 can use a combination of the encoding methods described in the first to fifth embodiments.

[0180] The communication unit 2110 of the network camera 2102 transmits the encoded image data encoded by the encoding unit 2108 to the client device 2104. Furthermore, the communication unit 2110 receives a command from the client device 2104. The command includes a command for setting a parameter for encoding by the encoding unit 2108. The control unit 2112 controls other units in the network camera 2102 according to the command received by the communication unit 2110. The client device 2104 has a communication unit 2114, a decoding unit 2116, and a control unit 2118. The communication unit 2118 of the client device 2104 transmits a command to the network camera 2102. Furthermore, the communication unit 2118 of the client device 2104 receives the encoded image data from the network camera 2102. The decoding unit 2116 decodes the encoded image data by using the decoding method described in any one of the first to fifth embodiments. As another example, the decoding unit 2116 can use a combination of the decoding methods described in the first to fifth embodiments.

[0181] The control unit 2118 of the client device 2104 controls other units in the client device 2104 according to a user operation or command received by the communication unit 2114. The control unit 2118 of the client device 2104 controls the display device 2120 to display an image decoded by the decoding unit 2116. The control unit 2118 of the client device 2104 also controls the display device 2120 to display a GUI (Graphical User Interface) for specifying values ​​of parameters of the network camera 2102 including parameters for encoding by the encoding unit 2108. The control unit 2118 of the client device 2104 also controls other units in the client device 2104 according to a user operation input to the GUI displayed by the display device 2120. The control unit 2118 of the client device 2104 controls the communication unit 2114 of the client device 2104 to transmit a command for specifying values ​​of parameters of the network camera 2102 to the network camera 2102 according to a user operation input to the GUI displayed by the display device 2120. The network camera system 2100 can determine whether the camera 2102 utilizes a zoom or pan while recording video, and such information may be used when encoding the video stream as a zoom or pan, while the shot can benefit from the use of an affine mode, which is well suited for encoding complex movements such as zooming, rotation, and / or stretching (which can be side effects of panning, especially if the lens is a "fisheye" lens).

[0182] FIG. 21 is a diagram showing a smartphone 2200. The smartphone 2200 includes a communication unit 2202, a decoding / encoding unit 2204, a control unit 2206, and a display unit 2208. The communication unit 2202 receives encoded image data via a network. The decoding unit 2204 decodes the encoded image data received by the communication unit 2202. The decoding unit 2204 decodes the encoded image data by using the decoding method described in the first to fifth embodiments. The decoding unit 2204 can use at least one of the decoding methods described in the first to fifth embodiments. For example, the encoding unit 2202 can use a combination of the decoding methods described in the first to fifth embodiments. The control unit 2206 controls other units in the smartphone 2200 in response to a user operation or command received by the communication unit 2202.

[0183] For example, the control unit 2206 controls the display unit 2208 to display images decoded by the decoding unit 2204. The smartphone may further comprise an image recording device 2210 (e.g., a digital camera associated with the circuit) for recording images or videos. Such recorded images or videos may be encoded by the decoding / encoding unit 2204 under the direction of the control unit 2206. The smartphone may further comprise a sensor 2212 adapted to sense the orientation of the mobile device. Such sensors may include an accelerometer, a gyroscope, a compass, a global positioning (GPS) unit or similar position sensor. Such a sensor 2212 may determine whether the smartphone changes orientation, and such information may be used when encoding the video stream as a change in orientation, while a video capture may benefit from the use of an affine mode well suited to encoding complex movements such as rotations.

[0184] (Alternatives and Modifications) It will be appreciated that the aim of the present invention is to ensure that affine modes are utilized in the most efficient way, and the particular examples given above relate to conveying the use of affine modes depending on the likelihood that they will be perceived as useful. A further example of this may be applied to the encoder when it is known that complex motion is being coded, for which affine transformations are particularly efficient. Examples of such cases include: a) Camera zoom in / out b) Portable cameras (e.g., cell phones) that change orientation during capture (i.e., rotational movement) c) Panning a "fisheye" lens camera (e.g. stretching / distorting parts of the image) As such, indications of complex motion during the recording process may be raised such that affine mode is given a high probability of being used for slices, frame sequences, or the entire actual video stream. In a further example, affine mode may be given a high probability of being used depending on the features or functionality of the device used to record the video. For example, mobile devices are more likely to change orientation than (say) fixed surveillance cameras, so affine mode may be more appropriate for encoding video from the former. Examples of features or functionality include the presence / use of zooming means, the presence / use of position sensors, the presence / use of panning means, whether the device is handheld, or user selection on the device.

[0185] Although the present invention has been described with reference to the embodiments, it is to be understood that the present invention is not limited to the disclosed embodiments. It will be understood by those skilled in the art that various changes and modifications can be made without departing from the scope of the present invention, as defined in the appended claims. All features disclosed herein (including the appended claims, abstract and drawings), and / or all steps of any method or process so disclosed, may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive. Each feature disclosed herein (including the appended claims, abstract and drawings), unless otherwise stated, may be replaced by an alternative feature serving the same, equivalent or similar purpose. Thus, unless otherwise stated, each feature disclosed is merely one example of a generic series of equivalent or similar features.

[0186] It is also to be understood that any result of the above-mentioned comparison, determination, evaluation, selection, execution, implementation, or consideration, e.g., a selection made during an encoding or filtering process, may be indicated or determinable / inferable from data in the bitstream, e.g., in a flag or data indicating the result, such that the indicated or determined / inferred result may be used in the process instead of actually performing the comparison, determination, evaluation, selection, execution, implementation, or consideration, e.g., during a decoding process. In the claims, the word "having" 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 used to advantage. Reference signs appearing in the claims are only illustrative and shall have no limiting effect on the scope of the claims.

[0187] In the foregoing embodiments, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium may include a computer-readable storage medium corresponding to a tangible medium, such as a data storage medium, or a communication medium including any medium that facilitates transfer of a computer program from one place to another, for example according to a communication protocol. In this manner, the computer-readable medium may generally correspond to (1) a tangible computer-readable storage medium that is non-transitory, or (2) a communication medium such as a signal or carrier wave. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0188] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, flash memory, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Also, any connection is properly referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but instead cover non-transitory tangible storage media. As used herein, disk and disc include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while disks reproduce data optically with a laser. Combinations of the above should also be included within the scope of computer readable media.

[0189] The instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, the term "processor" as used herein may refer to any of the foregoing structures, or any other structure suitable for implementing the techniques described herein. Furthermore, in some aspects the functionality described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or may be incorporated into a combined codec. Additionally, the techniques may be implemented entirely in one or more circuit or logic elements.

Claims

1. generating a list of a plurality of motion vector predictor candidates, which may include candidates for sub-block collocated temporal prediction and candidates for sub-block affine prediction; Decoding a motion vector predictor index for the current block using CABAC decoding; and using the motion vector predictor index to identify one of the plurality of motion vector predictor candidates in the list; a first bit of the motion vector predictor index is decoded by CABAC decoding using a context variable, and all bits of the motion vector predictor index except for the first bit of the motion vector predictor index are bypass decoded; a maximum number of motion vector predictor candidates that can be included in the list depends on whether the sub-block affine prediction is enabled; The size of the current block is 2n×2m (n and m are positive integers); A method comprising:

2. The sub-block collocated temporal prediction may use motion information of each of a plurality of sub-blocks in a block in another image that is co-located with a current block in the image.

2. The method of claim 1 .

3. the plurality of sub-blocks in the block in the other image are a plurality of sub-blocks obtained by dividing the block in the other image into four; 3. The method of claim 2 .

4. The sub-block affine prediction can derive motion information of each of a plurality of sub-blocks in a current block using two or three pieces of motion information.

2. The method of claim 1 .

5. Each of the plurality of sub-blocks from which motion information is derived in the sub-block affine prediction has a size of 4×4.

5. The method of claim 4.

6. The sub-block affine prediction includes motion information corresponding to the top left position of the current block, and a motion information corresponding to a top right position of the current block, and the motion information of each of a plurality of sub-blocks in the current block can be derived using the motion information.

2. The method of claim 1 .

7. The maximum number of motion vector predictor candidates that can be included in the list further depends on whether the sub-block collocated temporal prediction is enabled at the SPS level.

2. The method of claim 1 .

8. the plurality of motion vector predictor candidates are merge candidates, and the motion vector predictor index is a merge index.

2. The method of claim 1 .

9. The size of the current block is 16×16.

2. The method of claim 1 .

10. generating means for generating a list including a plurality of motion vector predictor candidates, which may include candidates for sub-block collocated temporal prediction and candidates for sub-block affine prediction; decoding means for decoding a motion vector predictor index for a current block using CABAC decoding; and means for identifying one of a plurality of motion vector predictor candidates in the list using the motion vector predictor index; a first bit of the motion vector predictor index is decoded by CABAC decoding using a context variable, and all bits of the motion vector predictor index except for the first bit of the motion vector predictor index are bypass decoded; a maximum number of motion vector predictor candidates that can be included in the list depends on whether the sub-block affine prediction is enabled; The size of the current block is 2n×2m (n and m are positive integers); A decoding device comprising:

11. The sub-block collocated temporal prediction may use motion information of each of a plurality of sub-blocks in a block in another image that is co-located with a current block in the image.

11. The decoding device according to claim 10.

12. the plurality of sub-blocks in the block in the other image are a plurality of sub-blocks obtained by dividing the block in the other image into four; 12. The decoding device according to claim 11 .

13. The sub-block affine prediction can derive motion information of each of a plurality of sub-blocks in a current block using two or three pieces of motion information.

11. The decoding device according to claim 10.

14. Each of the plurality of sub-blocks from which motion information is derived in the sub-block affine prediction has a size of 4×4.

14. The decoding device according to claim 13.

15. The sub-block affine prediction includes motion information corresponding to the top left position of the current block, and a motion information corresponding to a top right position of the current block, and the motion information of each of a plurality of sub-blocks in the current block can be derived using the motion information.

11. The decoding device according to claim 10.

16. The maximum number of motion vector predictor candidates that can be included in the list further depends on whether the sub-block collocated temporal prediction is enabled at the SPS level.

11. The decoding device according to claim 10.

17. the plurality of motion vector predictor candidates are merge candidates, and the motion vector predictor index is a merge index.

11. The decoding device according to claim 10.

18. generating a list of a plurality of motion vector predictor candidates, which may include candidates for sub-block collocated temporal prediction and candidates for sub-block affine prediction; identifying one of the plurality of motion vector predictor candidates in the list; encoding, for a current block, motion vector predictor indices for the identified motion vector predictor candidates using CABAC coding; a first bit of the motion vector predictor index is coded by CABAC coding using a context variable, and all bits of the motion vector predictor index except for the first bit of the motion vector predictor index are bypass coded; a maximum number of motion vector predictor candidates that can be included in the list depends on whether the sub-block affine prediction is enabled; The size of the current block is 2n×2m (n and m are positive integers); A method comprising:

19. The sub-block collocated temporal prediction may use motion information of each of a plurality of sub-blocks in a block in another image that is co-located with a current block in the image.

20. The method of claim 18 .

20. The sub-block affine prediction can derive motion information of each of a plurality of sub-blocks in a current block using two or three pieces of motion information.

20. The method of claim 18 .

21. means for generating a list of a plurality of motion vector predictor candidates, which may include candidates for sub-block collocated temporal prediction and candidates for sub-block affine prediction; means for identifying one of the plurality of motion vector predictor candidates in the list; means for encoding motion vector predictor indices for the identified motion vector predictor candidates for a current block using CABAC coding; a first bit of the motion vector predictor index is coded by CABAC coding using a context variable, and all bits of the motion vector predictor index except for the first bit of the motion vector predictor index are bypass coded; a maximum number of motion vector predictor candidates that can be included in the list depends on whether the sub-block affine prediction is enabled; The size of the current block is 2n×2m (n and m are positive integers); 13. An encoding device comprising:

22. To a computer or processor A computer program product adapted to carry out the method according to any one of claims 1 to 9.

23. To a computer or processor A computer program for causing the computer to carry out the method according to any one of claims 18 to 20.

Images