Method and apparatus for video coding

Abstract

Aspects of the present disclosure provide methods and apparatuses for video encoding / decoding. In some examples, the apparatus for video decoding includes a receiving circuit and a processing circuit. For example, the processing circuit decodes prediction information of the current block in a picture from a coded video bitstream and determines an IBC prediction mode distinct from the inter prediction mode and the intra prediction mode based on an intra-block copy (IBC) prediction mode use flag from the decoded prediction information. Additionally, the processing circuit determines a block vector pointing to a reference region in the picture in response to the determination of the IBC prediction mode and reconstructs the current block based on reference samples in the reference region in the picture.

Description

Technology Field

[0001] Integration by citation

[0002] This application claims the benefit of priority to U.S. Provisional Application No. 62 / 800,397, "METHODS FOR SIGNALING FLAGS OF INTRA BLOCK COPY AND PREDICTION MODE," filed February 1, 2019, and the benefit of priority to U.S. Patent Application No. 16 / 526,689, "METHOD AND APPARATUS FOR VIDEO CODING," filed July 30, 2019. The entire disclosures of the prior applications are incorporated herein by reference in their entirety.

[0003] Technology field

[0004] The present disclosure describes embodiments generally related to video coding. Background Technology

[0005] The background description provided in this specification is intended to provide a general context for the present disclosure. The research of the currently registered inventors and any modes of description described in the background section that may not otherwise be regarded as prior art at the time of filing are not recognized as prior art with respect to the present disclosure, either explicitly or implicitly.

[0006] Video coding and decoding can be performed using inter-picture prediction accompanied by motion compensation. Uncompressed digital video may contain a series of pictures, each having, for example, a spatial dimension of 1920x1080 luminance samples and associated chrominance samples. This series of pictures may have a fixed or variable picture rate (informally also known as the frame rate), for example, 60 pictures per second or 60 Hz. Uncompressed video has significant bitrate requirements. For example, 1080p60 4:2:0 video at 8 bits per sample (1920x1080 luminance sample resolution at a 60 Hz frame rate) requires bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 gigabytes of storage space.

[0007] One objective of video coding and decoding may be to reduce redundancy in the input video signal through compression. Compression can help reduce the previously described bandwidth or storage requirements by more than two orders of magnitude in some cases. Both lossless and lossy compression, as well as combinations thereof, can be utilized. Lossless compression refers to techniques where an exact copy of the original signal can be reconstructed from the compressed original signal. When using lossy compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signals is small enough to make the reconstructed signal useful for the intended application. For video, lossy compression is widely used. The amount of acceptable distortion depends on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio may reflect the fact that higher acceptable distortion can yield a higher compression ratio.

[0008] Video encoders and decoders can utilize techniques from several broad categories, including, for example, motion compensation, transformation, quantization, and entropy coding.

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

[0010] For example, traditional intra-coding, such as that known from MPEG-2 generation coding techniques, does not use intra-prediction. However, some newer video compression techniques include methods that attempt to use surrounding sample data and / or metadata acquired during the encoding / decoding of spatially adjacent and preceding data blocks in the decoding order, for example. These techniques are hereinafter referred to as "intra-prediction" techniques. Note that in at least some cases, intra-prediction uses only reference data from the current picture being reconstructed, rather than from reference pictures.

[0011] There may be many different forms of intra-prediction. If more than one of these techniques can be used in a given video coding technique, the technique in use may be coded in an intra-prediction mode. In certain cases, modes may have submodes and / or parameters, which may be coded individually or included in a mode codeword. The codeword used for a given mode / submode / parameter combination can influence the coding efficiency gain through intra-prediction, and the entropy coding technique used to convert the codewords into a bitstream can do so as well.

[0012] Specific modes of intra-prediction were introduced with H.264, improved in H.265, and further enhanced in newer coding techniques such as JEM (joint exploration model), VVC (versatile video coding), and BMS (benchmark set). A predictor block can be formed using neighbor sample values ​​belonging to already available samples. The sample values ​​of neighbor samples are copied into the predictor block according to direction. A reference to the direction in use can be encoded in the bitstream or predicted itself.

[0013] Referring to FIG. 1, a subset of 9 known predictor directions from the 33 possible predictor directions of H.265 (corresponding to 33 angle modes out of 35 intra modes) is shown in the lower right. The point (101) where the arrows converge indicates the sample being predicted. The arrows indicate the direction in which the sample is being predicted. For example, arrow (102) indicates that the sample (101) is predicted to the upper right from the sample or samples at an angle of 45 degrees from the horizontal. Similarly, arrow (103) indicates that the sample (101) is predicted to the lower left from the sample or samples at an angle of 22.5 degrees from the horizontal.

[0014] Referring still to FIG. 1, a square block (104) of 4x4 samples (indicated by a bold dashed line) is depicted in the upper left. The square block (104) contains 16 samples, each labeled "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 2nd sample in the Y dimension (from the top) and the 1st sample in the X dimension (from the left). Similarly, sample S44 is the 4th sample in both the Y and X dimensions of the block (104). Since the block is 4x4 samples in size, S44 is located in the lower right. Additional reference samples following a similar numbering scheme are shown. For the block (104), the reference sample is labeled R, its Y position (e.g., row index) and X position (column index). In both H.264 and H.265, the predicted samples are adjacent to the block being reconstructed; therefore, negative values ​​do not need to be used.

[0015] Intra-picture prediction can be performed by appropriately copying reference sample values ​​from neighboring samples by the signaled prediction direction. For example, assume that the coded video bitstream contains signaling indicating a prediction direction corresponding to the arrow (102) for this block—that is, samples are predicted from the prediction sample or samples upward to the right, at a 45-degree angle from the horizontal. In that case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Subsequently, sample S44 is predicted from reference sample R08.

[0016] In certain cases, the values ​​of multiple reference samples can be combined, for example, through interpolation to calculate a reference sample, particularly when the directions are not evenly divided by 45 degrees.

[0017] As video coding technology has advanced, the number of possible directions has increased. In H.264 (2003), nine different directions could be represented. This increased to 33 in H.265 (2013), and JEM / VVC / BMS could support up to 65 directions at the time of release. Experiments were conducted to identify the most likely directions, and specific techniques in entropy coding were used to represent these likely directions with a small number of bits, allowing for specific penalties for less likely directions. Additionally, directions themselves can sometimes be predicted from neighboring directions used in adjacent, already decoded blocks.

[0018] FIG. 2 illustrates a schematic diagram (201) depicting 65 intra-predicted directions according to JEM to illustrate the number of predicted directions increasing over time.

[0019] The mapping of intra-predicted direction bits within a coded video bitstream representing direction can vary depending on the video coding technique; for example, it can range from simple direct mappings of predicted directions to intra-predicted modes to complex adaptive methods involving codewords, most probable modes, and similar techniques. However, in all cases, there may be specific directions that are statistically less likely to occur in the video content than other specific directions. Since the goal of video compression is to reduce redundancy, in a well-functioning video coding technique, these less likely directions will be represented by a larger number of bits than the more likely directions.

[0020] Aspects of the present disclosure provide methods and apparatuses for video encoding / decoding. In some examples, the apparatus for video decoding includes a receiving circuit and a processing circuit. For example, the processing circuit decodes prediction information of the current block in a picture from a coded video bitstream and determines an IBC prediction mode distinct from the inter prediction mode and the intra prediction mode based on an intra block copy (IBC) prediction mode use flag from the decoded prediction information. Additionally, the processing circuit determines a block vector pointing to a reference region in the picture in response to the determination of the IBC prediction mode and reconstructs the current block based on reference samples in the reference region in the picture.

[0021] In some embodiments, the processing circuit decodes an IBC prediction mode use flag from the coded video bitstream. In other embodiments, the processing circuit infers an IBC prediction mode use flag based on the IBC enable flag and the type of the tile group to which the current block belongs. In one example, the processing circuit infers an IBC prediction mode use flag to indicate IBC prediction mode when the IBC enable flag indicates enabling, the tile group is of type I, and the current block meets size requirements. The IBC enable flag is a parameter of at least one level among the video level, sequence level, picture level, and tile group level.

[0022] In one embodiment, when the tile group or slice type is of type I, the current block satisfies the size constraint, and the IBC prediction mode use flag is not signaled in the coded video bitstream, the processing circuit infers the value of the IBC prediction mode use flag according to the IBC enable flag. In another embodiment, when the tile group or slice type is of type B or P, the current block satisfies the size constraint, and the IBC prediction mode use flag is not signaled in the coded video bitstream, the processing circuit infers that the IBC prediction mode use flag is 0.

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

[0024] In some embodiments, the processing circuit determines a prediction mode flag and an IBC prediction mode use flag based on decoded prediction information. Then, the processing circuit selects a prediction mode from the IBC prediction mode, intra prediction mode, and inter prediction mode based on a combination of the prediction mode flag and the IBC prediction mode use flag.

[0025] In some examples, the processing circuit determines the IBC prediction mode for the current block when the current block meets size requirements.

[0026] Aspects of the present disclosure also provide a non-transient computer-readable medium storing instructions that cause a computer to perform a method for video decoding when executed by a computer for video decoding. Brief explanation of the drawing

[0027] Additional features, nature, and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings. Figure 1 is a schematic diagram of an exemplary subset of intra prediction modes. Figure 2 is a diagram of exemplary intra-predicted directions. FIG. 3 is a schematic diagram of a simplified block diagram of a communication system (300) according to one embodiment. FIG. 4 is a schematic diagram of a simplified block diagram of a communication system (400) according to one embodiment. FIG. 5 is a schematic diagram of a simplified block diagram of a decoder according to one embodiment. FIG. 6 is a schematic diagram of a simplified block diagram of an encoder according to one embodiment. FIG. 7 illustrates a block diagram of an encoder according to another embodiment. FIG. 8 illustrates a block diagram of a decoder according to another embodiment. FIG. 9 illustrates an example of an intra-block copy according to an embodiment of the present disclosure. FIGS. 10a to 10d illustrate examples of valid search ranges for an intra-block copy mode according to an embodiment of the present disclosure. FIG. 11 illustrates a flowchart outlining a process (1100) according to one embodiment of the present disclosure. FIG. 12 is a schematic diagram of a computer system according to one embodiment. Specific details for implementing the invention

[0028] FIG. 3 illustrates a simplified block diagram of a communication system (300) according to one embodiment of the present disclosure. The communication system (300) includes a plurality of terminal devices capable of communicating with each other, for example, through a network (350). For example, the communication system (300) includes a first pair of terminal devices (310 and 320) interconnected through the network (350). In the example of FIG. 3, the first pair of terminal devices (310 and 320) perform unidirectional transmission of data. For example, a terminal device (310) may encode video data (for example, a stream of video pictures captured by the terminal device (310)) for transmission to another terminal device (320) through the network (350). The encoded video data may be transmitted in the form of one or more coded video bitstreams. The terminal device (320) receives coded video data from the network (350), decodes the coded video data to recover video pictures, and can display the video pictures according to the recovered video data. Unidirectional data transmission may be common in media serving applications, etc.

[0029] In another example, the communication system (300) includes a second pair of terminal devices (330 and 340) that perform bidirectional transmission of coded video data that may occur, for example, during a video conference. For bidirectional transmission of data, in one example, each terminal device among the terminal devices (330 and 340) may code video data (e.g., a stream of video pictures captured by the terminal device) for transmission to another terminal device among the terminal devices (330 and 340) via a network (350). Each terminal device among the terminal devices (330 and 340) may also receive coded video data transmitted by another terminal device among the terminal devices (330 and 340), decode the coded video data to recover video pictures, and display the video pictures on an accessible display device according to the recovered video data.

[0030] In the example of FIG. 3, the terminal devices (310, 320, 330, and 340) may be exemplified as servers, personal computers, and smartphones, but the principles of the present disclosure are not limited thereto. Embodiments of the present disclosure are applied in laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network (350) represents any number of networks that transmit coded video data between terminal devices (310, 320, 330, and 340), including, for example, wired and / or wireless communication networks. The communication network (350) may exchange data on circuit-switched and / or packet-switched channels. Representative networks include communication networks, local area networks, wide area networks, and / or the Internet. For the purposes of this discussion, the architecture and topology of the network (350) may not be important to the operation of the present disclosure unless described herein.

[0031] FIG. 4 illustrates the arrangement of a video encoder and a video decoder in a streaming environment as an example of an application for the disclosed subject. The disclosed subject may be equally applicable to other video-enabled applications, including, for example, video conferencing, digital TV, storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0032] A streaming system may include a capture subsystem (413) which may include, for example, a digital camera, a video source (401) that generates a stream (402) of uncompressed video pictures. In one example, the stream (402) of video pictures includes samples captured by a digital camera. The stream (402) of video pictures, depicted in bold lines to emphasize the high data capacity compared to encoded video data (404) (or coded video bitstream), may be processed by an electronic device (420) comprising a video encoder (403) coupled to the video source (401). The video encoder (403) may include hardware, software, or a combination thereof to enable or implement the embodiments of the disclosed subject matter as described in more detail below. Encoded video data (404) (or encoded video bitstream (404)), depicted as a thin line to emphasize the low data capacity compared to the stream (402) of video pictures, may be stored on a streaming server (405) for future use. One or more streaming client subsystems, such as the client subsystems (406 and 408) in FIG. 4, may access the streaming server (405) to retrieve copies (407 and 409) of the encoded video data (404). The client subsystem (406) may include, for example, a video decoder (410) within an electronic device (430). The video decoder (410) decodes the incoming copy (407) of the encoded video data and generates an outgoing stream (411) of video pictures that can be rendered on a display (412) (e.g., a display screen) or another rendering device (not depicted). In some streaming systems, encoded video data (404, 407, and 409) (e.g., video bitstreams) may be encoded according to specific video coding / compression standards.Examples of such standards include ITU-T Recommendation H.265. In one 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.

[0033] Note that the electronic devices (420 and 430) may include other components (not shown). For example, the electronic device (420) may also include a video decoder (not shown) and the electronic device (430) may also include a video encoder (not shown).

[0034] FIG. 5 illustrates a block diagram of a video decoder (510) according to one embodiment of the present disclosure. The video decoder (510) may be included in an electronic device (530). The electronic device (530) may include a receiver (531) (e.g., a receiving circuit). The video decoder (510) may be used instead of the video decoder (410) in the example of FIG. 4.

[0035] The receiver (531) may receive one or more coded video sequences to be decoded by the video decoder (510); in the same or other embodiments, may receive one coded video sequence at a time, wherein the decoding of each coded video sequence is independent of other coded video sequences. The coded video sequences may be received from a channel (501), which may be a hardware / software link to a storage device that stores the encoded video data. The receiver (531) may receive the encoded video data along with other data, e.g., coded audio data and / or auxiliary data streams, which may be forwarded to their respective use entities (not described). The receiver (531) may separate the coded video sequences from the other data. To prevent network jitter, a buffer memory (515) may be combined between the receiver (531) and the entropy decoder / parser (520) (hereinafter "parser (520)"). In certain applications, the buffer memory (515) is part of the video decoder (510). In other applications, it may be outside the video decoder (510) (not described). In other applications, for example, to prevent network jitter, a buffer memory (not described) outside the video decoder (510) and, additionally, for example to handle playback timing, another buffer memory (515) inside the video decoder (510) may exist. When the receiver (531) is receiving data from a storage / forward device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (515) may not be needed or may be small.For use on best effort packet networks such as the Internet, a buffer memory (515) may be required, may be relatively large, advantageously adaptively sized, and may be implemented at least partially in an operating system or similar elements (not described) outside the video decoder (510).

[0036] The video decoder (510) may include a parser (520) to reconstruct symbols (521) from a coded video sequence. The categories of the symbols include information used to manage the operation of the video decoder (510), and potentially, as illustrated in FIG. 5, information for controlling a rendering device (512) (e.g., a display screen) that is not an integral part of the electronic device (530) but can be coupled to the electronic device (530). The control information for the rendering device(s) may be in the form of SEI (Supplemental Enhancement Information) messages or VUI (Video Usability Information) parameter set fragments (not depicted). The parser (520) may parse / entropy decode the received coded video sequence. The coding of the coded video sequence may follow video coding techniques or standards and may follow various principles including variable-length coding, Huffman coding, and arithmetic coding with or without context sensitivity. The parser (520) may extract a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder from the coded video sequence based on at least one parameter corresponding to a group. The subgroups may include Group of Pictures (GOPs), pictures, tiles, slices, macroblocks, Coding Units (CUs), blocks, Transform Units (TUs), Prediction Units (PUs), etc. The parser (520) may also extract information such as transform coefficients, quantizer parameter values, motion vectors, etc. from the coded video sequence.

[0037] The parser (520) can generate symbols (521) by performing an entropy decoding / parsing operation on a video sequence received from a buffer memory (515).

[0038] The reconstruction of the symbols (521) may involve a number of different units depending on the type of the coded video picture or its parts (e.g., inter- and intra-picture, inter- and intra-block), and other factors. Which units are involved, and the manner in which, may be controlled by subgroup control information parsed from the video sequence coded by the parser (520). The flow of this subgroup control information between the parser (520) and the number of units below is not described for clarity.

[0039] In addition to the functional blocks already mentioned, the video decoder (510) may be conceptually subdivided into a number of functional units as described below. In actual implementations operating under commercial constraints, many of these units may interact closely with one another and be at least partially integrated with one another. However, for the purpose of illustrating the disclosed subject, the conceptual subdivision into the functional units below is appropriate.

[0040] The first unit is a scaler / inverse transform unit (551). The scaler / inverse transform unit (551) receives quantized transform coefficients as well as control information, including which transform to use, block size, quantization factor, quantization scaling matrices, etc., as symbol(s) (521) from the parser (520). The scaler / inverse transform unit (551) can output blocks containing sample values ​​that can be input to an aggregator (555).

[0041] In some cases, the output samples of the scaler / inverse transform (551) may relate to an intra-coded block; that is, a block that uses prediction information from previously reconstructed parts of the current picture rather than prediction information from previously reconstructed pictures. Such prediction information may be provided by an intra-picture prediction unit (552). In some cases, the intra-picture prediction unit (552) uses surrounding already reconstructed information fetched from the current picture buffer (558) to generate a block of the same size and shape as the block being reconstructed. The current picture buffer (558) buffers, for example, a partially reconstructed current picture and / or a fully reconstructed current picture. In some cases, the aggregator (555) adds the prediction information generated by the intra-prediction unit (552) to the output sample information provided by the scaler / inverse transform unit (551) on a per-sample basis.

[0042] In other cases, the output samples of the scaler / inverse unit (551) may be intercoded and potentially associated with a motion-compensated block. In such cases, the motion compensation prediction unit (553) may access the reference picture memory (557) to fetch samples used for prediction. After motion-compensating the fetched samples according to the symbols (521) associated with the block, these samples may be added by the aggregator (555) to the output of the scaler / inverse unit (551) (in this case, called residual samples or residual signals) to generate output sample information. The addresses in the reference picture memory (557) where the motion compensation prediction unit (553) fetches prediction samples may be controlled by motion vectors available to the motion compensation prediction unit (553) in the form of symbols (521) that may have, for example, X, Y, and reference picture components. Motion compensation may also include interpolation of sample values ​​fetched from reference picture memory (557) when subsample accurate motion vectors are in use, motion vector prediction mechanisms, etc.

[0043] Various loop filtering techniques within the loop filter unit (556) may be performed on the output samples of the aggregator (555). Video compression techniques may include in-loop filter techniques that are made available to the loop filter unit (556) as symbols (521) from the parser (520) and are controlled by parameters included in the coded video sequence (also referred to as the coded video bitstream), but which respond not only to meta-information acquired during the decoding of the previous (in decoding order) parts of the coded picture or coded video sequence, but also to previously reconstructed and loop-filtered sample values.

[0044] The output of the loop filter unit (556) may be a sample stream that is not only output to the rendering device (512) but may also be stored in the reference picture memory (557) for use in future inter-picture predictions.

[0045] Certain coded pictures, when fully reconstructed, can be used as reference pictures for future prediction. For example, when a coded picture corresponding to a current picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (520)), the current picture buffer (558) can become part of the reference picture memory (557), and a new current picture buffer can be reallocated before starting the reconstruction of the next coded picture.

[0046] A video decoder (510) can perform decoding operations according to a predetermined video compression technique in a standard such as ITU-T Rec. H.265. In that the coded video sequence adheres to both the syntax of the video compression technique or standard and the profiles documented in the video compression technique or standard, the coded video sequence may comply with the syntax specified by the video compression technique or standard in use. Specifically, the profile may select specific tools from all tools available in the video compression technique or standard as the only tools available for use under that profile. Additionally, for compliance, it may be necessary for the complexity of the coded video sequence to be within the boundaries defined by the levels of the video compression technique or standard. In some cases, the levels limit the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the levels may, in some cases, be further restricted through HRD (Hypothetical Reference Decoder) specifications and metadata for managing HRD buffers signaled in the coded video sequence.

[0047] In one embodiment, the receiver (531) may receive additional (redundant) data along with the encoded video. This additional data may be included as part of the encoded video sequence(s). This additional data may be used by the video decoder (510) to properly decode the data and / or more accurately reconstruct the original video data. The additional data may be in the form, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0048] FIG. 6 illustrates a block diagram of a video encoder (603) according to one embodiment of the present disclosure. The video encoder (603) is included in an electronic device (620). The electronic device (620) includes a transmitter (640) (e.g., a transmitting circuit). The video encoder (603) may be used instead of the video encoder (403) in the example of FIG. 4.

[0049] The video encoder (603) can receive video samples from a video source (601) (which is not part of the electronic device (620) in the example of FIG. 6) capable of capturing video image(s) to be encoded by the video encoder (603). In another example, the video source (601) is part of the electronic device (620).

[0050] A video source (601) may provide a source video sequence to be coded by a video encoder (603) in the form of a digital video sample stream, which may have any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, …), any color space (e.g., BT.601 Y CrCB, RGB, …), and any suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media serving system, the video source (601) may be a storage device that stores previously prepared video. In a video conferencing system, the video source (601) may be a camera that captures local image information as a video sequence. The video data may be provided as a plurality of individual pictures that impart motion when viewed sequentially. The pictures themselves may be organized as a spatial array of pixels, where each pixel may contain one or more samples depending on the sampling structure, color space, etc. being used. A person skilled in the art can easily understand the relationship between pixels and samples. The following description focuses on the samples.

[0051] According to one embodiment, the video encoder (603) can code and compress pictures of a source video sequence into a coded video sequence (643) in real time or under any other time constraints required by the application. Enforcing an appropriate coding rate is one function of the controller (650). In some embodiments, the controller (650) controls other functional units and is functionally coupled to other functional units as described below. The coupling is not described for clarity. Parameters set by the controller (650) may include rate control related parameters (picture skip, quantizer, lambda values ​​of rate-distortion optimization techniques, …), picture size, picture group (GOP) layout, maximum motion vector search range, etc. The controller (650) may be configured to have other suitable functions related to the video encoder (603) optimized for a specific system design.

[0052] In some embodiments, the video encoder (603) is configured to operate in a coding loop. For the sake of oversimplification, in one example, the coding loop may include a source coder (630) (responsible for generating symbols, such as a symbol stream, based on, for example, the input picture to be coded and reference picture(s)), and a (local) decoder (633) embedded in the video encoder (603). The decoder (633) reconstructs the symbols to generate sample data in a manner similar to that which the (remote) decoder also generates (since any compression between the symbols and the coded video bitstream is lossless in the video compression techniques considered in the disclosed subject). The reconstructed sample stream (sample data) is input into the reference picture memory (634). Because the decoding of the symbol stream produces bit-exact results independently of the decoder location (local or remote), the content within the reference picture memory (634) is also bit exact between the local encoder and the remote encoder. In other words, the prediction part of the encoder "sees" as reference picture samples exactly the same sample values ​​that the decoder "sees" when using prediction during decoding. This basic principle of reference picture synchronicity (and, for example, the resulting drift when synchronicity cannot be maintained due to channel errors) is also used in some related technologies.

[0053] The operation of the “local” decoder (633) may be the same as the operation of the “remote” decoder, such as the video decoder (510) already described in detail above in relation to FIG. 5. However, with brief reference to FIG. 5, since symbols are available and the encoding / decoding of symbols into a coded video sequence by the entropy coder (645) and the parser (520) may be lossless, the entropy decoding parts of the video decoder (510), including the buffer memory (515) and the parser (520), may not be fully implemented in the local decoder (633).

[0054] An observation that can be made at this point is that any decoder technique, excluding the parsing / entropy decoding present in the decoder, must also inevitably exist in the corresponding encoder in substantially the same functional form. For this reason, the disclosed subject focuses on decoder operations. Since encoder techniques are the inverses of the comprehensively described decoder techniques, their descriptions may be condensed. Further details are required only in specific areas and are provided below.

[0055] During operation, in some examples, the source coder (630) may perform motion-compensated predictive coding, which predictively codes the input picture by referencing one or more previously coded pictures from a video sequence designated as a "reference picture." In this way, the coding engine (632) codes the differences between pixel blocks of the input picture and pixel blocks of the reference picture(s) that can be selected as predictive reference(s) for the input picture.

[0056] The local video decoder (633) can decode the coded video data of pictures that may be designated as reference pictures based on the symbols generated by the source coder (630). The operations of the coding engine (632) may advantageously be lossy processes. If the coded video data can be decoded in a video decoder (not shown in FIG. 6), the reconstructed video sequence may be a replica of the source video sequence, typically having some errors. The local video decoder (633) can replicate the decoding processes that can be performed by the video decoder on the reference pictures and allow the reconstructed reference pictures to be stored in the reference picture cache (634). In this way, the video encoder (603) can locally store copies of reconstructed reference pictures having common content as reconstructed reference pictures to be acquired by the far-end video decoder (without transmission errors).

[0057] The predictor (635) can perform prediction searches for the coding engine (632). That is, for a new picture to be coded, the predictor (635) can search the reference picture memory (634) for specific metadata or sample data (as candidate reference pixel blocks), such as reference picture motion vectors, block shapes, etc., which can serve as appropriate prediction references for the new pictures. The predictor (635) can operate on a sample block-by-pixel block basis to find appropriate prediction references. In some cases, as determined by the search results obtained by the predictor (635), the input picture may have prediction references drawn from a number of reference pictures stored in the reference picture memory (634).

[0058] The controller (650) can manage the coding operation of the source coder (630), including, for example, the settings of parameters and subgroup parameters used to encode video data.

[0059] The outputs of all the aforementioned function units may undergo entropy coding in an entropy coder (645). The entropy coder (645) converts the symbols generated by the various function units into a coded video sequence by losslessly compressing the symbols according to techniques such as Huffman coding, variable-length coding, and arithmetic coding.

[0060] The transmitter (640) may buffer the coded video sequence(s) generated by the entropy coder (645) to prepare for transmission over a communication channel (660), which may be a hardware / software link to a storage device for storing the encoded video data. The transmitter (640) may merge the coded video data from the video coder (603) with other data to be transmitted, e.g., coded audio data and / or auxiliary data streams (sources not shown).

[0061] The controller (650) can manage the operation of the video encoder (603). During coding, the controller (650) can assign a specific coded picture type to each coded picture, which can influence the coding techniques that can be applied to each picture. For example, pictures can often be assigned as one of the following picture types:

[0062] An Intra Picture (I Picture) may be one that can be coded and decoded without using any other picture in the sequence as a source of prediction. Some video codecs allow different types of Intra Pictures, including, for example, Independent Decoder Refresh ("IDR") pictures. A person skilled in the art recognizes the corresponding variations of I Pictures and their respective applications and features.

[0063] The predictive picture (P picture) may be coded and decoded using intra prediction or inter prediction, using at most one motion vector and reference index to predict the sample values ​​of each block.

[0064] A bi-directionally predictive picture (Picture B) may be coded and decoded using intra-prediction or inter-prediction, using at most two motion vectors and reference indices to predict sample values ​​of each block. Similarly, multi-prediction pictures may use more than two reference pictures and associated metadata for the reconstruction of a single block.

[0065] Source pictures are generally spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples, respectively) and can be coded on a block-by-block basis. Blocks can be predictively coded by referencing other (already coded) blocks determined by the coding assignment applied to each of the blocks' pictures. For example, blocks of pictures I can be non-predictively coded, or they can be predictively coded by referencing already coded blocks of the same picture (spatial prediction or intra prediction). Pixel blocks of picture P can be predictively coded via spatial prediction or temporal prediction by referencing one previously coded reference picture. Blocks of pictures B can be predictively coded via spatial prediction or temporal prediction by referencing one or two previously coded reference pictures.

[0066] The video encoder (603) can perform coding operations according to a predetermined video coding technology or standard, such as ITU-T Rec. H.265. In the operation, the video encoder (603) can perform various compression operations, including predictive coding operations that utilize temporal and spatial redundancies in the input video sequence. Thus, the coded video data can comply with the syntax specified by the video coding technology or standard in use.

[0067] In one embodiment, the transmitter (640) may transmit additional data along with the encoded video. The source coder (630) may include such data as part of the encoded video sequence. The additional data may include other forms of redundant data such as temporal / spatial / SNR enhancement layers, redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

[0068] Video can be captured as multiple source pictures (video pictures) in a temporal sequence. Intra-picture prediction (often abbreviated as intra prediction) utilizes spatial correlations within a given picture, while inter-picture prediction utilizes (temporal or other) correlations between pictures. In one example, a specific picture being encoded / decoded, referred to as the current picture, is partitioned into blocks. When a block within the current picture is similar to a reference block within a previously encoded and still buffered reference picture in the video, the block within the current picture can be encoded by a vector referred to as a motion vector. The motion vector points to the reference block within the reference picture and, if multiple reference pictures are in use, may have a third dimension identifying the reference picture.

[0069] In some embodiments, a bi-prediction technique may be used in inter-picture prediction. According to the bi-prediction technique, two reference pictures, such as a first reference picture and a second reference picture, are used, in which both have a decoding order in the video preceding the current picture (however, the display order may be in the past and future, respectively). A block in the current picture may be coded by a first motion vector pointing to a first reference block in the first reference picture, and a second motion vector pointing to a second reference block in the second reference picture. A block may be predicted by a combination of the first reference block and the second reference block.

[0070] In addition, merge mode techniques can be used in inter-picture prediction to improve coding efficiency.

[0071] According to some embodiments of the present disclosure, predictions such as inter-picture predictions and intra-picture predictions are performed on a block basis. For example, according to the HEVC standard, a picture within a sequence of video pictures is partitioned into coding tree units (CTUs) for compression, and the CTUs within the picture have the same size, such as 64x64 pixels, 32x32 pixels, or 16x16 pixels. Generally, a CTU contains three coding tree blocks (CTBs), which are one luma CTB and two chroma CTBs. Each CTU can be recursively quadtree split into one or more coding units (CUs). For example, a CTU of 64x64 pixels can be split into one CU of 64x64 pixels, four CUs of 32x32 pixels, or sixteen CUs of 16x16 pixels. In one example, each CU is analyzed to determine a prediction type for the CU, such as an inter-prediction type or an intra-prediction type. The CU is divided into one or more prediction units (PUs) based on temporal and / or spatial predictability. Typically, each PU includes a luminal prediction block (PB) and two chroma PBs. In one embodiment, the prediction operation in coding (encoding / decoding) is performed on a unit of prediction blocks. Using a luminal prediction block as an example of a prediction block, the prediction block includes a matrix of values ​​(e.g., luminal values) for pixels, such as 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc.

[0072] FIG. 7 illustrates a video encoder (703) according to another embodiment of the present disclosure. The video encoder (703) is configured to receive a processing block (e.g., a prediction block) of sample values ​​within a current video picture in a sequence of video pictures, and to encode the processing block into a coded picture that is part of a coded video sequence. In one example, the video encoder (703) is used instead of the video encoder (403) in the example of FIG. 4.

[0073] In the HEVC example, the video encoder (703) receives a matrix of sample values ​​for a processing block, such as a prediction block, such as 8x8 samples. The video encoder (703) determines which of the intra mode, inter mode, or two prediction mode the processing block is best coded, for example, using rate-distortion optimization. When the processing block is to be coded in intra mode, the video encoder (703) may encode the processing block into the coded picture using an intra prediction technique; when the processing block is to be coded in inter mode or two prediction mode, the video encoder (703) may encode the processing block into the coded picture using an inter prediction technique or a two prediction technique, respectively. In certain video coding techniques, the merge mode may be an inter-picture prediction submode in which motion vectors are derived from one or more motion vector predictors without the benefit of coded motion vector components outside the predictors. In certain other video coding techniques, there may be motion vector components applicable to the target block. In one example, the video encoder (703) includes other components such as a mode determination module (not shown) for determining the mode of the processing blocks.

[0074] In the example of FIG. 7, the video encoder (703) includes an inter encoder (730), an intra encoder (722), a residual calculator (723), a switch (726), a residual encoder (724), a general controller (721), and an entropy encoder (725) combined together as shown in FIG. 7.

[0075] The inter-encoder (730) is configured to receive samples of a current block (e.g., a processing block), compare the block with one or more reference blocks within reference pictures (e.g., blocks within previous and later pictures), generate inter-predicted information (e.g., description of redundant information according to the inter-encoding technique, motion vectors, merge mode information), and calculate inter-predicted results (e.g., predicted blocks) based on the inter-predicted information using any suitable technique. In some examples, the reference pictures are decoded reference pictures that are decoded based on encoded video information.

[0076] The intra-encoder (722) is configured to receive samples of the current block (e.g., processing block), compare the block with already coded blocks within the same picture in some cases, generate quantized coefficients after transformation, and in some cases also receive intra-prediction information (e.g., intra-prediction direction information according to one or more intra-encoding techniques). In one example, the intra-encoder (722) also calculates intra-prediction results (e.g., prediction blocks) based on reference blocks within the same picture and intra-prediction information.

[0077] A general controller (721) is configured to determine general control data and to control other components of the video encoder (703) based on the general control data. In one example, the general controller (721) determines the mode of the block and provides a control signal to the switch (726) based on the mode. For example, when the mode is intra mode, the general controller (721) controls the switch (726) to select an intra mode result for use by the residual calculator (723), and controls the entropy encoder (725) to select intra prediction information and include the intra prediction information in the bitstream; when the mode is inter mode, the general controller (721) controls the switch (726) to select an inter prediction result for use by the residual calculator (723), and controls the entropy encoder (725) to select inter prediction information and include the inter prediction information in the bitstream.

[0078] The residual calculator (723) is configured to calculate the difference (residual data) between the received block and the prediction results selected from the intra-encoder (722) or the inter-encoder (730). The residual encoder (724) is configured to operate based on the residual data to encode the residual data and generate transformation coefficients. In one example, the residual encoder (724) is configured to transform the residual data from the spatial domain to the frequency domain and generate transformation coefficients. Then, quantization processing is performed on the transformation coefficients to obtain quantized transformation coefficients. In various embodiments, the video encoder (703) also includes a residual decoder (728). The residual decoder (728) is configured to perform an inverse transformation and generate decoded residual data. The decoded residual data can be suitably used by the intra-encoder (722) and the inter-encoder (730). For example, the inter encoder (730) can generate decoded blocks based on decoded residual data and inter prediction information, and the intra encoder (722) can generate decoded blocks based on decoded residual data and intra prediction information. The decoded blocks are appropriately processed to generate decoded pictures, and the decoded pictures are buffered in a memory circuit (not shown) and can be used as reference pictures in some examples.

[0079] The entropy encoder (725) is configured to format the bitstream to include the encoded block. The entropy encoder (725) is configured to include various information according to a suitable standard, such as the HEVC standard. In one example, the entropy encoder (725) is configured to include general control data, selected prediction information (e.g., intra prediction information or inter prediction information), residual information, and other suitable information within the bitstream. According to the subject matter disclosed, it is noted that when coding a block in the inter mode or the merged submode of both prediction modes, residual information is not present.

[0080] FIG. 8 illustrates a drawing of a video decoder (810) according to another embodiment of the present disclosure. The video decoder (810) is configured to receive coded pictures that are part of a coded video sequence and to decode the coded pictures to generate reconstructed pictures. In one example, the video decoder (810) is used instead of the video decoder (410) in the example of FIG. 4.

[0081] In the example of FIG. 8, the video decoder (810) includes an entropy decoder (871), an inter decoder (880), a residual decoder (873), a reconstruction module (874), and an intra decoder (872) combined together as shown in FIG. 8.

[0082] The entropy decoder (871) may be configured to reconstruct specific symbols representing the syntax elements that constitute the coded picture from the coded picture. Such symbols may include, for example, prediction information (e.g., intra-predicted information or inter-predicted information) capable of identifying specific samples or metadata used for prediction by each of the mode in which the block is coded (e.g., intra-mode, inter-mode, bi-predicted mode, the latter two being in a merged submode or other submode), the intra-decoder (872), or the inter-decoder (880), for example, residual information in the form of quantized transformation coefficients. In one example, when the prediction mode is an inter- or bi-predicted mode, the inter-predicted information is provided to the inter-decoder (880); and when the prediction type is an intra-predicted type, the intra-predicted information is provided to the intra-decoder (872). Inverse quantization can be performed on the residual information and is provided to the residual decoder (873).

[0083] The inter decoder (880) is configured to receive inter prediction information and generate inter prediction results based on the inter prediction information.

[0084] The intra decoder (872) is configured to receive intra prediction information and generate prediction results based on the intra prediction information.

[0085] The residual decoder (873) is configured to perform inverse quantization to extract dequantized transform coefficients and to process the dequantized transform coefficients to transform the residual from the frequency domain to the spatial domain. The residual decoder (873) may also require specific control information (including quantizer parameters (QP)), and that information may be provided by the entropy decoder (871) (since this may only be low-capacity control information, the data path is not described).

[0086] The reconstruction module (874) is configured to form a reconstructed block by combining the residuals output by the residual decoder (873) and the prediction results (which, in some cases, are output by the inter or intra prediction module) in the spatial domain, and the reconstructed block may be part of a reconstructed picture, and the reconstructed picture may eventually be part of a reconstructed video. Note that other suitable operations, such as deblocking operations, may be performed to improve visual quality.

[0087] It should be noted that the video encoders (403, 603, and 703), and video decoders (410, 510, and 810) can be implemented using any suitable technique. In one embodiment, the video encoders (403, 603, and 703), and video decoders (410, 510, and 810) can be implemented using one or more integrated circuits. In another embodiment, the video encoders (403, 603, and 603), and video decoders (410, 510, and 810) can be implemented using one or more processors that execute software instructions.

[0088] Aspects of the present disclosure provide techniques for signaling flags for intra-block copy and prediction mode.

[0089] Block-based compensation can be used for inter-prediction and intra-prediction. In the case of inter-prediction, block-based compensation from different pictures is known as motion compensation. In the case of intra-prediction, block-based compensation can also be performed from previously reconstructed regions within the same picture. Block-based compensation from reconstructed regions within the same picture is referred to as intra-picture block compensation, current picture referencing (CPR), or intra-block copy (IBC). A displacement vector representing the offset between the current block and the reference block within the same picture is referred to as a block vector (or BV for short). Unlike motion vectors in motion compensation, which can be arbitrary values ​​(positive or negative in the x or y direction), block vectors have several constraints to ensure that the reference block is available and has already been reconstructed. Additionally, in some examples, for parallel processing considerations, certain reference regions, such as tile boundaries or wavefront ladder shape boundaries, are excluded.

[0090] The coding of block vectors can be explicit or implicit. In explicit mode (or referred to as AMVP (advanced motion vector prediction) mode in intercoding), the difference between the block vector and its predictor is signaled; in implicit mode, the block vector is recovered from the predictor (referred to as the block vector predictor) in a manner similar to the motion vector in merge mode. In some implementations, the resolution of the block vector is limited to integer positions; in other systems, the block vector is allowed to point to fractional positions.

[0091] In some examples, the use of intra-block copies at the block level can be signaled using a reference index approach. The current picture being decoded is then treated as a reference picture. In one example, this reference picture is placed at the last position in the list of reference pictures. This special reference picture is also managed alongside other temporal reference pictures within a buffer, such as the decoded picture buffer (DPB).

[0092] There are also some variations of intra-block copies, such as flipped intra-block copies (reference blocks are flipped horizontally or vertically before being used to predict the current block), or line-based intra-block copies (each compensation unit inside an MxN coding block is an Mx1 or 1xN line).

[0093] FIG. 9 illustrates an example of an intra-block copy according to an embodiment of the present disclosure. The current picture (900) is being decoded. The current picture (900) includes a reconstructed area (910) (dot area) and an area to be decoded (920) (white area). The current block (930) is being reconstructed by a decoder. The current block (930) may be reconstructed from a reference block (940) located in the reconstructed area (910). The position offset between the reference block (940) and the current block (930) is referred to as a block vector (950) (or BV (950)).

[0094] In some examples (e.g., VVC), the search range of the intra-block copy mode is constrained to be within the current CTU. Then, the memory requirement for storing reference samples for the intra-block copy mode is the size of one (max) CTU of the samples. In one example, the (max) 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 access speeds faster than main storage) can store samples of size 128x128, and the total memory includes an existing reference sample memory portion for storing reconstructed samples within the current block, such as a 64x64 area, and an additional memory portion for storing samples of three different areas of size 64x64. Therefore, in some examples, the effective search range of intra-block copy mode is extended to a portion of the left CTU, and the total memory requirement for storing reference pixels remains unchanged (e.g., 1 CTU size, 4 times the total 64x64 reference sample memory).

[0095] In some embodiments, an update process is performed to update stored reference samples from the left CTU with reconstructed samples from the current CTU. Specifically, in some examples, the update process is performed based on 64x64 luma samples. In one embodiment, for each of the four 64x64 block regions within the CTU-sized memory, reference samples in the regions from the left CTU may be used to predict a coding block in the current CTU in CPR mode until any block among the blocks in the same region of the current CTU is coding or is coding.

[0096] FIGS. 10a through 10d illustrate examples of valid search ranges for an intra-block copy mode according to an embodiment of the present disclosure. In some examples, the encoder / decoder includes a cache memory capable of storing samples of one CTU, such as 128x128 samples. Also, in the examples of FIGS. 10a through 10d, the current block for prediction has a size of 64x64 samples. Note that the examples can be suitably modified for current blocks of other suitable sizes.

[0097] FIGS. 10a through 10d each illustrate the current CTU (1020) and the left CTU (1010). The left CTU (1010) contains four blocks (1011-1014), each block having a sample size of 64x64 samples. The current CTU (1020) contains four blocks (1021-1024), each block having a sample size of 64x64 samples. The current CTU (1020) is the CTU containing the current block being reconstructed (indicated by the label "Curr" and having a vertical stripe pattern). The left CUT (1010) is located immediately to the left of the current CTU (1020). Note that in FIGS. 10a through 10d, the gray blocks are the blocks that have already been reconstructed, and the white blocks are the blocks to be reconstructed.

[0098] In FIG. 10a, the current block being reconstructed is block (1021). Cache memory stores reconstructed samples within blocks (1012, 1013, and 1014), and cache memory will be used to store reconstructed samples of the current block (1021). In the example of FIG. 10a, the valid search range for the current block (1021) includes blocks (1012, 1013, and 1014) within the left CTU (1010) having reconstructed samples stored in cache memory. Note that in one embodiment, the reconstructed samples of block (1011) are stored in main memory having a slower access rate than cache memory (e.g., copied from cache memory to main memory before the reconstruction of block (1021)).

[0099] In FIG. 10b, the current block being reconstructed is block (1022). Cache memory stores reconstructed samples within blocks (1013, 1014, and 1021), and cache memory will be used to store reconstructed samples of the current block (1022). In the example of FIG. 10b, the valid search range for the current block (1022) includes blocks (1013 and 1014) within the left CTU (1010) and block (1021) within the current CTU (1020) that have reconstructed samples stored in cache memory. Note that in one embodiment, the reconstructed samples of block (1012) are stored in main memory having a slower access rate than cache memory (e.g., copied from cache memory to main memory before reconstructing block (1022)).

[0100] In FIG. 10c, the current block being reconstructed is block (1023). Cache memory stores reconstructed samples within blocks (1014, 1021, and 1022), and cache memory will be used to store reconstructed samples of the current block (1023). In the example of FIG. 10c, the valid search range for the current block (1023) includes blocks (1014) within the left CTU (1010) and blocks (1021 and 1022) within the current CTU (1020) that have reconstructed samples stored in cache memory. Note that in one embodiment, the reconstructed samples of block (1013) are stored in main memory having a slower access rate than cache memory (e.g., copied from cache memory to main memory before reconstructing block (1023)).

[0101] In FIG. 10d, the current block being reconstructed is block (1024). Cache memory stores reconstructed samples within blocks (1021, 1022, and 1023), and cache memory will be used to store reconstructed samples of the current block (1024). In the example of FIG. 10d, the valid search range for the current block (1024) includes blocks (1021, 1022, and 1023) within the current CTU (1020) having reconstructed samples stored in cache memory. Note that in one embodiment, the reconstructed samples of block (1014) are stored in main memory having a slower access rate than cache memory (e.g., copied from cache memory to main memory before the reconstruction of block (1024)).

[0102] In the examples above, the cache memory has a total memory space for a CTU size of 1 (maximum). The examples can be adjusted to fit other suitable CTU sizes.

[0103] According to an embodiment of the present disclosure, before an intra-block copy is used, the coding block may be coded in intra-mode (intra-coding) or inter-mode (inter-picture prediction). In one example, a prediction mode flag "pred_mode_flag" having 1 bin (binary bit) is signaled or inferred at the coding block level to distinguish the coding modes (intra-mode or inter-mode) for the current block. For example, if the prediction mode flag "pred_mode_flag" is 0, MODE_INTER (indicating inter-mode) is used; otherwise (if pred_mode_flag is 1), MODE_INTRA (indicating intra-mode) is used.

[0104] In some embodiments, when an intra-block copy is used, to indicate the intra-block copy for the current block, the prediction mode flag "pred_mode_flag" is signaled (e.g., pred_mode_flag is 0) to indicate the inter-block mode, and then an inference or explicit signaling method is used to indicate whether the current block is coded in intra-block copy mode. In the inference method, in one example, if the current block is in merge mode and a merge candidate is coded in intra-block copy mode, the current block is also coded in intra-block copy mode. In the explicit signaling, if a reference index is signaled to indicate that the current block refers to a reference picture which is the current picture, the current block is coded in intra-block copy mode.

[0105] According to some embodiments of the present disclosure, an intra-block copy is considered as a distinct mode other than an intra-prediction mode (intra-mode) or an inter-prediction mode (inter-mode), and signaling of intra-block copy usage (e.g., using the flag "pred_mode_ibc_flag") and pred_mode_flag is specified at the block level.

[0106] The proposed methods may be used individually or combined in any order. Additionally, each of the methods (or embodiments), the encoder, and the decoder may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored on a non-transient computer-readable medium. Hereinafter, the term block may be interpreted as a prediction block, a coding block, or a coding unit, i.e., a CU.

[0107] The following discussions are based on the assumption that the Intra-Block Copy (IBC) mode is considered as a distinct mode different from the Intra-Prediction mode or Inter-Prediction mode.

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

[0109] According to a first aspect of the present disclosure, the IBC prediction mode use flag "pred_mode_ibc_flag" is signaled when a high-level IBC enable flag (such as sps_ibc_enabled_flag) is true and by one or more other conditions.

[0110] In one example, if 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 in an I tile group (e.g., tile_group_type=I) (e.g., cu_skip_flag=0), the current block may be in IBC predict mode or intra predict mode. Thus, pred_mode_ibc_flag is signaled to indicate whether the current block is coded in intra predict mode (0) or IBC predict mode (1).

[0111] In another example, if the high-level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is coded using skip mode in an I tile group (e.g., tile_group_type=I) (e.g., cu_skip_flag=1), the current block is inferred to be coded in IBC predict mode and the IBC predict mode use flag "pred_mode_ibc_flag" is not signaled in one example.

[0112] In another example, the current coding block is not coded using intra prediction mode in a P or B tile group (slice_tile_group_type != I) (CuPredMode[ x0 ][ y0 ] != MODE_INTRA), and the current block is coded in skip mode (cu_skip_flag=1), the current block can be coded in inter prediction mode or IBC prediction mode. Thus, pred_mode_ibc_flag is signaled to indicate whether the current block is coded in inter prediction mode (0) or IBC prediction mode (1).

[0113] In another example, if 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=0), the current block may be any of intra-prediction mode, inter-prediction mode, and IBC prediction mode. In one embodiment, pred_mode_flag is signaled to indicate that the current block is not in intra-prediction mode (e.g., pred_mode_flag is signaled as 1). Then, pred_mode_ibc_flag is signaled to indicate whether the current block is coded in inter-prediction mode (0) or IBC prediction mode (1).

[0114] In another example, if CuPredMode[ x0 ][ y0 ] is equal to MODE_INTRA (e.g., if pred_mode_flag is signaled as 0), the current block is coded in intra prediction mode and there is no need to signal additional flags (e.g., pred_mode_ibc_flag).

[0115] In an embodiment according to the first aspect of the present disclosure, the syntax and associated semantics for pre_mode_flag and pred_mode_ibc_flag are specified in Table 1. In this embodiment, the block size for the IBC mode is not restricted. Note that the current block is a luminance block rather than a chroma block in various examples.

[0116]

[0117] In one example, when pred_mode_flag is decoded as 0, the current coding unit is coded in inter-prediction mode or IBC prediction mode. Then, pred_mode_flag is decoded from the coded video bitstream. When pred_mode_flag is decoded as 1, the current coding unit is coded in intra-prediction mode.

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

[0119] In some examples, when pred_mode_flag is not present in the encoded video bitstream, the variable CuPredMode[ x ][ y ] is inferred to be the same as MODE_INTRA : MODE_IBC when decoding an I-tile group (cu_skip_flag[ x0 ][ y0 ] == 0) for x = x0..x0 + cbWidth - 1 and y = y0..y0 + cbHeight - 1, and MODE_INTER when decoding a P or B-tile group, where cbWidth is the width of the current block and cbHeight is the height of the current block. For example, in an I-tile group, the possible prediction modes are MODE_INTRA and MODE_IBC. Subsequently, the prediction mode can be determined based on cu_skip_flag. When cu_skip_flag is 0 (not skip mode), the prediction mode for the current block is MODE_INTRA; When cu_skip_flag is 1 (skip mode), the prediction mode for the current block is MODE_IBC. Also, in a P or B tile group, and if pred_mode_flag is not present, the prediction mode is inferred to be MODE_INTER.

[0120] In some examples, when pred_mode_ibc_flag is decoded as 0, the current coding unit is not coded in IBC predictive mode; when pred_mode_ibc_flag is decoded as 1, the current coding unit is coded in IBC predictive mode. When pred_mode_ibc_flag is not present in the coded video bitstream, pred_mode_ibc_flag is inferred to be the same as sps_ibc_enabled_flag when decoding I tile groups and the same as 0 when decoding P or B tile groups.

[0121] In some embodiments, the current prediction mode for the current block may be determined based on pred_mode_ibc_flag. In one example, the variable CuPredMode[ x ][ y ] is derived based on pred_mode_ibc_flag for x = x0..x0 + cbWidth - 1 and y = y0..y0 + cbHeight - 1. For example, when pred_mode_ibc_flag is 0, CuPredMode[ x ][ y ] is set to MODE_INTRA when decoding I tile groups and to MODE_INTER when decoding P or B tile groups; when pred_mode_ibc_flag is 1, CuPredMode[ x ][ y ] is set to MODE_IBC.

[0122] According to a second aspect of the present disclosure, block sizes are considered in the process of determining a prediction mode from an intra prediction mode, an inter prediction mode, and an IBC prediction mode. For example, the width and / or height of an IBC-coded block is smaller than a threshold in some constraint examples. Accordingly, pred_mode_ibc_flag is signaled when a high-level ibc enable flag (such as sps_ibc_enabled_flag) is true, when the block size satisfies the constraints (that the IBC-coded block must be smaller than a threshold on each side), and by one or more other conditions.

[0123] In one example, if 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 in an I tile group (e.g., tile_group_type=I) (e.g., cu_skip_flag=0), the current block may be in IBC predict mode or intra predict mode. Thus, pred_mode_ibc_flag is signaled to indicate whether the current block is coded in intra predict mode (0) or IBC predict mode (1).

[0124] In another example, if a high-level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is coded using skip mode in an I tile group (e.g., tile_group_type=I) (e.g., cu_skip_flag=1), the current block is inferred to be coded in IBC predict mode. Then, no pred_mode_ibc_flag is signaled in the coded video bitstream.

[0125] In another example, the current coding block is not coded using intra prediction mode in a P or B tile group (slice_tile_group_type != I) (CuPredMode[ x0 ][ y0 ] != MODE_INTRA), and the current block is coded in skip mode (cu_skip_flag=1), the current block may be coded in inter prediction mode or IBC prediction mode. Thus, pred_mode_ibc_flag is signaled in the coded video bitstream to indicate whether the current block is coded in inter prediction mode (0) or IBC prediction mode (1).

[0126] In another example, if 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=0), the current block may be any of intra-prediction mode, inter-prediction mode, and IBC prediction mode. In one embodiment, pred_mode_flag is signaled to indicate that the current block is not in intra-prediction mode (e.g., pred_mode_flag is signaled as 1). Then, pred_mode_ibc_flag is signaled to indicate whether the current block is coded in inter-prediction mode (0) or IBC prediction mode (1).

[0127] In another example, if CuPredMode[ x0 ][ y0 ] is equal to MODE_INTRA (e.g., if pred_mode_flag is signaled as 0), the current block is coded in intra prediction mode and there is no need to signal additional flags.

[0128] Note that when pred_mode_ibc_flag is not signaled, the prediction mode for the current block may be MODE_INTRA, MODE_INTER, or MODE_IBC, depending on the circumstances.

[0129] In one example, if sps_ibc_enabled_flag is false or if the sizes of the current blocks do not meet the size requirements, the current block cannot be coded in IBC mode. Therefore, the current block is coded in intra or inter prediction mode depending on other conditions.

[0130] In another example, sps_ibc_enabled_flag is true, and the sizes of the current block satisfy the size requirements. If cu_skip_flag is 1 and the current tile group type is I, the current block is coded in MODE_IBC. If pred_mode_flag signals that it is in intra prediction mode and the current tile group type is not I, the current block is coded in MODE_INTRA.

[0131] In a tile group, when the sizes of the current block size do not meet the size requirements, the skip mode flag (e.g., cu_skip_flag) does not need to be signaled (it can be inferred to be false), or the skip mode flag can be signaled but always 0 (false).

[0132] In an embodiment according to a second aspect of the present disclosure, the syntax and associated semantics for pre_mode_flag and pred_mode_ibc_flag are specified in Table 2. In this embodiment, the block size for the IBC prediction mode is constrained so as not to be larger than the thresholds 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 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 one example, WIDTH_THD and HEIGHT_THD are set to 32. The semantics for these two flags are similar to those in the above embodiment.

[0133]

[0134] In one example, when pred_mode_flag is decoded as 0, the current coding unit is coded in inter-prediction mode or IBC prediction mode. When pred_mode_flag is 1, the current coding unit is coded in intra-prediction mode.

[0135] In some examples, the variable CuPredMode[ x ][ y ] is initialized based on pred_mode_flag for x = x0..x0 + cbWidth - 1 and y = y0..y0 + cbHeight - 1. For example, when pred_mode_flag is decoded as 0, CuPredMode[ x ][ y ] is set to MODE_INTER; when pred_mode_flag is decoded as 1, CuPredMode[ x ][ y ] is set to MODE_INTRA.

[0136] 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 MODE_INTRA : MODE_IBC when decoding an I-tile group (cu_skip_flag[ x0 ][ y0 ] = = 0) for x = x0..x0 + cbWidth - 1 and y = y0..y0 + cbHeight - 1, and equal to MODE_INTER when decoding a P or B-tile group. For example, in an I-tile group, the possible prediction modes are MODE_INTRA and MODE_IBC. Subsequently, the prediction mode can be determined based on cu_skip_flag. When cu_skip_flag is 0 (not skip mode), the prediction mode for the current block is MODE_INTRA; when cu_skip_flag is 1 (skip mode), the prediction mode for the current block is MODE_IBC. Additionally, in P or B tile groups, if pred_mode_flag is absent, the prediction mode is inferred to be MODE_INTER.

[0137] In some examples, when decoding with pred_mode_ibc_flag as 0, the current coding unit is not coded in IBC predictive mode; when decoding with pred_mode_ibc_flag as 1, the current coding unit is coded in IBC predictive mode. When pred_mode_ibc_flag is not present in the coded video bitstream, pred_mode_ibc_flag is used when decoding I-tile groups (sps_ibc_enabled_flag&&cbWidth <WIDTH_THD&&cbHeight<HEIGHT_THD)와 동일한 것으로 추론되고, P 또는 B 타일 그룹을 디코딩할 때 0과 동일한 것으로 추론된다.

[0138] In some embodiments, the current prediction mode for the current block may be determined based on pred_mode_ibc_flag. In one example, the variable CuPredMode[ x ][ y ] is derived based on pred_mode_ibc_flag for x = x0..x0 + cbWidth - 1 and y = y0..y0 + cbHeight - 1. For example, when pred_mode_ibc_flag is 0, CuPredMode[ x ][ y ] is set to MODE_INTRA when decoding I tile groups and to MODE_INTER when decoding P or B tile groups; when pred_mode_ibc_flag is 1, CuPredMode[ x ][ y ] is set to MODE_IBC.

[0139] According to a third aspect of the present disclosure, the prediction mode of the current coding block is jointly determined by pred_mode_ibc_flag, cu_skip_flag, pred_mode_flag, and tile_group_type. In some examples, the initialization of the prediction mode of the current coding block (e.g., initialization of CuPredMode[ x ][ y ] for x = x0..x0 + cbWidth - 1 and y = y0..y0 + cbHeight - 1) is not performed, and if pred_mode_ibc_flag, cu_skip_flag, pred_mode_flag, and tile_group_type are decoded or inferred, 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.

[0140] In one example, if a high-level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is not coded using skip mode in an I tile group (e.g., tile_group_type=I) (e.g., cu_skip_flag=0), the current block may be in IBC predictive mode or intra predictive mode. Thus, pred_mode_ibc_flag is signaled to indicate whether the current block is coded in intra predictive mode (e.g., pred_mode_ibc_flag is 0) or IBC predictive mode (e.g., pred_mode_ibc_flag is 1).

[0141] In another example, if the high-level IBC enable flag (e.g., sps_ibc_enabled_flag) is true and the current coding block is coded using skip mode in an I tile group (e.g., tile_group_type=I) (e.g., cu_skip_flag=1), the current block is inferred to be coded in IBC predict mode.

[0142] In another example, the current coding block is not coded using intra prediction mode in a P or B tile group (slice_tile_group_type != I) (CuPredMode[ x0 ][ y0 ] != MODE_INTRA), and the current block is coded in skip mode (cu_skip_flag=1), the current block can be coded in inter prediction mode or IBC prediction mode. Thus, pred_mode_ibc_flag is signaled to indicate whether the current block is coded in inter prediction mode (e.g., pred_mode_ibc_flag is 0) or IBC prediction mode (e.g., pred_mode_ibc_flag is 1).

[0143] In another example, if 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=0), the current block may be any of intra-prediction mode, inter-prediction mode, and IBC prediction mode. In one embodiment, pred_mode_flag is signaled to indicate that the current block is not in intra-prediction mode (e.g., pred_mode_flag is signaled as 1). Then, pred_mode_ibc_flag is signaled to indicate whether the current block is coded in inter-prediction mode (0) or IBC prediction mode (1).

[0144] In another example, if the current block is not coded in skip mode (e.g., cu_skip_flag=0) and CuPredMode[ x0 ][ y0 ] in a P or B tile group is equal to MODE_INTRA (e.g., signaled as pred_mode_flag 0), the current block is coded in intra prediction mode and there is no need to signal additional flags.

[0145] In an embodiment according to a third aspect of the present disclosure, the syntax and associated semantics for pre_mode_flag and pred_mode_ibc_flag are specified in Table 3, which is identical to Table 1. In this embodiment, the block size for the IBC mode is not restricted. Note that the current block is a luminance block rather than a chroma block in various examples.

[0146]

[0147] In one example, when pred_mode_flag is decoded as 0, the current coding unit is coded in inter-prediction mode or IBC prediction mode. When pred_mode_flag is decoded as 1, the current coding unit is coded in intra-prediction mode or IBC prediction mode.

[0148] When pred_mode_flag is not present in the coded video bitstream, pred_mode_flag is inferred based on cu_skip_flag and the type of tile group. For example, to decode an I tile group, pred_mode_flag is set to 1 when cu_skip_flag[ x0 ][ y0 ] is 0 (not in skip mode), and pred_mode_flag is set to 0 when cu_skip_flag[ x0 ][ y0 ] is 1. To decode a P or B tile group, pred_mode_flag is set to 0.

[0149] In some examples, when pred_mode_ibc_flag is decoded as 0, the current coding unit is not coded in IBC predictive mode; when pred_mode_ibc_flag is decoded as 1, the current coding unit is coded in IBC predictive mode. When pred_mode_ibc_flag is not present in the coded video bitstream, pred_mode_ibc_flag is inferred to be the same as sps_ibc_enabled_flag when decoding I tile groups and the same as 0 when decoding P or B tile groups.

[0150] Additionally, in some embodiments, the variable CuPredMode[ x ][ y ] (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 - 1 and y = y0..y0 + cbHeight - 1, for example, according to Table 4:

[0151]

[0152] In Table 4, when pred_mode_flag is 0 and pred_mode_ibc_flag is 0, the variable CuPredMode[ x ][ y ] is MODE_INTER; when pred_mode_flag is 1 and pred_mode_ibc_flag is 0, the variable CuPredMode[ x ][ y ] is MODE_INTRA; when pred_mode_ibc_flag is 1, the variable CuPredMode[ x ][ y ] is MODE_IBC regardless of the value of pred_mode_flag.

[0153] Note that in various embodiments, the use of sps_ibc_enabled_flag (the IBC enable flag at the SPS level) may be replaced with other high-level IBC enable flags, such as the IBC enable flag at the picture level, the IBC enable flag at the tile group level, etc.

[0154] FIG. 11 illustrates a flowchart outlining a process (1100) according to one embodiment of the present disclosure. The process (1100) may be used in the reconstruction of a block coded in intra mode to generate a prediction block for a block being reconstructed. In various embodiments, the process (1100) is executed by a processing circuit within terminal devices (310, 320, 330 and 340), such as a processing circuit that performs the functions of a video encoder (403), a processing circuit that performs the functions of a video decoder (410), a processing circuit that performs the functions of a video decoder (510), a processing circuit that performs the functions of a video encoder (603), etc. In some embodiments, the process (1100) is implemented by software instructions, and thus, when the processing circuit executes the software instructions, the processing circuit performs the process (1100). The process starts at (S1101) and proceeds to (S1110).

[0155] In (S1110), the prediction information of the current block in the picture is decoded from the coded video bitstream.

[0156] In (S1120), an IBC prediction mode use flag is decoded or inferred from the prediction information. Next, based on the IBC prediction mode use flag, an IBC prediction mode distinct from the intra prediction mode and the inter prediction mode is determined, in one example. In some embodiments, the IBC prediction mode, the intra prediction mode, and the inter prediction mode are three distinct prediction modes. In one example, the IBC prediction mode is selected based on one of the intra prediction mode and the inter prediction mode, a prediction mode flag (e.g., pred_mode_flag) indicating a possible mode selected from the IBC prediction mode, and an IBC prediction mode use flag (e.g., pred_mode_ibc_flag). The prediction mode flag and the IBC prediction mode use flag can be decoded or inferred from the coded video bitstream.

[0157] In (S1130), a block vector is determined in response to the determination of the IBC prediction mode. The block vector points to a reference region within the picture.

[0158] At (S1140), the current block is reconstructed based on reference samples within the reference area of ​​the picture. Then, the process proceeds to (S1199) and terminates.

[0159] The techniques described above may be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, FIG. 12 illustrates a computer system (1200) suitable for implementing specific embodiments of the disclosed subject matter.

[0160] Computer software may be coded using any suitable machine code or computer language in which assembly, compilation, linking, or similar mechanisms can be performed to generate code containing instructions that can be executed directly or through interpretation, micro-code execution, etc., by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc.

[0161] The commands can be executed on various types of computers or their components, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, Internet of Things devices, etc.

[0162] The components of the computer system (1200) illustrated in FIG. 12 are exemplary in nature and are not intended to imply any limitation on the scope of use or functionality of the computer software implementing the embodiments of the present disclosure. The configuration of the components should not be interpreted as having any dependency or requirement in relation to any one or a combination thereof of the components illustrated in the exemplary embodiments of the computer system (1200).

[0163] The computer system (1200) may include specific human interface input devices. Such human interface input devices may respond to input by one or more human users through, for example, tactile input (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), and olfactory input (not described). Human interface devices may also be used to capture specific media that are not necessarily directly related to conscious input by humans, such as audio (e.g., voice, music, ambient sound), images (e.g., scanned images, photographic images obtained from a still image camera), and video (e.g., 2D video, 3D video including stereoscopic video).

[0164] Input human interface devices may include one or more of: a keyboard (1201), a mouse (1202), a trackpad (1203), a touch screen (1210), a data glove (not shown), a joystick (1205), a microphone (1206), a scanner (1207), and a camera (1208) (only one of each is depicted).

[0165] The computer system (1200) may also include specific human interface output devices. Such human interface output devices may stimulate one or more human user's senses through, for example, tactile output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., touch-screen (1210), data-glove (not shown), or haptic feedback via joystick (1205), but there may also be haptic feedback devices that do not serve as input devices), audio output devices (e.g., speakers (1209), headphones (not depicted)), visual output devices (e.g., screens (1210) including CRT screens, LCD screens, plasma screens, and OLED screens, each with or without touch-screen input capability and with or without haptic feedback capability—some of which may output two-dimensional visual output or output beyond three dimensions through means such as stereographic output—; virtual reality glasses (not depicted), holographic displays and smoke tanks (not depicted)), and printers (not depicted).

[0166] The computer system (1200) may also include human-accessible storage devices and their associated media, such as optical media including a CD / DVD ROM / RW (1220) having a media (1221) such as a CD / DVD, a thumb-drive (1222), a removable hard drive or solid-state drive (1223), legacy magnetic media such as tape and floppy disk (not depicted), specialized ROM / ASIC / PLD-based devices such as a security dongle (not depicted).

[0167] Those skilled in the art should also understand that the term "computer-readable medium" as used in connection with the subject matter disclosed herein does not include transmission media, carriers, or other transient signals.

[0168] The computer system (1200) may also include an interface to one or more communication networks. The networks may be, for example, wireless, wired, or optical. The networks may additionally be local, wide-area, metropolitan, automotive and industrial, real-time, delay-tolerant, etc. Examples of networks include local area networks, such as Ethernet, wireless LANs, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., TV wired or wireless wide-area digital networks including cable TV, satellite TV, and terrestrial broadcast TV, automotive and industrial including CANBus, etc. Certain networks generally require external network interface adapters attached to specific general-purpose data ports or peripheral buses (1249) (e.g., USB ports of the computer system (1200)); others are generally integrated into the core of the computer system (1200) by attachment to a system bus as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks, the computer system (1200) can communicate with other entities. Such communication may be unidirectional receive-only (e.g., broadcast TV), unidirectional transmit-only (e.g., CANbus to specific CANbus devices), or bidirectional with other computer systems using, for example, local area or wide area digital networks. Specific protocols and protocol stacks may be used for each of the networks and network interfaces as described above.

[0169] The aforementioned human interface devices, human-accessible storage devices, and network interfaces can be attached to the core (1240) of the computer system (1200).

[0170] The core (1240) may include one or more central processing units (CPUs) (1241), specialized programmable processing units in the form of graphics processing units (GPUs) (1242), field programmable gate areas (FPGAs) (1243), hardware accelerators (1244) for specific tasks, etc. These devices may be connected via a system bus (1248), along with internal mass storage (1247), such as read-only memory (ROM) (1245), random access memory (1246), internal non-user accessible hard drives, SSDs, etc. In some computer systems, the system bus (1248) may be accessible in the form of one or more physical plugs to enable expansion by additional CPUs, GPUs, etc. Peripheral devices may be attached directly to the core's system bus (1248) or via a peripheral bus (1249). Architectures for peripheral buses include PCI, USB, etc.

[0171] CPUs (1241), GPUs (1242), FPGAs (1243), and accelerators (1244) can be combined to execute specific instructions that can constitute the aforementioned computer code. The computer code may be stored in ROM (1245) or RAM (1246). Transient data may also be stored in RAM (1246), while persistent data may be stored, for example, in internal mass storage (1247). High-speed storage and retrieval of any of the memory devices may be made possible through the use of cache memory, which may be closely associated with one or more CPUs (1241), GPUs (1242), mass storage (1247), ROM (1245), RAM (1246), etc.

[0172] A computer-readable medium may have computer code for performing various computer-implemented operations. The medium and the computer code may be those specifically designed and configured for the purposes of this disclosure, or they may be of a kind well known and available to those skilled in the field of computer software technology.

[0173] As an example rather than a limitation, a computer system (1200) having an architecture, and specifically a core (1240), may provide functionality as a result of processor(s) (including CPUs, GPUs, FPGAs, accelerators, etc.) executing software implemented on one or more types of tangible computer-readable media. Such computer-readable media may be media associated with specific storage of the core (1240) that is of a non-transient nature, such as core-internal mass storage (1247) or ROM (1245), as well as user-accessible mass storage as described above. Software implementing various embodiments of the present disclosure may be stored on such devices and executed by the core (1240). The computer-readable media may include one or more memory devices or chips as needed. Software may enable the core (1240) and, specifically, the processors within it (including a CPU, GPU, FPGA, etc.) to execute specific processes or specific parts of specific processes described herein, including defining data structures stored in RAM (1246) and modifying such data structures according to processes defined by the software. Additionally or alternatively, the computer system may provide functionality as a result of logic hardwired or otherwise implemented in a circuit (e.g., accelerator (1244)) that can operate instead of or with the software to execute specific processes or specific parts of specific processes described herein. Reference to software may include logic, where appropriate, and vice versa. Reference to a computer-readable medium may include, where appropriate, a circuit storing software for execution (e.g., an integrated circuit (IC)), or a circuit implementing logic for execution, or both. The present disclosure includes any suitable combination of hardware and software.

[0174] 부록 A: 두문자어들

[0175] JEM: joint exploration model

[0176] VVC: versatile video coding

[0177] BMS: benchmark set

[0178] MV: Motion Vector

[0179] HEVC: High Efficiency Video Coding

[0180] SEI: Supplementary Enhancement Information

[0181] VUI: Video Usability Information

[0182] GOPs: Groups of Pictures

[0183] TUs: Transform Units,

[0184] PUs: Prediction Units

[0185] CTUs: Coding Tree Units

[0186] CTBs: Coding Tree Blocks

[0187] PBs: Prediction Blocks

[0188] HRD: Hypothetical Reference Decoder

[0189] SNR: Signal Noise Ratio

[0190] CPUs: Central Processing Units

[0191] GPUs: Graphics Processing Units

[0192] CRT: Cathode Ray Tube

[0193] LCD: Liquid-Crystal Display

[0194] OLED: Organic Light-Emitting Diode

[0195] CD: Compact Disc

[0196] DVD: Digital Video Disc

[0197] ROM: Read-Only Memory

[0198] RAM: Random Access Memory

[0199] ASIC: Application-Specific Integrated Circuit

[0200] PLD: Programmable Logic Device

[0201] LAN: Local Area Network

[0202] GSM: Global System for Mobile communications

[0203] LTE: Long-Term Evolution

[0204] CANBus: Controller Area Network Bus

[0205] USB: Universal Serial Bus

[0206] PCI: Peripheral Component Interconnect

[0207] FPGA: Field Programmable Gate Areas

[0208] SSD: solid-state drive

[0209] IC: Integrated Circuit

[0210] CU: Coding Unit

[0211] Although the present disclosure describes various exemplary embodiments, modifications, substitutions, and various alternative equivalents exist within the scope of the present disclosure. Accordingly, it will be acknowledged that those skilled in the art will be able to devise a number of systems and methods that implement the principles of the present disclosure and are therefore within the true meaning and scope thereof, even though they are not expressly illustrated or described in this specification.

Claims

Claim 1 A video encoding method comprising: determining, by a processing circuit of a video encoder, a high-level flag indicating whether an intra-block copy (IBC) prediction mode is enabled in a coded video bitstream; determining, when the high-level flag indicates that the IBC prediction mode is enabled, whether an IBC prediction mode use flag is signaled for the current block in a picture to be included in the coded video bitstream based on the type of tile group or slice to which the current block belongs, wherein when the IBC prediction mode use flag is not signaled, the IBC prediction mode is inferred to be applied to the current block according to the tile group or slice of the current block; determining a block vector pointing to a reference region in the picture based on the IBC prediction mode of the current block; and encoding the current block based on reference samples in the reference region in the picture. Claim 2 A method according to claim 1, further comprising the step of generating prediction information for the current block—the prediction information being included in the coded video bitstream—and determining whether to signal the IBC prediction mode use flag for the current block, comprising determining whether to signal the IBC prediction mode use flag in the generated prediction information. Claim 3 A method according to paragraph 2, wherein the generated prediction information includes the high-level flag indicating whether the IBC prediction mode is enabled. Claim 4 A method according to paragraph 3, wherein the IBC prediction mode use flag is determined to be signaled when (i) the current block is not coded in skip mode and (ii) the tile group or slice is of type I. Claim 5 A method according to paragraph 3, wherein (i) the tile group or slice is of type I and (ii) the value of the IBC prediction mode use flag is inferred according to the high level flag when it is determined that the IBC prediction mode use flag is not signaled in the coded video bitstream. Claim 6 A method according to claim 1, wherein (i) the tile group or slice is of type B or P and (ii) when it is determined that the IBC prediction mode use flag is not signaled in the coded video bitstream, the IBC prediction mode use flag is inferred to be 0. Claim 7 A method according to paragraph 3, wherein the high-level flag is at least one parameter among video level, sequence level, picture level, tile group level, or slice level. Claim 8 A method according to claim 1, further comprising at least one step of generating a prediction mode flag to be included in the coded video bitstream; and determining whether the IBC prediction mode use flag is signaled based on a skip flag and the type of tile group or slice to which the current block belongs. Claim 9 A method according to claim 2, further comprising: a step of selecting a prediction mode among the IBC prediction mode, intra prediction mode, and inter prediction mode; and a step of determining a prediction mode flag and determining whether to signal the IBC prediction mode use flag based on the selected prediction mode. Claim 10 A method according to paragraph 2, further comprising the step of selecting a prediction mode of the current block from one of an intra prediction mode and an inter prediction mode when the current block does not satisfy a size requirement. Claim 11 A video encoding device comprising a processing circuit configured to perform the method of any one of claims 1 to 10. Claim 12 A non-transient computer-readable medium in which instructions are stored, wherein the instructions, when executed by a processor in a video encoder, cause the processor to execute the method of any one of claims 1 to 10. Claim 13 A method for processing visual media data, comprising the step of performing a conversion between a visual media file and a bitstream of visual media data according to a format rule, wherein the bitstream includes a high-level flag indicating whether an intra-block copy (IBC) prediction mode is enabled in the bitstream, and wherein the format rule specifies that when the high-level flag indicates that the IBC prediction mode is enabled, it is determined that an intra-block copy (IBC) prediction mode use flag is signaled for the current block within the picture to be included in the bitstream based on the type of tile group or slice to which the current block belongs, and wherein the format rule specifies that when the IBC prediction mode use flag is not signaled, it is inferred that the IBC prediction mode is applied to the current block according to the tile group or slice of the current block.

Images