Video encoding / decoding method, device and computer program

Abstract

To provide video encoding / decoding method and device using an in-frame block copy mode.SOLUTION: A device for video decoding includes a reception circuit and a processing circuit, wherein the processing circuit encodes prediction information on a current block which is being encoded from an encoded video bitstream. The prediction information indicates an in-frame block copy mode, and determines a block vector indicating a reference block in the same picture as the current block. The reference block is restricted to an encoded region, and a reconstructed sample is buffered in a reference sample memory. The encoded region is one of a plurality of previous definition regions of an encoding tree unit (CTU). The processing circuit reconstructs at least a sample of the current block on the basis of the reconstructed sample of the reference block retrieved from the reference sample memory.SELECTED DRAWING: Figure 14

Description

[Technical field]

[0001] This application claims priority to U.S. Patent Application No. 16 / 699,235, entitled "METHOD AND APPARATUS FOR VIDEO CODING," filed November 29, 2019, which in turn claims priority to U.S. Provisional Application No. 62 / 774,148, entitled "CONSTRAINTS ON REFERENCE BLOCK LOCATIONS FOR INTRA BLOCK COPY," filed November 30, 2018, and U.S. Provisional Application No. 62 / 790,454, entitled "INTRA PICTURE BLOCK COMPENSATION BUFFER REUSE WITH NON SQUARE BLOCK PARTITIONS," filed January 9, 2019, the entire contents of which are incorporated by reference.

[0002] This disclosed subject matter describes embodiments that generally relate to video encoding. [Background technology]

[0003] The background description provided in this specification is intended to provide a general background to the contents of the present disclosure. In view of the extent of the work described in the background art section, the work of the currently signed inventors and aspects not otherwise limited as prior art at the time of filing are not expressly or implicitly admitted as prior art to the contents of the present disclosure.

[0004] Video encoding and decoding can be performed using interframe prediction with motion compensation. Uncompressed digital video may include a sequence of pictures, each having a spatial dimension, e.g., 1920x1080 luminance samples and associated chrominance samples. The sequence of pictures may have a fixed or variable picture rate (also informally called frame rate), e.g., 60 pictures per second or 60 Hz. Uncompressed video has high bitrate requirements. For example, 1080p60 4:2:0 video (1920x1080 luminance sample resolution at 60 Hz frame rate) with 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 GB of storage space.

[0005] Video encoding and decoding aims at reducing redundancy in the video signal input by compression. Compression contributes to reducing the bandwidth or storage space requirements mentioned above, in some circumstances by two or more orders of magnitude. Lossless compression, lossy compression, and combinations thereof can be used. Lossless compression refers to techniques that allow for the reconstruction of an exact copy of the original signal from the compressed original signal. When lossy compression is used, the reconstructed signal may differ from the original signal, but the distortion between the original and reconstructed signals is small enough that the reconstructed signal is useful for the intended application. In the case of video, lossy compression is applied to a large extent. The amount of acceptable distortion depends on the application, e.g., users of consumer streaming media applications tolerate higher distortion than users of television distribution applications. The compression ratio reached reflects that the higher the permitted / tolerable distortion, the higher the compression ratio.

[0006] Video encoders and decoders may utilize techniques in a number of broad categories including, for example, motion compensation, transform, quantization, entropy coding, and so on.

[0007] Video codec techniques include a technique called intra-coding, in which sample values ​​are represented without reference to samples or other data from a previously reconstructed reference picture. In some video codecs, a picture is spatially subdivided into sample blocks. A picture may be an intra-picture if all sample blocks are coded in an intra-mode. Intra-pictures and their derivatives (e.g., independent decoder refresh pictures) may be used as the first picture or as still pictures in coded video bitstreams and video sessions, since they can reset the decoder state. Samples in an intra-block may be subjected to a transform, and the transform coefficients may be quantized before entropy coding. Intra-prediction may be a technique that minimizes the sample values ​​in the pre-transform domain. In some cases, the smaller the DC value after the transform and the smaller the AC coefficients, the fewer bits are needed to represent the entropy coded block for a given quantization step size.

[0008] Conventional intraframe coding, known for example from MPEG-2 encoding techniques, does not use intraframe prediction. However, new video compression techniques include techniques that utilize metadata and / or surrounding sample data obtained during encoding / decoding of spatially adjacent and preceding data blocks in decoding order. Such techniques are referred to as "intraframe prediction" techniques. In at least some cases, intraframe prediction uses only reference data from the current picture being reconstructed, and does not use reference data from reference pictures.

[0009] There are various forms of intra prediction. If more than one such technique is available for a given video coding technique, the technique may be coded as an intra prediction mode. In some cases, the mode may have sub-modes and / or parameters that may be coded separately or included in the mode codeword. Which codeword is used for a given mode / sub-mode / parameter combination may affect the coding efficiency gains from intra prediction, as may the entropy coding technique used to convert the codeword into a bitstream.

[0010] Certain modes of intraframe prediction are introduced in H.264 and refined in H.265 and further refined in new coding techniques such as the Joint Exploration Model (JEM), Versatile Video Coding (VVC) and Benchmark Set (BMS). Neighboring sample values ​​belonging to already available samples may be used to form a predictor block. The sample values ​​of the neighboring samples are copied into the predictor block according to a direction. The reference of the direction of use may be coded in the bitstream or predicted itself. Summary of the Invention [Means for solving the problem]

[0011] Aspects of the present disclosure provide a method and apparatus for video encoding / decoding. In some examples, the apparatus for video decoding includes a receiving circuit and a processing circuit. In some embodiments, the processing circuit decodes prediction information of a current block currently being encoded from an encoded video bitstream. The prediction information indicates an intra-frame block copy mode. The processing circuit then determines a block vector that points to a reference block in the same picture as the current block. The reference block is restricted to a coding region, and reconstructed samples are buffered in a reference sample memory. The coding region is one of a plurality of predefined regions of a coding tree unit (CTU). Then, the processing circuit reconstructs samples of at least the current block based on the reconstructed samples of the reference block retrieved from the reference sample memory.

[0012] In some examples, the coding region has a square shape. In the examples, the CTU is arranged to have a luma component of 128x128 samples.

[0013] In an embodiment, the reference sample memory is arranged to update samples buffered in the reference sample memory on a coded domain basis.

[0014] In some embodiments, the processing circuitry checks whether multiple corners of the reference block are within the encoded region.

[0015] In one example, if the CTU contains 128x128 luma samples, the size of the coding region is 64x64 luma samples. In another example, if the CTU contains less than 128x128 luma samples, the size of the coding region is the same as the size of the CTU.

[0016] In some embodiments, the processing circuit moves the reference block into the coded region if the reference block is partially in the coded region before the move. In an example, the processing circuit moves the reference block in a direction that reduces the distance between the reference block and the current block. In another example, the processing circuit moves the reference block in a direction that increases the percentage of reference samples in the coded region.

[0017] In some embodiments, the processing circuit uses information of a first reference sample in the coding region as information of a second reference sample outside the coding region when the reference block is partially in the coding region. In some examples, flexible block partitioning is prohibited in partitioning the CTU.

[0018] Aspects of the present disclosure further provide a non-transitory computer-readable medium having instructions stored thereon that, when executed by a computer, cause the computer to perform the method for video encoding to perform video decoding. [Brief description of the drawings]

[0019] Other features, nature and various advantages of the disclosed subject matter will become more apparent based on the following detailed description and drawings, in which:

[0020] [Figure 1] FIG. 1 is a schematic diagram of a simplified block diagram of a communication system (100) according to an embodiment.

[0021] [Diagram 2] FIG. 2 is a schematic diagram of a simplified block diagram of a communication system (200) according to an embodiment.

[0022] [Diagram 3] FIG. 2 is a schematic diagram of a simplified block diagram of a decoder according to an embodiment;

[0023] [Figure 4] FIG. 2 is a schematic diagram of a simplified block diagram of an encoder according to an embodiment;

[0024] [Diagram 5] 4 shows a block diagram of an encoder according to another embodiment.

[0025] [Figure 6] 4 shows a block diagram of a decoder according to another embodiment;

[0026] [Figure 7] 1 illustrates an example of intra-frame block copying according to an embodiment of the present disclosed subject matter.

[0027] [Figure 8] 1A-D show examples of valid search ranges for reference sample memory updating and intra-frame block copying modes according to embodiments of the present disclosed subject matter.

[0028] [Figure 9] AH show some examples that may result in the division of a non-square block.

[0029] [Figure 10A] FIG. 1 shows two examples of encoding order and use of reference sample memory. [Figure 10B] FIG. 1 shows two examples of encoding order and use of reference sample memory.

[0030] [Figure 11] A and B show examples of samples from two different coding regions in a reference block.

[0031] [Figure 12] AF show examples of reference sample memory reuse strategies.

[0032] [Figure 13] AF show examples of update processes according to some embodiments of the present disclosed subject matter.

[0033] [Figure 14] 1 shows a flowchart outlining an example process according to some embodiments of the present disclosed subject matter.

[0034] [Figure 15] FIG. 1 is a schematic diagram of a computer system according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0035] FIG. 1 illustrates a simplified block diagram of a communication system (100) according to an embodiment of the present disclosure. The communication system (100) includes a plurality of terminal devices that can communicate with each other, for example, via a network (150). For example, the communication system (100) includes a first pair of terminal devices (110), (120) connected to each other via the network (150). In the example of FIG. 1, the first pair of terminal devices (110), (120) perform unidirectional data transmission. For example, the terminal device (110) transmits video data (e.g., a video picture stream captured by the terminal device (110)) to another terminal device (120) via the network (150). The encoded video data may be transmitted in the form of one or more encoded video bitstreams. The terminal device (120) receives the encoded video data from the network (150), recovers video pictures by decoding the encoded video data, and displays the video pictures according to the recovered video data. One-way data transmission is common in media service applications, for example.

[0036] In another example, the communication system (100) includes a second pair of terminal devices (130), (140) for performing bidirectional transmission of encoded video data, which may occur, for example, during a video conference. For the bidirectional data transmission, in the example, each of the terminal devices (130), (140) can transmit video data (e.g., a video picture stream captured by the terminal device) to another of the terminal devices (130), (140) via the network (150). Each of the terminal devices (130), (140) can further receive the encoded video data transmitted from the other of the terminal devices (130), (140), decode the encoded video data to recover the video pictures, and display the video pictures on an accessible display device according to the recovered video data.

[0037] In the example shown in FIG. 1, terminal devices (110), (120), (130), and (140) are shown as a server, a personal computer, and a smartphone, although the principles of the present disclosure are not so limited. Embodiments of the present disclosure apply to laptop computers, tablets, media players, and / or specialized video conferencing equipment. Network (150) represents any number of networks, including, for example, wired and / or wireless communication networks, for transmitting encoded video data between terminal devices (110), (120), (130), and (140). Communication network (150) may exchange data over circuit-switched and / or packet-switched channels. Exemplary networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of this discussion, unless otherwise described herein, the architecture and topology of network (150) is not important to the operation of the present disclosure.

[0038] As an example of an application of the disclosed subject matter, Figure 2 shows an arrangement of a video encoder and a video decoder in a streaming transmission environment. The disclosed subject matter is equally applicable to other applications that support video, such as those including video conferencing, digital television, and compressed video stored on digital media including CDs, DVDs, memory sticks, and the like.

[0039] The streaming transmission system includes a capture subsystem (213) including a video source (201), such as a digital camera, for constructing an uncompressed video picture stream (202). In the example, the video picture stream (202) includes samples captured by the digital camera. The video picture stream (202), depicted as a thick line to emphasize the amount of data when compared to the encoded video data (204) (or encoded video bitstream), is processed by an electronic device (220) including a video encoder (203) coupled to the video source (201). The video encoder (203) may include hardware, software, or a combination thereof to realize or implement aspects of the disclosed subject matter, as described in more detail below. The encoded video data (204) (or encoded video bitstream (204)), depicted as a thin line to emphasize the amount of data when compared to the video picture stream (202), is stored in a streaming server (205) for later use. One or more streaming client subsystems, such as client subsystems (206), (208) in FIG. 2, can access a streaming server (205) to retrieve copies (207), (209) of the encoded video data (204). The client subsystem (206) includes a video decoder (210), for example in an electronic device (230). The video decoder (210) decodes an input copy (207) of the encoded video data and constructs a derived video picture stream (211) that is displayed on a display (212) (e.g., a screen) or other display device (not shown). In a streaming transmission system, the encoded video data (204), (207), and (209) (e.g., a video bitstream) can be encoded according to a video encoding / compression standard. Examples of these standards include the ITU-T H.265 proposal. In an example, the video encoding standard under development is informally referred to as Versatile Video Coding, or VVC. The disclosed subject matter applies in the context of VVC.

[0040] Additionally, the electronics 220 and 230 may include other components (not shown). For example, the electronics 220 may include a video decoder (not shown), and the electronics 230 may include a video encoder (not shown).

[0041] 3 is a block diagram of a video decoder (310) according to an embodiment of the present disclosed subject matter. The video decoder (310) may be included in an electronic device (330). The electronic device (330) may include a receiver (331) (e.g., receiving circuitry). The video decoder (310) may replace the video decoder (210) in the example of FIG. 2.

[0042] The receiver (331) can receive one or more coded video sequences to be decoded by the video decoder (310), in the same or other embodiments, one coded video sequence at a time, with the decoding of each coded video sequence being independent of the other coded video sequences. The coded video sequences can be received from a channel (301), which can be a hardware / software link to a storage device for storing the coded video data. The receiver (331) can receive coded video data and other data, such as coded audio data and / or auxiliary data streams, which can be forwarded to respective utilization entities (not shown). The receiver (331) can separate the coded video sequences from the other data. To prevent network jitter, a buffer memory (315) is coupled between the receiver (331) and the entropy decoder / parser (320), hereinafter referred to as the "parser (320)". In some applications, the buffer memory (315) is part of the video decoder (310). In other applications, the buffer memory (315) may be external to the video decoder (310) (not shown). In yet other applications, a buffer memory (not shown) may be provided external to the video decoder (310) to, for example, prevent network jitter, and another buffer memory (315) may be provided internal to the video decoder (310) to, for example, handle playback timing. When the receiver (331) receives data from a store-and-forward device or an isochronous network with sufficient bandwidth and controllability, the buffer memory (315) may not be required, or may be small. For example, a buffer memory (315) may be required for use with a best-effort packet network such as the Internet, and the buffer memory (315) may be relatively large, advantageously having a self-adaptive size, and implemented at least in part by an operator system or similar element (not shown) external to the video decoder (310).

[0043] The video decoder (310) has a parser (320) that reconstructs codes (321) based on the coded video sequence. These categories of codes include information for managing the operation of the video decoder (310) and latent information for controlling a display device, such as a display device (312) (e.g., a screen), which is not an integral part of the electronic device (330) but is coupled to the electronic device (330) as shown in FIG. 3. The control information used by the display device(s) may be in the form of Supplementary Enhancement Information (SEI) messages or Video Usability Information (VUI) parameter set segments (not shown). The parser (320) performs parsing / entropy decoding on the received coded video sequence. The coding of the coded video sequence is based on a video coding technique or standard and follows various principles such as variable length coding, Huffman coding, arithmetic coding with or without context sensitivity, etc. The parser (320) extracts, from the coded video sequence, a subgroup parameter set for at least one of the subgroups of pixels in the video decoder based on at least one parameter corresponding to the group, including a group of pictures (GOP), a picture, a tile, a slice, a macroblock, a coding unit (CU), a block, a transform unit (TU), a prediction unit (PU), etc. The parser (320) can further extract information from the coded video sequence, such as transform coefficients, quantizer parameter values, motion vectors, etc.

[0044] The parser (320) may construct a code (321) by performing an entropy decoding / parsing operation on the video sequence received from the buffer memory (315).

[0045] Depending on the type of coded video picture or part thereof (e.g., inter-frame and intra-frame pictures, inter-frame and intra-frame blocks) and other factors, the reconstruction of the code (321) may involve several different units. Which units are involved, and how, may be controlled by subgroup control information that the parser (320) parses from the coded video sequence. For the sake of brevity, the flow of such subgroup control information between the parser (320) and the following units is not described:

[0046] In addition to the functional blocks already mentioned, the video decoder (310) can be conceptually subdivided into a number of functional units, as described below. In an actual implementation that operates within commercial constraints, some of these units may interact closely with each other and may be at least partially integrated with each other. However, for the purpose of illustrating the subject matter of the disclosure, it is appropriate to conceptually subdivide the video decoder (310) into the following functional units:

[0047] The first unit is a scalar / inverse transform unit (351). The scalar / inverse transform unit (351) receives quantized transform coefficients as code(s) (321) and control information from the parser (320). The control information includes what transform scheme to use, block size, quantization factor, quantization scaling matrix, etc. The scalar / inverse transform unit (351) can output a block containing sample values, which are input to an aggregator (355).

[0048] In some cases, the output samples of the scalar / inverse transform unit (351) may belong to intra-coded blocks, i.e., they do not use predictability information from a previously reconstructed picture, but can use a block of predictability information from a previously reconstructed portion of the current picture. Such predictability information is provided by an intra-picture prediction unit (352). In some situations, the intra-picture prediction unit (352) generates a block that is the same size and shape as the block being reconstructed, based on surrounding reconstructed information extracted from the current picture buffer (358). For example, the current picture buffer (358) buffers a partially reconstructed current picture and / or a fully reconstructed current picture. In some situations, the aggregator (355) adds prediction information generated by the intra-picture prediction unit (352) to the output sample information provided by the scalar / inverse transform unit (351) based on each sample.

[0049] In other cases, the output samples of the scalar / inverse transform unit (351) may belong to an inter-frame coded block and a latent motion compensated block. In such a situation, the motion compensated prediction unit (353) can extract samples for prediction by accessing the reference picture memory (357). After performing motion compensation on the extracted samples based on the code (321) belonging to the block, these samples are added to the output of the scalar / inverse transform unit (351) from the aggregator (355) (in this case, they are called residual samples or residual signals) to generate output sample information. The addresses in the reference picture memory (357) from which the motion compensated prediction unit (353) extracts the prediction samples can be controlled by a motion vector, which is provided to the motion compensated prediction unit (353) in the form of a code (321), which may have, for example, X, Y and reference picture components. Motion compensation may further include interpolation of sample values ​​extracted from a reference picture memory (357), motion vector prediction mechanisms, etc., when using sub-sample accurate motion vectors.

[0050] The output samples of the aggregator (355) can utilize various loop filtering techniques in the loop filter unit (356). Video compression techniques include in-loop filter techniques, which are included in the coded video sequence (also called coded video bitstream) and used to control parameters of the loop filter unit (356) as codes (321) from the parser (320), but which can be responsive to meta information obtained during decoding of a coded picture or previous part of the coded video sequence (in decoding order), and to sample values ​​previously reconstructed and subjected to loop filtering.

[0051] The output of the loop filter unit (356) may be a sample stream that is output to a display device (312) and stored in a reference picture memory (357) for subsequent use in inter-frame picture prediction.

[0052] Once fully reconstructed, a coded picture can be used as a reference picture for future prediction. For example, once a coded picture corresponding to a current picture is fully reconstructed and the coded picture is recognized (e.g., via the parser (320)) as a reference picture, the current picture buffer (358) becomes part of the reference picture memory (357), and a new current picture buffer is reallocated before reconstructing a subsequent coded picture.

[0053] The video decoder (310) may perform decoding operations based on a given video compression technique in a standard, such as the ITU-T H.265 proposal. A coded video sequence complies with the grammar specified by the video compression technique or standard in use in the sense that the coded video sequence conforms to both the grammar of the video compression technique or standard and the profile documented in the video compression technique or standard. Specifically, a profile may select some tools from all available tools in the video compression technique or standard as the tools available under the profile. For compliance, the complexity of the coded video sequence may be required to be within a range defined by a level of the video compression technique or standard. In some circumstances, the level may limit the maximum picture size, the maximum frame rate, the maximum reconstruction sampling rate (e.g., measured in units of millions of samples per second), and the maximum reference picture size. In some circumstances, the limits set by the level may be further limited via the specification of a hypothetical reference decoder (HRD) and HRD buffer management metadata signaled in the coded video sequence.

[0054] In an embodiment, the receiver (331) can receive additional (redundant) data and the encoded video. The additional data is included as part of the encoded video sequence(s). The additional data can be utilized by the video decoder (310) to properly decode the data and / or more accurately reconstruct the original video data. The additional data can be in the form of, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0055] 4 shows a block diagram of a video encoder (403) according to an embodiment of the present disclosed subject matter. The video encoder (403) is included in an electronic device (420). The electronic device (420) includes a transmitter (440) (e.g., a transmission circuit). The video encoder (403) can be substituted for the video encoder (203) in the example of FIG. 2.

[0056] The video encoder (403) can receive video samples from a video source (401) (not part of the electronic device (420) in the FIG. 4 example) that can capture video images to be encoded by the video encoder (403). In other examples, the video source (401) is part of the electronic device (420).

[0057] The video source (401) can provide a source video sequence that is encoded by the video encoder (403) 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 YCrCB, RGB, ...), and any suitable sampling configuration (e.g., YCrCb 4:2:0, YCrCb 4:4:4). In a media service system, the video source (401) can be a storage device for storing previously prepared videos. In a video conferencing system, the video source (401) can be a camera for capturing local image information as a video sequence. The video data can be provided as a number of separate pictures that are given motion when viewed in sequence. The pictures themselves are organized as a spatial pixel array, and each pixel may contain one or more samples, depending on the sampling configuration, color space, etc. used. The relationship between pixels and samples is easily understood by those skilled in the art. The following description focuses on samples.

[0058] According to an embodiment, the video encoder (403) encodes pictures of a source video sequence in real time or any other time constraint required by the application and compresses them as an encoded video sequence (443). Running at an appropriate encoding rate is one function of the controller (450). In some embodiments, the controller (450) controls and is functionally coupled to other functional units described below, which are not shown for the sake of simplicity. Parameters set by the controller (450) may include parameters related to rate control (picture skip, quantizer, lambda value for rate distortion optimization techniques...), picture size, group of pictures (GOP) placement, maximum motion vector search range, etc. The controller (450) may be configured to have other suitable functions, which may be attributed to the video encoder (403) optimized for a given system design.

[0059] In some embodiments, the video encoder (403) is arranged to operate in an encoding loop. As a very simple description, in one example, the encoding loop includes a source encoder (430) (e.g., responsible for constructing a code, such as a code stream, based on an input picture to be encoded and reference picture(s)) and a (local) decoder (433) embedded in the video encoder (403). The decoder (433) reconstructs the code and constructs sample data in the same way that a (remote) decoder constructs sample data (because in the video compression techniques considered in the disclosed subject matter, the compression between the code and the encoded video bit stream is both lossless). The reconstructed sample stream (sample data) is input to a reference picture memory (434). The decoding of the code stream produces bit-exact results that are independent of the decoder location (local or remote), so that the contents in the reference picture memory (434) are bit-exact between the local encoder and the remote encoder. In other words, the reference picture samples "seen" by the prediction part of the encoder are exactly the same as the sample values ​​"seen" by the decoder when it tries to use the prediction during decoding. The basic principle of reference picture synchrony (and the drift that occurs when synchrony cannot be maintained, e.g. from channel errors) also applies in related fields.

[0060] The operation of the "local" decoder (433) may be the same as that of a "remote" decoder, such as the video decoder (310) detailed above in conjunction with Figure 3. However, with brief reference to Figure 3, the entropy decoding portion of the video decoder (310), including the buffer memory (315) and the parser (320), may not be fully implemented in the local decoder (433), if a code is available and the entropy encoder (445) and the parser (320) are capable of losslessly encoding / decoding the code into an encoded video sequence.

[0061] In this case, any decoder techniques other than analysis / entropy decoding present in the decoder will necessarily be present in the corresponding encoder in essentially the same functional form. For this reason, the subject matter of this disclosure will focus on the operation of the decoder. As opposed to the encoder techniques being fully described, the description of the encoder techniques may be simplified. Only certain areas require more detailed description, which are provided below.

[0062] During operation, in some examples, the source encoder (430) can perform motion-compensated predictive encoding, which refers to one or more previously encoded pictures from the video sequence, designated as "reference pictures," and performs predictive encoding on the input picture. In this manner, the encoding engine (432) encodes the difference between pixel blocks of the input picture and pixel blocks selected as the reference picture(s) of the prediction reference(s) of the input picture.

[0063] The local video decoder (433) can decode the encoded video data of pictures that can be designated as reference pictures based on the codes constructed by the source encoder (430). The operation of the encoding engine (432) is preferably a lossy process. Once the encoded video data can be decoded by a video decoder (not shown in FIG. 4), the reconstructed video sequence can be a copy of the source video sequence, which generally has some errors. The local video decoder (433) copies the decoding process that the video decoder performs on the reference pictures and stores the reconstructed reference pictures in a reference picture cache (434). In this manner, the video encoder (403) stores locally a copy of the reconstructed reference picture, which has a common content (no transmission errors) with the reference picture of the reconstruction obtained by the remote video decoder.

[0064] The predictor (435) can perform a prediction search for the coding engine (432). That is, for a new picture to be coded, the predictor (435) searches the reference picture memory (434) for sample data (as candidate reference pixel blocks) of suitable prediction references for the new picture, or for certain metadata, such as reference picture motion vectors, block shapes, etc. The predictor (435) can find suitable prediction references by operating pixel block by pixel block based on the sample blocks. In some situations, the input picture may have prediction references obtained from multiple reference pictures stored in the reference picture memory (434), as determined based on the search results obtained by the predictor (435).

[0065] The controller (450) can manage the encoding operations of the source encoder (430), for example, setting parameters for encoding the video data and subgroup parameters.

[0066] The output of all the functional units mentioned above can be entropy coded in an entropy coder (445), which converts the codes generated by the various functional units into a coded video sequence by performing lossless compression based on techniques such as Huffman coding, variable length coding, arithmetic coding, etc.

[0067] The transmitter (440) buffers the encoded video sequence(s) constructed by the entropy encoder (445) to prepare them for transmission over a communication channel (460), which may be a hardware / software link to a storage device for storing the encoded video data. The transmitter (440) merges the encoded video data from the video encoder (403) with other data to be transmitted, such as encoded audio data and / or auxiliary data streams (sources not shown).

[0068] The controller (450) can manage the operation of the video encoder (403). During encoding, the controller (450) assigns each encoded picture a particular encoding picture type, which can affect the encoding technique that can be applied to the respective image. For example, pictures are typically assigned one of the following picture types:

[0069] An intraframe picture (I-picture) may be a picture that is coded and decoded without using any other picture in a sequence as a source of prediction. Some video codecs allow different types of intraframe pictures, including, for example, independent decoder refresh ("IDR") pictures. Those skilled in the art will understand the variations of I-pictures and their corresponding applications and characteristics.

[0070] A predictive picture (P-picture) may be a picture that is encoded and decoded using intra-frame prediction (intra-prediction) or inter-frame prediction (inter-prediction), which uses at most one motion vector and reference index to predict the sample values ​​of each block.

[0071] A bidirectionally predictive picture (B-picture) may be a picture that is coded and decoded using intra-frame or inter-frame prediction, which predicts the sample values ​​of each block by at most two motion vectors and reference indices. Similarly, a multi-predictive picture can use more than two reference pictures and associated metadata to reconstruct a single block.

[0072] A source picture can generally be spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8 or 16x16 samples) and coded block by block. These blocks are predictively coded with reference to other (already coded) blocks, which are determined by the coding assignment applied to the block's corresponding picture. For example, blocks of an I picture may be non-predictively coded or predictively coded (spatial or intraframe prediction) with reference to already coded blocks of the same picture. Pixel blocks of a P picture may be predictively coded via spatial or temporal prediction with reference to one previously coded reference picture. Blocks of a B picture may be predictively coded via spatial or temporal prediction with reference to one or two previously coded reference pictures.

[0073] The video encoder (403) may perform encoding operations based on a given video encoding technique or standard, for example, the ITU-T H.265 proposal. In its operation, the video encoder (403) may perform various compression operations, including predictive encoding operations that exploit temporal and spatial redundancy in the input video sequence. Thus, the encoded video data conforms to a grammar specified by the video encoding technique or standard used.

[0074] In an embodiment, the transmitter (440) can transmit additional data and the encoded video. The source encoder (430) may include such data as part of the encoded video sequence. The additional data may include temporal / spatial / SNR enhancement layers, other types of redundant data such as redundant pictures and slices, Supplemental Enhancement Information (SEI) messages, Video Usability Information (VUI) parameter set segments, etc.

[0075] A video may be captured as multiple source pictures (video pictures) in a temporal order. Intraframe picture prediction (commonly simplified to intraframe prediction) exploits spatial associations in a particular picture, while interframe picture prediction exploits associations (temporal or other) between pictures. In the example, a particular picture in the encoding / decoding, called the current picture, is divided into blocks. If a block in the current picture resembles a reference block in a previously encoded and still buffered reference picture in the video, the block in the current picture may be coded by a vector called a motion vector. The motion vector points to a reference block in the reference picture, and may have a third dimension for identifying the reference picture when multiple reference pictures are used.

[0076] In some embodiments, a bidirectional prediction technique is used for inter-frame picture prediction. Based on the bidirectional prediction technique, two reference pictures, such as a first reference picture and a second reference picture, are utilized, both of which are before the current picture in the video in decoding order (but may be in the past and future, respectively, in display order). A block in the current picture can be encoded 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 can be predicted by a combination of the first reference block and the second reference block.

[0077] Moreover, the merge mode technique is used in inter-frame picture prediction to improve coding efficiency.

[0078] According to some embodiments of the subject matter of the present disclosure, prediction such as inter-frame picture prediction and intra-frame picture prediction is performed for each block. For example, based on the HEVC standard, a picture in a video picture sequence is divided into coding tree blocks (CTUs) for compression, and the CTUs in a picture have the same size, for example, 64×64 pixels, 32×32 pixels, or 16×16 pixels. Generally, a CTU includes three coding tree blocks (CTBs), including one luminance CTB and two chrominance CTBs. Each CTU is recursively divided into one or more coding units (CUs) in a quad tree. For example, a CTU of 64×64 pixels is divided into one CU of 64×64 pixels, or four CUs of 32×32 pixels, or 16 CUs of 16×16 pixels. In the example, each CU is analyzed to determine the prediction type used for the CU, such as an inter-frame prediction type or an intra-frame prediction type. Depending on the temporal and / or spatial predictability, a CU is divided into one or more prediction units (PUs). Generally, each PU includes a luma prediction block (PB) and two chrominance PBs. In an embodiment, the prediction operation in coding (encoding / decoding) is performed on a prediction block basis. As an example of a prediction block, a luma prediction block is used, which includes a matrix of pixel values ​​(e.g., luma values), such as 8×8 pixels, 16×16 pixels, 8×16 pixels, 16×8 pixels, etc.

[0079] 5 shows a diagram of a video encoder (503) according to another embodiment of the present disclosed subject matter. The video encoder (503) is arranged to receive a processed block of sample values ​​(e.g., a predictive block) in a current video picture in a video picture sequence, and to encode the processed block into a coded picture as part of a coded video sequence. In the example, the video encoder (503) is used in place of the video encoder (203) in the example of FIG. 2.

[0080] In an HEVC example, a video encoder (503) receives a processing block, e.g., a matrix of sample values, e.g., a predictive block of 8x8 samples. The video encoder (503) determines whether to optimally encode the processing block using intra mode, inter mode, or bidirectional predictive mode, e.g., by rate-distortion optimization. If encoding the processing block in intra mode, the video encoder (503) may encode the processing block into a coded picture using intra prediction techniques, and if encoding the processing block in inter mode or bidirectional predictive mode, the video encoder (503) may encode the processing block into a coded picture using inter prediction or bidirectional prediction techniques, respectively. In some video encoding techniques, the merge mode may be an inter picture prediction submode, deriving motion vectors from one or more motion vector predictors, without borrowing any encoded motion vector components outside of the predictor. In some other video encoding techniques, there may be motion vector components that are applied to the theme block. In the example, the video encoder (503) includes other components, such as a mode decision module (not shown) for determining the mode of the processing blocks.

[0081] In the example of FIG. 5, the video encoder (503) includes an interframe encoder (530), an intraframe encoder (522), a residual calculator (523), a switch (526), ​​a residual encoder (524), a general controller (521), and an entropy encoder (525), concatenated as shown in FIG. 5.

[0082] The inter-frame encoder (530) is configured to receive samples of a current block (e.g., a processing block), compare the block with one or more reference blocks in a reference picture (e.g., blocks in a previous picture and a subsequent picture), generate inter-frame prediction information (e.g., motion vectors, merge mode information, descriptions for redundant information due to inter-frame coding techniques), and calculate an inter-frame prediction result (e.g., a prediction block) using any suitable technique based on the inter-frame prediction information. In some examples, the reference picture is a decoded reference picture that has been decoded based on the coded video information.

[0083] The intra-encoder (522) is configured to receive samples of a current block (e.g., a processing block), in some cases compare and transform the block with coded blocks in the same picture, generate quantization coefficients, and in some circumstances further generate intra-prediction information (e.g., intra-prediction direction information according to one or more intra-encoding techniques). In one example, the intra-encoder (522) further calculates an intra-prediction result based on a reference block in the same picture as the intra-prediction information (e.g., a prediction block).

[0084] The generic controller (521) is configured to determine generic control data and control other components of the video encoder (503) based on the generic control data. In one example, the generic controller (521) determines the mode of the block and provides a control signal to the switch (526) based on the mode. For example, if the mode is an intra mode, the generic controller (521) controls the switch (526) to select an intra mode result of use of the residual calculator (523), controls the entropy encoder (525) to select intra prediction information, and includes the intra prediction information in the bitstream. If the mode is an inter mode, the generic controller (521) controls the switch (526) to select an inter prediction result of use of the residual calculator (523), controls the entropy encoder (525) to select inter prediction information, and includes the inter prediction information in the bitstream.

[0085] The residual calculator (523) is configured to calculate a difference (residual data) between the received block and a prediction result selected from the intraframe encoder (522) or the interframe encoder (530). The residual encoder (524) is configured to operate on the residual data and generate transform coefficients by encoding the residual data. In one example, the residual encoder (524) is configured to transform the residual data from the spatial domain to the frequency domain to generate transform coefficients. After transforming the coefficients, the quantized transform coefficients are obtained through a quantization process. In each embodiment, the video encoder (503) further includes a residual decoder (528). The residual decoder (528) is configured to perform an inverse transform and generate decoded residual data. The decoded residual data can be utilized by the intraframe encoder (522) and the interframe encoder (530), as appropriate. For example, the inter-frame encoder (530) may generate decoded blocks based on the decoded residual data and inter-frame prediction information, and the intra-frame encoder (522) may generate decoded blocks based on the decoded residual data and intra-frame prediction information. In some instances, the decoded blocks may be appropriately processed to generate decoded pictures, which may be buffered in a memory circuit (not shown) and used as reference pictures.

[0086] The entropy encoder (525) is configured to format the bitstream to include the encoded block. The entropy encoder (525) is configured to include various information in accordance with an appropriate standard, such as the HEVC standard. In an example, the entropy encoder (525) is configured to include in the bitstream general control data, selected prediction information (e.g., intraframe prediction information or interframe prediction information), residual information, and other appropriate information. It is noted that, in accordance with the disclosed subject matter, the residual information is not present when encoding a block in an interframe mode or a merged submode of a bidirectional prediction mode.

[0087] 6 shows a diagram of a video decoder (610) in accordance with another embodiment of the subject matter of this disclosure. The video decoder (610) is configured to receive coded pictures as part of a coded video sequence and to decode the coded pictures to generate reconstructed pictures. In the example, the video decoder (610) is used in place of the video decoder (210) in the example of FIG. 2.

[0088] In the example of FIG. 6, the video decoder (610) includes an entropy decoder (671), an interframe decoder (680), a residual decoder (673), a reconstruction module (674), and an intraframe decoder (672), concatenated as shown in FIG. 6.

[0089] The entropy decoder (671) is arranged to reconstruct, based on the coded picture, some codes indicative of the grammar elements that compose the coded picture. Such codes include, for example, the mode for coding the block (e.g., intra mode, inter mode, bidirectional prediction mode, merged submode of the latter two or other submodes), prediction information (e.g., intra prediction information or inter prediction information) that can be used by the intra decoder (672) or the inter decoder (680), respectively, to recognize some samples or metadata for prediction, residual information, for example in the form of transform coefficients for quantization, etc. In the example, if the prediction mode is an inter or bidirectional prediction mode, the inter prediction information is provided to the inter decoder (680), and if the prediction type is an intra prediction type, the intra prediction information is provided to the intra decoder (672). The residual information is provided to the residual decoder (673) via inverse quantization.

[0090] The inter-frame decoder (680) is configured to receive the inter-frame prediction information and to generate an inter-frame prediction result based on the inter-frame prediction information.

[0091] The intraframe decoder (672) is configured to receive the intraframe prediction information and to generate a prediction result based on the intraframe prediction information.

[0092] The residual decoder (673) is arranged to perform inverse quantization to extract inverse quantized transform coefficients and to transform the residual from the frequency domain to the spatial domain by processing the inverse quantized transform coefficients. The residual decoder (673) may require some control information (including quantizer parameters (QP)), which is provided by the entropy decoder (671) (data path not shown since this is a small amount of control information).

[0093] The reconstruction module (674) is arranged to combine, in the spatial domain, the residual output from the residual decoder (673) with a prediction result (which may be output from an inter-frame prediction module or an intra-frame prediction module, as the case may be), to form a reconstructed block, which may be part of a reconstructed picture, which may be part of a reconstructed video, and to perform other suitable operations, such as a deblocking operation, to improve visual quality.

[0094] It should be noted that the video encoder (203), video encoder (403), video encoder (503), and video decoder (210), video decoder (310), and video decoder (610) may be implemented using any suitable technology. In one embodiment, the video encoder (203), video encoder (403), video encoder (503), and video decoder (210), video decoder (310), and video decoder (610) may be implemented via one or more integrated circuits. In another embodiment, the video decoders (203), (403), (403), and video decoders (210), (310), and (610) are implemented by one or more processors for executing software instructions.

[0095] Aspects of the present disclosure provide techniques for constraining reference block locations in intra-frame block copy mode, and further provide techniques for reusing intra-frame picture block compensation buffers with non-square block partitions.

[0096] Block-based compensation may be used for inter-frame prediction and intra-frame prediction. In the case of inter-frame prediction, compensation based on blocks from different pictures is called motion compensation. In the case of intra-frame prediction, compensation based on blocks may be performed on previously reconstructed regions in the same picture. Compensation based on blocks of reconstructed regions from the same picture is called intra-frame picture block compensation, current picture referencing (CPR) or intra block copy (IBC). A displacement vector indicating the offset between a current block and a reference block in the same picture is called a block vector (or abbreviated as BV). Unlike the motion vector in motion compensation, which can be any value (positive or negative in x or y direction), the block vector is constrained to ensure that a reference block is available and has already been reconstructed. Also, in some examples, considering parallel processing, some reference regions that are tile boundaries or wavefront ladder boundary are excluded.

[0097] The coding of block vectors may be explicit or implicit. In explicit mode (similar to Advanced Motion Vector Prediction (AMVP) mode in interframe coding), the difference between the block vector and its predicted value is signaled, while in implicit mode, the block vector is reconstructed from the predicted value (called block vector predictor) similar to the motion vector in merge mode. In some implementations, the resolution of block vectors is limited to integer positions, while in other systems block vectors are allowed to point to fractional positions.

[0098] In some examples, a block level flag (IBC flag) may be used to signal the use of block level intra-frame block copy. In an embodiment, the IBC flag is signaled when the current block is not coded in merge mode. In another embodiment, the IBC flag is signaled using a reference index method. The current picture being decoded is then considered as a reference picture. In an example, such a reference picture is set to the last position of a list of reference pictures. The particular reference picture is further managed in a buffer, such as a decoded picture buffer (DPB), together with other temporal reference pictures.

[0099] There are also several variants of intra-frame block copying, such as flipped intra-frame block copying (where the reference block is flipped horizontally or vertically before being used to predict the current block) or row-based intra-frame block copying (where each compensation unit in an M×N coding block is an M×1 or 1×N row).

[0100] 7 shows an example of intra-frame block copying according to an embodiment of the subject matter of the present disclosure. A current picture (700) is being decoded. The current picture (700) includes a reconstructed region (710) (gray region) and a region to be decoded (720) (white region). A current block (730) is being reconstructed by the decoder. The current block (730) can be reconstructed according to a reference block (740) in the reconstructed region (710). The position offset between the reference block (740) and the current block (730) is called a block vector (750) (or BV (750)).

[0101] In some implementation examples, the reconstructed samples of the current picture may be buffered in a dedicated memory. Considering the cost of implementation, the reference region cannot be as large as a full frame, and is limited to the storage size of the dedicated memory. In some embodiments, the block vectors in the intra-frame block copy are allowed to refer to only some adjacent regions, not to the full picture. In one example, the memory size of the dedicated memory is one CTU, and if the reference block is in the same CTU as the current block, the intra-frame block copy mode may be used. In another example, the memory size is two CTUs, and if the reference block is in the current CTU or in the CTU to the left of the current CTU, the intra-frame block copy mode may be used. In one example, if the reference block is outside the designated local region, the reference sample cannot be used for intra-frame picture block compensation, even if the reference block has already been reconstructed.

[0102] In the case of constrained reference regions, the efficiency of intra-frame block copying is limited. There is a need to further improve the efficiency of intra-frame block copying in constrained reference regions.

[0103] In some versions of video coding standards, for example in the version of VVC, a picture is divided into an array of non-overlapping CTUs. The size of a CTU is set to 128x128 luma samples (and corresponding chroma samples depending on the color format). For example, one or other combination of tree partitioning methods such as binary tree (BT) partitioning, ternary tree (TT) partitioning, etc. may be used to partition the CTUs into coding units (CUs). BT partitioning divides a parent block in half horizontally or vertically. Compared to the parent block, the two smaller partitions obtained by BT partitioning have half the size. TT partitioning divides a parent block into three parts horizontally or vertically. The middle part of the three parts is twice the size of the other two parts. Compared to the parent block, the three smaller partitions obtained by TT partitioning have ¼, ½ and ¼ the size.

[0104] In some embodiments, the partitioning of blocks at the 128x128 level is constrained to allow several outcomes, for example, one 128x128 block, two 128x64 blocks, two 64x128 blocks, or four 64x64 blocks. In some examples, the partitioning is further constrained to not allow TT partitioning in either direction (horizontal or vertical) at the 128x64 or 64x128 block level. Also, in examples, 128x64 or 64x128, if further partitioned, is only allowed to partition into two 64x64 blocks. The constrained partition type is called the normal partition type.

[0105] In some examples, intraframe block copy is realized with limited memory requirements. In an example of the implementation, a designated memory that stores reference samples of previously coded CUs and is used for future intraframe block copy references is called a reference sample memory. For example, the maximum size of the reference sample memory (also called a buffer) for storing unfiltered samples in intraframe block copy mode is the size of one CTU (128×128 luma samples and corresponding chroma samples). In order to fully utilize such constrained memory, in some examples, the buffer is updated every 64×64. In an example, if a part of the reference sample memory has not yet been updated using reconstructed samples from the current CTU, these parts of data stored in the memory are actually reconstructed samples from the left CTU. These samples are used as references for predicting the current block in the intraframe block copy mode. Then, the effective search range is extended from within the current CTU to a part of the left CTU.

[0106] Thus, in some embodiments, before updating the reference sample memory using the reconstructed samples in the current CTU, the reference sample memory may be reused to store previously encoded samples in the left CTU. In some embodiments, the availability of the reference sample memory is updated every 64×64. In an example, when any sample of the reference samples in a 64×64 block is updated, the entire 64×64 block is considered to be updated using the reconstructed samples from the current CTU, and is not considered to store the samples before the update. In some implementation examples, the addressing operations of allocating contiguous memory spaces in a memory (e.g., a buffer memory, an on-chip memory, etc.) to store the reconstructed samples of the 64×64 block, and storing and reading back the reconstructed samples from the contiguous memory spaces can be performed with relatively simple calculations. In some examples, the contiguous memory spaces that store the reconstructed samples of the coding area (e.g., a 64×64 coding area) are referred to as memory update units. Accessing the samples in the memory update units may be performed using reduced addressing calculations, and accessing samples in different memory update units requires an increased number of addressing calculations.

[0107] 8A-8D show examples of effective search ranges for the reference sample memory update per 64×64 and intra-frame block copy modes according to embodiments of the present disclosure. In some examples, the encoder / decoder includes a cache memory that can store samples of one CTU (e.g., 128×128 samples). Also, in the examples of FIG. 8A-8D, the CTU is divided into four 64×64 coding regions. The coding region with the current block for prediction (which may be equal to or smaller than the coding region) is called the current coding region (labeled as "Curr"). It should be noted that the examples may be appropriately modified for coding regions of other suitable sizes.

[0108] Each of Figures 8A to 8D shows a current CTU (820) and a left CTU (810). The left CTU (810) includes four coding regions (811) to (814), each of which has a sample size of 64 x 64 samples. The current CTU (820) includes four coding regions (821) to (824), each of which has a sample size of 64 x 64 samples. The current CTU (820) includes a CTU that includes a current coding region (e.g., having a vertical stripe pattern, as shown by the label "Curr") that is being reconstructed. The left CTU (810) is adjacent to the left side of the current CTU (820). In Figures 8A to 8D, the gray blocks are coding regions that have already been reconstructed, and the white blocks are coding regions to be reconstructed.

[0109] In Fig. 8A, the current coding region being reconstructed is coding region (821). The cache memory stores reconstructed samples in coding regions (812), (813), and (814), and the cache memory is used to store reconstructed samples of the current coding region (821). In the example of Fig. 8A, the valid search range of the current coding region (821) includes coding regions (812), (813), and (814) in the left CTU (810), and the reconstructed samples in these regions are stored in the cache memory. In the example, when updating the cache memory using one or more reconstructed samples from the current coding region (821), it is recognized that the coding region (811) cannot be used for CPR prediction in the cache memory (marked as "X") because part of the coding region (811) has already been updated with reconstructed samples from the current CTU. Note that in an embodiment, the reconstructed samples of the coding region (811) are stored in main memory, which has a slower access speed than the cache memory (e.g., copied from the cache memory to the main memory before reconstructing the coding region (821)).

[0110] In Fig. 8B, the current coding region being reconstructed is coding region (822). The cache memory stores reconstructed samples in coding regions (813), (814) and (821), and the cache memory is used to store reconstructed samples of the current coding region (822). In the example of Fig. 8B, the valid search range of the current coding region (822) includes coding regions (813) and (814) in the left CTU (810) and coding region (821) in the current CTU (820), and the reconstructed samples of these regions are stored in the cache memory. In the example, when updating the cache memory using one or more reconstructed samples from the current coding region (822), it is recognized that the coding region (812) cannot be used for CPR prediction in the cache memory (marked as "X") because part of the coding region (812) has already been updated with reconstructed samples from the current CTU. Note that in an embodiment, the reconstructed samples of the coding region (812) are stored in main memory, which has a slower access speed than the cache memory (e.g., copied from the cache memory to main memory before reconstructing the coding region (822)).

[0111] In Fig. 8C, the current coding region being reconstructed is coding region (823). The cache memory stores reconstructed samples in coding regions (814), (821) and (822), and the cache memory is used to store reconstructed samples of the current coding region (823). In the example of Fig. 8C, the valid search range of the current coding region (823) includes coding region (814) in the left CTU (810) and coding regions (821) and (822) in the current CTU (820), and the reconstructed samples of these regions are stored in the cache memory. In the example, when updating the cache memory using one or more reconstructed samples from the current coding region (823), it is recognized that the coding region (813) cannot be used for CPR prediction in the cache memory (marked as "X") because part of the coding region (813) has already been updated with reconstructed samples from the current CTU. Note that in an embodiment, the reconstructed samples of the coding region (813) are stored in main memory, which has a slower access speed than the cache memory (e.g., copied from the cache memory to the main memory before reconstructing the coding region (823)).

[0112] In Fig. 8D, the current coding region being reconstructed is coding region (824). The cache memory stores reconstructed samples in coding regions (821), (822), and (823), and the cache memory is used to store reconstructed samples of the current coding region (824). In the example of Fig. 8D, the valid search range of the current coding region (824) includes coding regions (821), (822), and (823) in the current CTU (820), and the reconstructed samples of these regions are stored in the cache memory. In the example, when updating the cache memory using one or more reconstructed samples from the current coding region (824), it is recognized that the coding region (814) cannot be used for CPR prediction in the cache memory (marked as "X") because part of the coding region (814) has already been updated with reconstructed samples from the current CTU. Note that in an embodiment, the reconstructed samples of the coding region (814) are stored in main memory, which has a slower access speed than the cache memory (e.g., copied from the cache memory to main memory before reconstructing the coding region (824)).

[0113] In the example of Figures 8A-8D, a total memory of 4x64x64 luma samples (together with corresponding chroma samples) is used for intra-frame block copy compensation. Note that the techniques used in the examples of Figures 8A-8D can be appropriately modified for other memory sizes (e.g., a total memory of 3x64x64, 2x64x64 luma samples).

[0114] Note that in some embodiments, ternary tree division at the 128x128 level and lower levels is allowed, and the division results may be non-square blocks.

[0115] In some examples, a CTU may be partitioned using ternary tree partitioning at the 128x128 level. For horizontal TT partitioning, the partitioned blocks are 128x32, 128x64, and 128x32. For vertical partitioning, the partitioned blocks are 32x128, 64x128, and 32x128.

[0116] Also, in some examples, ternary tree division may be used at the 128x64 / 64x128 level, and the resulting blocks may be non-square blocks.

[0117] 9A to 9H show examples of non-square block divisions.

[0118] According to some aspects of the present disclosure, some partition types, such as 128x128 level TT partitioning, may result in coding blocks that are not included in a 64x64 coding region or that cannot contain one or more 64x64 coding regions.

[0119] When allowing these partition types on top of the normal partition types, the reference sample update process may no longer be one-to-one aligned with the 64x64 coding region. A method needs to be developed to implement the reference sample memory cache reuse strategy mentioned above.

[0120] According to an aspect of the present disclosure, some reference region constraints can be used to improve the performance of intra-frame block copy. More specifically, in an example, the location of the reference sample block in the reference sample memory is constrained to be within the same 64x64 coding region. In some embodiments, the size of the reference sample memory is fixed to two 64x64 luma samples (with corresponding chroma samples). It should be noted that the techniques used in the present disclosure can be appropriately modified for use with different reference sample memory sizes, such as memory sizes of three 64x64 luma samples and corresponding chroma samples, four 64x64 luma samples and corresponding chroma samples (i.e., one CTU size), etc.

[0121] In general, the size of an IBC coded block may be the same as any normal interframe coded block. According to one aspect of the present disclosure, the size of an IBC coded block is limited to utilize the reference sample memory more efficiently. In an example, the size of an IBC coded block is limited to an upper limit, e.g., not larger than 64 luma samples in width or height (note that a corresponding size constraint applies to the chroma samples, depending on the color format, e.g., 4:2:0 format, the size of a chroma block in IBC mode must not exceed 32 samples on each side). Also, in some examples, the size of an IBC coded block is limited to a lower limit, e.g., not smaller than 32 luma samples in width or height. Note that in the description, a maximum IBC size of 64x64 luma samples is used, but the technique can be appropriately modified for other maximum IBC sizes.

[0122] In the following description, the maximum size of the reference sample memory for storing intra-frame block copy reference samples corresponds to the memory size for storing two 64x64 luma samples and the corresponding chroma samples.

[0123] According to some aspects of the present disclosure, the reference sample memory has a size for storing sample information of two coding regions, each coding region having a size of 64×64 luma samples, and the sample information includes luma sample information of the 64×64 luma samples and chroma sample information of the corresponding chroma samples. The reference sample memory then stores the sample information of the current coding region in the current CTU and sample information of another coding region, which is one of several previously encoded 64×64 coding regions.

[0124] Figures 10A and 10B show two examples of the coding order and the use of the reference sample memory. In Figures 10A and 10B, the grey areas are coding areas that have already been coded (e.g., 64x64 luma samples), the white areas are areas that have not yet been coded, and the shaded areas(s) are coding areas(s) in which the current coding block is located. Also, in Figures 10A and 10B, the two coding areas in the reference sample memory are indicated by the dotted box(s).

[0125] In Fig. 10A, in the example, the CTU performs horizontal binary division or quadtree division at 128x128 level, and the coding order of the 64x64 coding region follows (1001) to (1004).

[0126] In Fig. 10B, in the example, the CTU performs vertical binary division at 128x128 level, and the coding order of the 64x64 coding region follows (1011) to (1014).

[0127] In the examples of Figures 10A and 10B, when the current coding block is located in one of the four 64x64 coding areas in the current CTU, the reference sample memory may store another 64x64 coding area that is assigned as a reference for the intra-frame block copy mode.

[0128] It should be noted that Figures 10A and 10B are examples and other possible reference region assignments are possible. In an embodiment, the top right 64x64 coding region is used as a reference region for the bottom right 64x64 coding region, as shown in Figures 10A and 10B. In another embodiment, the top left 64x64 coding region is used as a reference region for the bottom right 64x64 coding region.

[0129] Ideally, the reconstructed samples in the reference sample memory may be used to predict the current block in the intra-frame block copy mode. However, there are cases where the samples in the reference block are from two different 64x64 coding regions.

[0130] 11A and 11B show examples of samples in a reference block from two different 64×64 coding regions. In FIG. 11A, a part of the reference block is from one 64×64 coded coding region, and another part is already reconstructed but belongs to another 64×64 previously coded coding region. In FIG. 11B, a part of the reference block is from one 64×64 coded region, and another part is already reconstructed but belongs to the current 64×64 coding region. Since each of the 64×64 coding regions in the reference sample memory is operated separately, the two 64×64 coding regions in the memory cannot be physically connected. These locations of the reference block in different coding regions as shown in FIG. 11A and 11B may result in undesirable extra memory accesses or operations.

[0131] According to some aspects of the present disclosure, an additional constraint is used together with other appropriate block vector constraints that make intra-frame block copy work in a particular video / image coding system. An additional constraint is imposed on the block vectors of the intra-frame block copy mode to ensure that the entire reference block for the intra-frame block copy mode is within the same 64×64 coding region. The 64×64 coding region refers to each CTU having 128×128 luma samples (plus corresponding chroma samples) can be divided into four non-overlapping 64×64 regions. In some examples, each of these 64×64 regions is considered as a 64×64 coding region in the constraint.

[0132] In an embodiment, for example, the top corner of a CTU is (0,0), the top left corner of the reference block is denoted as (Ref_TLx, Ref_TLy), and the bottom right corner of the reference block is denoted as (Ref_BRx, Ref_BRy). The additional constraint takes the form that the bitstream consistency requirements of the following conditions (Equation 1) and (Equation 2) must be satisfied. Ref_BRx / 64=Ref_TLx / 64 (Formula 1) Ref_BRy / 64=Ref_TLy / 64 (Equation 2)

[0133] If (Equation 1) is satisfied, the integer part of Ref_BRx / 64 is equal to the integer part of Ref_TLx / 64. If (Equation 2) is satisfied, the integer part of Ref_BRy / 64 is equal to the integer part of Ref_TLy / 64. Note that the division operation may be performed by shifting 6 bits to the right.

[0134] In some embodiments, when a block vector points to a reference block position where not all samples in the reference block belong to the same 64x64 coding region, the block vector may be clipped to a nearby reference block position that meets the same 64x64 coding region requirement. In an embodiment, clipping refers to moving the original reference block position (which covers at least two 64x64 regions) in one direction, vertically or horizontally. In an example, moving in a direction that reduces the distance between the reference block and the current block. Also, moving in a direction that increases the percentage of reference samples that belong to the same 64x64 sample region, and finally making the entire reference block belong to the same 64x64 region.

[0135] For the example shown in Figure 11A, the reference block can be moved vertically up until all samples belong to the top 64x64 coding region. Note that in the example shown in Figure 11A, moving the reference block down may increase the distance between the two blocks, while moving the reference block horizontally does not change the percentage of samples in each 64x64 coding region.

[0136] For the example shown in Figure 11B, the reference block can be moved horizontally to the right until all samples belong to the current 64x64 coding region. Note that in the example shown in Figure 11B, moving the reference block to the left may increase the distance between the two blocks, while moving the reference block vertically does not change the percentage of samples in each 64x64 coding region.

[0137] In some embodiments, when a block vector points to a reference block position where not all samples in the reference block belong to the same 64x64 coding region, samples outside the 64x64 coding region may be generated by padding samples (copying samples at the borders of the 64x64 coding region vertically and / or horizontally). The padding process can be performed in a manner similar to the border extension of reference pictures in motion compensation.

[0138] In the example, the upper left corner of the reference block is located within a 64x64 coding region, and the 64x64 coding region is considered to be the coding region that the reference block should come from. If any part of the reference block is outside the coding region, padding can be used to determine the samples of that part.

[0139] In another example, the lower right corner of the reference block is located within a 64x64 coding region, and the 64x64 coding region is considered to be the coding region from which the reference block should originate. If any part of the reference block is outside the coding region, padding can be used to determine the samples of that part.

[0140] In another example, the upper left corner of the reference block is located in a 64x64 coding region, and the 64x64 coding region is first used to determine which coding region the reference block comes from. If the position of the upper left corner is not a valid reference position, the lower right corner of the reference block is considered to determine which coding region the reference block comes from.

[0141] In another example, the lower right corner of the reference block is located in a 64x64 coding region, and the 64x64 coding region is first used to determine which coding region the reference block comes from. If the position of the lower right corner is not a valid reference position, the upper left corner of the reference block is considered to determine which coding region the reference block comes from.

[0142] In another embodiment, if the block vector points to a reference block position where all samples in the reference block are outside the valid reference region (current 64x64 coding region or previously coded 64x64 coding region(s)), samples outside the 64x64 coding region may be generated by padding the samples (vertically and / or horizontally copying the samples at the nearest valid reference region boundary). The padding process may be performed similarly to the reference picture boundary extension in motion compensation, where the boundary can be considered as the boundary of the allowed reference region(s).

[0143] Aspects of the present disclosed subject matter further provide a flexible block partitioning strategy and buffer reuse mechanism for intra-frame block copying.

[0144] In some embodiments, when using intra-frame block copying for a given coding level (e.g., sequence, picture, or slice / tile / tile group), flexible block partition types, e.g., 128x32 / 32x128, cannot be used.

[0145] In an embodiment, if a flexible block partition type is not used for a given coding level (e.g., sequence, picture, or slice / tile / tile group), the intra-frame block copy mode may use a reference sample memory reuse strategy, such as an update processing and buffering reuse strategy based on a 64x64 coding region.

[0146] In an embodiment, when using a flexible block partition type for a given coding level (e.g., sequence, picture, or slice / tile / tile group), the intra-frame block copy mode cannot use the reference sample memory reuse strategy disclosed in the above disclosure, except that in the example, block vectors are restricted to refer to reconstructed portions of the current CTU.

[0147] In an embodiment, when using the flexible block partition types mentioned above for a given coding level (e.g., sequence, picture or slice / tile / tile group), the reference sample memory reuse strategy mentioned above may be modified.

[0148] In some examples, when the coding block is in the first TT partition at the CTU (128x128) level (e.g., left 32x128 or top 128x32), or a BT partition (top 128x64 or left 64x128) or a QT partition (top left 64x64), some of the reference samples in the left CTU can be used.

[0149] Figures 12A to 12F show examples of reference sample memory reuse strategies. In each example shown in Figures 12A to 12F, the current coding block is shown in diagonal lines and the available reference regions are shown in grey.

[0150] In the example, the 64x64 (sample) region in the upper right corner of the left CTU is the available reference region, shown in grey in the example of Figures 12A-12C.

[0151] In another example, the rightmost 32x128 (sample) region in the left CTU is the available reference region, shown in grey in the example of Figures 12D-12F.

[0152] In another example, the top 128x32 region in the left CTU is an available reference region.

[0153] In another example, the selection of the region is determined by the partitioning of the left CTU, for example, if the left CTU uses 128x128 level quadtree partitioning, the top right 64x64 (sample) region in the left CTU may be used to predict the coding blocks in the first partition of the current CTU.

[0154] In another example, when using a total memory size of 3×64×64 for the coding blocks in the first division of the current CTU, the size of the memory for storing reference samples from the left CTU is 64×64 in size (not necessarily square). The memory space does not necessarily store square shaped samples.

[0155] In another embodiment, when a total memory size of 4×64×64 is used for the coding blocks in the first division of the current CTU, the size of the memory for storing the reference samples from the left CTU is 2×64×64 in size (not necessarily two squares). The memory space does not necessarily store two squares of samples.

[0156] In some embodiments, when using both flexible block partitioning type and intra-frame block copy mode at a given coding level (e.g., for a sequence, picture or slice / tile / tile group), techniques are used to reuse reference sample memory, effectively increasing the search range for intra-frame block copy while keeping storage requirements the same or reducing storage requirements.

[0157] In some examples, instead of using the previous 64x64 based update process, submit a smaller or equal granularity update process with more block shapes (e.g., 32x32 or 32x64 or 64x32 or 16x128 shapes). In examples, the update process may use 32x32 (sample) units and may divide the current CTU using 128x128 level TT.

[0158] FIG. 13A-FIG. 13C show an example of the update process using 32×32 (sample) units, and FIG. 13D-FIG. 13F show another example of the update process using 32×32 (samples). Each 32×32 (sample) unit is shown as a small square. In the example of FIG. 13A-FIG. 13F, the reference sample memory size is 128×128 in total. Then, a first memory space of 3×64×64 samples is allocated to store samples of reference samples for intra-frame block copy reference purpose, and a second memory space of 64×64 samples is allocated to the current 64×64 size unit (not necessarily square, the total number of luma samples is equal to 64×64 samples). For each 64x64 or 64x128 size partition and its subpartitions (not necessarily square, luma samples are equal to 64x64 samples), the reconstructed samples in the current CTU and some other previously coded regions (e.g., shown as gray areas in Figures 13A to 13F) may be stored in a reference sample memory and can be referenced for prediction of intra-frame block copies.

[0159] FIG. 14 shows a flow chart outlining a process (1400) according to an embodiment of the present disclosure. The process (1400) is used to reconstruct a block coded in intraframe mode and generates a prediction block for the block being reconstructed. In various embodiments, the process (1400) is performed by a processing circuit such as a processing circuit in the terminal devices (110), (120), (130), and (140), a processing circuit performing the function of a video encoder (203), a processing circuit performing the function of a video decoder (210), a processing circuit performing the function of a video decoder (310), a processing circuit performing the function of a video encoder (403), etc. In some embodiments, the process (1400) is implemented by software instructions, such that when the processing circuit executes the software instructions, the processing circuit performs the process (1400). The process starts at (S1401) and runs through (S1410).

[0160] At (S1410), prediction information for the current block is decoded from the encoded video bitstream, where the prediction information indicates an intra-frame block copy mode.

[0161] At (S1420), a block vector is determined that points to a reference block in the same picture as the current block.

[0162] In (S1430), the reference block is checked to determine whether the reference block is entirely in the coding region. In some embodiments, a reference sample memory with limited storage space is reused to store previous coded samples. For example, before updating the reference sample memory using reconstructed samples in the current CTU, the reference sample memory stores samples in a CTU to the left of the current CTU. The reference sample memory is updated using reconstructed samples in units of coding regions in the current CTU. In an embodiment, the availability of the reference sample memory is updated in 64x64 units. In an example, once any sample of the reference samples in a 64x64 block has already been updated, the entire 64x64 block is considered to be updated using reconstructed samples from the current CTU, and is not considered to be stored samples before updating. In an embodiment, a CTU of 128x128 samples includes four 64x64 regions, which may be called coding regions.

[0163] In an embodiment, the multiple corners of the reference block are checked to determine whether the reference block is entirely within the coding region. If the reference block is entirely within the coding region, processing proceeds to (S1450); otherwise, processing proceeds to (S1440).

[0164] In (S1440), the reference block is appropriately restricted to the coding region. In some embodiments, the reference block is appropriately moved to the coding region. In some embodiments, some reference samples not in the coding region may be padded using other reference samples not in the coding region. Then, in the example, the memory access of the reconstructed reference samples of the current block can be realized by accessing only one memory update unit.

[0165] In (S1450), the current block is reconstructed based on the reconstructed sample of the reference block retrieved from the reference sample memory. For example, the reference sample memory is accessed to retrieve the reconstructed sample of the reference block, and then the sample of the current block is reconstructed based on the reconstructed sample retrieved from the reference sample memory. Since the reference block is restricted to determine that the reference sample of the reference block is entirely in one coding region or based on one coding region, the addressing operation of retrieving the reference sample can be easily and efficiently performed. Then, the process proceeds to (S1499) and ends.

[0166] The techniques may be implemented as computer software by computer-readable instructions and physically stored on one or more computer-readable media. For example, Figure 15 illustrates a computer system (1500) for implementing some embodiments of the disclosed subject matter.

[0167] Computer software may be encoded in any suitable machine code or computer language, which may be edited, compiled, linked, or otherwise constructed to produce code containing instructions that are executed directly by one or more computer central processing units (CPUs), graphics processing units (GPUs), or the like, or may be executed by interpretation, microcode execution, or the like.

[0168] The instructions may be executed by various types of computers or components thereof, including, for example, personal computers, tablets, servers, smart phones, gaming devices, Internet of Things devices, and the like.

[0169] The components of the computer system (1500) shown in Figure 15 are exemplary in nature and are not limiting on the scope or functionality of use of the computer software of the embodiments for implementing the subject matter of the present disclosure, nor should the arrangement of components be construed as having any dependency or requirement regarding any one or combination of components shown in the illustrative implementation of the computer system (1500).

[0170] The computer system (1500) may include several human machine interface input devices. Such human machine interface input devices may respond to input from one or more human users, for example, through tactile input (e.g., keystrokes, slides, data glove movements), audio input (e.g., voice, tapping), visual input (e.g., posture), and olfactory input (not shown). The human machine interface devices may also capture certain media that are not necessarily directly related to the conscious input of a human being, such as audio (e.g., voice, music, ambient sounds), images (e.g., scanned images, photographic images obtained from still image capture devices), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video).

[0171] The input man-machine interface devices may include one or more of a keyboard (1501), a mouse (1502), a touchpad (1503), a touch panel (1510), a data glove (not shown), a joystick (1505), a microphone (1506), a scanner (1507), and an imaging device (1508) (only one of each described).

[0172] The computer system (1500) may further include human-machine interface output devices. Such human-machine interface output devices may stimulate one or more of the human user's senses, for example, through haptic output, sound, light, and smell / taste. Such human-machine interface output devices may include haptic output devices (e.g., haptic feedback via a touch panel (1510), data gloves (not shown), or joystick (1505), although there are also haptic feedback devices that are not used as input devices), audio output devices (e.g., speakers (1509), headphones (not shown)), visual output devices (e.g., a screen (1510), including a CRT screen, LCD screen, plasma screen, OLED screen, each of which may or may not have touch panel input and haptic feedback capabilities, some of which may provide two-dimensional visual output or three or more dimensional output, such as by means of stereoscopic image output, including virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0173] The computer system (1500) may further include human-accessible storage devices and associated media, including, for example, optical media including CD / DVD ROM / RW (1520) with media such as CDs / DVDs (1521), thumb drives (1522), removable hard drives or solid state drives (1523), traditional magnetic media such as magnetic tape and floppy disks (not shown), dedicated ROM / ASIC / PLD based devices, such as dongles (not shown), etc.

[0174] Those skilled in the art will appreciate that in conjunction with the presently disclosed subject matter, the term "computer-readable medium" as used does not include transmission media, carrier waves or other transient signals.

[0175] The computer system (1500) may further include an interface for one or more communication networks. The network may be, for example, wireless, wired, or optical. The network may further be local, wide area, metropolitan, vehicular, industrial, real-time, delay-tolerant, etc. Examples of networks include local area networks such as Ethernet, cellular networks including wireless LAN, GSM, 3G, 4G, 5G, LTE, etc., television wired or wireless wide area digital networks including cable television, satellite television, and terrestrial television, vehicular and industrial networks including CANBus, etc. Some networks typically require an external network interface adapter coupled to a general-purpose data port or peripheral bus (1549) (e.g., a USB port of the computer system (1500)), while other networks are typically integrated into the core of the computer system (1500) by coupling to a system bus described below (e.g., an Ethernet interface to a PC computer system, or a cellular network interface to a smartphone computer system). Through any of these networks, the computer system (1500) can communicate with other entities. Such communications may be one-way and receive only (e.g., broadcast television), one-way and transmit only (e.g., a CANbus to a CANbus device), or two-way (e.g., to another computer system over a local or wide area digital network). Specific protocols and protocol stacks may be utilized for each of these networks and network interfaces described above.

[0176] The man-machine interface devices, human-accessible storage devices, and network interfaces mentioned above may be coupled to a core (1540) of the computer system (1500).

[0177] The core (1540) includes one or more central processing units (CPU) (1541), graphic processing units (GPU) (1542), specialized programmable processing units in the form of field programmable gate arrays (FPGA) (1543), hardware accelerators for certain tasks (1544), etc. These devices are connected via a system bus (1548) along with read only memory (ROM) (1545), random access memory (1546), internal mass storage devices (1547) such as hard disk drives, SSDs, etc. that are not accessible to the internal user. In some computer systems, the system bus (1548) can be expanded by additional CPUs, GPUs, etc., by accessing the system bus (1548) in the form of one or more physical plugs. Peripheral devices are coupled to the core's system bus (1548) directly or through a peripheral bus (1549). Peripheral bus architectures include PCI, USB, etc.

[0178] The CPU (1541), GPU (1542), FPGA (1543) and accelerator (1544) can execute a number of instructions, which, when combined, constitute the computer code referred to above. The computer code is stored in ROM (1545) or RAM (1546). Transient data is stored in RAM (1546) and permanent data may be stored, for example, in an internal mass storage device (1547). A cache memory can be used to quickly store and retrieve any of the memory devices, and the cache memory can be closely associated with one or more of the CPU (1541), GPU (1542), mass storage device (1547), ROM (1545), RAM (1546), etc.

[0179] The computer readable medium may include computer code for performing various computer implemented operations, and the medium and computer code may be specially designed and constructed for the purposes of the subject matter of this disclosure, or may be of the type known and available to those skilled in the art of computer software.

[0180] By way of example and not limitation, a computer system having the architecture (1500), and in particular the core (1540), may provide functionality by having a processor(s) (including CPU, GPU, FPGA, accelerator, etc.) execute software embodied in one or more tangible computer-readable media. Such computer-readable media may be storage devices such as the user-accessible mass storage media discussed above, and non-transitory core (1540) internal mass storage (1547) or ROM (1545). Software for implementing the teachings of the present disclosure in various embodiments may be stored in such devices and executed by the core (1540). Depending on the particular needs, the computer-readable media may include one or more storage devices or chips. The software may cause the core (1540), and in particular the processors therein (including CPU, GPU, FPGA, etc.) to execute certain processes or parts of certain processes described herein, to define data structures stored in RAM (1546), and to modify such data structures based on the processes defined by the software. Also, or alternatively, the computer system may provide functionality embodied in circuitry (e.g., accelerator (1544)), either hardwired or otherwise, that can operate in place of or in conjunction with software to perform particular processes or portions of particular processes described herein. Where appropriate, references to software may include logic, and conversely, references to logic may include software. Where appropriate, references to computer-readable media may include circuitry (e.g., integrated circuits (ICs)) on which software is stored for execution, circuitry embodying logic for execution, or both. The subject matter of this disclosure includes any appropriate combination of hardware and software. Appendix A: Acronyms JEM: Joint Exploration Model VVC: Versatile Video Coding BMS: Benchmark Set MV: Motion Vector HEVC: High Efficiency Video Coding SEI: Replenishment Enhancement Information VUI: Video Usability Information GOP: Group of Pictures TU: conversion unit PU: Prediction unit CTU: Coding Tree Unit CTB: coding tree block PB: Predicted block HRD: Hypothetical Reference Decoder SNR: Signal to Noise Ratio CPU: Central Processing Unit GPU: Graphics Processing Unit CRT: cathode ray tube LCD: Liquid crystal display OLED: Organic Light Emitting Diode CD:Compact Disc DVD: Digital Video Disc ROM: Read-Only Memory RAM: Random Access Memory ASIC: Application Specific Integrated Circuit PLD: Programmable Logic Device LAN: Local Area Network GSM: Global Mobile System of Systems LTE: Long Term Evolution CANBus: Controller Area Network Bus USB: Universal Serial Bus PCI: Peripheral Component Interconnect FPGA: Field Programmable Gate Array SSD: Solid State Drive IC: Integrated Circuit CU: Coding Unit

[0181] While the present disclosure describes some illustrative examples, there are modifications, substitutions, and various substitute equivalents that fall within the scope of the present disclosure. Thus, many systems and methods that embody the principles of the present disclosure and are within the spirit and scope of the present disclosure will be contemplated by those skilled in the art, although not expressly described herein.

Claims

1. A method for encoding video, performed by an encoder, the method comprising: determining prediction information for a current block of a current coding region, and encoding the prediction information in a coded video bitstream, wherein the prediction information indicates an intra-frame block copy mode, and if a coding tree unit (CTU) to which the current block belongs contains fewer than 128x128 luma samples, a size of the coding region is the same as a size of the CTU; otherwise, the CTU is divided into a plurality of coding regions, and the current coding region is a coding region to which the current block belongs among the plurality of coding regions; determining a block vector pointing to a reference block in the same picture as the current block, the reference block being within a search area that includes a coding area having reconstructed samples buffered in a reference sample memory; reconstructing at least one sample of the current block based on the reconstructed sample of the reference block retrieved from the reference sample memory; The search area is updated in units of coding areas. method.

2. The method of claim 1 , wherein each coding region has a square shape.

3. A method for encoding video, performed by an encoder, the method comprising: determining prediction information for a current block of a current coding region, and encoding the prediction information in a coded video bitstream, wherein the prediction information indicates an intra-frame block copy mode, and if a coding tree unit (CTU) to which the current block belongs contains fewer than 128x128 luma samples, a size of the coding region is the same as a size of the CTU; otherwise, the CTU is divided into a plurality of coding regions, and the current coding region is a coding region to which the current block belongs among the plurality of coding regions; determining a block vector pointing to a reference block in the same picture as the current block, the reference block being within a search area that includes a coding area having reconstructed samples buffered in a reference sample memory; reconstructing at least one sample of the current block based on the reconstructed sample of the reference block retrieved from the reference sample memory; and further comprising at least checking whether multiple corners of the reference block are within the same coding region. method.

4. The method of claim 1 , further comprising the step of: if the reference block is partially within the search area, moving the reference block into the search area.

5. The method of claim 4 , further comprising the step of moving the reference block in a direction that decreases the distance between the reference block and the current block.

6. The method of claim 4 , further comprising the step of moving the reference block in a direction that increases the percentage of reference samples in the coding domain.

7. 2. The method of claim 1, further comprising the step of: if the reference block is partially within the search area, using information of a first reference sample within the search area as information of a second reference sample outside the search area.

8. The method of claim 1 , wherein flexible block division is prohibited in dividing the CTU.

9. 1. An apparatus for decoding video, comprising: processing circuitry; The processing circuitry is configured to perform the method according to any one of claims 1 to 8. Device.

10. A computer program product for causing a processor of a decoder to carry out the method according to any one of claims 1 to 8.

11. A method for encoding video, performed by an encoder, the method comprising generating and transmitting an encoded bitstream; the coded video bitstream includes prediction information indicating an intra-frame block copy mode, and if a coding tree unit (CTU) to which a current block belongs includes less than 128x128 luma samples, the size of the coding region is the same as the size of the CTU; otherwise, the CTU is divided into a plurality of coding regions, and the current coding region is a coding region to which the current block belongs among the plurality of coding regions; determining a block vector pointing to a reference block in the same picture as the current block, the reference block being within a search area that includes a coding area having reconstructed samples buffered in a reference sample memory; reconstructing at least one sample of the current block based on the reconstructed sample of the reference block retrieved from the reference sample memory; The search area is updated in units of coding areas. method.

Images