RU2774871C1 - Block decoded vector transformation for internal image bloc compensation - Google Patents

Abstract

FIELD: video coding.

SUBSTANCE: invention relates to the field of video coding. The effect is achieved by receiving a bit stream of encoded video, including the current image. It is determined whether the current block in the current code tree packet contained in the current picture is encoded in the intra block copy mode based on a flag included in the encoded video bitstream. In response to determining that the current block is encoded in IBC copy mode, a block vector is determined pointing to the first reference block for the current block; an operation is performed on said block vector such that when the first reference block is not fully reconstructed or is outside the correct search range for the current block, the block vector is modified to point to a second reference block that is in the fully reconstructed region and within the correct search range for the current block; and the current block is decoded based on the modified block vector.

EFFECT: improving the efficiency of video coding.

11 cl, 15 dwg

Description

Inclusion by reference

[0001] The present disclosure refers to the priority of U.S. Patent Application No. 16/860,975 entitled "Transforming a Decoded Block Vector for Internal Image Block Compensation" and filed April 28, 2020, which refers to the priority of U.S. Provisional Application No. 62/863, entitled "Transforming a Decoded Block Vector for Internal Image Block Compensation" and filed on June 18, 2019, all of which are hereby incorporated by reference in their entirety.

Technical field

[0002] The present invention relates generally to video coding.

Prerequisites for the creation of the invention

[0003] Below, to give an overview of the context of the present invention, a description of the existing prior art. The work done by the authors of this application, as well as aspects of the present invention that cannot be attributed to the prior art at the time of filing of the application, even if they are described in this section devoted to the description of the prior art, can neither be implied nor explicitly attributed to the state of the art, despite being included in this section.

[0004] Video coding and video decoding may be performed using motion-compensated inter-picture prediction. Uncompressed digital video may comprise a sequence of images, each having a given spatial size, such as 1920×1080 luminance samples and corresponding chrominance samples. Such an image sequence may have a fixed or variable image rate (informally also referred to as a frame rate) of, for example, 60 images per second, or 60 Hz. Uncompressed video places high demands on the bit rate. For example, 1080p60 4:2:0 video with 8-bit sample depth (resolution of 1920x1080 luma samples at 60Hz frame rate) requires about 1.5 Gbps of bandwidth. An hour of such video requires more than 600 GB of storage.

[0005] One of the objectives of video coding and video decoding is to reduce redundancy in the input video signal due to compression. Compression can reduce bandwidth or storage requirements to two orders of magnitude or more in some cases. Both lossless and lossy compression, as well as their combinations, can be applied. Lossless compression refers to methods in which an exact copy of the original signal can be restored from a compressed signal. When lossy compression is used, the reconstructed signal may not be identical to the original signal, however, the difference between the original and reconstructed signals is small enough that the reconstructed signal is suitable for the intended application. Lossy compression is widely used for video. The amount of distortion allowed depends on the particular application; for example, users of commercial streaming applications may be more tolerant of distortion than users of broadcast television applications. The compression ratio is subject to the following pattern: the greater the allowable distortion, the greater the achievable compression ratio.

[0006] A number of techniques can be applied in the video encoder and video decoder in various categories, including, for example, motion compensation, transforms, quantization, and entropy coding.

[0007] Among the technologies used in video codecs, there are techniques known as intra-coding. With internal coding, sample values are presented without reference to samples or other data from previously reconstructed reference pictures. In some video codecs, images are spatially divided into blocks of samples. When all blocks of samples are encoded in intra-mode, such a picture may be called an intra-encoded picture. Intra-coded pictures and their derivatives, such as independent decoding update pictures, may be used to restore the initial state of the decoder, and accordingly may be used as the first picture in the encoded video stream and video session, or as a still picture. The samples of the intra-coded block may be transformed, wherein the transform coefficients may be quantized before entropy coding. Intra-prediction is this technique that minimizes sample values in the range before performing the transformation. In some cases, the smaller the values of the DC coefficients after the transformation, and the smaller the AC coefficient, the fewer bits are required, at a given quantization step, to represent the block after entropy coding.

[0008] Conventional intra coding methods proposed in, for example, MPEG-2 generation coding methods do not use intra prediction. However, some newer video compression technologies have techniques that attempt to perform prediction based on, for example, ambient sample data and/or metadata obtained by encoding/decoding spatially contiguous and preceding, in decoding order, data blocks. Such methods will henceforth be referred to as "internal prediction" methods. It should be noted that, in at least some cases, only reference data from the current image currently being reconstructed is used for intra prediction, and not from reference images.

[0009] There are many different types of intra prediction. When more than one of these methods is allowed in a video coding technology, the technology used may have an intra prediction mode. In some cases, modes may have sub-modes and/or parameters that may be encoded separately or included in the mode codeword. Which codeword is used for a given mode/submode/parameter combination can affect the coding performance of intra prediction. The entropy coding method used to convert the code words into a bit stream may also have an impact.

[0010] One of the intra prediction modes was introduced in the H.264 standard, improved in the H.265 standard, and further improved in new coding technologies such as the Joint Exploration Model (JEM), Universal Video Coding (versatile video coding, VVC) and "Set of standards" (benchmark set, BMS). A block prediction may be generated using sample values relating to already available samples. The values of neighboring samples are copied into the prediction block in accordance with the given direction. An indication of which direction to use may be encoded in the bitstream, or may also be predicted.

[0011] Motion compensation is a lossy compression technique relating to techniques in which a block of sample data from a previously reconstructed image, or a portion thereof, after a spatial shift in the direction specified by a motion vector (MV), is used to predict a new restored image or part of it. In some cases, the reference image may be the same as the current predicted image. The motion vectors may have two dimensions, X and Y, or three dimensions, the third of which indicates the applied reference picture (which may be a temporal dimension, indirectly).

[0012] In some video compression technologies, the motion vector applied to a certain area of sample data may be predicted based on other motion vectors, for example, based on vectors related to other areas of sample data, spatially adjacent to the area being reconstructed, and preceding this motion vector in decoding order. This can significantly reduce the amount of data required for motion vector encoding, and thus reduce redundancy and improve compression efficiency. Motion vector prediction can be efficient, for example, because when encoding the input video signal received from the camera (called raw video), there is a statistical probability that areas larger than the areas of applicability of a single motion vector move in the same direction, and therefore can in some cases be predicted using similar motion vectors calculated from the motion vectors of neighboring regions. As a result, the motion vector found for a given area may be similar or identical to the motion vector predicted based on the surrounding motion vectors, and therefore may be represented, after entropy encoding, by fewer bits than needed to directly encode the motion vector. In some cases, motion vector prediction may be an example of lossless compression of a signal (namely, motion vectors) derived from the original signal (namely, a stream of samples). In other cases, motion vector prediction may be lossy, for example, due to rounding errors when calculating a prediction based on multiple surrounding motion vectors.

[0013] Various motion vector prediction mechanisms are described in the H.265/HEVC standard (ITU-T Recommendation H.265 "High Efficiency Video Coding", December 2016). Of the many motion vector prediction mechanisms proposed in the H.265 standard, this document describes a method, hereinafter referred to as "spatial merge" (spatial merge).

[0014] Consider FIG. 1: current block (101), contains samples for which, during the motion search process, the encoder determined that they can be predicted based on the previous block of the same size, but shifted in space. Instead of encoding this motion vector directly, it may be computed based on the metadata associated with one or more reference pictures, e.g., from the immediately preceding (in decoding order) reference picture, using a motion vector related to any of the five samples denoted A0, A1 and B0, B1, B2 (102-106, respectively). In H.265, motion vector prediction can use candidates from the same reference picture that was used for the neighboring block.

The essence of the invention

[0015] In aspects of the present invention, methods and apparatuses for video coding in a decoder are provided. In one embodiment of the present invention, a method for video coding in a decoder is provided. In the proposed method, an encoded video bitstream including the current image is received. It is determined whether the current block in the current coding tree unit (CTU) contained in the current picture is encoded in intra block copy (IBC) mode based on a flag included in the encoded video bitstream. In response to determining that the current block is encoded in IBC copy mode, a block vector is determined pointing to the first reference block for the current block; an operation is performed on said block vector such that when the first reference block is not fully reconstructed or is outside the correct search range for the current block, the block vector is modified to point to a second reference block that is in the fully reconstructed region and within the correct search range for the current block; and the current block is decoded based on the modified block vector.

[0016] In one embodiment of the present invention, said fully reconstructed area and the current block are in the same tile, slice, or group of tiles.

[0017] In one embodiment of the present invention, performing said operation includes performing a modulo operation on the x-component and on the y-component of the block vector based on the size of the current CTU.

[0018] In one embodiment of the present invention, performing said operation includes performing a modulo operation on the x-component of the block vector based on a value that is a multiple of the size of the current CTU. Said operation also includes performing a modulo operation on the y-component of the block vector based on the size of the current CTU.

[0019] In one embodiment of the present invention, performing said operation modifies the block vector only when the first reference block is not completely recovered or is outside the correct search range for the current block.

[0020] In one embodiment of the present invention, performing said operation does not modify the block vector when the first reference block is fully recovered and is within the correct search range for the current block.

[0021] In one embodiment of the present invention, the correct search range for the current block includes the current CTU.

[0022] In one embodiment of the present invention, performing said operation modifies the block such that the offset of the first reference block relative to the CTU including the first reference block is identical to the offset of the second reference block relative to the current CTU.

[0023] In one embodiment of the present invention, performing said operation includes truncating the block vector such that the truncated block vector points to a second reference block that lies on the boundary of the valid search range for the current block when the first reference block is not fully recovered or is not found within the valid search range for the current block.

[0024] In aspects of the present invention, devices configured to perform any of the methods described above are provided.

[0025] Aspects of the present invention also provide computer-readable storage media that store instructions that, when executed by a computer, cause that computer to perform any of the methods described above.

Brief description of the drawings

[0026] Additional features, essence and various advantages of the proposed invention can be understood in more detail with the help of the following detailed description and the attached drawings, where:

[0027] in FIG. 1 shows a sketch illustration of the current block and its surrounding spatial merge candidates in one example;

[0028] FIG. 2 is a schematic diagram of a simplified block diagram of a communication system, in accordance with one embodiment of the present invention;

[0029] FIG. 3 is a schematic diagram of a simplified block diagram of a communication system, in accordance with one embodiment of the present invention;

[0030] FIG. 4 is a sketch of a simplified block diagram of a decoder, in accordance with one embodiment of the present invention;

[0031] FIG. 5 is a sketch of a simplified block diagram of an encoder, in accordance with one embodiment of the present invention;

[0032] in FIG. 6 is a block diagram of an encoder in accordance with one embodiment of the present invention;

[0033] in FIG. 7 is a block diagram of a decoder in accordance with one embodiment of the present invention;

[0034] in FIG. 8 shows an example of intra block copy (IBC) compensation in accordance with one embodiment of the present invention;

[0035] in FIG. 9A-9D show examples of IBC copy compensation in accordance with some of the embodiments of the present invention;

[0036] in FIG. 10 shows an example of spatial fusion candidates in accordance with one embodiment of the present invention;

[0037] in FIG. 11 is a flowchart illustrating a decoding procedure in accordance with one embodiment of the present invention;

[0038] FIG. 12 is a schematic illustration of a computer system in accordance with one embodiment of the present invention.

Detailed description of embodiments of the invention

[0039] I. Encoder and decoder for video coding

[0040] In FIG. 2 illustrates a simplified block diagram of a communications system (200) in accordance with one embodiment of the present invention. The communication system (200) includes a plurality of terminal devices that can communicate with each other, for example, over a network (250). For example, the communication system (200) may include a first pair of terminal devices (210) and (220) connected over a network (250). In the example of FIG. 2, the first pair of terminal devices (210) and (220) performs unidirectional data transmission. For example, the terminal device (210) may encode video data (eg, a video stream captured by the terminal device (210)) for transmission to another terminal device (220) over the network (250). The encoded video data may be transmitted in the form of one or more encoded video bitstreams. The terminal device (220) may receive the encoded video data from the network (250), decode the encoded video data to recover the video images, and display the video images in accordance with the recovered video data. Unidirectional data transmission is widely used in media service applications and similar applications.

[0041] In another example, the communication system (200) may include a second pair of terminal devices (230) and (240) that perform bidirectional transmission of encoded video data. This situation can arise, for example, during video conferencing. In bidirectional data transmission, in one example, each terminal device, (230) and (240), may encode video data (for example, a stream of video images captured by the terminal device) for transmission to another terminal device, (230) or (240), over the network (250). Each of the terminal devices (230) and (240) may also receive the encoded video data transmitted by the other terminal device, (230) or (240), and decode the encoded video data to reconstruct the video images and also play back the video images on an existing display device in accordance with recovered video data.

[0042] In the example of FIG. 2 terminal devices (210), (220), (230) and (240) may be servers, personal computers or smartphones, but without limiting the intent of the present invention. Embodiments of the present invention may be applied to laptop computers, tablet computers, media players and/or dedicated video conferencing equipment. Network (250) may be any number of networks transmitting encoded video data between terminal devices (210), (220), (230) and (240), including, for example, wired and/or wireless communication networks. The communication network (250) may provide communication over circuit-switched and/or packet-switched links. Examples of such networks may be telecommunications networks, local area networks, wide area networks and/or the Internet. In the present description, the architecture and topology of the network (250) do not play any role in the operation of the proposed invention, unless explicitly indicated.

[0043] FIG. 3 illustrates, as an example of the application of the present invention, the placement of a video encoder and decoder in a streaming environment. The proposed invention can be applied with equal efficiency in other areas where video is used, including, for example, videoconferencing, digital television, storage of compressed video on digital media, including CDs, DVDs, memory cards, and the like.

[0044] The streaming system may include a capture subsystem (313), which may include a video source (301), such as a video camera, that generates an uncompressed video stream (302). In one example, the video stream (302) may include samples captured by a digital camera. The video stream (302), shown in bold to emphasize the high amount of data compared to the encoded video data (304) (encoded video bitstreams), may be processed by an electronic device (320) that includes a video encoder (303) associated with the source (301 ) video. The video encoder (303) may include hardware, software, or a combination of both that enable aspects of the present invention to be implemented, as described in more detail below. The encoded video data (304) (or encoded video bitstream (304)), shown with a thin line to emphasize the smaller amount of data compared to the video stream (302), may be stored on the streaming server (305) for future use. One or more streaming client subsystems, such as client subsystem (306) and (308) in FIG. 3 may access the stream server (305) to obtain copies (307) and (309) of the encoded video data (304). The client subsystem (306) may include a video decoder (310), such as in an electronic device (330). The video decoder (310) decodes the received copy (307) of the encoded video data and generates an output video stream (311) that can be drawn on a display (312) (for example, a display screen) or on another display device (not shown). In some streaming systems, encoded video data (304), (307), and (309) (eg, bitstreams) may be encoded according to predetermined video coding/video compression standards. Examples of such standards include, without limitation, Recommendation H.265. ITU-T. In one example, a video coding standard currently under development informally referred to as Universal Video Coding (VVC) may be used. The invention described herein can be applied in the context of the VVC standard.

[0045] It should be noted that the electronic devices (320) and (330) may include other components (not shown in the drawing). For example, the electronic device (320) may also include a video decoder (not shown), and the electronic device (330) may also include a video encoder (not shown).

[0046] FIG. 4 shows a block diagram of a video decoder (410) in accordance with one embodiment of the present invention. The video decoder (410) may be included in the electronic device (430). The electronic device (430) may include a receiver (431) (eg, receiver circuits). Video decoder (410) may be used instead of video decoder (310) shown in the example of FIG. 3.

[0047] The receiver (431) may receive one or more encoded video sequences for decoding by the decoder (410). In the same or alternative embodiment of the present invention, the video sequences may be received in turn, with the decoding of each of the encoded video sequences independent of the decoding of the remaining video sequences. The encoded video sequence may be received from a channel (401), which may be a hardware and/or software link to a storage device where the encoded video data is stored. The receiver (431) may receive encoded video data along with other data, such as encoded audio data and/or auxiliary data streams, which may be redirected to the respective elements using them (not shown). The receiver (431) may separate the encoded video sequence from the rest of the data. To combat network "jitter" (jitter) between the receiver (431) and entropy decoder/analyzer (420) (hereinafter, "analyzer") can be installed buffer memory (415). In some practical applications, the buffer memory (410) may be part of the video decoder (410). In other cases, it may be located outside the video decoder (410) (not shown in the drawing). In other cases, there may be a buffer memory outside the video decoder (410) (not shown in the drawing), for example, to combat network jitter, and, additionally, another buffer memory (415) inside the video decoder (410), for example, to comply with timing playback. When the receiver (431) receives data from a storage or transmission device with sufficient bandwidth and controllability, or from a network with isosynchronous transmission, the buffer (415) may be unnecessary or small. In the case of non-guaranteed packet networks such as the Internet, the buffer 315 is necessary, can be relatively large and yet have an adaptive size, while at least partly it can be implemented in the operating system or in similar elements (not shown in the figure ) outside the video decoder (410).

[0048] The video decoder (410) may include an analyzer (420) for recovering symbols (421) from the entropy coded video sequence. Various types of these symbols may include information used to control the operation of the video decoder (410) as well as potentially information to control a display device, such as a display device (412) (e.g., a display screen) that is not an integral part of the electronic device. (430), but may be associated with it, in accordance with the illustration of FIG. 3. Control information for display devices may, for example, be in the form of Supplementary Enhancement Information (SEI) messages or Video Usability Information (VUI) parameter set fragments (not shown). The analyzer (420) may perform analysis/entropy decoding of the received encoded video sequence. The encoded video sequence may be encoded in accordance with some video coding technology or standard, and may variously follow principles well known to those skilled in the art, including variable length coding, Huffman coding, context-dependent or context-independent arithmetic coding, and the like. .P. The analyzer (420) can extract from the encoded video sequence a set of subgroup parameters for at least one subgroup of pixels in the video decoder based on at least one parameter corresponding to the group. Subgroups may include groups of pictures (Groups of Pictures, GOP), images, tiles, slices, macroblocks, code packages (Coding Units, CU), blocks of samples (blocks), transformation packages (Transform Units, TU), prediction packages (Prediction Units , PU), etc. The analyzer (420) may also extract information such as transform coefficients, quantizer parameter values, motion vectors, and the like from the encoded video sequence.

[0049] The analyzer (420) may perform entropy decoding/analysis operations on the video sequence received from the buffer memory (415) and generate symbols (421).

[0050] Symbol recovery (421) may involve different device blocks depending on the type of encoded video images or parts thereof (e.g., internally and externally predicted images, internally and externally predicted sample blocks), as well as other factors. \Which blocks of the device will be used, and how, can be determined by the control information of the subgroup extracted from the encoded video sequence by the analyzer (420). For simplicity, the flow of such subgroup control information between the analyzer (420) and the plurality of device blocks described below is not shown in the drawing.

[0051] In addition to the functional blocks already mentioned, the video decoder (410) can be conceptually subdivided into a set of functional blocks, described below. In commercial implementations, many of these blocks interact closely with each other and can be at least partially mutually integrated. However, for purposes of describing the present invention, the division into functional blocks described below is suitable.

[0052] The first of these blocks may be a scaling/inverse transform block (451). The scaling/inverse transform block (451) receives quantized transform coefficients as well as control information, including information about which transform should be used, block size, quantization factor, quantization scaling matrices, etc., in the form of symbols (421) from analyzer (420). Block (451) scaling/inverse transformation may produce blocks of samples, including sample values that can be entered into the aggregator (455).

[0053] In some cases, the samples at the output of the block (451) scaling / inverse transformation may refer to an intra-coded block of samples, that is: a block of samples for which do not use prediction information from previously restored images, but can use information from previously restored parts of the current image. Such prediction information may be provided by the intra picture prediction block 452 . In some cases, the block (452) intra image prediction generates a block of the same size and shape as the restored block, using already restored information about its environment, obtained from the current (partially restored) image in the buffer (458) current images. In the buffer (458) current images are placed, for example, a partially restored current image and/or a fully restored current image. The aggregator (455) may in some cases add the prediction information generated by the intra prediction block (452) to the sample output provided by the scaling/inverse transform block 451 individually for each sample.

[0054] In other cases, the samples at the output of the scaler/inverse transform block (451) may refer to inter-prediction, and potentially, a motion-compensated block of samples. In such cases, the motion compensation prediction block (453) may access the reference picture memory (457) and obtain samples used for prediction. After motion compensation, the received samples, in accordance with the symbols (421) related to this block of samples, can be added by the aggregator (455) to the output data of the block (451) scaling / inverse transformation (in this case they are called difference samples or difference signal) , as a result of which the output information of the samples is formed. Reference picture memory addresses (457) from which the motion compensation prediction block (453) obtains predicted samples may be determined by the motion vectors available to the motion compensation prediction block (453) in the form of symbols, which may have, for example, X- component, Y-component, and reference image component. The motion compensation may also include interpolation of sample values obtained from the reference picture memory (457) when motion vectors, motion vector prediction mechanisms, and the like having sub-pixel accuracy are applied.

[0055] The output samples from the aggregator (455) may be processed using various loop filtering techniques in the loop filter block (456). Video compression technologies may include in-loop filtering technologies that are controlled by parameters contained in the encoded video sequence (also referred to as the encoded video bitstream) and provided to the loop filtering block (456) as symbols (421) from the parser (420). They may also depend on the meta-information obtained during the decoding of the previous (in the order of decoding) parts of the encoded image or encoded video sequence, as well as on previously restored and loop-filtered sample values.

[0056] The output of the loop filtering block (456) may be a sample stream that is fed to the display (412) and also stored in the reference picture memory (457) for use in future inter-picture prediction.

[0057] Individual encoded pictures, after they are completely restored, can be used as reference for future prediction. For example, after the complete restoration of the encoded picture corresponding to the current picture, if it was determined as a reference (for example, by the analyzer (420)), the current reference picture stored in the current picture buffer (458) can be placed in the reference picture memory (457). , and a new buffer of current pictures may be allocated before starting the next encoded picture recovery.

[0058] Video decoder 410 may perform decoding operations in accordance with a predetermined video compression technology that may be documented in a standard, such as ITU-T H.265 recommendation. The encoded video sequence may conform to the syntax given by the applicable video compression technology or standard in the sense that it conforms to the syntax given in the document or standard of the video compression technology, and in particular to the syntax of the specified profiles of the standard. In particular, a profile allows you to select a part of the tools from all the tools available in the video compression technology or standard as available for use in this profile. However, in order to comply with some of the video compression technologies or standards, the complexity of the encoded video sequence must be within the limits determined by the level of video compression technology or standard. In some cases, the levels of the standard limit the maximum image size, the maximum frame rate, the maximum sampling rate (measured in Ms/s, for example), the maximum reference image size, and the like. The restrictions imposed by the layers can in some cases be further limited by the specifications of the Hypothetical Reference Decoder (HRD) and metadata for managing the buffer of the HRD decoder signaled in the encoded video sequence.

[0059] In one of the embodiments of the present invention, the receiver (431) can receive additional (redundant) data along with the encoded video. This additional data may be an integral part of the encoded video sequence (or video sequences). The additional data may be used by the video decoder (410) to correctly decode the data and/or to recover the original video data more accurately. The additional data may take the form of, for example, refinement temporal, spatial or signal-to-noise ratio (SNR) refinement levels, redundant slices, redundant images, forward error correction codes, and the like.

[0060] FIG. 5 shows a block diagram of a video encoder (503) in accordance with one embodiment of the present invention. The video encoder (503) is included in the electronic device (520). The electronic device (520) includes a transmitter (540) (eg, transmission circuits). A video encoder (503) may be used in place of the video encoder (303) shown in the example of FIG. 3.

[0061] The video encoder (503) may receive video samples from a video source (501) (which is not part of the electronic device (520) in the example of FIG. 5) capturing video for encoding by the video encoder (503). In another example, the video source (501) may be part of an electronic device (520).

[0062] The video source (501) can supply the original video sequence for encoding by the video encoder (503) in the form of a digital stream of video samples having any suitable bit depth (for example: 8 bits, 10 bits, 12 bits, ...), any color space (for example, BT.601 Y CrCB, RGB, …) and any suitable reporting structure (eg Y CrCb 4:2:0, Y CrCb 4:4:4). In the media service system, the video source (501) may be a storage device that stores pre-prepared video. In a videoconferencing system, the video source (501) may be a video camera that captures image information locally in the form of a video sequence. The video data may be in the form of multiple individual images that convey a sense of movement when viewed sequentially. The images themselves may be organized as a spatial array of pixels, where each pixel may include one or more samples, depending on the sample structure used, color space, and the like. Those skilled in the art should recognize the relationship between pixels and samples. Further in the present description will be considered readings.

[0063] In accordance with one embodiment of the present invention, the video encoder (503) may encode and compress images of the source video sequence into the encoded video sequence (543) in real time, or in accordance with other time constraints imposed by practical application. One of the functions of the controller (550) may be to provide a suitable code rate. In some of the embodiments of the present invention, the controller (550) controls other functional blocks, described below, and is operatively associated with these blocks. This relationship is not shown in the drawing for simplicity. The parameters set by the controller (550) may include parameters related to speed control (skipping pictures, quantizer, λ value for rate-distortion optimization methods, ...), picture size, GOP arrangement, maximum motion vector search range, and etc. The controller (550) may be configured to have other suitable functions related to the video encoder (503) optimized for a particular system design.

[0064] In some embodiments of the present invention, the video encoder (503) may be configured to operate in a coding loop. Extremely simplified, in one example, the coding loop may include a source encoder (530) (for example, which is responsible for generating symbols, i.e., a symbol stream, based on the input picture being encoded, and reference pictures), and a (local) decoder (533 ) built into the video encoder (503). The decoder (533) decompresses the symbols to generate sample data identical to that which a (remote) decoder would also generate (because the compression of the symbols in the encoded bitstream in the compression techniques of the present invention is lossless). This reconstructed sample stream (sample data) may be input to the reference picture memory 534 . Since the decoding of the symbol stream results in the same bit-accurate results regardless of the decoder (local or remote), the contents of the reference picture memory (534) are also the same bit-accurate in the local encoder and the remote encoder. In other words, the prediction subsystem in the encoder "sees" as reference picture samples exactly the same sample values that the decoder "sees" using prediction in decoding. This fundamental principle of reference picture synchronism (and the resulting drift if synchronism cannot be achieved due to, for example, channel errors) is used in some prior art solutions.

[0065] The operation of a "local" decoder (533) is similar to a "remote" decoder, such as a video decoder (410), which has already been described in detail above in connection with FIG. 4. However, returning to FIG. 4, since the symbols are available, and the entropy encoder (545) and parser (420) can be losslessly encoded/decoded into the encoded video sequence, the entropy decoding subsystems from the decoder (410) may not be fully implemented in the local decoder (533). ), including buffer memory (415) and analyzer (420).

[0066] It can be seen here that any decoding technology other than analysis/entropy decoding available in a decoder must be present in a substantially identical functional form in a corresponding encoder. For this reason, the description of the present invention is focused on the operation of the decoder. A description of the encoding techniques may be omitted as they may be the reverse of the decoding techniques described in detail. Only in some places a more detailed description is needed, and it will be given below.

[0067] In performing its operations, in some of the examples, the source encoder (530) may perform motion compensation-based predictive encoding, wherein an input image is predictively encoded based on one or more previously encoded pictures of the video sequence that have been labeled " base frames. Thus, the coding subsystem (532) encodes the differences between blocks of pixels in the input image and blocks of pixels in the reference image (or images) that can be chosen as reference for predicting the input image.

[0068] The local video decoder (533) may decode encoded video data of images marked as reference, depending on the symbols generated by the source encoder (530). The operations of the encoding subsystem (532) are preferably lossy data processing. When the encoded video data is decoded in a video decoder (not shown in FIG. 5), the reconstructed video sequence is typically a replica of the original video sequence with some errors. The local video decoder (533) exactly reproduces the decoding process that could be performed by a remote video decoder on the reference pictures and places the recovered reference pictures in the reference picture cache (534). Thus, the video encoder (503) may locally store copies of the reconstructed reference pictures having the same content as the reconstructed reference pictures received by the remote video decoder (in the absence of transmission errors).

[0069] The predictor (535) may search for predictions for the coding subsystem (532). That is, for a new encoded picture, the predictor (535) may search the reference picture memory (534) to find sample data (as candidate pixel reference blocks) or metadata such as reference picture motion vectors, block shapes, etc. which can serve as reference for new images. The predictor (535) may find suitable reference data for each individual block of pixels. In some cases, depending on the search results obtained by the predictor (535), the reference data for predicting the input image may be extracted from multiple reference pictures stored in the reference picture memory (534).

[0070] The controller (550) can control the encoding operations in the source encoder (530), including, for example, setting parameters and subgroup parameters used to encode video data.

[0071] The output of all of the functional blocks described above may be entropy encoded in an entropy encoder (545). The entropy encoder (545) converts the symbols generated by the various functional blocks into an encoded video sequence by compressing these symbols, without loss, in accordance with techniques known to those skilled in the art, for example, Hoffman coding, variable length coding, arithmetic coding, etc.

[0072] The transmitter (540) may buffer the encoded video sequence (or video sequences) generated by the entropy encoder (545) to prepare it for transmission over a communication channel (560), which may be a hardware and/or software link to a storage device. where the encoded video data is stored. The transmitter (540) may combine the encoded video data from the video encoder (503) with other transmitted data, such as encoded audio and/or ancillary data streams (their sources are not shown).

[0073] The controller (550) may control the operation of the video encoder (503). When encoding, the controller (550) may assign to each encoded picture some type of encoded picture, which may affect the encoding methods applied to it. For example, images can be assigned one of the following types:

[0074] An intra predictive picture (1-picture) may be an image that is encoded and decoded without using any other pictures of the video sequence as a source for prediction. Some video codecs support various types of intrinsically predictable images, such as Independent Decoder Refresh (IDR) images. Those skilled in the art should be aware of such 1-picture variations, as well as their properties and applicability.

[0075] A predictive picture (P-picture) is a picture that can be encoded and decoded using intra or inter prediction using a maximum of one motion vector and a reference picture pointer to predict sample values of each block.

[0076] A bi-directionally predictive picture (B-picture) is a picture that can be encoded and decoded using intra or inter prediction using a maximum of two motion vectors and reference picture pointers to predict the sample values of each block. Likewise, in the case of multi-predicted pictures, more than two reference pictures and associated metadata can be used to reconstruct one block.

[0077] Source images are typically spatially partitioned into a plurality of sample blocks (eg, 4×4, 8×8, 4×8, or 16×16 sample blocks each) and encoded block by block. Blocks of samples may be predictively encoded based on other (already encoded) blocks, depending on the coding types assigned to the images corresponding to these blocks. For example, blocks of samples in I-pictures may be encoded without prediction or predicted based on already coded blocks of the same picture ("spatial prediction" or "intra prediction"). Blocks of pixels in P-pictures may be encoded without prediction, with spatial prediction, or with temporal prediction based on a single previously encoded reference picture. Blocks of pixels in B-pictures may be encoded without prediction, with spatial prediction, or with temporal prediction based on one or two previously encoded reference pictures.

[0078] The video encoder (503) may perform encoding operations in accordance with a predetermined video coding technology or standard, which may be documented in a standard, such as ITU-T.H.265 H.265 recommendation. In operation, the video encoder (503) may perform various compression operations, including predictive coding operations that exploit temporal and spatial redundancy in the input video sequence. The encoded video data may suitably follow the syntax given by the applied video coding technology or standard.

[0079] In one of the embodiments of the present invention, the transmitter (540) may, in conjunction with the encoded video, transmit additional data. The source encoder (530), for example, may provide data such as a fragment of an encoded video sequence. The additional data may include data on refinement temporal, spatial or SNR levels, redundant images or slices, SEI messages or fragments of VUI parameter sets, and the like.

[0080] The video may be captured as a plurality of source images (video images) in time sequence. Intra-image prediction (often abbreviated as "internal prediction") is possible due to the presence of spatial correlations in images, and external image prediction is possible due to correlation (temporal or otherwise) between different images. In one example, the encoded or decoded image, which is called the current image, is divided into blocks of samples. When a block in the current picture is similar to a reference block of samples in a previously encoded and still buffered reference picture of the same video, that block of the current picture may be encoded with a vector called a motion vector. The motion vector points to a reference block in the reference picture, and also, if multiple reference pictures are used, has a third dimension identifying the reference picture.

[0081] In some embodiments, a bidirectional prediction technique may be used for inter-prediction of images. The bidirectional prediction method uses two reference pictures, namely a first reference picture and a second reference picture, both of which precede the current picture in the video in decoding order (however, they may be preceding and following, respectively, in display order). A block in the current picture may be encoded with 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. The block may be predicted by a combination of the first reference block and the second reference block.

[0082] Also, in order to improve coding efficiency, a merge mode technique can be applied in inter-picture prediction.

[0083] In accordance with some of the embodiments of the present invention, the elementary unit for prediction, that is, inter- and intra-picture prediction, are blocks of samples. For example, according to the standard HEVC, an image in a video sequence is split into Code Tree Packets (CTUs) for compression, with all CTU packets in the image having the same size, namely 64x64 pixels, 32x32 pixels, or 16x16 pixels. In general, a CTU contains three coding tree blocks (CTBs): one luma CTB and two chrominance CTBs. Each CTU may be recursively split, in the form of a quadtree, into one or more coding units (CUs). For example, a 64x64 pixel CTU can be split into one 64x64 pixel coding packet, CU, four 32x32 pixel CU packets, or 16 16x16 pixel CU packets. In one example, each CU burst is analyzed to determine the type of prediction for that burst, i.e., inter prediction or intra prediction. The CU packet is split into one or more prediction units (PUs), depending on the temporal and/or spatial prediction capability. In general, each PU packet contains a luma prediction block (PB) and two chrominance PBs. In one of the embodiments of the present invention, the elementary unit for the prediction operation when encoding (encoding/decoding) is a prediction block. Using the luminance prediction block as an example: The prediction block contains a matrix of values (eg, luminance values) of pixels, for example, 8×8 pixels, 16×16 pixels, 8×16 pixels, 16×8 pixels, and the like.

[0084] FIG. 6 shows a block diagram of a video encoder (603) in accordance with yet another embodiment of the present invention. The video encoder (603) is configured to receive a block to be processed (eg, a prediction block) of sample values within the current video image from the video sequence and to encode the block to be processed into an encoded image that is part of the encoded video sequence. In one example, a video encoder (603) may be used in place of the video encoder (303) shown in the example of FIG. 3.

[0085] In the case of the HEVC standard, the video encoder (603) receives, as a processing block, a matrix of sample values, for example, an 8x8 prediction block. The video encoder (603) determines whether the block being processed can be most efficiently encoded using intra prediction, inter prediction, or bidirectional prediction by, for example, bit rate-distortion optimization. If the block to be processed will be encoded in intra prediction mode, the video encoder (603) may use an intra prediction technique to encode the block to be processed into an encoded picture; and when the block to be processed is encoded in inter-prediction or bi-prediction mode, the video encoder (603) may use an inter-prediction or bi-prediction method to encode the block to be processed, respectively. In some video coding technologies, the merge mode may be an inter-picture prediction sub-mode in which a motion vector is computed from one or more motion vector predictions without involving an encoded motion vector component outside of the predictions. In some other video coding technologies, the motion vector component applicable to the block being processed may be present. In one example, the video encoder (603) may include other components, such as a mode determination module (not shown) to determine the mode to be applied to the blocks being processed.

[0086] In the example of FIG. 6, the video encoder (603) includes an inter prediction encoder (630), an intra prediction encoder (622), a residual calculator (623), a switch (626), a residual encoder (624), a main controller (621), and an entropy encoder connected together. in accordance with the illustration of FIG. 6.

[0087] The inter prediction encoder (630) is configured to receive samples of the current block (eg, block being processed), to compare this block with one or more reference blocks in the reference pictures (eg, blocks in previous and subsequent pictures), to generate information inter prediction (eg, description of redundant information according to the inter prediction method, motion vectors, merge mode information) and to calculate inter prediction results (eg, predicted block) based on the inter prediction information using any suitable method. In some examples, the reference pictures are reference pictures decoded based on encoded video information.

[0088] The intra prediction encoder (622) is configured to receive samples of the current block (e.g., the block being processed), in some cases, to compare this block with already encoded blocks in the same picture, to generate quantized coefficients after the transform, and in some cases cases, also intra prediction information (eg, intra prediction direction information according to one or more intra prediction methods). In one example, the intra prediction encoder (622) also calculates intra prediction results (eg, a predicted block) based on intra prediction information and reference blocks of samples in the same picture.

[0089] The main controller (621) is configured to determine the general control data and to control the remaining components of the video encoder (603) based on the general control data. In one example, the main controller (621) may determine the mode for the block and provide a control signal to the switch (626) depending on the mode. For example, when an intra prediction mode is needed, the main controller (621) controls a switch (626) to cause the residual calculator (623) to use the result of the intra prediction mode, and also controls the entropy encoder (625) to select the intra prediction information and include this information in the bitmap. flow; and when the inter prediction mode is needed, the main controller (621) controls the switch (626) to ensure that the result of the inter prediction mode is used by the residual calculator (623), and also controls the entropy encoder (625) to select the inter prediction information and include this information in the bit stream .

[0090] The residual calculator (623) is configured to calculate the difference (residual data) between the received block of samples and the prediction results selected from the intra predictive encoder (622) or the inter predictive encoder (630). The residual encoder (624) is configured to operate on the residual data and encode the residual data to generate transform coefficients. In one example, the residual encoder (624) to generate transform coefficients may be configured to convert residual data from spatial to frequency. The transform coefficients are then quantized and the quantized transform coefficients are obtained. In various embodiments of the present invention, the video encoder (603) also includes a residual decoder (628). The residual decoder (628) is configured to perform inverse transformation and generate decoded residual data. The decoded residual data is appropriately used in the intra predictive encoder (622) and the inter predictive encoder (630). For example, inter predictive encoder (630) may generate decoded sample blocks based on decoded residual data and inter prediction information, and intra predictive encoder (622) may generate decoded sample blocks based on decoded residual data and intra prediction information. The decoded blocks of samples are processed appropriately and generate decoded images, which, in some examples, can be buffered in memory circuits (not shown in the figure) and used as reference images.

[0091] The entropy encoder (625) is configured to format the bitstream to include a coded block. The entropy encoder (625) is configured to include [in the bitstream] various information in accordance with the standard used, for example, the HEVC standard. In one example, the entropy encoder (625) may be configured to include, in the bitstream, general control data, selected prediction information (eg, intra prediction or inter prediction information), residual information, and other suitable information. It should be noted that, according to the present invention, when encoding a block in the merge submode, both in the intra prediction mode and in the inter prediction mode, there is no residual information.

[0092] FIG. 7 shows a block diagram of a video decoder (710) in accordance with yet another embodiment of the present invention. The video decoder (710) is configured to receive encoded pictures that are part of the encoded video sequence and decode the encoded pictures to generate reconstructed pictures. In one example, video decoder (710) may be used in place of video decoder (310) shown in the example of FIG. 3.

[0093] In the example of FIG. 7, the video decoder (710) includes an entropy decoder (771), an inter-prediction decoder (780), a residual decoder (773), a reconstruction unit (774), and an intra-prediction decoder (772), combined in accordance with the illustration of FIG. 7.

[0094] The entropy decoder (771) may be configured to recover, based on the encoded image, the characters that represent the syntax elements that make up the encoded image. These symbols may include, for example: the mode in which the block is encoded (e.g., intra prediction mode, inter prediction mode, bidirectional prediction mode, the latter two being in a merge submode or another submode), prediction information (e.g., intra prediction information, or inter-prediction) that may indicate a piece of metadata used for prediction by the intra-prediction decoder (772) or inter-prediction decoder (780), respectively, residual information, e.g., in the form of quantized transform coefficients, and the like. In one example, when the mode is inter prediction or bidirectional prediction mode, inter prediction information is provided to the inter prediction decoder (780); and when the intra prediction type is used, the intra prediction information is provided to the intra prediction decoder (772). The residual information may be inversely quantized and passed to the residual decoder (773).

[0095] The inter prediction decoder (780) is configured to receive inter prediction information and generate inter prediction results based on it.

[0096] The intra prediction decoder (772) is configured to receive intra prediction information and generate inter prediction results based on it.

[0097] The residual decoder (773) is configured to perform inverse quantization to obtain the dequantized transform coefficients, as well as to process the dequantized transform coefficients to convert the residual from frequency values to spatial values. The residual decoder (773) may also need certain control information, including the Quantizer Parameter (QP), which may be provided by the entropy decoder (771) (this data path is not shown in the drawing, since such control information has only a small amount ).

[0098] The reconstruction module (774) is configured to combine, in spatial terms, the residual outputted by the residual decoder (773) and the prediction results (provided by the inter prediction modules or intra prediction modules, as the case may be), to form a reconstructed block that may be part of the restored image, and the restored image, in turn, may be part of the restored video. It should be noted that other appropriate operations such as a deblocking operation and the like may be performed to improve the quality of the video.

[0099] It should be noted that video encoders (303), (503) and (603), as well as video decoders (310), (410) and (710) can be implemented using any suitable technology. In one of the embodiments of the present invention, video encoders (303), (503) and (603), as well as video decoders (310), (410) and (710) can be implemented using one or more integrated circuits. In another embodiment of the present invention, video encoders 303, 503, and 503, as well as video decoders 310, 410, and 710, may be implemented using one or more processors executing program instructions.

[0100] II. Internal block copying

[0101] The block may be encoded using a reference block from the same picture or from another picture. Block compensation using reference blocks from other images may be referred to as motion compensation. Block compensation using reference blocks from previously reconstructed regions of the same image may be referred to as internal block compensation, current picture referencing (CPR), or intra block copying (IBC). The offset vector that represents the offset between the current sample block and the reference block is called the block vector (BV or bvL). Unlike the motion vectors in motion compensation, which can be of any value (positive or negative, in both the x and y directions), the BV block vectors are constrained to ensure that the reference block has already been restored and its restored samples available. In some of the embodiments of the present invention, in view of the restrictions imposed on the possibility of parallel processing, exclude reference areas outside the given boundaries (for example, tile boundaries or stepped wave boundaries).

[0102] The encoding of the block vector, BV, may be explicit or implicit. In explicit mode, the difference between a block vector and its prediction can be signaled similarly to the advanced motion vector prediction (AMVP) mode of outer coding. In the implicit mode, the block vector may be reconstructed based on the prediction only, for example, similar to the motion vectors in the merge mode. The resolution of block vectors, in some implementations, is chosen to be integer positions, or, in some examples, fractional positions.

[0103] The use of block level IBC copying may be signaled using a block level flag (or IBC flag). In some examples, this flag may be set when the current block is not being encoded in merge mode. In other examples, this flag may be set using a pointer to the reference data, such as by considering the current picture being decoded as a reference. Such a reference image may be placed at the last position in the list (for example) in the screen content coding (SCC) extension of the HEVC standard. Such a special reference picture may be held together with other temporary reference pictures in a decoded picture buffer (DPB).

[0104] In the present invention, one of the embodiments of IBC copying is used as an example, however, embodiments of the present invention can be applied to other variations of IBC copying. Variations on IBC copying may include, for example, treating IBC copying as a third mode different from intra prediction or inter prediction modes. Accordingly, the block vector prediction in the merge mode and the AMVP mode can be separated from the normal inter prediction mode. For example, for the IBC copy mode, a separate merge candidate list can be defined/formed, all entries in which are block vectors. Similarly, the block vector prediction list in the AMVP IBC mode can only consist of block vectors. The calculation procedure for candidates in the block vector prediction list may follow the same logic as in the external merge candidate list or the AMVP prediction list. For example, in HEVC or VVC external merge mode, 5 adjacent spatial locations are considered to calculate their own merge candidate list for IBC copy.

[0105] FIG. 8 is a sketch illustration of the current block (810) of samples in the current picture (800) that is encoded using IBC-based compensation, in accordance with one embodiment of the present invention. In FIG. 8 shows one example of the use of IBC-based compensation, in which the current image (800) includes 15 blocks of samples organized in 3 terms and 5 columns. In some examples, each block corresponds to a CTUy. The current sample block (810) includes a subblock (812) (eg, a coding block in a CTU) that has a block vector (822) pointing to a reference subblock (832) in the current picture (800).

[0106] Reconstructed samples of the current image may be stored in memory or in a block of memory (eg, dedicated or dedicated memory, or memory chunk). To reduce the complexity of the implementation, the reference area in which the recovered samples for reference blocks can be located can be smaller than the entire frame, depending on the amount of allocated memory. Therefore, for the current sub-block to which IBC-based compensation is applied, in some examples, the reference IBC sub-blocks may be limited to only specified neighboring regions and not include the entire image.

[0107] In one example, the amount of memory may be limited to one CTU, which means that the IBC copy mode can only be applied when the reference block is in the same CTU as the current block. In another example, the amount of memory can be limited to two CTUs, which means that the IBC copy mode can only be used when the reference block is either in the current CTU or in a CTU located to the left of the current one. When the reference block is outside the limited reference area (ie, allocated local area), even if restored, such reference samples cannot be used for IBC copy based compensation. Accordingly, the decoder must check whether the reconstructed or found block vector points to a reference block in the bounded reference region (ie, the correct search region). Aspects of the present invention include methods that remove some of these restrictions, allowing a decoder to modify and use a block vector even when the block vector points to a reference block outside the restricted reference region.

[0108] In one of the embodiments of the present invention, the requirements of efficient use of memory dictate the need to store reference samples used in IBC copying in a volume of one CTU. In one example, the CTU size may be 128x128 samples. The current CTU includes the current area currently being restored. The current area has a size of 64x64 samples. Since the reference memory can also store restored values from the current area, the reference memory, when its size is one CTUy of size 128x128 samples, can contain 3 additional areas of 64x64 samples. Accordingly, the search range may include separate portions of a previously recovered CTU, while the memory requirements for storing reference samples remain unchanged (for example, a total of 1 CTU of 128x128 samples, or 4 times 64x64 reference samples).

[0109] In one example, when the search range is limited in IBC copying, the block vector for the current block may be limited to the boundary of the current CTB, the boundary of the left neighboring CTB, or the like, depending on the position of the current block and the amount of memory.

[0110] In FIG. 9A-9D show examples of IBC copy compensation in accordance with some of the embodiments of the present invention. In accordance with the illustration of FIG. 9A-9D, the current picture (901) includes the current CTU being restored (915) and the previously restored CTU (910) adjacent to the left of the current CTU (915). The CTU packets in the current picture (901) have a CTU size and a CTU width. The current CTU (915) includes 4 areas (916)-(919). Similarly, the previously recovered CTU (910) includes 4 areas (911)-(914). In one embodiment of the present invention, the size of the CTU may be equal to the size of the reference memory. For example, the size of the CTU and the size of the reference memory can be 128×128 samples, while each of the areas (911)-(914) and (916)-(919) will have a size of 64×64 samples.

[0111] Referring to the illustration of FIG. 9A, the current area (916) is in the process of being restored. The current area (916) includes the currently restored block. In accordance with some of the embodiments of the present invention, the search range for the current block does not include the area (911) located at the same position as the current area (916), and includes areas (912)-(914) of the previously restored CTU (910 ).

[0112] Referring to the illustration of FIG. 9 In the process of reconstruction is the current area (917). The current area (917) includes the currently restored block. In the previously restored CTU (910), the position of the current area (917) is occupied by the (so-called "co-located") area (912). The search range for the current block does not include the co-located area (912). The search range includes areas (913) and (914) of the previously restored CTU(910) as well as area (916) in the current CTU (915). The search range also does not include the area (911) due to limitations on the size of the reference memory (ie, the size of one CTU).

[0113] In accordance with illustration 9C, the current area (918) is in the process of reconstruction. The current area (918) includes the currently restored block. In the previously restored CTU (910), the co-located for the current area (918) is the area (913). The search range for the current block does not include the co-located area (913). The search range includes the region (914) of the previously recovered CTU (910), as well as regions (916) and (917) in the current CTU (915). The search range also does not include areas (911) and (912) due to restrictions on the amount of reference memory.

[0114] Referring to the illustration of FIG. 9D, the current area (919) is under reconstruction. The current area (919) includes the currently restored block. In the previously recovered CTU (910), the co-located for the current area (919) is the area (914). The search range for the current block does not include the co-located area (914). The search range includes areas (916)-(918) in the current CTU (915). The search range does not include areas (911)-(913) due to limitations on the size of the reference memory, and therefore, the search range does not include the previously restored CTU (910) at all.

[0115] Various restrictions may be imposed on block vectors and/or search ranges. In one embodiment of the present invention, the search range for the current recoverable block in the current CTU is limited to the current CTU packet.

[0116] In one embodiment of the present invention, the current image is a luma image and the current CTU packet is a luminance CTU including a plurality of luma samples and a block vector (mvL having 1/16 pixel resolution). In some of the embodiments of the present invention, the luminance motion vector mvL, for the sake of bitstream compatibility, is subject to the constraints A1, A2, B1, C1, and C2 described below.

[0117] In some of the embodiments of the present invention, the first constraint (A1) and the second constraint (A2) require that the reference block for the current block has already been restored. For example, when the reference block is rectangular, an accessibility check procedure may be performed to see if the top left and bottom right references of the reference block have been recovered. If both the top left and bottom right readings of the reference block are restored, it is concluded that the reference block has been restored.

[0118] For the first constraint (A1), in accordance with some of the embodiments of the present invention, when the reference block availability determination procedure is called, with the position (xCurr, yCurr) of the upper left count of the current block set to (xCb, yCb), and position (xCb + (mvL[0] >> 4), yCb + (mvL[1] >> 4)) of the upper left sample of the reference block as input, the output will be TRUE if the upper left the reference frame count is restored, where the motion vector mvL is a two-dimensional vector having an x-component mvL[0] and a y-component mvL[1].

[0119] For the second constraint (A2), in accordance with some of the embodiments of the present invention, when the reference block availability determination procedure is called, with the position (xCurr, yCurr) of the upper left count of the current block set to (xCb, yCb), and position (xCb + (mvL[0] >> 4) + cbWidth - 1, yCb + (mvL[1] >> 4) + cbHeight - 1) of the reference block's lower right sample as input, the output will be TRUE ( true) if the reference block's bottom right sample is restored. The cbWidth and cbHeight parameters represent the width and height of the reference block, respectively.

[0120] The third constraint (B1) in some of the embodiments of the present invention includes at least one of the following conditions: 1) the value (mvL[0] >> 4) + cbWidth is less than or equal to 0, which means that the reference block is on the left is located to the left of the current block and does not overlap the current block; 2) the value (mvL[1] >> 4) + cbHeight is less than or equal to 0, which means that the reference block to the left is on top of the current block and does not overlap the current block.

[0121] In the fourth constraint (C1), in some of the embodiments of the present invention, the following conditions must be met:

where CtbLog2SizeY is the base 2 logarithm (log2) of the CTU width. For example, when the CTU width is 128 samples, CtbLog2SizeY is 7. Equations (1) and (2) determine that the CTU including the reference block is in the same CTU row as the current CTU (i.e., the previously recovered CTU ( 1010) is on the same line as the current CTU (1015) when the reference block is in the previously restored CTU(1010)). Equations (3) and (4) determine that the CTU including the reference block is either in the CTU column to the left of the current CTU or in the same column as the current CTU. The fourth constraint described by equations (1)-(4) specifies that the CTU including the reference block is either in the current CTU or in the left adjacent CTU.

[0122] The fifth constraint (C2), in some of the embodiments of the present invention, specifies that when the reference block is in the adjacent left of the current CTU, the reference block's co-located area is not recovered (i.e., none of the samples in the co-located area has not been restored). In this case, the co-located area for the reference block is in the current CTU.

[0123] In one example, the fifth constraint can be specified as follows: If (xCb + (mvL[0] >> 4)) >> CtbLog2SizeY is equal to (xCb >> CtbLog2SizeY) - 1 when the reference block availability determination procedure is called, with current block position (xCurr, yCurr) set to (xCb, yCb) and position (((xCb + (mvL[0] >> 4) + CtbSizeY) >> (CtbLog2SizeY - 1)) << (CtbLog2SizeY - 1), ((yCb + (mvL[1] >> 4)) >> (CtbLog2SizeY - 1)) << (CtbLog2SizeY - 1)), as input, then FALSE on output indicates to the fact that the co-located area has not been restored.

[0124] In the above equations, xCb and yCb are the x and y coordinates of the current block, respectively. The variables cbHeight and cbWidt represent the height and width of the current block, respectively. The variables mvL0[0] and mvL0[1] denote the x- and y-components of the block vector mvL0, respectively. The constraints on the search range and/or the block vector may include any suitable combination of the first, second, third, fourth, and fifth constraints described above. In one example, the first, second, third, fourth and/or fifth constraints may be modified.

[0125] III. Spatial Merge Candidates

[0126] In FIG. 10 shows an example of candidate positions for spatial fusion in the current block (1010) of samples, in accordance with one embodiment of the present invention. Among the candidate positions shown in FIG. 4, a maximum of four merge candidates can be selected and calculated. In one example, the calculation order may be: A0, B0, B1, A1, and B2. In one example, position B2 is only considered if all coding packets with positions A0, B, 0, B1, and A1 are not available or are intra-predictively encoded. In one example, an encoding package at a position may not be available if that encoding package belongs to another slice or tile.

[0127] IV. Calculating Merge Candidates Based on History

[0128] In some embodiments of the present invention, history-based motion vector prediction (HMVP) merge candidates are added to the extended merge list of the current coding package after the spatial and temporal candidate MVP predictions. In HMVP prediction, the motion information of previously encoded sample blocks may be stored in a table (or history buffer) and used as MVP candidates for the current coding package. Such traffic information is called HMVP candidates. A table with multiple HMVP candidates may be processed during encoding and decoding procedures. In one example, the table may be flushed (emptied) when a new CTU row begins. In one embodiment of the present invention, when an inter-prediction encoded coding packet having no sub-blocks is encountered, the corresponding information may be entered in the table with the last entry as a new HMVP candidate.

[0129] In one embodiment of the present invention, the size of the HMVP table, denoted S, may be set to 6. Accordingly, up to 6 HMVP candidates may be added to the table. When a new motion prediction candidate is added to the table, in one embodiment of the present invention, a strict first-in-first-out (FIFO) rule can be applied. However, when a new HMVP candidate is added, a redundancy check can be performed to see if there is an identical HMVP candidate in the table. If an identical HMVP candidate is found in the table, it can be removed from the table, and all subsequent HMVP candidates can be moved forward. The new HMVP candidate can then be added to the end of the table.

[0130] In one embodiment of the present invention, HMVP candidates are used in a procedure for recovering an extended list of merge candidates. In one embodiment of the present invention, several newly added HMVP candidates in the table may be checked one after the other and inserted into the expanded list of candidates, in positions after the TMVP candidate. Redundancy checks can be performed to determine if HMVP candidates are similar or identical to spatial or temporal merge candidates previously added to the extended merge list.

[0131] HMVP candidates may also be used in the AMVP candidate list generation procedure. The motion vectors of the last K HMVP candidates in the table are inserted after the TMVP candidate. Only HMVP candidates having the same reference picture as the target AMVP reference picture are used to reconstruct the AMVP candidate list. HMVP candidates are pruned. In some practical applications, K is chosen to be 4, while the size of the AMVP list is left unchanged, i.e., equal to 2.

[0132] To reduce the number of redundancy checks, the following simplifications may be introduced in one embodiment of the present invention:

(i) the number of HMPV candidates used to form the extended merge list is set to (N<=4) ? M: (8-N) where N is the number of available candidates in the expanded merge list and M is the number of available HMVP candidates in the history table.

(ii) If the total number of available merge candidates in the expanded merge list reaches the maximum allowed number of merge candidates minus 1, the HMVP-based merge candidate list generating procedure is terminated.

[0133] In accordance with some of the embodiments of the present invention, when IBC copying functions as a mode separate from inter prediction, a separate history buffer called HBVP can be used to store previously encoded IBC block vectors. In the case of an IBC copy mode separate from inter-prediction, it is desirable to have a simplified procedure for calculating block vectors. The candidate list for block vector prediction in AMVP IBC copying may be the same as the list used in IBC merge mode (Merge Candidate List), with two spatial candidates + five HBVP candidates.

[0134] The size of the IBC merge candidate list may be denoted by MaxNumMergeCand. The value of MaxNumMergeCand may be determined by the size of the inter-prediction mode merge candidate list, MaxNumMergeCand, which is denoted, in some examples, six_minus_max_num_merge_cand. The variable six_minus_max_num_merge_cand can be the maximum number of MVP (motion vector prediction) merge candidates supported in a slice, subtracted from 6.

[0135] In some examples, the maximum number of MVP merge candidates, MaxNumMergeCand, can be calculated as follows:

MaxNumMergeCand = 6 - six_minus_max_num_merge_cand

[0136] The MaxNumMergeCand value may range from 1 to 6 inclusive. For motion vector prediction in the non-merge mode, the same list generated for the IBC merge mode can be used. However, in some examples, in the case of the non-merge mode, the size of the candidate list is always 2. Accordingly, it is necessary to propose suitable methods for determining the size of the IBC merge candidate list, as well as the size of the prediction list in the non-merge IBC mode (AMVP mode), when MaxNumMergeCand can be is set to various values, and the maximum size of the IBC merge candidate list may be set to be different from the size of the merge candidate list in the inter prediction mode.

[0137] V. Motion vector conversion/modification for IBC mode

[0138] In accordance with the foregoing description, existing restrictions on a valid decoded block vector include, in some of the embodiments of the present invention, at least two requirements:

[0139] (i) the reference block pointed to by the block vector must be completely reconstructed and be in the same coding region as the current block. The same coding area may be understood to mean areas whose samples can be predicted based on each other, such as the same tile, the same slice, or the same group of tiles. This type of constraint may be referred to as an accessibility check constraint.

[0140] (ii) The reference block pointed to by the block vector must be within the allowed search range, to enable wave parallel processing (WPP), within the range of the current and leftmost CTU to satisfy memory constraints etc. This type of constraint may be referred to as a range constraint.

[0141] Aspects of the present invention include methods for transforming/modifying a decoded block vector in such a way as to remove some of the restrictions (eg, range restrictions, availability check). In this regard, the decoder may not be required to check if the block vector satisfies some of the constraints when decoding the current block in the IBC copy mode.

[0142] For example, bitstream compatibility requirements may specify that a motion vector (mvL) must point to a reference block entirely located in the same CTU as the current block, or entirely located in a left adjacent sample block having the same height, as the current block, and a width equal to 128 brightness samples, i.e. all of the following conditions must be met:

[0143] The above-described restrictions imposed for bitstream compatibility (ie, equations (5)-(8)) can be removed if the block vector is transformed/modified in accordance with some of the embodiments of the present invention.

[0144] In some of the embodiments of the present invention, the x- and y-components of the block vector can be moduloed based on the size of the current CTU, so that when the upper left position of the reference block is outside the predetermined search range for IBC copy (e.g., current CTU or left neighbor CTU), modifying the block vector may move the upper left corner of the reference block inside the target range (e.g., inside the allowed/valid search range, based on the size of the reference memory and the position of the current block in the current CTU). In one example, the modified block vector may point to the top corner of another reference block, within the target range. Otherwise, when the block vector points to a reference block within the target range, this block vector may remain unchanged (no modification is performed).

[0145] In one embodiment of the present invention, an incorrect block vector (eg, outside the correct search range) may be modified to be located in the current CTU. In one embodiment of the present invention, the invalid block vector may be modified to be located in the current CTU or the left neighbor CTU when the search target range includes the current CTU and the left neighbor CTU. In one embodiment of the present invention, the target tolerance range may include the current CTU and several CTUs to the left, depending on the size of the reference sample memory and the size of the CTU in the current picture.

[0146] In one example, the x-component of the block vector and the y-component of the block vector can be modified using the following formulas:

[0147] In the above two equations (9) and (10), bvL[0] is the x-component of the block vector, and bvL[1] is the y-component of the block vector. CtbSizeY is the size of the CTU (eg in luminance counts) and "%" is the modulo operator. The modulo operation may be performed based on a multiple of the CTU size when the target range includes one or more CTUs on the left. Said multiple corresponds to the number of one or more CTUs on the left that are within the target range. For example, such a multiple could be 2 when the target range includes the current CTU and the left adjacent CTU, or 8 when the target range includes the current valid search range and the three left CTUs. The top left position of the current CTU, (xCurrCtuTL, yCurrCtuTL), and the top left position of the CTU in which the reference block resides, (xRefCtuTL, yRefCtuTL), can be computed as follows:

[0148] Meanwhile, in equation (9), the variable numLeftCtus denotes the number of CTUs to the left of the current CTU and can be calculated as follows:

[0149] After the modification, a shift operation can be performed to change the resolution of the block vector to the resolution that is used in storage. The following is an example of changing the resolution of a block vector:

[0150] In some of the embodiments of the present invention, the block vector can be modified so that the offset of the reference block relative to the CTU in which it was located before the modification is identical to the offset of the modified block reference vector relative to the current CTU after the modification. In this regard, modification of the block vector may not result in a change in the offset. In equation (9), the offset can be (xRefCtuTL < xCurrCtuTL && xCurrCtuTL xRefCtuTL <= numLeftCtus * CtbSizeY).

[0151] In one embodiment of the present invention, the lower right corner (xRefBR, yRefBR) of the reference block can be modified similarly to its upper left corner (xRefTL, yRefTL) as described above. Accordingly, aspects of the present invention make it possible to ensure that the entire reference block, and not just its upper left corner, will be within the current CTU.

[0152] In one embodiment of the present invention, a truncation operation may be performed to adjust the decoded block vector such that, after truncation, the block vector always points to a reference block within the target range. When the top-left position of the reference block is outside the correct search range for IBC copying (for example, the current CTU or the left neighbor CTU), modifying the block vector allows the top-left position to be adjusted so that the top-left corner of the reference block is within the target range. Otherwise, when the block vector points to a reference block within the target range, that block vector may remain unchanged (eg, no truncation operation is performed).

[0153] In one example, if one of the x or y components of the block vector lies outside the target range, then the upper left corner of the reference block can be truncated to the target range using a clipping operation. The bottom right corner of the reference block can also be truncated to the target range. When both the upper left corner of the reference box and the lower right corner of the reference box are truncated to the target range, the reference box will lie entirely within the target range.

[0154] In one embodiment of the present invention, when the y-coordinate of the upper-left corner of the reference block (pointed to by the block vector) lies outside the row of the current CTU, the block vector may be truncated to be in the top row of the current CTU (i.e., i.e. at the boundary of the current CTU). Similarly, if the x-coordinate of the upper left corner of the reference box (pointed to by the box vector) is out of range equal to the current CTUy and the left adjacent CTUy, the box vector can be truncated to be in the leftmost column of the current CTU. Accordingly, the out-of-bounds block vector may be truncated so that the modified reference block is either in the top row or leftmost column of the current CTU.

[0155] It should be noted that all other constraints (eg, the first, second, third, and fifth constraints described above) may also be imposed, or used, to determine if the modified block vector is correct.

[0156] In one embodiment of the present invention, by applying modifications (using the truncation or modulo operations described above) to the decoded block vector, the bitstream restrictions described below can be removed.

[0157] One or more of the following conditions must be true:

The value (mvL[0] >> 4) + cbWidth is less than or equal to 0; and

the value (mvL[1] >> 4) + cbHeight is less than or equal to 0.

[0158] The above conditions can be used to ensure that the reference block does not overlap with the current block. If the reference block overlaps the current block (ie, both conditions are not met), the block vector can be modified to ensure that at least one of the above two conditions is met. In one embodiment of the present invention, the above two conditions can be removed even if no operations or modifications are performed on the decoded block vector.

[0159] In one example, the following operations may be performed to ensure that one of the two conditions described above is met:

When (mvL[0] >> 4) + cbWidth > 0 and (mvL[1] >> 4) + cbHeight > 0, the following applies:

mvL[0] =- cbWidth << 4.

[0160] In another example, the following operations may be performed to ensure that one of the two conditions described above is met:

When (mvL[0] >> 4) + cbWidth > 0 and (mvL[1] >> 4) + cbHeight > 0, the following applies:

mvL[1] = -cbHeight << 4.

[0161] VI. Examples of decoding procedures

[0162] In FIG. 11 is a flowchart describing a procedure (1100) of a decoding procedure in accordance with some of the embodiments of the present invention. Procedure (1100) may be used to decode the current block in IBC copy mode. In various embodiments of the present invention, the procedure (1100) may be executed by data processing circuits, for example, data processing circuits in terminal devices (210), (220), (230) and (240), data processing circuits that perform the functions of a video decoder (310 ), data processing circuits that function as a video encoder (410), and the like. In some of the embodiments of the present invention, procedure (1100) may be implemented by program instructions, for example, when data processing circuits execute program instructions, these data processing circuits may execute procedure (1100). The procedure starts with a step (S1101), then proceeds to a step (S1110).

[0163] In step (S1110), an encoded video bitstream including the current picture is received.

[0164] In step (S1120), it is determined whether the current block in the current Code Tree Packet (CTU) contained in the current picture is encoded in Intra Block Copy (IBC) mode based on a flag included in the encoded video bitstream. Such a flag may be an IBC flag indicating the use of IBV at the block level. If it is determined that the current block is not IBC coded, the procedure shown in FIG. 11 complete.

[0165] In step (S1130), in response to determining that the current block is encoded in the IBC copy mode, a block vector is determined that points to the first reference block for the current block. The block vector may be determined based on the AMVP IBC mode or the merge mode.

[0166] In step (S1140), an operation is performed on the block vector such that when the first reference block is not completely restored or is not within the correct search range for the current block, the block vector is modified to point to a second reference block that is in the fully restored area and within the valid search range for the current block. For example, a modulo operation can be performed on the x-component and y-component of a block vector based on the size of the current CTU. In one example, the x-component of the block vector and the y-component of the block vector may be modified using Equation (9) and Equation (10). In one embodiment of the present invention, a modulo operation is performed on the x-component of the block vector based on a value that is a multiple of the size of the current CTU. In one embodiment of the present invention, a modulo operation on the y-component of the block vector is performed based on the size of the CTU. When the block vector points to a reference block that is fully reconstructed and is within the correct search range for the current block, the operation performed (eg, equations (9) and 10)) does not modify the block vector. In this case, the first reference block is the same as the reference block.

[0167] In step (S1150), the current block is decoded based on the modified block vector. Namely, the current block may be decoded based on the reference samples in the second reference block of samples pointed to by the modified block vector. The procedure (1100) proceeds to step (S1199) where it ends.

[0168] VII. computer system

[0169] The methods described above may be implemented in computer software that uses computer-readable instructions and is physically stored on one or more computer-readable media. For example, in FIG. 12 shows a computer system (1200) suitable for implementing some of the embodiments of the present invention.

[0170] Computer software may be encoded using any suitable machine code or programming language that can be processed through assembly, compilation, linking, or similar mechanisms, resulting in a code that includes instructions executed directly or by interpretation, execution microcode, etc., one or more computer central processing units (CPU), graphic processors (Graphics Processing Units, GPU), etc.

[0171] The instructions may be executed on computers, or computer components, of various types, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, IoT devices, and the like.

[0172] The computer system components (1200) shown in FIG. 12 are provided by way of example only and are not intended to suggest any limitation as to the scope or functionality of the computer software implementing the embodiments of the present invention. Likewise, the component configuration shown is also not to be interpreted as having any dependency or requirement associated with any component illustrated in the exemplary computer system (1200) or combination of such components.

[0173] The computer system (1200) may include input devices from the user interface. Input devices in a user interface may respond to input from one or more users using, for example, tactile input (eg, keystrokes, swipe gestures, cyber glove movements), audio input (eg, voice, handclaps), visual input (for example, gestures), olfactory input (not shown in the drawing). User interface devices may also be used to capture media of various types, not necessarily associated with conscious input from a human, such as audio (eg, voice, music, environmental sounds), images (eg, scanned images, still images taken from a camera), video (eg 2D video, 3D video including stereoscopic video).

[0174] User interface devices may include one or more of the following (the drawing shows only one device of each type): keyboard (1201), mouse (1202), trackpad (1203), touch screen (1210), cyber glove (not shown on the drawing), joystick (1205), microphone (1206), scanner (1207), camera (1208).

[0175] The computer system (1200) may also include user interface output devices. User interface output devices may affect the senses of one or more users, such as through tactile output, sound, light, and/or smell/taste. User interface output devices may include tactile output devices (e.g., tactile feedback from a touch screen (1210), a cyber glove (not shown) or a joystick (1205), however non-input tactile output devices may also be present) . For example, such devices can be audio output devices (for example, speakers (1209), headphones (not shown)), visual output devices (for example, screens (1210), including CRT screens, LCD screens, plasma screens, OLED - screens, both touch and non-touch, with or without tactile feedback, while some of the screens may be capable of displaying two-dimensional visual information or more than three-dimensional visual information, using the same means, such as stereographic output, virtual reality glasses (not shown in the drawing), holographic displays, holographic smoke machines, and printers (not shown in the drawing).

[0176] The computer system (1200) may also include user-accessible storage devices and associated storage media, such as optical media including CD/DVD ROM/RW (1220), CD/DVD media (1221), or similar, flash drive (1222), removable hard drive or solid state drive (1223), previously used magnetic media, such as tapes or floppy disks (not shown in the drawing), specialized devices based on ROM / ASIC / PLD, for example, hardware keys (not shown in the drawing), etc.

[0177] Those of skill in the art should understand that the term "computer-readable storage medium" as used in connection with the present invention does not include transmission media, carrier waves, or other energy dependent signals.

[0178] The computer system (1200) may also interface with one or more communication networks. Networks can be, for example, wireless, wired or optical. Networks can also be local, wide area, metro, vehicle or industrial, real-time networks, delay tolerant, and the like. Examples of networks include local area networks such as Ethernet, wireless LANs, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., wired or wireless WANs for digital broadcasting, including cable TV, satellite TV, and broadcast networks. , networks of vehicles and industrial facilities, including CANBus, etc. Some networks require external network interface adapters that connect to general purpose data ports or peripheral buses (1249) (for example, computer system USB ports (1200)). Other networks may be integrated into the internal structure of the computer system (1200) by connecting to the system bus, as described below (for example, an Ethernet interface in a personal computer system or a cellular network interface in a smartphone-based computer system). The use of any of these networks allows the computer system (1200) to communicate with other entities. Such communications can be unidirectional, receive only (eg broadcast), unidirectional, transmit only (eg CANbus network to some CANbus devices) or bidirectional, eg to other computer systems using LANs or WANs. Any of the networks and network interfaces described above may use the appropriate protocols and protocol stacks.

[0179] The above-described user interface devices, user-accessible storage devices, and network interfaces may be connected to the basic internal structure (1240) of the computer system (1200).

[0180] The basic internal structure (1240) may include one or more central processing units (CPU) (1241), graphics processing units (GPU) (1242), specialized programmable data processing units in the form of electrically programmable gate arrays (Field Programmable Gate Areas, FPGA ) (1243), hardware accelerators (1244) for certain tasks, etc. These devices, along with Read-only memory (ROM) (1245), random access memory (1246), high capacity internal memory such as internal, user-accessible hard drives, SSD drives and similar memory (1247) can be combined by the system bus (1248). In some computer systems, the system bus (1248) may be accessed in the form of one or more physical connectors, allowing the system to be expanded with additional CPUs, GPUs, and the like. Peripherals can be connected either directly to the base system bus (1248) or to the peripheral bus (1249). Examples of peripheral bus architectures are PCI, USB, and the like.

[0181] CPUs (1241), GPUs (1242), FPGAs (1243), and accelerators (1244) may execute instructions that, collectively, may constitute the computer code described above. The computer code may be stored in ROM (1245) or RAM (1246). Temporary data can then be stored in RAM (1246), while permanent data can be stored, for example, in a high-capacity internal memory (1247). High speed storage and retrieval of data can be achieved through the use of cache memory, which can be closely associated with one or more CPU (1241), GPU (1242), memory (1247) large capacity, ROM (1245 ), RAM (1246), etc.

[0182] Computer-readable storage media may store computer code for performing various computer-executable operations. Such media and computer code may be specially designed and manufactured for the purposes of the present invention or may be widely available and known to those skilled in the art of computer software.

[0183] As a non-limiting example, a computer system with an architecture (1200), and in particular, a basic structure (1240), can provide the required functionality as a result of execution by a processor (or processors) (including CPUs, GPUs, FPGAs, accelerators, etc.). .p.), software implemented on one or more tangible computer-readable storage media. Such computer-readable storage media may be media associated with mass storage devices described above that are accessible to users, or non-volatile storage devices in the base structure (1240), such as built-in mass storage device (1247) or ROM (1245). Software that implements various embodiments of the present invention may be stored in such devices and executed by the internal structure (1240) of the computer system. The computer-readable storage medium, depending on specific requirements, may include one or more storage devices or memory chips. The software may provide execution, by the underlying structure (1240), and in particular by its processors (including CPU, GPU, FPGA, etc.), of the necessary procedures, or parts of the necessary procedures described in this document, including the creation of structures data stored in RAM (1246), and modification of these data structures in accordance with the procedures defined by the software. In addition or alternatively, the computer system may provide the required functionality as a result of the operation of logic, hard-coded or otherwise embodied in an electrical circuit (for example, an accelerator (1244)), which may work with or instead of software to perform the required procedures. or parts of the required procedures described in this document. Reference to software, where appropriate, may imply such logic and vice versa. Reference to a computer-readable medium, where appropriate, may refer to an electrical circuit (eg, an integrated circuit) that stores executable software, an electrical circuit that implements executable logic, or both. All appropriate combinations of hardware and software are within the scope of the present invention.

Appendix A: Abbreviations

JEM: Joint Exploration Model

VVC: Versatile video coding

BMS: Benchmark set

MV: Motion Vector

HEVC: High Efficiency Video Coding

SEI: Supplementary Enhancement Information

VUI: Video Usability Information

GOP: Groups of Pictures

TU: Transform Units,

PU: Prediction Units

CTU: Coding Tree Units

CTB: Coding Tree Blocks

RV: Prediction Blocks

HRD: Hypothetical Reference Decoder

SNR: Signal-to-noise ratio (Signal Noise Ratio)

CPU: Central Processing Units

GPU: Graphic processors (Graphics Processing Units)

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: Custom Integrated Circuit (Application-Specific Integrated Circuit)

PLD: Programmable Logic Device

LAN: Local area network (Local Area Network)

GSM: Global System for Mobile communications

LTE: Long term evolution

CANBus: Controller Area Network Bus

USB: Universal Serial Bus (Universal Serial Bus)

PCI: Peripheral Component Interconnect

FPGA: Field Programmable Gate Areas

SSD: solid-state hard drive (solid-state drive)

IC: Integrated circuit (Integrated Circuit)

CU: Coding Unit

CG: Coefficient Group

IBC: Intra Block Copy

[0184] This document has described several embodiments of the present invention, however, modifications, changes and equivalent substitutions are possible, which fall within the scope of the present invention. Accordingly, it is to be understood that those skilled in the art are capable of creating a variety of systems and methods that, while not expressly described herein, accomplish the intent of the present invention and are therefore within its scope and spirit.

Claims (18)

1. Video decoding method, characterized in that it contains: receiving an encoded video bitstream including the current picture (S1110); determining whether the current block in the current Code Tree Packet (CTU) contained in the current picture is encoded in Intra Block Copy (IBC) mode based on a flag included in the encoded video bitstream (S1120); and, in response to determining that the current block is encoded in IBC copy mode, determining a block vector that points to a first reference block for the current block (S1130); performing an operation on the block vector when the first reference block is not within the correct search range for the current block, the block vector being modified by this operation to point to a second reference block that is within the correct search range for the current block (S1140); and decoding the current block based on the modified block vector (S1150), wherein the incorrect block vector outside the correct search range is modified to be located in the current CTU or the left neighbor CTU, when the target range includes the current CTU and the left neighbor CTU, and the target range includes the current CTU and some number of left CTUs, depending on the size reference sample memory and CTU size in the current picture. 2. The method of claim. 1, in which the second reference block is in a completely reconstructed area, while the second reference block and the current block are in the same tile, slice or group of tiles. 3. The method of claim 1, wherein performing said operation includes: performing a modulo operation on the x-component and on the y-component of the block vector based on the size of the current CTU. 4. The method according to p. 1, in which the implementation of the above operation includes: performing a modulo operation on the x-component of the block vector based on a value that is a multiple of the size of the current CTU; and performing a modulo operation on the y-component of the block vector based on the size of the current CTU. 5. The method of claim 1, wherein performing said operation modifies the block vector only when the first reference block is not fully reconstructed or is outside the correct search range for the current block. 6. The method of claim 1, wherein performing said operation does not modify the block vector when the first reference block is fully reconstructed and is within a valid search range for the current block. 7. The method of claim 1, wherein the correct search range for the current block includes the current CTU. 8. The method of claim 1, wherein performing said operation modifies the block vector such that the offset of the first reference block relative to the CTU including the first reference block is identical to the offset of the second reference block relative to the current CTU. 9. The method of claim 1, wherein performing said operation includes: truncating the block vector such that the truncated block vector points to a second reference block that lies on the boundary of a valid search range for the current block, when the first reference block is not fully recovered or not is within the valid search range for the current block. 10. A device for video decoding, including: data processing circuits configured to perform the method according to any one of paragraphs. 1-9. 11. A computer-readable storage medium that stores instructions that, when executed by a video decoding computer, cause that computer to execute the method of any one of claims. 1-9.

Images