Patent Description:
Video coding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can include a series of pictures, each picture having a spatial dimension of, for example, <NUM> x <NUM> luminance samples and associated chrominance samples. The series of pictures can have a fixed or variable picture rate (informally also known as frame rate), of, for example <NUM> pictures per second or <NUM>. Uncompressed video has significant bitrate requirements. For example, 1080p60 <NUM>:<NUM>:<NUM> video at <NUM> bit per sample (1920x1080 luminance sample resolution at <NUM> frame rate) requires close to <NUM> Gbit/s bandwidth. An hour of such video requires more than <NUM> GBytes of storage space.

In some video compression techniques, an MV applicable to a certain area of sample data can be predicted from other MVs, for example from those related to another area of sample data spatially adjacent to the area under reconstruction, and preceding that MV in decoding order. Doing so can substantially reduce the amount of data required for coding the MV, thereby removing redundancy and increasing compression. MV prediction can work effectively, for example, because when coding an input video signal derived from a camera (known as natural video) there is a statistical likelihood that areas larger than the area to which a single MV is applicable move in a similar direction and, therefore, can in some cases be predicted using a similar motion vector derived from MVs of neighboring area. That results in the MV found for a given area to be similar or the same as the MV predicted from the surrounding MVs, and that in turn can be represented, after entropy coding, in a smaller number of bits than what would be used if coding the MV directly. In some cases, MV prediction can be an example of lossless compression of a signal (namely: the MVs) derived from the original signal (namely: the sample stream). In other cases, MV prediction itself can be lossy, for example because of rounding errors when calculating a predictor from several surrounding MVs.

Various MV prediction mechanisms are described in <NPL>). Out of the many MV prediction mechanisms that H. <NUM> offers, described here is a technique henceforth referred to as "spatial merge".

Referring to <FIG>, a current block (<NUM>) comprises samples that have been found by the encoder during the motion search process to be predictable from a previous block of the same size that has been spatially shifted. Instead of coding that MV directly, the MV can be derived from metadata associated with one or more reference pictures, for example from the most recent (in decoding order) reference picture, using the MV associated with either one of five surrounding samples, denoted A0, A1, and B0, B1, B2 (<NUM> through <NUM>, respectively). <NUM>, the MV prediction can use predictors from the same reference picture that the neighboring block is using. The order of forming a candidate list may be A0 → B0 → B1 → A1 → B2.

Document<NPL>, discloses that, depending on whether Intra Block Copy (IBC) merge mode or inter merge mode applies for the current block, the size of the index for a candidate list of vector predictors is set to the maximum number of IBC candidates or to the maximum number of inter merge mode candidates.

It corresponds to the embodiment described in Table <NUM> and the related paragraphs, i.e. the paragraph preceding Table <NUM> and the paragraph following Table <NUM>, and in <FIG> and the related paragraphs. Parts of the description and drawings referring to other embodiments, not covered by the claims, are examples useful for understanding the invention.

A streaming system may include a capture subsystem (<NUM>), that can include a video source (<NUM>), for example a digital camera, creating for example a stream of video pictures (<NUM>) that are uncompressed. In an example, the stream of video pictures (<NUM>) includes samples that are taken by the digital camera. The stream of video pictures (<NUM>), depicted as a bold line to emphasize a high data volume when compared to encoded video data (<NUM>) (or coded video bitstreams), can be processed by an electronic device (<NUM>) that includes a video encoder (<NUM>) coupled to the video source (<NUM>). The video encoder (<NUM>) can include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter as described in more detail below. The encoded video data (<NUM>) (or encoded video bitstream (<NUM>)), depicted as a thin line to emphasize the lower data volume when compared to the stream of video pictures (<NUM>), can be stored on a streaming server (<NUM>) for future use. One or more streaming client subsystems, such as client subsystems (<NUM>) and (<NUM>) in <FIG> can access the streaming server (<NUM>) to retrieve copies (<NUM>) and (<NUM>) of the encoded video data (<NUM>). A client subsystem (<NUM>) can include a video decoder (<NUM>), for example, in an electronic device (<NUM>). The video decoder (<NUM>) decodes the incoming copy (<NUM>) of the encoded video data and creates an outgoing stream of video pictures (<NUM>) that can be rendered on a display (<NUM>) (e.g., display screen) or other rendering device (not depicted). In some streaming systems, the encoded video data (<NUM>), (<NUM>), and (<NUM>) (e.g., video bitstreams) can be encoded according to certain video coding/compression standards. Examples of those standards include ITU-T Recommendation H. In an example, a video coding standard under development is informally known as Versatile Video Coding (WC). The disclosed subject matter may be used in the context of VVC.

When the coded video data may be decoded at a video decoder (not shown in <FIG>), the reconstructed video sequence typically may be a replica of the source video sequence with some errors.

The predictor (<NUM>) may operate on a sample blockby-pixel block basis to find appropriate prediction references.

For example, pictures often may be assigned as one of the following picture types:
An Intra Picture (I picture) may be one that may be coded and decoded without using any other picture in the sequence as a source of prediction.

Block based compensation from a different picture may be referred to as motion compensation. Block compensation may also be done from a previously reconstructed area within the same picture, which may be referred to as intra picture block compensation, intra block copy (IBC), or current picture referencing (CPR). For example, a displacement vector that indicates an offset between a current block and the reference block is referred to as a block vector. According to some embodiments, a block vector points to a reference block that is already reconstructed and available for reference. Also, for parallel processing consideration, a reference area that is beyond a tile/slice boundary or wavefront ladder-shaped boundary may also be excluded from being referenced by the block vector. Due to these constraints, a block vector may be different from a motion vector in motion compensation, where the motion vector can be at any value (positive or negative, at either x or y direction).

The coding of a block vector may be either explicit or implicit. In an explicit mode, which is sometimes referred to as (Advanced Motion Vector Prediction) AMVP mode in inter coding, the difference between a block vector and its predictor is signaled. In the implicit mode, the block vector is recovered from the block vector's predictor, in a similar way as a motion vector in merge mode. The resolution of a block vector, in some embodiments, is restricted to integer positions. In other embodiments, the resolution of a block vector may be allowed to point to fractional positions.

The use of intra block copy at the block level may be signaled using a block level flag, referred to as an IBC flag. In one embodiment, the IBC flag is signaled when a current block is not coded in merge mode. The IBC flag may also be signaled by a reference index approach, which is performed by treating the current decoded picture as a reference picture. In HEVC Screen Content Coding (SCC), such a reference picture is put in the last position of the list. This special reference picture may also be managed together with other temporal reference pictures in the DPB. IBC may also include variations such as flipped IBC (e.g., the reference block is flipped horizontally or vertically before used to predict current block), or line based (IBC) (e.g., each compensation unit inside an MxN coding block is an Mx1 or 1xN line).

<FIG> illustrates an embodiment of intra picture block compensation (e.g., intra block copy mode). In <FIG>, a current picture <NUM> includes a set of block regions that have already been coded/decoded (i.e., gray colored squares) and a set of block regions that have yet to be coded/decoded (i.e., white colored squares). A block <NUM> of one of the block regions that have yet to be coded/decoded may be associated with a block vector <NUM> that points to another block <NUM> that has previously been coded/decoded. Accordingly, any motion information associated with the block <NUM> may be used for the coding/decoding of block <NUM>.

In some embodiments, the search range of the CPR mode is constrained to be within the current CTU. The effective memory requirement to store reference samples for CPR mode is <NUM> CTU size of samples. Taking into account the existing reference sample memory to store reconstructed samples in a current 64x64 region, <NUM> more 64x64 sized reference sample memory are required. Embodiments of the present disclosure extend the effective search range of the CPR mode to some part of the left CTU while the total memory requirement for storing reference pixels are kept unchanged (<NUM> CTU size, <NUM>64x64 reference sample memory in total).

In <FIG>, the upper left region of CTU <NUM> is the current region being decoded. When the upper left region of CTU <NUM> is decoded, the entry [<NUM>] of the reference sample memory is overwritten with the samples from this region, as illustrated in <FIG> (e.g., over-written memory location(s) has diagonal cross-hatching). In <FIG>, the upper right region of CTU <NUM> is the next current region being decoded. When the upper right region of CTU <NUM> is decoded, the entry [<NUM>] of the reference sample memory is overwritten with the samples from this region, as illustrated in <FIG>. In <FIG>, the lower left region of CTU <NUM> is the next current region being decoded. When the lower left region of CTU <NUM> is decoded, the entry [<NUM>] of the reference sample memory is overwritten with the samples from this region, as illustrated in <FIG>. In <FIG>, the lower right region of CTU <NUM> is the next current region being decoded. When the lower right region of CTU <NUM> is decoded, the entry [<NUM>] of the reference sample memory is overwritten with the samples from this region, as illustrated in <FIG>.

In some embodiments, the bitstream conformance conditions that a valid block vector (mvL, in <NUM>/<NUM> - pel resolution) should follow the conditions specified below. In some embodiments, the luma motion vector mvL obeys the following constraints A1, A2, B1, C1, and C2.

In a first constraint (A1), when the derivation process for block availability (e.g., neighbouring blocks availability checking process) is invoked with the current luma location (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma location (xCb + (mvL[<NUM>] >> <NUM>) + cbWidth - <NUM>, yCb + (mvL[<NUM>] >> <NUM>) + cbHeight - <NUM>) as inputs, the output shall be equal to TRUE.

In a second constraint (A2), when the derivation process for block availability (e.g., neighbouring blocks availability checking process) is invoked with the current luma location (xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma location (xCb + (mvL[<NUM>] >> <NUM>) + cbWidth - <NUM>, yCb + (mvL[<NUM>] >> <NUM>) + cbHeight - <NUM>) as inputs, the output shall be equal to TRUE.

In a third constraint (B1), one or both of the following conditions are true:.

In a fourth constraint (C1), the following conditions are true:.

In a fifth constraint (C2), when (xCb + (mvL[<NUM>] >> <NUM>)) >> CtbLog2SizeY is equal to (xCb >> CtbLog2SizeY) - <NUM>, the derivation process for block availability (e.g., neighbouring blocks availability checking process) is invoked with the current luma location(xCurr, yCurr) set equal to (xCb, yCb) and the neighbouring luma location ( ( (xCb + (mvL[<NUM>] >> <NUM>) + CtbSizeY) >> (CtbLog2SizeY - <NUM> ) ) << (CtbLog2SizeY - <NUM>), ( ( yCb + (mvL[<NUM>] >> <NUM>) ) >> (CtbLog2SizeY - <NUM>)) << (CtbLog2SizeY - <NUM>) ) as inputs, and the output shall be equal to FALSE.

In the above equations, xCb and yCb are the x and y coordinates of the current block, respectively. The variables cbHeight and cbWidth are the height and width of the current block, respectively. The variable CtbLog2sizeY refers to the CTU size in the log2 domain. For example, CtbLog2sizeY = <NUM> means that the CTU size is <NUM> x <NUM>. The variables mvL0[<NUM>] and mvL0[<NUM>] refer to the x and y components of block vector mvL0, respectively. If an output is FALSE, the samples for a reference block are determined to be available (e.g., neighboring block is available for intra block copy usage). If an output is TRUE, the samples for a reference block are determined to be not available.

According to some embodiments, a history-based MVP (HMVP) method includes a HMVP candidate that is defined as the motion information of a previously coded block. A table with multiple HMVP candidates is maintained during the encoding/decoding process. The table is emptied when a new slice is encountered. Whenever there is an inter-coded non-affine block, the associated motion information is added to the last entry of the table as a new HMVP candidate. The coding flow of the HMVP method is depicted in <FIG>.

The table size S is set to be <NUM>, which indicates up to <NUM> HMVP candidates may be added to the table. When inserting a new motion candidate into the table, a constrained FIFO rule is utilized such that a redundancy check is first applied to determine whether an identical HMVP is in the table. If found, the identical HMVP is removed from the table and all the HMVP candidates afterwards are moved forward (i.e., with indices reduced by <NUM>). <FIG> shows an example of inserting a new motion candidate into the HMVP table.

HMVP candidates may be used in the merge candidate list construction process. The latest several HMVP candidates in the table are checked in order and inserted into the candidate list after the TMVP candidate. Pruning may be applied on the HMVP candidates to the spatial or temporal merge candidate excluding sub-block motion candidate (i.e., ATMVP).

In some embodiments, to reduce the number of pruning operations, the number of HMPV candidates to be checked (denoted by L) is set as L = (N <=<NUM> ) ? M: (<NUM> - N), where N indicates a number of available non-sub-block merge candidates and M indicates a number of available HMVP candidates in the table. In addition, once the total number of available merge candidates reaches the signaled maximally allowed merge candidates minus <NUM>, the merge candidate list construction process from the HMVP list is terminated. Furthermore, the number of pairs for combined bi-predictive merge candidate derivation is reduced from <NUM> to <NUM>.

HMVP candidates could also be used in the AMVP candidate list construction process. The motion vectors of the last K HMVP candidates in the table are inserted after the TMVP candidate. Only HMVP candidates with the same reference picture as the AMVP target reference picture are used to construct the AMVP candidate list. Pruning is applied on the HMVP candidates. In some applications, K is set to <NUM> while the AMVP list size is kept unchanged (i.e., equal to <NUM>).

According to some embodiments, when intra block copy operates as a separate mode from inter mode, a separate history buffer, referred to as HBVP, may be used for storing previously coded intra block copy block vectors. As a separate mode from inter prediction, it is desirable to have a simplified block vector derivation process for intra block copy mode. The candidate list for IBC BV prediction in AMVP mode may share the one used in IBC merge mode (merge candidate list), with <NUM> spatial candidates + <NUM> HBVP candidates.

The merge candidate list size of IBC mode may be assigned as MaxNumMergeCand. The MaxNumMergeCand may be determined by the inter mode merge candidate list size MaxNumMergeCand, which is specified, in some examples, as six_minus_max_num_merge_cand. The variable six_minus_max_num_merge_cand may specify the maximum number of merge motion vector prediction (MVP) candidates supported in a slice subtracted from <NUM>.

In some examples, the maximum number of merging MVP candidates, MaxNumMergeCand, may be derived as: <MAT>.

The value of MaxNumMergeCand may be in the range of <NUM> to <NUM>, inclusive. In some video coding systems, the merge list size for IBC mode is signaled separately from the merge list size of inter merge mode, for all I/P/B slices. The range of this size may be the same as inter merge mode (e.g., from <NUM> to <NUM>, inclusively). In some examples, a maximum number of IBC candidates, MaxNumIbcMergeCand may be derived as: <MAT>.

In Eq. (<NUM>), the variable six_minus_max_num_ibc_merge_cand specifies the maximum number of IBC merging motion vector prediction (MVP) candidates supported in the slice subtracted from <NUM>. The value of MaxNumIBCMergeCand may be in the range of <NUM> to <NUM>, inclusive. In some video coding systems, the merge index signaling for IBC merge mode may still share the merge index signaling used for inter merge mode. In this regard, the IBC merge mode and inter merge mode may share the same syntax element for the merge index. Because the merge index is binarized using truncated rice (TR) code, the maxinum length of the merge index is MaxNumMergeCand - <NUM>. However, there is a need for a solution for merge index signaling when the MaxNumIbcMergeCand is not equal to MaxNumMergeCand.

The embodiments of the present disclosure are to be used separately. Further, each of the methods, encoder, and decoder according to the embodiments of the present disclosure may be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits). In one example, the one or more processors execute a program that is stored in a non-transitory computer-readable medium. According to some embodiments, the term block may be interpreted as a prediction block, a coding block, or a coding unit (i.e., CU).

According to some embodiments, the number of a maximum merge size for the merge index binarization is set to be switchable between the numbers of MaxNumMergeCand and MaxNumIbcMergeCand. For example, when current block is coded in IBC mode, the maximum merge size for the merge index is MaxNumIbcMergeCand. However, when the currnet block is not coded in the IBC mode, the maximum merge size for the merge index is MaxNumMergeCand. Table <NUM> illustrates example syntax elements and associated binarizations.

As illustrated in Table <NUM>, the binarization of the merge index (i.e., merge_idx[][]) is based on whether the current block is coded in the IBC mode. Furthermore, FL refers to fixed length; cMax refers to a maximum possible value of a variable length code; eRiceParam is the rice parameter of a variable length code. The rice parameter may be used to determine a binary code of each input value. In truncated binary code, the rice parameter is <NUM>.

According to an embodiment representing the invention, the number of maximum merge size for the merge index binarization is set to be the maximum number between MaxNumMergeCand and MaxNumIbcMergeCand. Since in an I slice/tile group, the value of MaxNumMergeCand is not signaled, the MaxNumMergeCand may have an inferred value of <NUM> (i.e., mininum posibble value for MaxNumIbcMergeCand). Accordingly, when MaxNumMergeCand is not signalled, the value of six_minus_max_num_merge_cand is inferred to be <NUM> since the value of MaxNumMergeCand is inferred to be <NUM>. Therefore, in Eq. (<NUM>), MaxNumMergeCand is equal to <NUM> since six_minus_max_num_merge_cand is <NUM>. In Eq. (<NUM>) the value of MaxNumIbcMergeCand is in the range of <NUM> to <NUM>, inclusive.

Table <NUM> illustrates example syntax and associated binarizations.

As illustrated in Table <NUM>, the binarization of the merge index (i.e., merge_idx[][]) is based on whether the maximum number of merge mode candidates (i.e., MaxNumMergeCand) is greater than the maximum number of IBC candidates (i.e., MaxNumIbcMergeCand).

According to some embodiments, the range of MaxNumIbcMergeCand shall be smaller than or equal to MaxNumMergeCand. Since in the I slice/tile group, the value of MaxNumMergeCand is not signaled, the value of MaxNumMergeCand is inferred to be <NUM>. Accordingly, in Eq. (<NUM>), the value of six_minus_max_num_merge_cand is inferred to be <NUM> since MaxNumMergeCand is inferred to be <NUM>. In some embodiments, when the signaled MaxNumIbcMergeCand value is greater than MaxNumMergeCand, MaxNumIbcMergeCand is clipped to MaxNumMergeCand. Accordingly, in Eq. (<NUM>) if the slice type is I, the value of MaxNumIbcMergeCand shall be in the range of <NUM> to <NUM>, inclusive. However, if the slice type is P or B, the value of MaxNumIbcMergeCand is in the range of <NUM> to MaxNumMergeCand, inclusive. Accordingly, when the slice type is P or B (i.e., MaxNumMergeCand is not signalled), the value of MaxNumIbcMergeCand may be determined as follows: MaxNumIbcMergeCand = min(MaxNumIbcMergeCand, MaxNumMergeCand).

<FIG> illustrates an embodiment of a video decoding process performed by a video decoder such as video decoder (<NUM>). The process may start at step (S1200) where a coded video bitstream including a current picture is received. The process proceeds to step (S1202) where a predetermined condition associated with signaling data included in the coded video bitstream is determined.

The process proceeds to step (S1204) where, based on the predetermined condition, a size of an index included in the signaling data for a candidate list of vector predictors is set to one of a maximum number of merge mode candidates and a number of IBC candidates. As an example, the index may be a merge index included in the coded video bitstream. As an example not part of the invention, the predetermined condition includes determining whether the current block is coded in IBC mode. If the current block is encoded in the IBC mode, the size of the index is set to MaxNumIbcMergeCand. However, if the current block is not encoded in the IBC mode, the size of the index is set to MaxNumMergeCand.

In the invention, the predetermined condition includes determining whether a maximum number of merge mode candidates is greater than a maximum number of IBC candidates. If the maximum number of merge mode candidates is greater than the maximum number of IBC candidates, the size of the index is set to MaxNumMergeCand. However, if the maximum number of merge mode candidates is less than the maximum number of IBC candidates, the size of the index is set to MaxNumIbcMergeCand.

The process proceeds from step (S1204) to (S1206) where the candidate list is constructed with vector predictors. For example, if the current block is coded in the merge mode, the candidate list is the merge list, and the vector predictors are motion vectors. In another example, if the current block is coded in the IBC mode, the candidate list is a list of block vector predictors. The process proceeds from step (S1208) where a vector predictor from the candidate list is retrieved in accordance with the index that has a value that does not exceed the determined size of the index. For example, the value of the index that is used to retrieve a vector predictor from the candidate list cannot exceed the size of the index that is determined in step (S1204). The process proceeds to step (S1210) where the current block is decoded in accordance with the retrieved vector predictor.

<FIG> illustrates an embodiment of a video decoding process performed by a video decoder such as video decoder (<NUM>). The process may start at step (S1300) where a coded video bitstream including a current picture is received. The process proceeds to step (S1302) where signaling data from the coded video bitstream is retrieved for a current block. The process proceeds to step (S1304) to determine whether a maximum number of merge candidates is included in the retrieved signaling data for the current block. For example, it is determined whether MaxNumMergeCand is signaled. As discussed above, in some examples, MaxNumMergeCand is not signaled for I slice/tile group types, and signaled for P or B slice/tile group types.

The process proceeds to step (S1306) where a maximum number of intra block copy (IBC) candidates is set based on the determination of whether the maximum number of merge candidates is included in the signaling data for the current block. For example, if MaxNumMergeCand is not signaled, the value of MaxNumIbcMergeCand ranges from <NUM> to <NUM>, inclusive. However, if MaxNumMergeCand is signaled, the value of MaxNumIbcMergeCand ranges from <NUM> to MaxNumMergeCand, inclusive.

In some examples, a coding unit contains samples of both the luma and chroma components. These samples of chroma component may have an independent or separate split tree structure as compared to the one of luma component. In some examples, a separate coding tree structure starts from CTU level. Therefore, it is possible that a chroma CU (e.g., a CU that contains only two chroma components) can be larger than the chroma CU's luma counterpart at the corresponding sample location.

According to some embodiments, in a first method, when a dual-tree structure is used, chroma blocks can be coded in IBC mode when at least the following conditions are met:.

Based on the first method, the decoder side will be able to treat the chroma CU as a whole CU instead of as a sub-block based CU. Therefore, using a single derived BV from the collocated luma area (e.g., typically top-left corner of the CU) for decoding the CU is sufficient.

According to some embodiments, in a second method, when the dual-tree structure is used, different conditions may be used to enable the use of the chroma IBC mode with the dual tree structure. In one embodiment, chroma blocks can be coded in the IBC mode when (i) all the chroma samples' corresponding luma samples belong to the same luma coding block; and (ii) the same luma coding block is coded in the IBC mode. As an example, this condition is checked by evaluating the chroma CU's two corners. If the top-left chroma sample's luma correspondence and the bottom-right chroma sample's luma correspondence belong to the same luma coding block, then the entire chroma CU's corresponding luma area belong to the same luma coding block. In another embodiment, chroma blocks can be coded in the IBC mode when the corresponding luma coding.

Based on the second method, the decoder side will be able to treat the chroma CU as a whole CU instead of as a sub-block based CU. Therefore, using a single derived BV from the collocated luma area (typically top-left corner of the CU) for decoding the CU is sufficient.

According to some embodiments, for either the first method or second method regarding the dual-tree structure, the following disclosed non-limiting embodiments show how to signal the use of the chroma IBC mode with the dual-tree, when the above conditions in either the first method or the second method are met.

In one embodiment, the above constraints for using IBC mode for the chroma CU with the dual-tree structure are implemented such that a usage flag (e.g., ibc_flag) is signaled for each chroma CU when applicable. However, in this embodiment, only when all the conditions for the first method or all the conditions for the second method are met is the ibc_flag be signaled as true. Otherwise, the ibc_flag is signaled as false. In some examples, when all conditions are met for either the first method or the second method, the ibc_flag can also be signaled as false based on how the encoder is implemented.

In another embodiment, the above constraints for using the IBC mode for the chroma CU with the dual-tree structure are implemented such that a usage flag (e.g., ibc_flag) is not signaled at all. For example, for a chroma CU with the dual-tree structure, when all conditions for the first method or the second method are met, the CU is encoded in the IBC mode, and the ibc_flag is inferred as true. Otherwise, the ibc_flag is not signaled and inferred to be false.

Such human interface output devices may include tactile output devices (for example tactile feedback by the touch-screen.

(<NUM>), data-glove (not shown), or joystick (<NUM>), but there can also be tactile feedback devices that do not serve as input devices), audio output devices (such as: speakers (<NUM>), headphones (not depicted)), visual output devices (such as screens (<NUM>) to include CRT screens, LCD screens, plasma screens, OLED screens, each with or without touch-screen input capability, each with or without tactile feedback capability-some of which may be capable to output two dimensional visual output or more than three dimensional output through means such as stereographic output; virtual-reality glasses (not depicted), holographic displays and smoke tanks (not depicted)), and printers (not depicted).

Computer system (<NUM>) can also include an interface to one or more communication networks. Networks can for example be wireless, wireline, optical. Networks can further be local, wide-area, metropolitan, vehicular and industrial, real-time, delay-tolerant, and so on. Examples of networks include local area networks such as Ethernet, wireless LANs, cellular networks to include GSM, <NUM>, <NUM>, <NUM>, LTE and the like, TV wireline or wireless wide area digital networks to include cable TV, satellite TV, and terrestrial broadcast TV, vehicular and industrial to include CANBus, and so forth. Certain networks commonly require external network interface adapters that attached to certain general purpose data ports or peripheral buses (<NUM>) (such as, for example USB ports of the computer system (<NUM>)); others are commonly integrated into the core of the computer system (<NUM>) by attachment to a system bus as described below (for example Ethernet interface into a PC computer system or cellular network interface into a smartphone computer system). Using any of these networks, computer system (<NUM>) can communicate with other entities. Such communication can be uni-directional, receive only (for example, broadcast TV), uni-directional send-only (for example CANbus to certain CANbus devices), or bi-directional, for example to other computer systems using local or wide area digital networks. Certain protocols and protocol stacks can be used on each of those networks and network interfaces as described above.

These devices, along with Read-only memory (ROM) (<NUM>), Randomaccess memory (<NUM>), internal mass storage such as internal non-user accessible hard drives, SSDs, and the like (<NUM>), may be connected through a system bus (<NUM>).

Transitional data can also be stored in RAM (<NUM>), whereas permanent data can be stored for example, in the internal mass storage (<NUM>).

Claim 1:
A method of video decoding comprising:
receiving (S1200) a coded video bitstream including a current picture;
determining (S1202) a predetermined condition associated with signaling data included in the coded video bitstream, the predetermined condition including determining which of a maximum number of merge mode candidates and a maximum number of IBC candidates is greater;
setting (S1204), in response to determining that the maximum number of merge mode candidates is greater than the maximum number of IBC candidates, a size of an index included in the signaling data for a candidate list of vector predictors to the maximum number of merge mode candidates, and in response to determining that the maximum number of merge mode candidates is less than the maximum number of IBC candidates, setting the size of the index to the maximum number of IBC candidates;
constructing (S1206) the candidate list with vector predictors;
retrieving (S1208) a vector predictor from the candidate list in accordance with the index that has a value that does not exceed the set size of the index; and
decoding (S1210) the current block in accordance with the retrieved vector predictor.