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.

A video encoder and decoder can utilize techniques from several broad categories, including, for example, motion compensation, transform, quantization, and entropy coding.

Video codec technologies can include techniques known as intra coding. In intra coding, sample values are represented without reference to samples or other data from previously reconstructed reference pictures. In some video codecs, the picture is spatially subdivided into blocks of samples. When all blocks of samples are coded in intra mode, that picture can be an intra picture. Intra pictures and their derivations such as independent decoder refresh pictures, can be used to reset the decoder state and can, therefore, be used as the first picture in a coded video bitstream and a video session, or as a still image. The samples of an intra block can be exposed to a transform, and the transform coefficients can be quantized before entropy coding. Intra prediction can be a technique that minimizes sample values in the pre-transform domain. In some cases, the smaller the DC value after a transform is, and the smaller the AC coefficients are, the fewer the bits that are required at a given quantization step size to represent the block after entropy coding.

Traditional intra coding such as known from, for example MPEG-<NUM> generation coding technologies, does not use intra prediction. However, some newer video compression technologies include techniques that attempt, from, for example, surrounding sample data and/or metadata obtained during the encoding/decoding of spatially neighboring, and preceding in decoding order, blocks of data. Such techniques are henceforth called "intra prediction" techniques. Note that in at least some cases, intra prediction is only using reference data from the current picture under reconstruction and not from reference pictures.

There can be many different forms of intra prediction. When more than one of such techniques can be used in a given video coding technology, the technique in use can be coded in an intra prediction mode. In certain cases, modes can have submodes and/or parameters, and those can be coded individually or included in the mode codeword. Which codeword to use for a given mode/submode/parameter combination can have an impact in the coding efficiency gain through intra prediction, and so can the entropy coding technology used to translate the codewords into a bitstream.

A certain mode of intra prediction was introduced with H. <NUM>, refined in H. <NUM>, and further refined in newer coding technologies such as joint exploration model (JEM), versatile video coding (VVC), and benchmark set (BMS). A predictor block can be formed using neighboring sample values belonging to already available samples. Sample values of neighboring samples are copied into the predictor block according to a direction. A reference to the direction in use can be coded in the bitstream or may itself be predicted.

Referring to <FIG>, depicted in the lower right is a subset of nine predictor directions known from H. <NUM>'s <NUM> possible predictor directions (corresponding to the <NUM> angular modes of the <NUM> intra modes). The point where the arrows converge (<NUM>) represents the sample being predicted. The arrows represent the direction from which the sample is being predicted. For example, arrow (<NUM>) indicates that sample (<NUM>) is predicted from a sample or samples to the upper right, at a <NUM> degree angle from the horizontal. Similarly, arrow (<NUM>) indicates that sample (<NUM>) is predicted from a sample or samples to the lower left of sample (<NUM>), in a <NUM> degree angle from the horizontal.

Still referring to <FIG>, on the top left there is depicted a square block (<NUM>) of <NUM> x <NUM> samples (indicated by a dashed, boldface line). The square block (<NUM>) includes <NUM> samples, each labelled with an "S", its position in the Y dimension (e.g., row index) and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample in the Y dimension (from the top) and the first (from the left) sample in the X dimension. Similarly, sample S44 is the fourth sample in block (<NUM>) in both the Y and X dimensions. As the block is <NUM> x <NUM> samples in size, S44 is at the bottom right. Further shown are reference samples that follow a similar numbering scheme. A reference sample is labelled with an R, its Y position (e.g., row index) and X position (column index) relative to block (<NUM>). <NUM> and H. <NUM>, prediction samples neighbor the block under reconstruction; therefore no negative values need to be used.

Intra picture prediction can work by copying reference sample values from the neighboring samples as appropriated by the signaled prediction direction. For example, assume the coded video bitstream includes signaling that, for this block, indicates a prediction direction consistent with arrow (<NUM>)-that is, samples are predicted from a prediction sample or samples to the upper right, at a <NUM> degree angle from the horizontal. In that case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Sample S44 is then predicted from reference sample R08.

In certain cases, the values of multiple reference samples may be combined, for example through interpolation, in order to calculate a reference sample; especially when the directions are not evenly divisible by <NUM> degrees.

The number of possible directions has increased as video coding technology has developed. <NUM> (year <NUM>), nine different direction could be represented. That increased to <NUM> in H. <NUM> (year <NUM>), and JEM/VVC/BMS, at the time of disclosure, can support up to <NUM> directions. Experiments have been conducted to identify the most likely directions, and certain techniques in the entropy coding are used to represent those likely directions in a small number of bits, accepting a certain penalty for less likely directions. Further, the directions themselves can sometimes be predicted from neighboring directions used in neighboring, already decoded, blocks.

<FIG> shows a schematic (<NUM>) that depicts <NUM> intra prediction directions according to JEM to illustrate the increasing number of prediction directions over time.

The mapping of intra prediction directions bits in the coded video bitstream that represent the direction can be different from video coding technology to video coding technology; and can range, for example, from simple direct mappings of prediction direction to intra prediction mode, to codewords, to complex adaptive schemes involving most probable modes, and similar techniques. In all cases, however, there can be certain directions that are statistically less likely to occur in video content than certain other directions. As the goal of video compression is the reduction of redundancy, those less likely directions will, in a well working video coding technology, be represented by a larger number of bits than more likely directions. Document <CIT> discloses techniques for performing intrablock copy, wherein certain restrictions may be placed on one or more prediction techniques when intrablock copy prediction is enabled.

Aspects of the disclosure provide methods and apparatuses for video encoding/decoding. In some examples, an apparatus for video decoding includes receiving circuitry and processing circuitry. For example, the processing circuitry decodes prediction information of a current block in a picture from a coded video bitstream, and determines, based on an intra block copy (IBC) prediction mode usage flag from the decoded prediction information, an IBC prediction mode that is separate from an inter prediction mode and an intra prediction mode. Further, the processing circuitry determines, a block vector that points to a reference area in the picture in response to the determination of the IBC prediction mode, and reconstructs the current block based on reference samples within the reference area in the picture. The processing circuitry further infers the IBC prediction mode usage flag based on an IBC enable flag and a type of a tile group or slice that the current block belongs to. The processing circuitry further infers a value of the IBC prediction mode usage flag according to the IBC enable flag, when the tile group or slice type is I type, the current block satisfies a size constraint, and the IBC prediction mode usage flag is not signaled in the coded video bitstream. The processing circuitry further infers the IBC prediction mode usage flag to be <NUM>, when the tile group or slice type is B or P type, the current block satisfies a size constraint, and the IBC prediction mode usage flag is not signaled in the coded video bitstream.

In an example, the processing circuitry infers the IBC prediction mode usage flag to indicate the IBC prediction mode when the IBC enable flag is indicative of enabling, the tile group is I type, and the current block satisfies a size requirement. The IBC enable flag is a parameter of at least one of a video level, a sequence level, a picture level, and a tile group level.

In some embodiments, the processing circuitry decodes, from the coded video bitstream, a prediction mode flag. In other embodiments, the processing circuitry infers the prediction mode flag based on a skip flag and a type of a tile group that the current block belongs to.

In some embodiments, the processing circuitry determines, based on the decoded prediction information, a prediction mode flag, and the IBC prediction mode usage flag. Then, the processing circuitry selects a prediction mode from the IBC prediction mode, an intra prediction mode and an inter prediction mode based on a combination of the prediction mode flag and the IBC prediction mode usage flag.

In some examples, the processing circuitry determines the IBC prediction mode for the current block when the current block satisfies a size requirement.

Aspects of the disclosure also provide a non-transitory computer-readable medium storing instructions which when executed by a computer for video decoding cause the computer to perform the method for video decoding.

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 (VVC). The disclosed subject matter may be used in the context of VVC.

Video compression technologies can include in-loop filter technologies that are controlled by parameters included in the coded video sequence (also referred to as coded video bitstream) and made available to the loop filter unit.

(<NUM>) as symbols (<NUM>) from the parser (<NUM>), but can also be responsive to meta-information obtained during the decoding of previous (in decoding order) parts of the coded picture or coded video sequence, as well as responsive to previously reconstructed and loop-filtered sample values.

Aspects of the disclosure provide techniques for signaling flags for intra block copy and prediction mode.

Block based compensation can be used for inter prediction and intra prediction. For the inter prediction, block based compensation from a different picture is known as motion compensation. For intra prediction, block based compensation can also be done from a previously reconstructed area within the same picture. The block based compensation from reconstructed area within the same picture is referred to as intra picture block compensation, current picture referencing (CPR) or intra block copy (IBC). A displacement vector that indicates the offset between the current block and the reference block in the same picture is referred to as a block vector (or BV for short). Different from a motion vector in motion compensation, which can be at any value (positive or negative, at either x or y direction), a block vector has a few constraints to ensure that the reference block is available and already reconstructed. Also, in some examples, for parallel processing consideration, some reference area that is tile boundary or wavefront ladder shape boundary is excluded.

The coding of a block vector could be either explicit or implicit. In the explicit mode (or 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 a predictor (referred to as block vector predictor), in a similar way as a motion vector in merge mode. The resolution of a block vector, in some implementations, is restricted to integer positions; in other systems, the block vector is allowed to point to fractional positions.

In some examples, the use of intra block copy at block level, can be signaled using a reference index approach. The current picture under decoding is then treated as a reference picture. In an example, such a reference picture is put in the last position of a list of reference pictures. This special reference picture is also managed together with other temporal reference pictures in a buffer, such as decoded picture buffer (DPB).

There are also some variations for intra block copy, such as flipped intra block copy (the reference block is flipped horizontally or vertically before used to predict current block), or line based intra block copy (each compensation unit inside an MxN coding block is an Mx1 or 1xN line).

<FIG> shows an example of intra block copy according to an embodiment of the disclosure. Current picture (<NUM>) is under decoding. The current picture (<NUM>) includes a reconstructed area (<NUM>) (doted area) and to-be-decoded area (<NUM>) (white area). A current block (<NUM>) is under reconstruction by a decoder. The current block <NUM> can be reconstructed from a reference block <NUM> that is in the reconstructed area (<NUM>). The position offset between the reference block (<NUM>) and the current block (<NUM>) is referred to as a block vector (<NUM>) (or BV (<NUM>)).

In some examples (e.g., VVC), the search range of intra block copy mode is constrained to be within the current CTU. Then, the memory requirement to store reference samples for the intra block copy mode is <NUM> (largest) CTU size of samples. In an example, the (largest) CTU has a size of 128x128, and the current block has a size of 64x64. Thus, in some embodiments, the total memory (e.g., cache memory with fast access speed than a main storage) is able to store samples for a size of 128x128, and the total memory includes an existing reference sample memory portion to store reconstructed samples in the current block, such as a 64x64 region, and additional memory portion to store samples of three other regions of the size 64x64. Thus, in some examples, the effective search range of the intra block copy mode is extended to some part of the left CTU while the total memory requirement for storing reference pixels are kept unchanged (e.g., <NUM> CTU size, <NUM> times of the 64x64 reference sample memory in total).

In some embodiments, an update process is performed to update the stored reference samples from the left CTU to the reconstructed samples from the current CTU. Specifically, in some examples, the update process is done on a 64x64 luma sample basis. In an embodiment, for each of the four 64x64 block regions in the CTU size memory, the reference samples in the regions from the left CTU can be used to predict the coding block in current CTU with CPR mode until any of the blocks in the same region of the current CTU is being coded or has been coded.

<FIG> show examples of effective search ranges for the intra block copy mode according to an embodiment of the disclosure. In some examples, an encoder/decoder includes a cache memory that is able to store samples of one CTU, such as 128x128 samples. Further, in the <FIG> examples, a current block for prediction has a size of 64x64 samples. It is noted that the examples can be suitably modified for current block of other suitable sizes.

Each of <FIG> shows a current CTU (<NUM>) and a left CTU (<NUM>). The left CTU (<NUM>) includes four blocks (<NUM>)-(<NUM>), and each block has a sample size of 64x64 samples. The current CTU (<NUM>) includes four block (<NUM>)-(<NUM>), and each block has a sample size of 64x64 samples. The current CTU (<NUM>) is the CTU that includes a current block (as shown by a label "Curr" and with vertical stripe pattern) under reconstruction. The left CTU (<NUM>) is the immediate neighbor on the left side of the current CTU (<NUM>). It is noted in <FIG>, the grey blocks are blocks that are already reconstructed, and the white blocks are blocks that are to be reconstructed.

In <FIG>, the current block under reconstruction is the block (<NUM>). The cache memory stores reconstructed samples in the blocks (<NUM>), (<NUM>) and (<NUM>), and the cache memory will be used to store reconstructed samples of the current block (<NUM>). In the <FIG> example, the effective search range for the current block (<NUM>) includes the blocks (<NUM>), (<NUM>) and (<NUM>) in the left CTU (<NUM>) with reconstructed samples stored in the cache memory. It is noted that, in an embodiment, the reconstructed samples of the block (<NUM>) are stored in a main memory (e.g., are copied from the cache memory to the main memory before the reconstruction of the block (<NUM>)) that has a slower access speed than the cache memory.

In <FIG>, the current block under reconstruction is the block (<NUM>). The cache memory stores reconstructed samples in the blocks (<NUM>), (<NUM>) and (<NUM>), and the cache memory will be used to store reconstructed samples of the current block (<NUM>). In the <FIG> example, the effective search range for the current block (<NUM>) includes the blocks (<NUM>) and (<NUM>) in the left CTU (<NUM>) and (<NUM>) in the current CTU (<NUM>) with reconstructed samples stored in the cache memory. It is noted that, in an embodiment, the reconstructed samples of the block (<NUM>) are stored in a main memory (e.g., are copied from the cache memory to the main memory before the reconstruction of the block (<NUM>)) that has a slower access speed than the cache memory.

In <FIG>, the current block under reconstruction is the block (<NUM>). The cache memory stores reconstructed samples in the blocks (<NUM>), (<NUM>) and (<NUM>), and the cache memory will be used to store reconstructed samples of the current block (<NUM>). In the <FIG> example, the effective search range for the current block (<NUM>) includes the blocks (<NUM>) in the left CTU (<NUM>) and (<NUM>) and (<NUM>) in the current CTU (<NUM>) with reconstructed samples stored in the cache memory. It is noted that, in an embodiment, the reconstructed samples of the block (<NUM>) are stored in a main memory (e.g., are copied from the cache memory to the main memory before the reconstruction of the block (<NUM>)) that has a slower access speed than the cache memory.

In <FIG>, the current block under reconstruction is the block (<NUM>). The cache memory stores reconstructed samples in the blocks (<NUM>), (<NUM>) and (<NUM>), and the cache memory will be used to store reconstructed samples of the current block (<NUM>). In the <FIG> example, the effective search range for the current block (<NUM>) includes the blocks (<NUM>), (<NUM>) and (<NUM>) in the current CTU (<NUM>) with reconstructed samples stored in the cache memory. It is noted that, in an embodiment, the reconstructed samples of the block (<NUM>) are stored in a main memory (e.g., are copied from the cache memory to the main memory before the reconstruction of the block (<NUM>)) that has a slower access speed than the cache memory.

In the above examples, the cache memory has a total memory space for <NUM> (largest) CTU size. The examples can be suitably adjusted for other suitable CTU sizes.

According to an aspect of the disclosure, before intra block copy is used, a coding block may be coded in intra mode (intra coding) or inter mode (inter picture prediction). In an example, a prediction mode flag "pred_mode_flag" with <NUM> bin (binary bit) is signaled or inferred at coding block level to differentiate the coding modes (intra mode or inter mode) for the current block. For example, when the prediction mode flag "pred_mode_flag" is equal to <NUM>, MODE_INTER (indicating inter mode) is used; otherwise (pred_mode_flag is equal to <NUM>), MODE_INTRA (indicating intra mode) is used.

In some embodiments when the intra block copy is used, to indicate the intra block copy for a current block, the prediction mode flag "pred_mode_flag" is signaled (e.g.,, pred_mode_flag is equal to <NUM>) to indicate inter mode, then inferred or explicit signaling method is used to indicate if current block is coded in intra block copy mode. In an inferred method, in an example, the current block is in merge mode and when the merge candidate is coded in intra block copy mode, then the current block is coded in intra block copy mode as well. In an explicit signaling, when a reference index is signaled to indicate the current block refers to a reference picture that is the current picture, then the current block is coded in intra block copy mode.

According to some aspects of the disclosure, intra block copy is considered as a separate mode other than the intra prediction mode (intra mode) or the inter prediction mode (inter mode), the signaling of intra block copy usage (e.g., using a flag "pred_mode_ibc_flag") and pred_mode_flag are specified at block level.

The proposed methods may be used separately or combined in any order. Further, each of the methods (or embodiments), encoder, and decoder 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. In the following, the term block may be interpreted as a prediction block, a coding block, or a coding unit, i.e. CU.

The following discussions are based on the assumption that the intra block copy (IBC) mode is considered as a separate mode, different from intra prediction mode or inter prediction mode.

In some embodiments, the IBC prediction mode usage flag "pred_mode ibc__flag" is signaled or inferred at a block level based on a combination of the signaling of the skip mode flag (cu_skip_flag), the prediction mode flag (pred_mode_flag) and the tile group type of current tile group (tile_group_type).

According to a first aspect of the disclosure, the IBC prediction mode usage flag "pred_mode_ibc_flag" is signaled when a high level IBC enable flag (such as sps_ibc_enabled_flag) is true, and with one or more of other conditions.

In an example, the high level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is not coded using skip mode (e.g., cu_skip_flag = <NUM>) in I tile group (e.g., tile_group_type=I), then the current block can be IBC prediction mode or can be intra prediction mode. Thus, the pred_mode_ibc_flag is signaled to indicate whether the current block is coded in intra prediction mode (<NUM>) or IBC prediction mode (<NUM>).

In another example, the high level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is coded using skip mode (e.g., cu_skip_flag = <NUM>) in I tile group (e.g., tile_group_type=I), then the current block is inferred to be coded in the IBC prediction mode and the IBC prediction mode usage flag "pred_mode_ibc__flag" is not signaled in an example.

In another example, the current coding block is not coded using intra prediction mode (CuPredMode[ x0 ][ y0 ] != MODE_INTRA) in P or B tile group (slice_tile type != I), and the current block is coded in skip mode (cu_skip_flag = <NUM>), then the current block can be coded in the inter prediction mode or the IBC prediction mode. Thus, the pred_mode_ibc_flag is signaled to indicate whether the current block is code in inter prediction mode (<NUM>) or the IBC prediction mode (<NUM>).

In another example, the high level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current block is not coded in skip mode (cu_skip_flag = <NUM>), then the current block can be any of the intra prediction mode, inter prediction mode and IBC prediction mode. In an embodiment, the pred_mode_flag is signaled (for example the pred_mode_flag is signaled to be <NUM>) to indicate that the current block is not intra prediction mode. The pred_mode_ibc_flag is then signaled to tell whether the current block is code in inter prediction mode (<NUM>) or the IBC prediction mode (<NUM>).

In another example, when CuPredMode[ x0 ][ y0 ] is equal to MODE_INTRA (for example, the pred_mode_flag is signaled to be <NUM>), then the current block is coded in intra prediction mode, there is no need to signal extra flag (e.g., pred_mode_ibc_flag).

In an embodiment according to the first aspect of the disclosure, the syntax and associated semantics for pre_mode_flag and pred_mode_ibc_flag are specified in Table <NUM>. In this embodiment, the block size for IBC mode is not constrained. It is noted that the current block is luma block not chroma block in various examples.

In an example, when pred_mode_flag is decoded to be <NUM>, the current coding unit is coded in the inter prediction mode or the IBC prediction mode. Then, pred_mode_flag is decoded from the coded video bitstream. When pred_mode_flag is decoded to be <NUM>, the current coding unit is coded in intra prediction mode.

In some embodiments, the variable CuPredMode[ x ][ y ] (prediction mode of the coding unit) is initialized based on the pred_mode_flag, for x = x0. x0 + cbWidth -<NUM> and y = y0. y0 + cbHeight - <NUM>, and then will be further determined based on other conditions. For example, when pred_mode_flag is equal to <NUM>, CuPredMode[ x ][ y ] is set equal to MODE_INTER; and when pred_mode_flag is equal to <NUM>, CuPredMode[ x ][ y ] is set equal to MODE_INTRA.

In some examples, when pred_mode_flag is not present in the coded video bitstream, the variable CuPredMode[ x ][ y ] is inferred to be equal to (cu_skip_flag[ x0 ][ y0 ] = = <NUM>) ? MODE_INTRA : MODE_IBC when decoding an I tile group and MODE_INTER when decoding a P or B tile group for x = x0. x0 + cbWidth - <NUM> and y = y0. y0 + cbHeight - <NUM>, where cbWidth is the width of the current block, and cbHeight is the height of the current block. For example, in I tile group, the possible prediction modes are MODE_INTRA and MODE_IBC. Then, the prediction mode can be determined based on the cu_skip_flag. When the cu_skip_flag is <NUM> (no skip mode), the prediction mode for the current block is MODE_INTRA; and when the cu_skip_flag is <NUM> (skip mode), the prediction mode for the current block is MODE_IBC. Further, in P or B tile group, and the pred_mode_flag is not present, then the prediction mode is inferred to be MODE_INTER.

In some examples, when pred_mode_ibc_flag is decoded to be <NUM>, the current coding unit is not coded in the IBC prediction mode; and when pred_mode_ibc_flag is decoded to be <NUM>, the current coding unit is coded in the IBC prediction mode. When pred_mode_ibc_flag is not present in the coded video bitstream, the pred_mode_ibc_flag is inferred to be equal to sps_ibc_enabled_flag when decoding an I tile group, and is inferred to be equal to <NUM> when decoding a P or B tile group.

In some embodiments, based on the pred_mode_ibc_flag, the current prediction mode for the current block can be determined. In an example, the variable CuPredMode[ x ][ y ] is derived based on the pred_mode_ibc_flag for x = x0. x0 + cbWidth - <NUM> and y = y0. y0 + cbHeight - <NUM>. For example, when pred_mode_ibc_flag equals <NUM>, CuPredMode[ x ][ y ] is set to MODE_INTRA when decoding an I tile group, and MODE_INTER when decoding a P or B tile group; and when pred_mode_ibc_flag equals <NUM>, CuPredMode[ x ][ y ] is set to MODE_IBC.

According to a second aspect of the disclosure, block sizes are considered in the process to determine the prediction mode from the intra prediction mode, the inter prediction mode and the IBC prediction mode. For example, width and/or height of an IBC coded block is smaller than a threshold in some constrain examples. Accordingly, pred_mode_ibc_flag is signaled when high level ibc enable flag (such as sps_ibc_enabled_flag) is true, when the block size meets the constrains (IBC coded block should be smaller than a threshold each side) and with one or more of other conditions.

In another example, the high level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is coded using skip mode (e.g., cu_skip_flag = <NUM>) in I tile group (e.g., tile_group_type=I), then the current block is inferred to be coded in the IBC prediction mode. Then, no pred_mode_ibc_flag is signaled in the coded video bitstream.

In another example, the current coding block is not coded using intra prediction mode (CuPredMode[ x0 ][ y0 ] != MODE_INTRA) in P or B tile group (slice tile type != I), and the current block is coded in skip mode (cu_skip_flag = <NUM>), then the current block can be coded in the inter prediction mode or the IBC prediction mode. Thus, the pred_mode_ibc_flag is signaled in the coded video bitstream to indicate whether the current block is coded in inter prediction mode (<NUM>) or the IBC prediction mode (<NUM>).

In another example, when CuPredMode[ x0 ][ y0 ] is equal to MODE_INTRA (for example, the pred_mode_flag is signaled to be <NUM>), then the current block is coded in intra prediction mode, there is no need to signal extra flag.

It is noted that when pred_mode_ibc_flag is not signaled, depending on situations, the prediction mode for the current block may be either MODE_INTRA, MODE_INTER or MODE_IBC.

In an example, when sps_ibc_enabled_flag is false, or the sizes of the current block do not meet the size requirement, then current block cannot be coded in IBC mode. Accordingly the current block is coded in intra or inter prediction mode, according to other conditions.

In another example, sps_ibc_enabled_flag is true, and the sizes of the current block meet the size requirement. When cu_skip_flag equals <NUM>, and current tile group type is I, then current block is coded in MODE_IBC. When pred_mode_flag is signaled to be intra prediction mode and current tile group type is not I, then the current block is coded in MODE_INTRA.

In I tile group, when the sizes of the current block size do not meet the size requirement, the skip mode flag (e.g.,, cu_skip_flag) does not need to be signaled (can be inferred to be false), or the skip mode flag can be signaled but always be equal to <NUM> (false).

In an embodiment according to the second aspect of the disclosure, the syntax and associated semantics for pre_mode_flag and pred_mode_ibc_flag are specified in Table <NUM>. In this embodiment, the block size for IBC prediction mode is constrained not to be larger than a threshold for each side (width and height). For example, the size requirement uses a width threshold WIDTH_THD and a height threshold HEIGHT_THD to constrain the sizes of the IBC coded blocks. For an IBC coded block, the width of the IBC coded block is smaller than WIDTH_THD and the height of the IBC coded block is smaller than HEIGHT_THD. In an example, WIDTH_THD and HEIGHT_THD are set to be <NUM>. The semantics for these two flags is similar as the above embodiment.

In an example, when pred_mode_flag is decoded to be <NUM>, the current coding unit is coded in the inter prediction mode or the IBC prediction mode. When pred_mode_flag equals to <NUM>, the current coding unit is coded in intra prediction mode.

In some examples, the variable CuPredMode[ x ][ y ] is initialized based on the pred_mode_flag, for x = x0. x0 + cbWidth -<NUM> and y = y0. y0 + cbHeight - <NUM>. For example, when pred_mode_flag is decoded to be <NUM>, CuPredMode[ x ][ y ] is set equal to MODE_INTER; and when pred_mode_flag is decoded to be <NUM>, CuPredMode[ x ][ y ] is set equal to MODE_INTRA.

In some examples, when pred_mode_flag is not present in the coded video bitstream, the variable CuPredMode[ x ][ y ] is inferred to be equal to (cu_skip_flag[ x0 ][ y0 ] = = <NUM>) ? MODE_INTRA : MODE_IBC when decoding an I tile group and MODE_INTER when decoding a P or B tile group for x = x0. x0 + cbWidth - <NUM> and y = y0. y0 + cbHeight - <NUM>. For example, in I tile group, the possible prediction modes are MODE_INTRA and MODE_IBC. Then, the prediction mode can be determined based on the cu_skip__flag. When the cu_skip_flag is <NUM> (no skip mode), the prediction mode for the current block is MODE INTRA; and when the cu_skip_flag is <NUM> (skip mode), the prediction mode for the current block is MODE_IBC. Further, in P or B tile group, and the pred_mode_flag is not present, then the prediction mode is inferred to be MODE_INTER.

In some examples, when pred_mode_ibc_flag is decoded to be <NUM>, the current coding unit is not coded in the IBC prediction mode; and when pred_mode_ibc_flag is decoded to be <NUM>, the current coding unit is coded in the IBC prediction mode. When pred_mode_ibc_flag is not present in the coded video bitstream, the pred_mode_ibc_flag is inferred to be equal to (sps_ibc_enabled_flag&&cbWidth<WIDTH_THD&&cbHeight<HEIGHT_THD) when decoding an I tile group, and is inferred to be equal to <NUM> when decoding a P or B tile group.

According to a third aspect of the disclosure, the prediction mode of the current coding block is jointly decided by pred_mode_ibc_flag, cu_skip_flag, pred_mode_flag and tile_group_type. In some examples, no initialization of the prediction mode of the current coding block (e.g., initialization of CuPredMode[ x ][ y ] for x = x0. x0 + cbWidth -<NUM> and y = y0. y0 + cbHeight - <NUM>) is performed, pred_mode_ibc_flag, cu_skip_flag, pred_mode_flag and tile_group type are decoded or inferred, and then the prediction mode is directly determined based on a combination of pred_mode_ibc_flag, cu_skip_flag, pred_mode_flag and tile_group_type.

In an example, the high level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is not coded using skip mode (e.g., cu_skip_flag = <NUM>) in I tile group (e.g., tile_group_type=I), then the current block can be IBC prediction mode or can be intra prediction mode. Thus, the pred_mode_ibc_flag is signaled to indicate whether the current block is coded in intra prediction mode (e.g., the pred_mode_ibc_flag equals <NUM>) or IBC prediction mode (e.g., the pred_mode_ibc_flag equals <NUM>).

In another example, the high level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is coded using skip mode (e.g., cu_skip_flag = <NUM>) in I tile group (e.g., tile_group_type=I), then the current block is inferred to be coded in the IBC prediction mode.

In another example, the current coding block is not coded using intra prediction mode (CuPredMode[ x0 ][ y0 ] != MODE_INTRA) in P or B tile group (slice tile type != I), and the current block is coded in skip mode (cu_skip_flag = <NUM>), then the current block can be coded in the inter prediction mode or the IBC prediction mode. Thus, the pred_mode_ibc_flag is signaled to indicate whether the current block is code in inter prediction mode (e. , the pred_mode_ibc_flag equals <NUM>) or the IBC prediction mode (e. , the pred_mode_ibc_flag equals <NUM>).

In another example, when the current block is not coded in skip mode (e.g., cu_skip_flag=<NUM>) and CuPredMode[ x0 ][ y0 ] equals to MODE_INTRA (for example, the pred_mode_flag is signaled to be <NUM>) in P or B tile group, then the current block is coded in intra prediction mode, there is no need to signal extra flag.

In an embodiment according to the third aspect of the disclosure, the syntax and associated semantics for pre_mode_flag and pred_mode_ibc_flag are specified in Table <NUM> that is the same as Table <NUM>. In this embodiment, the block size for IBC mode is not constrained. It is noted that the current block is luma block not chroma block in various examples.

In an example, when pred_mode_flag is decoded to be <NUM>, the current coding unit is coded in the inter prediction mode or the IBC prediction mode. When pred_mode_flag is decoded to be <NUM>, the current coding unit is coded in intra prediction mode or IBC prediction mode.

When pred_mode_flag is not present in the coded video bitstream, the pred_mode_flag is inferred according to cu_skip_flag and the type of the tile group. For example, for decoding an I tile group, when cu_skip_flag[ x0 ][ y0 ] equals to <NUM> (not in skip mode), pred_mode_flag is set to <NUM>, and when cu_skip_flag[ x0 ][ y0 ] equals to <NUM>, the pred_mode_flag is set to <NUM>. For decoding P or B tile group, the pred_mode_flag is set to <NUM>.

Further, in some embodiments, the variable CuPredMode[ x ][ y ] (the prediction mode of the current block) is derived based on a combination of the values of pred_mode_flag and pred_mode_ibc_flag, for x = x0. x0 + cbWidth - <NUM> and y = y0. y0 + cbHeight - <NUM>, for example according to Table <NUM>:.

In Table <NUM>, when pred_mode_flag is <NUM> and pred_mode_ibc_flag is <NUM>, the variable CuPredMode[ x ][ y ] is MODE INTER; when pred_mode_flag is <NUM> and pred_mode_ibc_flag is <NUM>, the variable CuPredMode[ x ][ y ] is MODE INTRA; when pred_mode_ibc_flag is <NUM>, the the variable CuPredMode[ x ][ y ] is MODE_IBC no matter the value of pred_mode_flag.

It is noted that, in various embodiments, the usage of sps_ibc_enabled_flag (IBC enable flag at SPS level) may be replaced by another high level IBC enable flag, such as IBC enable flag at picture level, IBC enable flag at tile group level, and the like.

<FIG> shows a flow chart outlining a process (<NUM>) according to an embodiment of the disclosure. The process (<NUM>) can be used in the reconstruction of a block coded in intra mode, so to generate a prediction block for the block under reconstruction. In various embodiments, the process (<NUM>) are executed by processing circuitry, such as the processing circuitry in the terminal devices (<NUM>), (<NUM>), (<NUM>) and (<NUM>), the processing circuitry that performs functions of the video encoder (<NUM>), the processing circuitry that performs functions of the video decoder (<NUM>), the processing circuitry that performs functions of the video decoder (<NUM>), the processing circuitry that performs functions of the video encoder (<NUM>), and the like. In some embodiments, the process (<NUM>) is implemented in software instructions, thus when the processing circuitry executes the software instructions, the processing circuitry performs the process (<NUM>). The process starts at (S1101) and proceeds to (S1110).

At (S1110), prediction information of a current block in a picture is decoded from a coded video bitstream.

At (S1120), an IBC prediction mode usage flag is decoded or inferred from the prediction information. Then, based on the IBC prediction mode usage flag, in an example, an IBC prediction mode that is separate from an intra prediction mode and an inter prediction mode is determined. In some embodiments, the IBC prediction mode, the intra prediction mode and the inter prediction modes are three separate prediction modes. In an example, the IBC prediction mode is selected based on a prediction mode flag (e.g., pred_mode_flag) that is indicative of a possible mode selected from the IBC prediction mode and one of the intra prediction mode and the inter prediction mode, and the IBC prediction mode usage flag (e.g., pred_mode_ibc_flag). The prediction mode flag and the IBC prediction mode usage flag can be decoded from the coded video bitstream or can be inferred.

At (S1130), in response to the determination of the IBC prediction mode, a block vector is determined. The block vector points to a reference area in the picture.

At (S1140), the current block is reconstructed based on reference samples in the reference area in the picture. Then the process proceeds to (S1199) and terminates.

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 bidirectional, 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.

As an example and not by way of limitation, the computer system having architecture (<NUM>), and specifically the core (<NUM>) can provide functionality as a result of processor(s) (including CPUs, GPUs, FPGA, accelerators, and the like) executing software embodied in one or more tangible, computer-readable media. Such computer-readable media can be media associated with user-accessible mass storage as introduced above, as well as certain storage of the core (<NUM>) that are of non-transitory nature, such as core-internal mass storage (<NUM>) or ROM (<NUM>). The software implementing various embodiments of the present disclosure can be stored in such devices and executed by core (<NUM>). A computer-readable medium can include one or more memory devices or chips, according to particular needs. The software can cause the core (<NUM>) and specifically the processors therein (including CPU, GPU, FPGA, and the like) to execute particular processes or particular parts of particular processes described herein, including defining data structures stored in RAM.

(<NUM>) and modifying such data structures according to the processes defined by the software. In addition or as an alternative, the computer system can provide functionality as a result of logic hardwired or otherwise embodied in a circuit (for example: accelerator (<NUM>)), which can operate in place of or together with software to execute particular processes or particular parts of particular processes described herein. Reference to software can encompass logic, and vice versa, where appropriate. Reference to a computer-readable media can encompass a circuit (such as an integrated circuit (IC)) storing software for execution, a circuit embodying logic for execution, or both, where appropriate. The present disclosure encompasses any suitable combination of hardware and software. Appendix A: Acronyms.

Claim 1:
A method for video decoding in a decoder, comprising:
decoding (<NUM>) prediction information of a current block in a picture from a coded video bitstream;
determining (<NUM>), based on an intra block copy, IBC, prediction mode usage flag from the decoded prediction information, an IBC prediction mode that is separate from an inter prediction mode and an intra prediction mode;
determining (<NUM>), a block vector that points to a reference area in the picture in response to the determination of the IBC prediction mode; and
reconstructing (<NUM>) the current block based on reference samples within the reference area in the picture;
wherein the method further comprises:
inferring the IBC prediction mode usage flag based on an IBC enable flag and a type of a tile group or slice that the current block belongs to;
wherein when the tile group or slice type is B or P type, the current block satisfies a size constraint, and the IBC prediction mode usage flag is not signaled in the coded video bitstream, the method further comprises:
inferring the IBC prediction mode usage flag to be <NUM>.