Method, apparatus, and program for decoding video
By optimizing the search range and block vector determination for intra-block copy mode, the method addresses inefficiencies in intra-prediction, improving video coding efficiency and compression ratios.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- TENCENT AMERICA LLC
- Filing Date
- 2025-03-06
- Publication Date
- 2026-04-28
AI Technical Summary
Existing video coding techniques face inefficiencies in intra-prediction due to the increased number of possible directions, leading to higher bit usage for less likely directions, which affects compression efficiency.
The proposed method involves determining a block vector that points to a reference block within a certain memory size limit, checking boundaries and reconstruction status, and invalidating block vectors for partially reconstructed blocks, optimizing the search range for intra-block copy mode.
This approach reduces redundancy by efficiently representing likely and unlikely intra-prediction directions, enhancing video coding efficiency and compression ratios.
Smart Images

Figure 0007853470000001 
Figure 0007853470000002 
Figure 0007853470000003
Abstract
Description
Technical Field
[0001] Incorporation by Reference This application claims the benefit of priority of U.S. Patent Application No. 16 / 533,719, filed on Aug. 6, 2019, entitled "METHOD AND APPARATUS FOR VIDEO CODING", and claims the benefit of priority of U.S. Provisional Application No. 62 / 792,888, filed on Jan. 15, 2019, entitled "SEARCH RANGE ADJUSTMENT WITH VARIABLE CTU SIZE FOR INTRA PICTURE BLOCK COMPENSATION". The entire disclosure of the prior applications is incorporated herein by reference in its entirety.
[0002] Technical Field The present disclosure generally describes embodiments related to video coding.
Background Art
[0003] The background description provided herein is for the purpose of generally presenting the context of the present disclosure. The current research of the inventors listed is not expressly or implicitly admitted as prior art to the present disclosure in that the research is within the scope described in this background section and, in other respects, may not be eligible as prior art at the time of filing.
[0004] Video coding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can contain a series of images, each image having spatial dimensions of, for example, 1920 x 1080 luminance samples and associated color samples. The series of images can have a fixed or variable image rate (e.g., 60 images / second or 60Hz). Uncompressed video requires a high bitrate. For example, 1080p60 4:2:0 video with 8 bits per sample (1920x1080 luminance sample resolution at a frame rate of 60Hz) requires a bandwidth of nearly 1.5 Gbit / second. One hour of such video requires more than 600 GB of storage space.
[0005] One purpose of video coding and decoding is to reduce the redundancy of the input video signal through compression. Compression can, in some cases, reduce the need for the aforementioned bandwidth or storage space by more than two orders of magnitude. Both lossless and lossy compression, as well as combinations thereof, can be used. Lossless compression is a technique that allows an exact copy of the original signal to be reconstructed from the compressed original signal. When using lossy compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signals is small enough that the reconstructed signal can serve its intended purpose. In the case of video, lossy compression is widely used. The amount of distortion that is acceptable depends on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio can reflect that higher acceptable / acceptable distortion can result in a higher compression ratio.
[0006] Video encoders and decoders can utilize techniques from several broad categories, including, for example, motion compensation, transformation, quantization, and entropy coding.
[0007] Video codec techniques may include a technique known as intra coding. In intra coding, sample values are represented without referencing samples or other data from a previously reconstructed reference image. In some video codecs, the image is spatially divided into blocks of samples. If all blocks of samples are coded in intra mode, the image can be an intra image. Intra images and their derivatives, such as independent decoder refresh images, can be used to reset the decoder state and therefore can be used as the first image in the coded video bitstream and video session, or as a still image. Samples in intra blocks can be subjected to transformation, and the transformation coefficients can be quantized before entropy coding. Intra prediction may be a technique to minimize the sample values in the pre-transformation domain. In some cases, the smaller the post-transformation DC value and the smaller the AC coefficient, the fewer bits are needed for a given quantization step size to represent the block after entropy coding.
[0008] Traditional intra-encoding, such as that known from MPEG-2 generation coding techniques, does not use intra-prediction. However, some newer video compression techniques include, for example, techniques that attempt to find blocks of data from surrounding, preceding sample data and / or metadata obtained during the encoding / decoding of spatially adjacent data. Such techniques will hereafter be referred to as “intra-prediction” techniques. It should be noted that, in at least some cases, intra-prediction uses only reference data from the current image being reconstructed, and not reference data from the reference image.
[0009] Various forms of intra-prediction are possible. If one or more of these techniques can be used in a given video coding technique, the technique in use can be coded in intra-prediction mode. In certain cases, a mode may have submodes and / or parameters, which may be coded individually or included in a mode codeword. The codeword used for a given mode / submode / parameter combination may affect the coding efficiency gain through intra-prediction, and similarly, the entropy coding technique used to translate the codeword into a bitstream may also have an effect.
[0010] Certain intra-prediction modes were introduced in H.264, improved in H.265, and further refined with newer coding techniques such as the joint exploration model (JEM), versatile video coding (VVC), and benchmark set (BMS). Predictor blocks can be formed using adjacent sample values belonging to already available samples. Sample values of adjacent samples are copied to the predictor block according to direction. References to the direction in use can be coded in the bitstream or may be predicted themselves.
[0011] Referring to Figure 1, shown in the lower right is a subset of nine predictor directions known from the 33 possible predictor directions of H.265 (corresponding to the 33 angular modes of the 35 intra-modes). The point where the arrows converge (101) represents the predicted sample. The arrows indicate the direction in which the sample is predicted. For example, arrow (102) indicates that sample (101) is predicted to be directed upward and to the right at an angle of 45 degrees from the horizontal by one or more samples. Similarly, arrow (103) indicates that sample (101) is predicted to be directed downward and to the left of sample (101) at an angle of 22.5 degrees from the horizontal by one or more samples (101).
[0012] Referring further to Figure 1, a 4x4 sample square block (104) is shown in the upper left (indicated by a thick dashed line). The square block (104) contains 16 samples, each labeled "S" and including its position in the Y dimension (e.g., row index) and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample (from the top) in the Y dimension and the first sample (from the left) in the X dimension. Similarly, sample S44 is the fourth sample in both the Y and X dimensions within block (104). Since the block size is 4x4 samples, S44 is in the lower right. Furthermore, a reference sample following a similar numbering scheme is shown. The reference sample is labeled R, its Y position (e.g., row index) and X position (column index) relative to block (104). In both H.264 and H.265, the predicted sample is adjacent to the block being reconstructed, There is no need to use negative values.
[0013] Intra-image prediction works by copying reference sample values from adjacent samples depending on the signal prediction direction. For example, suppose the coded video bitstream contains a signal indicating the prediction direction for this block, which corresponds to arrow (102). That is, a sample is predicted from one or more prediction samples to the upper right at an angle of 45 degrees from the horizontal. In this case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Then, sample S44 is predicted from reference sample R08.
[0014] In certain cases, especially when the direction is not evenly divisible by 45 degrees, the values of multiple reference samples can be combined, for example, by interpolation, to calculate a reference sample.
[0015] The number of possible directions is increasing with the development of video coding technology. H.264 (2003) could represent nine different directions. This increased to 33 in H.265 (2013), and JEM / VVC / BMS at the time of disclosure can support up to 65 directions. Experiments have been conducted to identify the most likely directions, and certain entropy coding techniques are used to represent those possible directions in a small number of bits, accepting a certain penalty for less likely directions. Furthermore, the direction itself can sometimes be predicted from the adjacent directions used in adjacent, already decoded blocks.
[0016] Figure 2 shows a schematic diagram (201) of 65 intra-prediction directions by JEM to illustrate the increasing number of prediction directions over time.
[0017] The mapping of intra-predicted direction bits in a coded video bitstream representing direction can vary from video coding technique to video coding technique, for example, from simple direct mapping of the predicted direction to complex adaptive schemes including intra-predicted mode, code name, most likely mode, and similar techniques. However, in any case, there may be certain directions in video content that are statistically less likely to occur than other particular directions. Since the goal of video compression is to reduce redundancy, in well-functioning video coding techniques, less likely directions will be represented by more bits than more likely directions. [Overview of the Initiative]
[0018] Aspects of this disclosure provide methods and apparatus for video encoding / decoding. In some embodiments, the apparatus for video decoding includes a receiving circuit and a processing circuit. For example, the processing circuit decodes predictive information for the current block in the current coding tree unit (CTU) from a coded video bitstream. The predictive information represents an intra-block copy mode. The size of the current CTU is less than the maximum size of the reference sample memory for storing reconstructed samples. The processing circuit determines a block vector that points to a reference block of the same image as the current block. The reference block has reconstructed samples buffered in the reference sample memory. The processing circuit then reconstructs at least one sample of the current block based on the reconstructed sample of the reference block read from the reference sample memory.
[0019] In some embodiments, the processing circuit determines a block vector that points to a reference block located in the same CTU column as the current CTU, within the region from the (N-1)th CTU to the left of the current CTU to the adjacent CTU to the left of the current CTU, where the maximum size of the reference sample memory is N times the size of the current CTU, and N is a positive number greater than 1.
[0020] In some embodiments, the processing circuit checks whether the top boundary of the reference block is in the same CTU column. Furthermore, the processing circuit checks whether the bottom boundary of the reference block is in the same CTU column. Then, the processing circuit checks whether the left boundary of the reference block is to the right of the Nth CTU to the left, and whether the right boundary is to the left of the current CTU.
[0021] In some embodiments, the processing circuit checks whether the reference block is at least partially located in the Nth leftmost CTU in the same CTU column as the current CTU, where the maximum size of the reference sample memory is N times the size of the current CTU, and N is a positive number greater than 1.
[0022] Furthermore, the processing circuit checks whether the left boundary of the reference block is within the Nth CTU to the left. If the reference block is at least partially within the Nth CTU to the left, the processing circuit determines whether the collocated block of the reference block is at least partially reconstructed within the current CTU. In one embodiment, the processing circuit determines whether the upper left corner of the collocated block has been reconstructed. If the collocated block within the current CTU is at least partially reconstructed, the processing circuit invalidates the block vector pointing to the reference block.
[0023] In some embodiments, the processing circuit determines the reference block region within the Nth leftmost CTU containing the reference block, and determines whether the collocated block region of the reference block region has been at least partially reconfigured in the current CTU. The processing circuit then invalidates the block vector pointing to the reference block if the collocated block region in the current CTU has been at least partially reconfigured.
[0024] Also, an aspect of the present disclosure provides a non - transient computer - readable media storage storing instructions that cause a computer to execute a method for video coding when executed by the computer for video decoding. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] Further features, properties, and various advantages of the disclosed subject matter will become more apparent from the following detailed description and the accompanying drawings. [Figure 1] FIG. 1 is a schematic diagram of an exemplary subset of intra - prediction modes. [Figure 2] FIG. 2 is an explanatory diagram of an exemplary intra - prediction direction. [Figure 3] FIG. 3 schematically shows a simplified block diagram of a communication system (300) according to an embodiment. [Figure 4] FIG. 4 schematically shows a simplified block diagram of a communication system (400) according to an embodiment. [Figure 5] FIG. 5 schematically shows a simplified block diagram of a decoder according to an embodiment. [Figure 6] FIG. 6 schematically shows a simplified block diagram of an encoder according to an embodiment. [Figure 7] FIG. 7 is a block diagram of an encoder according to another embodiment. [Figure 8] FIG. 8 is a block diagram of a decoder according to another embodiment. [Figure 9] FIG. 9 shows an example of intra - block copy according to an embodiment of the present disclosure. [Figure 10A] FIG. 10A shows an example of an effective search range for the intra - block copy mode according to an embodiment of the present disclosure. [Figure 10B] FIG. 10B shows an example of an effective search range for the intra - block copy mode according to an embodiment of the present disclosure. [Figure 10C]Figure 10C shows an example of an effective search range for intrablock copy mode according to one embodiment of the present disclosure. [Figure 10D] Figure 10D shows an example of an effective search range for intrablock copy mode according to one embodiment of the present disclosure. [Figure 11] Figure 11 shows examples of colocated blocks according to some embodiments of the present disclosure. [Figure 12] Figure 12 shows examples of colocated blocks according to some embodiments of the present disclosure. [Figure 13] Figure 13 shows a flowchart outlining process examples according to several embodiments of the present disclosure. [Figure 14] Figure 14 is a schematic diagram showing a computer system according to one embodiment. [Modes for carrying out the invention]
[0026] Figure 3 shows a simplified block diagram of a communication system (300) according to one embodiment of the present disclosure. The communication system (300) includes a plurality of terminal devices that can communicate with each other, for example, via a network (350). For example, the communication system (300) includes a first pair of terminal devices (310) and (320) interconnected via the network (350). In the example of Figure 3, the first pair of terminal devices (310) and (320) perform one-way transmission of data. For example, terminal device (310) can encode video data (e.g., a stream of video images captured by terminal device (310)) and transmit it to other terminal devices (320) via the network (350). The encoded image data can be transmitted in the form of one or more encoded video bitstreams. Terminal device (320) can receive the encoded video data from the network (350), decode the encoded video data to reconstruct the video image, and display the video image according to the reconstructed video data. One-way data transmission can be common in media delivery applications and the like.
[0027] In another example, the communication system (300) includes a second pair of terminal devices (330) and (340) that perform bidirectional transmission of coded video data that may occur, for example, during a video conference. For bidirectional transmission of data, for example, each terminal device of terminal devices (330) and (340) may code video data (e.g., a stream of video images captured by the terminal device) for transmission to the other terminal device of terminal devices (330) and (340) via the network (350). Each terminal device of terminal devices (330) and (340) may receive coded video data transmitted by the other terminal device of terminal devices (330) and (340), decode the coded video data to restore video images, and display video images on an accessible display device according to the restored video data.
[0028] In the example in Figure 3, terminal devices (310), (320), (330), and (340) may be shown as a server, a personal computer, and a smartphone, but the principles of the present invention are not limited to these. Embodiments of the present invention find applications to laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network (350) represents any number of networks that transmit coded video data between terminal devices (310), (320), (330), and (340), including, for example, wireline and / or wireless communication networks. Communication network (350) can exchange data in circuit-switched and / or packet-switched channels. Typical networks include telecommunication networks, local area networks, wide area networks, and / or the Internet. For the purposes of this description, the architecture and topology of network (250) may not be important to the operation of the present invention unless otherwise described below.
[0029] Figure 4 shows the arrangement of a video encoder and video decoder in a streaming environment as an example of the application of the disclosed subject matter. The disclosed subject matter can be equally applied to other video-enabled applications, such as video conferencing, digital TV, and storing compressed video on digital media including CDs, DVDs, and memory sticks.
[0030] The streaming system may include a capture subsystem (413) which may include a video source (401), such as a digital camera, that generates a stream of uncompressed video images (402). In one embodiment, the stream of video images (402) includes samples captured by the digital camera. The stream of video images (402), drawn as a thick line to emphasize a higher data volume compared to encoded video data (404) (or encoded video bitstream), may be processed by an electronic device (420) which includes a video encoder (403) coupled to the video source (401). The video encoder (403) may include hardware, software, or a combination thereof, enabling or carrying out embodiments of the disclosed subject matter as will be described in more detail below. The encoded video data (404) (or encoded video bitstream (404)) may be shown as a thin line to emphasize a lower data volume compared to the stream of video images (402), and may be stored in a streaming server (405) for future use. One or more streaming client subsystems, such as client subsystems (406) and (408) in Figure 4, can access a streaming server (405) and read copies (407) and (409) of the encoded video data (404). Client subsystem (406) may include, for example, a video decoder (410) in an electronic device (430). The video decoder (410) decodes the input copy (407) of the encoded video data and generates an output stream (411) of a video image that can be rendered on a display (412) (e.g., a display screen) or other rendering device (not shown). In some streaming systems, the encoded video data (404), (407), and (409) (e.g., video bitstreams) may be coded according to a specific video coding / compression standard. Examples of these standards include ITU-T Recommendation H.265.For example, a video coding standard under development is informally known as General-Purpose Video Coding (VVC). The disclosed subject matter may be used in the context of VVC.
[0031] It should be noted that electronic devices (420) and (430) may include other components (not shown). For example, electronic device (420) may include a video decoder (not shown), and electronic device (430) may also include a video encoder (not shown).
[0032] Figure 5 shows a block diagram of a video decoder (510) according to one embodiment of the present disclosure. The video decoder (510) may be included in an electronic device (530). The electronic device (530) may include a receiver (531) (e.g., a receiving circuit). The video decoder (510) can be used in place of the video decoder (410) in the example of Figure 4.
[0033] The receiver (531) can receive one or more coded video sequences to be decoded by the video decoder (510), and in the same or different embodiments, it can receive one coded video sequence at a time, in which case the decoding of each coded video sequence is independent of other coded video sequences. The coded video sequences can be received from a channel (501), which may be a hardware / software link to a storage device that stores coded video data. The receiver (531) can receive the coded video data together with other data, such as coded audio data and / or accompanying data streams, which may be transmitted using their respective entities (not shown). The receiver (531) can isolate the coded video sequences from other data. To counteract network jitter, a buffer memory (515) may be coupled between the receiver (531) and the entropy decoder / parser (520) (hereinafter "Parser (520)"). In certain applications, the buffer memory (515) is part of the video decoder (510). In other cases, it may be located outside the video decoder (510) (not shown). In yet another case, a buffer memory (not shown) may exist outside the video decoder (510), for example to counter network jitter, and further, another buffer memory (515) may exist inside the video decoder (510), for example to handle playback timing. If the receiver (531) is receiving data from a storage / transfer device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (515) may be unnecessary or small.For use in best-effort packet networks such as the Internet, the buffer memory (515) is required, relatively large, and may be of an adaptive size, and may be at least partially implemented in an operating system or similar element (not shown) outside the video decoder (510).
[0034] The video decoder (510) may include a parser (520) for reconstructing symbols (521) from the coded video sequence. These categories of symbols include information used to manage the operation of the video decoder (510), as shown in Figure 5, and potential information for controlling rendering devices, such as a rendering device (512) (e.g., a display screen), which is not an integral part of the electronic device (530) but may be coupled to the electronic device (530). Control information for (multiple) rendering devices may take the form of additional extension information (SEI messages) or video usability information (VUI) parameter set fragments (not shown). The parser (520) can parse / entropy decode the received coded video sequence. The coding of the coded video sequence may follow video coding techniques or standards and may follow various principles, including variable-length coding, Huffman coding, and arithmetic coding with or without context sensitivity. The parser(520) may extract from the coded video sequence a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder, based on at least one parameter corresponding to a group. Subgroups may include image groups (GOPs), images, tiles, slices, macroblocks, coding units (CUs), blocks, transformation units (TUs), prediction units (PUs), etc. The parser(520) may also extract information such as transformation coefficients, quantization parameter values, and motion vectors from the coded video sequence.
[0035] The parser (520) may perform an entropy decode / parse operation on the video sequence received from the buffer memory (515) to generate symbols (521).
[0036] The reconstruction of symbol (521) may include multiple different units depending on the type of coded video image or part thereof (e.g., between and within images, between and within blocks) and other factors. Which units are included and how they are included can be controlled by subgroup control information parsed from the video sequence coded by parser (520). The flow of such subgroup control information between parser (520) and the following multiple units is not illustrated for clarity.
[0037] In addition to the functional blocks already described, the video decoder (510) can be conceptually divided into several functional units, as described below. In a practical implementation operating under commercial constraints, many of these units can interact closely with each other and be at least partially integrated. However, for the purpose of illustrating the disclosed subject, it is appropriate to conceptually subdivide it into the following functional units.
[0038] The first unit is the scaler / inverse unit (551). The scaler / inverse unit (551) receives quantized transformation coefficients, as well as control information from the parser (520) as symbols (521) to be used, including the transformation, block size, quantization coefficients, and quantization scaling matrix. The scaler / inverse unit (551) can output a block containing sample values that can be input to the aggregator (555).
[0039] In some cases, the output samples of the scaler / inverse transform (551) may relate to intracoded blocks, i.e., blocks that do not use predictive information from previously reconstructed images but can use predictive information from previously reconstructed portions of the current image. Such predictive information may be provided by an intra-image prediction unit (552). In some cases, the intra-image prediction unit (552) generates blocks of the same size and shape as the block being reconstructed, using surrounding already reconstructed information fetched from the current image buffer (558). The current image buffer (558) buffers, for example, a partially reconstructed current image and / or a fully reconstructed current image. The aggregator (555) may, in some cases, add the predictive information generated by the intra-predictive unit (552) to the output sample information provided by the scaler / inverse transform unit (551) for each sample.
[0040] In other cases, the output samples of the scaler / inverse unit (551) may be related to the intercoding and potentially related to the motion compensation block. In such cases, the motion compensation prediction unit (553) may access the reference image memory (557) to fetch samples to be used for prediction. After motion compensation of the fetched samples according to the symbols (521) associated with the block, these samples may be added by the aggregator (555) to the output of the scaler / inverse unit (551) (referred to in this case to residual samples or residual signals) to generate output sample information. The address in the reference image memory (557) from which the motion compensation prediction unit (553) fetches the prediction samples may be controlled by a motion vector and may be available to the motion compensation prediction unit (553) in the form of a symbol (521) which may have, for example, X, Y, and reference image components. Motion compensation may also include interpolating sample values so that they are fetched from a reference image memory (557) if the precise motion vectors of subsamples are used, a motion vector prediction mechanism, etc.
[0041] The output samples of the aggregator (555) can undergo various loop filtering techniques within the loop filter unit (556). The video compression technique may include in-loop filter technologies, which are controlled by parameters contained in the coded video sequence (also called the coded video bitstream) and made available to the loop filter unit (556) as symbols (521) from the parser (520), and which can respond to metadata obtained between the decoding of the coded image or coded video sequence and the decoding of preceding portions (in the decoding order), as well as to previously reconstructed and loop-filtered sample values.
[0042] The output of the loop filter unit (556) can be a sample stream that can be output to the rendering device (512) and can also be stored in the reference image memory (557) for use in future intra-image prediction.
[0043] Once a coded image is fully reconstructed, it can be used as a reference image for future predictions. For example, once the coded image corresponding to the current image is fully reconstructed and the coded image is identified as a reference image (e.g., by the parser (520)), the current image buffer (4558) can become part of the reference image memory (557), and a new current image buffer can be reallocated before starting the reconstruction of subsequent coded images.
[0044] The video decoder (510) may perform decoding operations according to a specified video compression technique of a standard such as ITU-T Rec.H.265. The coded video sequence may conform to the syntax specified by the video compression technique or standard being used, in the sense that the coded video sequence conforms to both the syntax of the video compression technique or standard and the profile documented in the video compression technique or standard. Specifically, a profile may select a particular tool from all tools available in the video compression technique or standard as the only tool that can be used under that profile. Also, for compliance, the complexity of the coded video sequence may be within the range defined by the level of the video compression technique or standard. In some cases, the level may limit the maximum image size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference image size, etc. The limitations set by the level may, in some cases, be further limited by the specification of the Hypothetical Reference Decoder (HRD) and the HRD buffer management metadata signaled in the coded video sequence.
[0045] In one embodiment, the receiver (531) may receive additional (redundant) data along with the encoded video. The additional data may be included as parts of the coded (multiple) video sequences. The additional data may be used by the video decoder (510) to properly decode the data and / or to more accurately reconstruct the original video data. The additional data may take the form of, for example, a temporal, spatial, or signal-to-noise ratio (SNR) enhancement layer, redundant slices, redundant images, or forward error correction code.
[0046] Figure 6 shows a block diagram of a video encoder (603) according to one embodiment of the present disclosure. The video encoder (603) is included in the electronic device (620). The electronic device (620) includes a transmitter (640) (e.g., a transmitting circuit). The video encoder (603) can be used instead of the video encoder (403) in the example in Figure 4.
[0047] The video encoder (603) may receive video samples from a video source (601) (not part of the electronic device (620) in the example in Figure 6) which can capture (multiple) video images coded by the video encoder (603). In another example, the video source (601) is part of the electronic device (620).
[0048] The video source (601) may provide a source video sequence to be coded by the video encoder (603) in the form of a digital video sample stream, which can be any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, ...), any color space (e.g., BT.601 Y CrCB, RGB, ...), and any suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media distribution system, the video source (601) may be a storage device that stores pre-prepared video. In a video conferencing system, the video source (601) may be a camera that captures local image information as a video sequence. The video data may be provided as a number of individual images that, when viewed in sequence, produce motion. The images themselves can be organized as a spatial array of pixels, and each pixel may contain one or more samples, depending on the sampling structure, color space, etc., in use. Those skilled in the art will readily understand the relationship between pixels and samples. The following description focuses on samples.
[0049] According to one embodiment, the video encoder (603) can encode and compress images from a source video sequence into a coded video sequence (643) in real time or under any other time constraints required by the application. Achieving an appropriate coding speed is one function of the controller (650). In some embodiments, the controller (650) controls and is functionally coupled to other functional units, as described below. The couplings are not shown for clarity. Parameters set by the controller (650) may include rate control-related parameters (image skip, quantizer, lambda value of rate distortion optimization technique, ...), image size, image group layout, maximum motion vector search range, etc. The controller (650) may be configured to have other appropriate functions related to the video encoder (603) optimized for a particular system design.
[0050] In some embodiments, the video encoder (603) is configured to operate in a coding loop. In an oversimplified explanation, in one example, the coding loop may include a source coder (630) (responsible for generating symbols, such as a symbol stream, based, for example, on an input image and a reference image to be coded) and a (local) decoder (633) embedded in the video encoder (603). The decoder (633) reconstructs the symbols to create sample data in a similar manner to how a (remote) decoder also creates (such that any compression between the symbols and the coded video bitstream is reversible in the video compression techniques considered in the disclosed subject). The reconstructed sample stream (sample data) is input to a reference image memory (634). Since decoding the symbol stream yields bit-exact results that are independent of the decoder location (local or remote), the contents of the reference image memory (634) are also bit-exact between the local encoder and the remote encoder. In other words, the predictive part of the encoder "sees" the exact same sample values as the reference image samples that the decoder "sees" when using the predictions during decoding. This fundamental principle of reference image synchronization (and the resulting drift when synchronization cannot be maintained, for example, due to channel errors) is also used in several related techniques.
[0051] The operation of the “local” decoder (533) can be the same as that of a “remote” decoder such as the video decoder (410), as has already been described in detail in relation to Figure 5. However, also briefly referring to Figure 5, since symbols are available and the coding / decoding of symbols to the coding video sequence by the entropy coder (645) and parser (520) can be reversible, the entropy decoding portion of the video decoder (510), including the buffer memory (515), and the parser (520) may not be fully implemented in the local decoder (633).
[0052] An observation that can be made in this regard is that any decoder techniques present within the decoder, other than pars / entropy decoding, must also exist in substantially the same functional form within the corresponding encoder. For this reason, the disclosed subject matter focuses on decoder operation. The description of encoder techniques can be omitted as it is the inverse of the comprehensively described decoder techniques. More detailed explanations are necessary only in specific areas and are provided below.
[0053] During operation, in some examples, the source coder (630) may perform motion-compensated predictive coding, predictively coding the input image by referencing one or more previously coded images from a video sequence designated as “reference images”. In this way, the coding engine (632) codes the difference between the pixel blocks of the input image and the pixel blocks of the reference images that may be selected as predictive references for the input image.
[0054] The local video decoder (633) can decode coded video data of an image that may be designated as a reference image, based on symbols generated by the source coder (630). The operation of the coding engine (632) may, advantageously, be a lossy process. If coded video data can be decoded by a video decoder (not shown in Figure 6), the reconstructed video sequence may typically be a duplicate of the source video sequence with some errors. The local video decoder (633) repeats the decoding process that may be performed by the video decoder on the reference image and produce a reconstructed reference image to be stored in the reference image cache (634). In this way, the video encoder (603) can locally store a copy of the reconstructed reference image with common content as the reconstructed reference image that will be obtained by the distal end video decoder.
[0055] The predictor (635) may perform a predictive search on the coding engine (632). In other words, for a new image to be coded, the predictor (635) may search the reference image memory (634) for specific metadata such as reference image motion vectors, block shapes, or sample data (as candidate reference pixel blocks) that can serve as appropriate predictive references for the new image. The predictor (635) may operate on a sample block-by-sample basis to find appropriate predictive references. In some cases, the input image may have predictive references drawn from multiple reference images stored in the reference image memory (634), as determined by the search results obtained by the predictor (635).
[0056] The controller (650) may manage the coding operations of the source coder (630), including, for example, setting parameters and subgroup parameters used to encode video data.
[0057] All outputs of the aforementioned functional units are subject to entropy coding in the entropy coder (645). The entropy coder (645) converts the symbols generated by the various functional units into coded video sequences by reversibly compressing the symbols according to techniques such as Huffman coding, variable-length coding, and arithmetic coding.
[0058] The transmitter (640) can buffer the coded video sequence created by the entropy coder (645) and prepare it for transmission via a communication channel (660), which may be a hardware / software link to a storage device that will store the encoded video data. The transmitter (640) can merge the coded video data from the video coder (603) with other data to be transmitted, such as coded audio data and / or auxiliary data streams (not shown).
[0059] The controller (650) may manage the operation of the video encoder (603). During coding, the controller (650) may assign a specific coded image type to each coded image, which may affect the coding technique that can be applied to each image. For example, an image is often assigned as one of the following image types:
[0060] Intra images (I images) can be coded and decoded without using other images in the sequence as prediction sources. Some video codecs allow different types of intra images, including, for example, Independent Decoder Refresh ("IDR") images. Those skilled in the art are aware of these variations of I images, as well as their respective uses and characteristics.
[0061] The predicted image (P-image) may be coded and decoded using inter-prediction or intra-prediction, which uses up to one motion vector and a reference index to predict the sample value of each block.
[0062] Bidirectionally predicted images (B images) may be coded and decoded using inter-prediction or intra-prediction, employing up to two motion vectors and reference indices to predict the sample values for each block. Similarly, multiple predicted images may use two or more reference images and associated metadata for the reconstruction of a single block.
[0063] The source image is typically divided spatially into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each), and each block is coded. Blocks may be coded predictively by referring to other (already coded) blocks, determined by the coding assignment applied to each image in the block. For example, blocks of image I may be coded non-predictively, or they may be coded predictively by referring to already coded blocks (spatial or inter-predictive) of the same image. Pixel blocks of image P may be coded predictively via spatial or temporal prediction by referring to a previously coded reference image. Blocks of image B can be predictively coded via spatial or temporal prediction, referencing one or two previously coded reference images.
[0064] The video encoder (603) may perform coding operations in accordance with a predetermined video coding technique or standard such as ITU-T Rec.H.265. In its operation, the video encoder (603) may perform various compression operations, including predictive coding operations that take advantage of temporal and spatial redundancy in the input video sequence. Thus, the coded video data may conform to the syntax specified by the video coding technique or standard being used.
[0065] In one embodiment, the transmitter (640) may transmit additional data along with the encoded video. The source coder (630) may include such data as part of the coded video sequence. The additional data may include temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant images and slices, SEI messages, VUI parameter set fragments, etc.
[0066] Video can be captured as multiple source images (video images) in a time sequence. Intra-image prediction (often abbreviated as inter-prediction) uses spatial correlations in a given image, while inter-image prediction uses (temporal or other) correlations between images. In one example, a particular image being coded / decoded, called the current image, is divided into blocks. If a block in the current image is analogous to a reference block in a previously coded and still-buffered reference image in a video, then the block in the current image may be coded by a vector called a motion vector. The motion vector points to a reference block in the reference image and may have a third dimension that identifies the reference image if multiple reference images are used.
[0067] In some embodiments, a bi-prediction technique can be used in image-to-image prediction. According to the bi-prediction technique, two reference images are used, such as a first reference image and a second reference image, both of which precede the current image in the video in decoding order (but may be past and future, respectively, in display order). A block in the current image can be coded by a first motion vector pointing to a first reference block in the first reference image and a second motion vector pointing to a second reference block in the second reference image. The block can be predicted by a combination of the first and second reference blocks.
[0068] Furthermore, merge mode techniques can be used for inter-image prediction to improve coding efficiency.
[0069] According to some embodiments of this disclosure, predictions such as inter-image prediction and intra-image prediction are performed in units of blocks. For example, according to the HEVC standard, images in a video image sequence are divided into coding tree units (CTUs) for compression, and the CTUs in an image have the same size, such as 64x64 pixels, 32x32 pixels, or 16x16 pixels. Generally, a CTU contains three coding tree blocks (CTBs), which are one luma CTB and two chroma CTBs. Each CTU can be recursively quadtree-partitioned into one or more coding units (CUs). For example, a 64x64 pixel CTU can be divided into one 64x64 pixel CU, four 32x32 pixel CUs, or sixteen 16x16 pixel CUs. In the example, each CU is analyzed to determine the prediction type of the CU, such as inter-prediction type or intra-prediction type. A CU is divided into one or more prediction units (PUs) depending on its temporal and / or spatial predictability. Generally, each PU contains a Luma prediction block (PB) and two Chroma PBs. In one embodiment, prediction operations in coding (encode / decode) are performed within the units of the prediction block. Using a Luma prediction block as an example of a prediction block, the prediction block contains a matrix of values (e.g., Luma values) for pixels, such as 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc.
[0070] Figure 7 shows a diagram of a video encoder (703) according to another embodiment of the present disclosure. The video encoder (703) is configured to receive a processing block (e.g., a prediction block) of sample values in the current video image within a video image sequence and to encode the processing block into a coded image which is part of a coded video sequence. In one embodiment, the video encoder (703) is used instead of the video encoder (403) in the example of Figure 4.
[0071] In the HEVC example, the video encoder (703) receives a matrix of sample values for a processing block, such as an 8x8 sample prediction block. The video encoder (703) determines whether the processing block is best coded using intra-mode, inter-mode, or bidirectional prediction mode, for example, using rate-distortion optimization. If the processing block is coded in intra-mode, the video encoder (703) may use intra-prediction techniques to encode the processing block into a coded image; if the processing block is coded in inter-mode or bidirectional prediction mode, the video encoder (703) may use inter-prediction techniques or bidirectional prediction techniques, respectively, to code the processing block into a coded image. In certain video coding techniques, the merge mode may be an inter-image prediction submode in which the motion vectors are derived from one or more motion vector predictors without benefiting from coded motion vector components outside the predictors. In certain other video coding techniques, there may be motion vector components applicable to the target block. In one embodiment, the video encoder (703) includes other components, such as a mode determination module (not shown) for determining the mode of the processing block.
[0072] In the example shown in Figure 7, the video encoder (703) includes an entropy encoder (725), an interencoder (730), an intraencoder (722), a residual calculator (723), a switch (726), a residual encoder (724), and a general-purpose controller (721), all coupled together as shown in Figure 7.
[0073] The interencoder (730) is configured to receive a sample of the current block (e.g., a processing block), compare the block to one or more reference blocks in the reference image (e.g., blocks in the preceding and subsequent images), generate interprediction information (e.g., a description of redundant information by the interencoding technique, motion vectors, merge mode information), and compute an interprediction result (e.g., a predicted block) based on the interprediction information using any appropriate technique. In some examples, the reference image is a decoded reference image, decoded based on encoded video information.
[0074] The intra encoder (722) is configured to receive a sample of the current block (e.g., a processing block), and optionally compare the block to a block already coded in the same image to generate quantized coefficients after transformation, and optionally also generate intra prediction information (e.g., intra prediction direction information according to one or more intra coding techniques). In one example, the intra encoder (722) also calculates an intra prediction result (e.g., a prediction block) based on the intra prediction information and reference block in the same image.
[0075] The general-purpose control device (721) is configured to determine general-purpose control data and to control other components of the video encoder (703) based on the general-purpose control data. In one embodiment, the general-purpose controller (721) determines the mode of a block and supplies control signals to the switch (726) based on that mode. For example, if the mode is intra-mode, the general-purpose controller (721) controls the switch (726) to select the intra-mode result to be used by the residual calculator (723), controls the entropy encoder (725) to select the intra-prediction information, and includes the intra-prediction information in the bitstream. If the mode is inter-mode, the general-purpose controller (721) controls the switch (726) to select the inter-prediction result to be used by the residual calculator (723), controls the entropy encoder (725) to select the inter-prediction information, and includes the inter-prediction information in the bitstream.
[0076] The residual calculator (723) is configured to calculate the difference (residual data) between the received block and the prediction result selected from the intra-encoder (722) or inter-encoder (730). The residual encoder (724) operates on the residual data and is configured to encode the residual data to generate conversion coefficients. In one embodiment, the residual encoder (724) is configured to convert the residual data from the spatial domain to the frequency domain and generate conversion coefficients. The conversion coefficients are then subjected to a quantization process to obtain quantized conversion coefficients. In various embodiments, the video encoder (703) also includes a residual decoder (728). The residual decoder (728) is configured to perform an inverse transform and generate decoded residual data. The decoded residual data can be appropriately used by the intra-encoder (722) and inter-encoder (730). For example, an interencoder (730) can generate a decoded block based on decoded residual data and interprediction information, and an intraencoder (722) can generate a decoded block based on decoded residual data and intraprediction information. In some embodiments, the decoded block is appropriately processed to generate a decoded image, which can be buffered in a memory circuit (not shown) and used as a reference image.
[0077] The entropy encoder (725) is configured to format the bitstream to include encoded blocks. The entropy encoder (725) is configured to include various information in accordance with an appropriate standard such as the HEVC standard. In one embodiment, the entropy encoder (725) is configured to include general control data, selected prediction information (e.g., intra-prediction information or inter-prediction information), residual information, and other appropriate information in the bitstream. Note that when coding blocks in either inter-mode or bidirectional prediction mode merge submodes in accordance with the disclosed subject, residual information is not present.
[0078] Figure 8 shows a diagram of a video decoder (810) according to another embodiment of the present disclosure. The video decoder (810) is configured to receive a coded image which is part of a coded video sequence, and to decode the coded image to produce a reconstructed image. In one embodiment, the video decoder (810) is used instead of the video decoder (410) in the embodiment of Figure 3.
[0079] In the embodiment shown in Figure 8, the video decoder (810) includes an intra decoder (872), an entropy decoder (871), an interdecoder (880), a residual decoder (873), and a reconfiguration module (874), all coupled together as shown in Figure 8.
[0080] The entropy decoder (871) can be configured to reconstruct specific symbols from the coded image that represent the syntactic elements that make up the coded image. Such symbols may include, for example, the mode in which the block is coded (e.g., intra-mode, inter-mode, bidirectional prediction mode, merge sub-mode, or inter-mode in another sub-mode, bidirectional prediction mode, etc.), prediction information (e.g., intra-prediction information or inter-prediction information), which can be used by the intra-decoder (822) or inter-decoder (880), respectively, to identify specific samples or metadata, such as residual information in the form of quantized transformation coefficients. For example, if the prediction mode is inter-mode or bidirectional prediction mode, inter-prediction information is provided to the inter-decoder (880), and if the prediction type is intra-prediction type, intra-prediction information is provided to the intra-decoder (872). The residual information may undergo inverse quantization and be provided to the residual decoder (873).
[0081] The interdecoder (880) is configured to receive interprediction information and generate interprediction results based on the interprediction information.
[0082] The intra decoder (872) is configured to receive intra prediction information and generate prediction results based on the intra prediction information.
[0083] The residual decoder (873) is configured to perform dequantization to extract dequantized transform coefficients and to process these dequantized transform coefficients to convert the residual from the frequency domain to the spatial domain. The residual decoder (873) may also require certain control information (including quantizer parameters (QP)), which may be provided by the entropy decoder (871) (the data path is not shown as it contains only low-volume control information).
[0084] The reconstruction module (874) is configured to combine the residuals, as output from the residual decoder (873), and the prediction results (possibly as output from the inter or intra prediction module) in the spatial domain to form a reconstruction block, which may be part of the reconstructed image and therefore part of the reconstructed video. Note that visual quality can be improved by performing other appropriate operations such as deblocking.
[0085] The video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) can be implemented using any suitable technology. In one embodiment, the video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) can be implemented using one or more integrated circuits. In another embodiment, the video encoders (403), (603), and (603) and the video decoders (410), (510), and (810) can be implemented using one or more processors that execute software instructions.
[0086] Aspects of this disclosure provide encoding / decoding techniques for intra-image block compensation, particularly techniques for adjusting the search range with a variable CTU size.
[0087] Block-based compensation can be used for inter-prediction and intra-prediction. For inter-prediction, block-based compensation can also be performed from previously reconstructed areas within the same image. Block-based compensation from reconstructed areas within the same image is called intra-image block compensation, current picture referencing (CPR), or intra-block copy (IBC). The displacement vector indicating the offset between the current block and the reference block within the same image is called the block vector (abbreviated as BV). Unlike the motion vector in motion compensation, the block vector can be any value (positive or negative, in either the x or y direction), but the block vector has some constraints to ensure that the reference block is available and has already been reconstructed. Also, in some examples, some reference areas that are tile boundaries or wavefront ladder shape boundaries are excluded to allow for parallel processing.
[0088] Block vector coding can be either explicit or implicit. In explicit mode (or referred to as Advanced Motion Vector Prediction (AMVP) mode in intercoding), the difference between the block vector and its predictor is signaled, while in implicit mode, the block vector is reconstructed from a predictor (referred to as a block vector predictor), similar to motion vectors in merge mode. The resolution of the block vector is limited to integer positions in some implementations, but in other systems, the block vector is allowed to point to fractional positions.
[0089] In some embodiments, the use of intra-block copying at the block level can be signaled using a block-level flag referred to as the IBC flag. In some embodiments, the IBC flag is signaled if the current block is not coded in merge mode. In other embodiments, the use of intra-block copying at the block level is signaled by a reference index approach. The current image being decoded is then treated as a reference image. In one embodiment, such a reference image is placed at the end of a list of reference images. This special reference image is managed together with other temporal reference images in a buffer such as a decoded image buffer (DPB).
[0090] Furthermore, intrablock copies have several variations, including flipped intrablock copies (where the reference block is flipped horizontally or vertically before being used to predict the current block) and line-based intrablock copies (where each compensation unit within an MxN coding block is an Mx1 or 1xN line).
[0091] Figure 9 shows an example of an intrablock copy according to one embodiment of the present disclosure. The current image (900) is being decoded. The current image (900) includes a reconstructed area (910) (dotted area) and an area to be decoded (920) (white area). The current block (930) is being reconstructed by the decoder. The current block (930) can be reconstructed from a reference block (940) located within the reconstructed area (910). The positional offset between the reference block (940) and the current block (930) is referred to as the block vector (950) (or BV(950)).
[0092] In some examples (e.g., VVC), the search range of intrablock copy mode is constrained to be within the current CTU. In this case, the memory requirement for storing reference samples for intrablock copy mode is 1 (largest) CTU size of samples. In one example, the (largest) CTU is 128 × 128 sample size. In some examples, the CTU is divided into four block regions, each having a size of 64 × 64 samples. Thus, in some embodiments, total memory (e.g., cache memory with a faster access speed than primary storage) can store 128 × 128 size samples, and the total memory includes an existing reference sample memory portion for storing samples reconfigured into the current block, such as a 64 × 64 region, and an additional memory portion for storing samples in three other 64 × 64 size regions. Thus, in some examples, the effective search range of intrablock copy mode is extended to a portion of the left CTU while the total memory requirement for storing the reference pixels remains unchanged (for example, four times the size of one CTU, totaling 64x64 reference sample memory).
[0093] In some embodiments, an update process is performed to update the stored reference samples from the left CTU to samples reconstructed from the current CTU. Specifically, in some examples, the update process is performed on a 64x64 luma sample basis. In one embodiment, for each of the four 64x64 block regions in the CTU-sized memory, reference samples in the region from the left CTU can be used to predict the coding blocks in the current CTU, which have CPR mode, until any of the blocks in the same region of the current CTU are being coded or have been coded.
[0094] Figures 10A–10D show examples of effective search ranges for intrablock copy mode according to one embodiment of the present disclosure. In some embodiments, the encoder / decoder includes a cache memory capable of storing samples of one CTU, such as 128 × 128 samples. Furthermore, in the examples of Figures 10A–10D, the current block area for prediction has a size of 64 × 64 samples. It should be noted that embodiments can be appropriately modified for current block areas of other preferred sizes.
[0095] Figures 10A–10D each show the current CTU(1020) and the left CTU(1010). The left CTU(1010) contains four block regions (1011)–(1014), each with a sample size of 64×64 samples. The current CTU(1020) contains four block regions (1021)–(1024), each with a sample size of 64×64 samples. The current CTU(1020) is the CTU containing the current block region being reconstructed (indicated by the label "Current" and the vertical stripe pattern). The left CTU(1010) is directly adjacent to the left of the current CTU(1020). As shown in Figures 10A–10D, gray blocks are block regions that have already been reconstructed, and white blocks are block regions that are to be reconstructed.
[0096] In Figure 10A, the current block region being reconfigured is block region (1021). The cache memory stores the reconfigured samples in block regions (1012), (1013), and (1014), and the cache memory will be used to store the reconfigured samples of the current block region (1021). In the example in Figure 10A, the effective search range for the current block region (1021) includes block regions (1012), (1013), and (1014) in the left CTU (1010), which has the reconfigured samples stored in the cache memory. Note that in one embodiment, the reconfigured samples of block region (1011) are stored in main memory, which has a slower access speed than the cache memory (for example, they are copied from the cache memory to main memory before the reconfiguration of block region (1021)).
[0097] In Figure 10B, the current block region being reconfigured is block region (1022). The cache memory stores the reconfigured samples in block regions (1013), (1014), and (1021), and the cache memory will be used to store the reconfigured samples of the current block region (1022). In the example in Figure 10B, the effective search range for the current block region (1022) includes block regions (1013) and (1014) in the left CTU (1010) and block region (1021) in the current CTU (1010), which have the reconfigured samples stored in the cache memory. Note that in one embodiment, the reconfigured samples of block region (1012) are stored in main memory, which has a slower access speed than the cache memory (for example, they are copied from the cache memory to main memory before the reconfiguration of block region (1022)).
[0098] In Figure 10C, the current block region being reconfigured is block region (1023). The cache memory stores the reconfigured samples in block regions (1014), (1021), and (1022), and the cache memory will be used to store the reconfigured samples of the current block region (1023). In the example in Figure 10C, the effective search range for the current block region (1023) includes block region (1014) in the left CTU (1010) and block regions (1021) and (1022) in the current CTU (1010), which have the reconfigured samples stored in the cache memory. Note that in one embodiment, the reconfigured samples of block region (1013) are stored in main memory, which has a slower access speed than the cache memory (for example, they are copied from the cache memory to main memory before the reconfiguration of block region (1023)).
[0099] In Figure 10D, the current block region being reconfigured is block region (1024). The cache memory stores the reconfigured samples in block regions (1021), (1022), and (1023), and the cache memory will now be used to store the reconfigured samples in block region (1024). In the example in Figure 10D, the effective search range for the current block region (1024) includes block regions (1021), (1022), and (1023) in the current CTU (1020), which have the reconfigured samples stored in the cache memory. Note that in one embodiment, the reconfigured samples in block region (1014) are stored in main memory, which has a slower access speed than the cache memory (for example, they are copied from the cache memory to main memory before the reconfiguration of block region (1024)).
[0100] In the example above, the cache memory has a total memory space of 1 (maximum) CTU size. The embodiment can be appropriately adjusted to other suitable CTU sizes. Note that the cache memory is referred to as reference sample memory in some embodiments.
[0101] The proposed methods can be used separately or in any combination in any order. Furthermore, each of the methods (or embodiments), encoders, and decoders may be implemented by a processing circuit (e.g., one or more processors, or one or more integrated circuits). In one embodiment, one or more processors execute a program stored in a non-temporary computer-readable medium. Hereinafter, the term "block" may be interpreted as a prediction block, coding block, or coding unit, i.e., a CU.
[0102] Aspects of this disclosure provide techniques for adjusting the search range so that, for example, the CTU size is smaller than the maximum CTU size when the CTU size changes. In an implementation, a designated memory that stores reference samples of CUs pre-coded for future intrablock copy references is referred to as reference sample memory (and in some embodiments as cache memory). This disclosure proposes a method for improving intrablock copy performance under specific reference area limitations. More specifically, the size of the reference sample memory for searching is limited. In the following description, the size of the reference sample memory is fixed at 128 × 128 lumens (along with the corresponding chromens). In some embodiments (e.g., the VVC standard), the maximum CTU size of one reference sample is considered to be the specified memory size. The proposed method can further be extended to various memory size / CTU size combinations, such as 64 × 64 lumens (plus the corresponding chromens) for the CTU size and 128 × 128 lumens (and the corresponding chromens) for the memory size.
[0103] In one aspect of the disclosure, collocated blocks in this disclosure refer to a pair of blocks having the same size and shape, where one collocated block is in a previously coded CTU and the other collocated block is in the current CTU, and one block of the pair is referred to as the collocated block of the other block of the pair. Furthermore, if the memory buffer size is designed to store the largest size CTU (e.g., 128 × 128), the preceding CTU, in one embodiment, refers to a CTU that has a CTU width luma sample offset of one to the left of the current CTU. Furthermore, these two collocated blocks each have the same position offset value with respect to the upper left corner of their own CTU. In other words, the collocated blocks are two blocks that have the same y-coordinate with respect to the upper left corner of the image, but in some embodiments, have a difference in CTU width in the x-coordinate with respect to each other.
[0104] Figure 11 shows examples of colocated blocks according to several embodiments of the present disclosure. In the embodiments of Figure 11, the current CTU and the left CTU are shown during decoding. Reconstructed areas are shown in gray, and areas to be reconstructed are shown in white. Figure 11 shows three examples of reference blocks in the left CTU relative to the current block in intra-block copy mode during decoding. The three examples are shown as reference block 1, reference block 2, and reference block 3. Figure 11 also shows colocated block 1 relative to reference block 1, colocated block 2 relative to reference block 2, and colocated block 3 relative to reference block 3. In the examples of Figure 11, the reference sample memory size is the CTU size. Reconstructed samples from the current CTU and the left CTU are stored in reference sample memory in a complementary manner. When reconstructed samples from the current CTU are written to reference sample memory, the reconstructed samples are written to the location of the colocated samples in the left CTU. For example, with respect to reference block 3, since the colocated block 3 is still within the current CTU and has not yet been reconfigured, reference block 3 can be found in reference sample memory. Reference sample memory still stores the sample of reference block 3 from the left-hand CTU and can be accessed quickly to retrieve the sample of reference block 3, and in one embodiment, reference block 3 can be used to reconfigure the current block in intra-block copy mode.
[0105] In other embodiments, with respect to reference block 1, the reconfiguration of the colocated block 1 within the current CTU is completed, and therefore, the reference sample memory stores the samples of the colocated block 1. Furthermore, the samples of reference block 1 are stored, for example, in off-chip storage which has a relatively high latency compared to the reference sample memory. Therefore, in one embodiment, reference block 1 is not found in the reference sample memory, and reference block 1 cannot be used to reconfigure the current block in intra-block copy mode.
[0106] Similarly, in other embodiments, a portion of the collocated block 2 is reconfigured relative to the reference block 2, and therefore the reference sample memory is updated to store the samples of the collocated block 2. Thus, in one embodiment, reference block 2 cannot be a valid reference block for reconfiguring the current block in intra-block copy mode.
[0107] Generally, in intrablock copy mode, for reference blocks in a CTU that have been decoded in advance, if the collocated blocks in the CTU have not yet been reconfigured, a sample of the reference block is available in the reference sample memory, and the sample of the reference block can be read from the reference sample memory to be used as a reference for reconfiguration in intrablock copy mode.
[0108] Note that in the above embodiment, the sample in the upper left corner of the collocated block in the current CTU, also referred to as the collocated sample in the upper left corner of the reference block, is checked. If the collocated sample in the current CTU has not yet been reconstructed, all remaining samples of the reference block are available for use as references for the intrablock copy.
[0109] Furthermore, in the above embodiment, the memory size of the reference sample memory is the size of one CTU, and it should be noted that the previously decoded CTU refers to the CTU adjacent to the left of the current CTU.
[0110] According to one aspect of the disclosure, the memory size of a reference sample memory may be larger than the size of one CTU.
[0111] Figure 12 shows an example of a colocated block according to some embodiments of the present disclosure. In the example of Figure 12, the reference sample memory is configured to have a size of N times the CTU (where N is an integer greater than or equal to 2), and thus the reference sample memory can store reconstructed samples from N+1 CTUs. For example, as shown in Figure 12, the current CTU (1210), the furthest left CTU (1230), and (multiple) intermediate left CTUs (1220) located between the current CTU (1210) and the furthest left CTU (1230), etc. The number of left CTUs is equal to N-1. The reconstructed samples of the current CTU (1210) and the furthest left CTU (1230) are stored in the reference sample memory in a complementary manner. To store the reconstructed sample of the current CTU (1210) in the reference sample memory, the reconstructed sample of the current CTU (1210) is written to the location of the colocated sample of the furthest left CTU (1230). The reconstructed area is shown in gray, and the area to be reconstructed is shown in white. In some embodiments, the left CTUs are numbered from the adjacent CTUs to the left to the furthest CTU to the left. For example, the adjacent CTU to the left of the current CTU (1210) is the 1st CTU to the left, the furthest left CTU (1230) is the Nth CTU to the left, and the CTU to the right of the furthest left CTU is the (N-1)th CTU to the left.
[0112] In the embodiment of Figure 12, the reference sample memory size is N times the size of the CTU, and therefore, all samples in the (multiple) intermediate left CTUs (1220) are available during the reconstruction of the samples in the current CTU (1210). However, samples in the furthest left CTU (1230) are only partially available in the reference sample memory and are under similar limitations as shown in the embodiment of Figure 11. For example, three examples of reference blocks in the furthest left CTU (1230) of the current block in intra-block copy mode during decoding are shown as reference block 1, reference block 2, and reference block 3. Figure 12 also shows collocated block 1 relative to reference block 1, collocated block 2 relative to reference block 2, and collocated block 3 relative to reference block 3. In this case, the x-coordinate offset between a pair of collocated blocks or samples is N times the CTU width. Other explanations for Figure 12 are the same as those for Figure 11 and have been described above, so for clarity, they are omitted here.
[0113] Note that in some embodiments, the reconfigured sample portion of the furthest left CTU(1230) and the reconfigured sample portion of the current CTU(1210) are complementary in the reference sample memory. When the sample of the current CTU(1210) is reconfigured, the reconfigured sample of the current CTU(1210) is written to the reference sample memory at the location of the reconfigured sample of the furthest left CTU(1230). The reconfigured sample of the furthest left CTU(1230) is overwritten in the reference sample memory by the reconfigured sample of the current CTU(1210).
[0114] Note that the example in Figure 12 can be used in scenarios where the reference sample memory size is greater than or equal to the CTU size. For example, if the reference sample memory size is four times the CTU size, the (multiple) middle left CTU(1220) contains three CTUs, and if the reference sample memory size is sixteen times the CTU size, the (multiple) middle left CTU(1220) contains fifteen CTUs. For example, if the reference sample memory size is equal to the CTU size, there is no middle left CTU(1220).
[0115] Aspects of this disclosure provide techniques for adjusting the search range in intrablock copy mode when the current CTU size is smaller than the maximum CTU size and the reference sample memory size is equal to one maximum CTU size. The reference sample memory can then buffer a number of previously decoded CTUs. If the reference block is from an adjacent CTU to the left, no additional conditional checks are required for availability. In this case, all CTUs to the left are available for intrablock copy referencing. In some embodiments, unified conditional checks are used for the cases where the current CTU size is equal to the maximum CTU size and where the current CTU size is smaller than the maximum CTU size.
[0116] Various parameters are used in the following description of the embodiments.
[0117] MaxCtbLog2SizeY indicates the maximum CTU size allowed on one side (height or width) in the log2 domain when the CTU is square. For example, if the maximum allowed CTU is 128 × 128 lumen sample height, MaxCtbLog2SizeY is equal to 7.
[0118] CtbLog2SizeY indicates the size of the CTU in the log2 domain, assuming the CTU is square, by one side (height or width).
[0119] cbHeight indicates the height of the coding block (also called the current block), and cbWidth indicates the width of the coding block. The position of the top-left corner of the coding block is indicated by (xCb, yCb), the position of the top-right corner is indicated by (xCb + cbWidth - 1, yCb), and the position of the bottom-left corner is indicated by (xCb, yCb + cbHeight - 1).
[0120] mvL0 represents the block vector, mvL0[0] represents the x-component of the block vector mvL0 at 1 / 16pel resolution, and mvL0[1] represents the y-component of the block vector mvL0 at 1 / 16pel resolution. Therefore, the integer value of the x-component is obtained by right-shifting mvL0[0] by 4 bits, and the integer value of the y-component is obtained by right-shifting mvL0[1] by 4 bits.
[0121] According to some aspects of this disclosure, the block vector mvL0 is restricted using a two-step restriction process to determine whether mvL0 is a valid block vector pointing to a reference block in intra-block copy mode and whether the reference block is fully stored in the reference sample memory. Thus, the reference sample memory can be accessed without reading the reference sample from main memory (e.g., off-chip memory).
[0122] In the first stage, the block vector mvL0 is checked to determine whether the block vector is within a potential valid block vector that points to a CTU-based search range that includes any CTU having all or part of the reconstructed samples in the reference sample memory. For example, the CTU-based search range includes the current CTU, the furthest left CTU, and any left CTU between the current CTU and the furthest left CTU. In one embodiment, the CTU size is equal to the maximum allowable CTU size, and the CTU-based search range includes the current CTU and the furthest left CTU (referred to as the left CTU in Figure 11), with no intermediate left CTUs between the current CTU and the furthest left CTU.
[0123] If block vector mvL0 is a potential valid block vector, it is checked in a second stage to determine whether it is a valid block vector. For example, in the second stage, if the block vector points to a reference block in the middle left CTU, then the block vector is a valid block vector. In the second stage, if the block vector points to a reference block in the farthest left CTU, block vector mvL0 is checked further to determine whether the collocated block of the reference block has been reconfigured.
[0124] In the first embodiment, the CTU size is equal to the maximum allowable CTU size, and therefore the reconstructed sample stored in the reference sample memory is either the current CTU or the furthest left CTU (the left CTU in Figure 11).
[0125] In the first stage, mvL0 is checked to determine if the block vector points to a CTU-based search range that includes the current CTU and the furthest leftmost CTU. In some examples, CTUs with the same y-value form a CTU row, and CTUs with the same x-value form a CTU column. In some embodiments, the constraints on the block vector mvL0 are expressed by equations (1) to (4): (yCb+(mvL0[1]>>4))>>CtbLog2SizeY=yCb>>CtbLog2SizeY (Formula 1) (yCb+(mvL0[1]>>4)+cbHeight-1)>>CtbLog2SizeY=yCb>>CtbLog2SizeY (Formula 2) (xCb+(mvL0[0]>>4))>>CtbLog2SizeY≧(xCb>>CtbLog2SizeY)-1 (Formula 3) (xCb+(mvL0[0]>>4)+cbWidth-1)>>CtbLog2SizeY≦(xCb>>CtbLog2SizeY) (Formula 4)
[0126] When equation (1) is satisfied, the top of the referenced block is in the same CTU row as the current block. When equation (2) is satisfied, the bottom of the referenced block is in the same CTU row as the current block. When equation (3) is satisfied, the left side of the referenced block is in the same CTU column as the current block, or in some cases, in the CTU column immediately to the left of the current block. When equation (4) is satisfied, the right side of the referenced block is in the same CTU column as the current block, or in some cases, in the CTU column to the left of the current block. Thus, in the embodiment, when equations 1 to 4 are satisfied, the referenced block is within the CTU-based search range.
[0127] In the second stage, if the reference block is located in the leftmost CTU, for example, if equation (5) is satisfied, the block vector mvL0 is checked to determine whether the collocated block of the reference block has been reconfigured. (xCb+(mvL[0]>>4))>>CtbLog2SizeY=(xCb>>CtbLog2SizeY)-1 (Formula 5)
[0128] In the examples, Currently, the top-left corner of the block is at (xCb, yCb), and the top-left corner of the referenced block is at (xCb+(mvL[0]>>4), yCb+(mvL0[1]>>4)), and the top-left corner of the collocated block is at (xCb+(mvL[0]>>4)+(1<<CtbLog2SizeY),yCb+(mvL0[1]> >4)) is located. In the example, the top-left corner of the collocated block is used to check the map that tracks the image reconstruction process. Note that if the position on the map is "false", in one example it indicates that the collocated block has not been reconstructed, and therefore the reference block is available in reference sample memory and can be used to reconstruct the current block in intra-block copy mode. In that case the block vector is a valid block vector. However, if the position on the map is "true", in one example it indicates that at least part of the collocated block has been reconstructed, and therefore a sample of the collocated block is stored in reference sample memory at the position of the sample of the reference block, and the sample of the reference block is not available in reference sample memory. Therefore the block vector mvL0 is not a valid block vector.
[0129] In the first embodiment, the second stage is based on collocated blocks, and the process in the first embodiment is referred to as a coding unit (CU) based update process.
[0130] In the second embodiment, the second step is based on block regions. For example, if the CTU has 128 × 128 samples, the CTU can be divided into four block regions, each having 64 × 64 samples. Similarly, in the second embodiment, the CTU size is equal to the maximum allowable CTU size, and therefore the reconstructed samples stored in the reference sample memory may be from either the current CTU or the furthest left CTU (the leftmost CTU in Figure 11).
[0131] In the first stage, the block vector mvL0 is checked to determine whether the block vector mvL0 points to a CTU-based search range that includes the current CTU and the furthest leftmost CTU, so that equations (1) to (4) are used in a manner similar to that of the first embodiment.
[0132] In the second stage, when equation (5) is satisfied, for example, when the reference block is in the leftmost CTU, the block vector mvL0 is checked to determine whether the collocated block region (e.g., a 64x64 block region) for the reference block has been reconfigured.
[0133] In the examples, Currently, the top-left corner of the block is at (xCb, yCb), and the top-left corner of the referenced block is at (xCb+(mvL[0]>>4), yCb+(mvL0[1]>>4)), The top-left corner of the collocated block region relative to the reference block is (((xCb+(mvL[0]>>4)+(1<<CtbLog2SizeY))> It is located at >(CtbLog2SizeY-1))<<(CtbLog2SizeY-1),((yCb+(mvL0[1]>>4))>>(CtbLog2SizeY-1))<<(CtbLog2SizeY-1)). In the example, the top-left corner of the collocated block region is used to check the map that tracks the image reconstruction process. If the position on the map is "false", in the example it indicates that the collocated block region has not been reconstructed, and therefore the reference block is available in reference sample memory and can be used to reconstruct the current block in intra-block copy mode. In that case the block vector is a valid block vector. However, if the position on the map is "true", it indicates that the collocated block region has been reconstructed or partially reconstructed, in which case the block vector mvL0 is not a valid block vector.
[0134] In the second embodiment, the second step is based on collocated blocks, and the process in the second embodiment is referred to as a block region-based update process. In the second embodiment, if a sample in any of the 64x64 block regions (collocated block regions) in the current CTU is reconfigured, the corresponding region in the reference sample memory to which the collocated sample (of the current sample) belongs is not available for intrablock copy referencing.
[0135] According to one aspect of this disclosure, the change in CTU size typically occurs as the width and / or height doubles or halves. For example, if the width and height are halved, a reference sample memory of one maximum CTU size can store samples equivalent to 4 CTUs.
[0136] In some embodiments, when the current CTU size CtbLog2SizeY of the Log2 domain is used, the number of CTUs that can store reference sample data in the reference sample memory buffer is variable, depending on the relationship between MaxCtbLog2SizeY and CtbLog2SizeY.
[0137] In the third embodiment, the CTU size is CtbLog2SizeY in the Log2 domain, and therefore the reconstructed sample stored in the reference sample memory consists of the current CTU, the furthest left CTU, and (multiple) intermediate left CTUs located between the current CTU and the furthest left CTU.
[0138] In the first stage, block mvL0 is checked to determine whether the block vector mvL0 points to a CTU-based search range that includes the current CTU, the furthest left CTU, and (multiple) intermediate left CTUs. In some embodiments, the constraints on block vector mvL0 are expressed by equations (6) to (9): (yCb+(mvL0[1]>>4))>>CtbLog2SizeY=yCb>>CtbLog2SizeY Formula (6) (yCb+(mvL0[1]>>4)+cbHeight-1)>>CtbLog2SizeY=yCb>>CtbLog2SizeY Equation (7) (xCb+(mvL0[0]>>4))>>CtbLog2SizeY>=(xCb>>CtbLog2SizeY)-1<<(2*(MaxCtbLog2SizeY-CtbLog2SizeY)) Equation (8) (xCb+(mvL0[0]>>4)+cbWidth-1)>>CtbLog2SizeY<=(xCb>>CtbLog2SizeY) Formula (9)
[0139] If equation (6) is satisfied, the top of the referenced block is in the same CTU row as the current block. If equation (7) is satisfied, the bottom of the referenced block is in the same CTU row as the current block. If equation (8) is satisfied, the left side of the referenced block is in the same CTU column as the current CTU, one of the (multiple) intermediate left CTUs, and the furthest left CTU. If equation (9) is satisfied, the right side of the referenced block is in the same CTU column as the current CTU, or one of the CTUs to the left of the current CTU (e.g., one of the (multiple) intermediate left CTUs, the furthest left CTU, etc.). Thus, in the embodiment, if equations (6) to (9) are satisfied, the referenced block is within the CTU-based search range.
[0140] If block vector mvL0 is a potential valid block vector, it is checked in a second stage to determine whether it is a valid block vector. For example, in the second stage, if the block vector points to a reference block in the middle left CTU, for example, if equation (10) is not satisfied, then the block vector is a valid block vector. In the second stage, if the reference block is in the furthest left CTU, for example, if equation (10) is satisfied, then block vector mvL0 is checked further to determine whether the collocated block of the reference block has been reconfigured. (xCb+(mvL[0]>>4))>>CtbLog2SizeY=(xCb>>CtbLog2SizeY)-(1<<(2*(MaxCtbLog2SizeY-CtbLog2SizeY))) Equation (10)
[0141] In the examples, Currently, the top-left corner of the block is at (xCb, yCb), the top-left corner of the reference block is at (xCb+(mvL[0]>>4), yCb+(mvL0[1]>>4)), and the top-left corner of the block collocated to the reference block is at (xCb+(mvL[0]>>4)+(1<<4^(MaxCtbLog2SizeY-CtbLog2SizeY)), yCb+(mvL0[1]>>4)). In one example, the top-left corner of the collocated block is used to check the map that tracks the image reconstruction process. If the position on the map is "false", in one example it indicates that the collocated block has not been reconstructed, and therefore the reference block is available in reference sample memory and can be used to reconstruct the current block in intra-block copy mode. In that case, the block vector is a valid block vector. However, if the position on the map is "true", one example indicates that at least a portion of the collocated blocks have been reconstructed, and therefore, samples of the collocated blocks are stored in the reference sample memory at the location of the reference block samples, and the reference block samples are not available in the reference sample memory. Therefore, the block vector mvL0 is not a valid block vector.
[0142] In the third embodiment, the second stage is based on colocated blocks, and the process in the third embodiment is referred to as a CU-based update process.
[0143] In the fourth embodiment, the second stage is based on block regions. For example, if the CTU size is CtbLog2SizeY in the Log2 domain and the block region size is CtbLog2SizeY-1 in the Log2 domain, the CTU can be divided into four block regions of the same size. Similarly, in the fourth embodiment, the reconstructed sample stored in the reference sample memory consists of the current CTU, the furthest left CTU, and the intermediate left CTU between the current CTU and the furthest left CTU.
[0144] In the first stage, the block vector mvL0 is checked to determine whether the block vector mvL0 is a potentially valid block vector that points to a CTU-based search range including the current CTU, the furthest left CTU, and (multiple) intermediate left CTUs between the current CTU and the furthest left CTU, so as to use equations (6) to (9) in a manner similar to the third embodiment.
[0145] If block vector mvL0 is a potential valid block vector, it is checked in a second stage to determine whether it is a valid block vector. For example, in the second stage, if the block vector points to a reference block in the middle left CTU, and equation (10) is not satisfied, then the block vector is a valid block vector. In the second stage, if the reference block is in the furthest left CTU, for example, if equation (10) is satisfied, then block vector mvL0 is checked to determine whether the block collocated with the reference block has been reconfigured.
[0146] In this example, the top-left corner of the current block is at (xCb, yCb), the top-left corner of the reference block is at (xCb+(mvL[0]>>4), yCb+(mvL0[1]>>4)), and the top-left corner of the collocated block region relative to the reference block is at (((xCb+(mvL[0]>>4)+(1<<4^(MaxCtbLog2SizeY-CtbLog2SizeY)))>>(CtbLog2SizeY-1))<<(CtbLog2SizeY-1),((yCb+(mvL0[1]>>4))>>(CtbLog2SizeY-1))<<(CtbLog2SizeY-1)). In this example, the top-left corner of the collocated block region is used to check the map that tracks the image reconstruction process. If the location on the map is "false," it indicates, in one example, that the collocated block region has not been reconfigured, and therefore the reference block is available in the reference sample memory and can be used to reconfigure the current block in intra-block copy mode. In that case, the block vector is a valid block vector. However, if the location on the map is "true," it indicates that the collocated block region has been reconfigured or partially reconfigured, and in that case, the block vector mvL0h is not a valid block vector.
[0147] In the fourth embodiment, the second step is based on colocated blocks, and the process in the fourth embodiment is referred to as a block region-based update process. In the fourth embodiment, if any sample of a colocated block region (relative to a reference block) is reconfigured within the current CTU, the corresponding region in the reference sample memory that stores the sample of the colocated block region is not available for intrablock copy reference.
[0148] According to some aspects of this disclosure, the leftmost CTU is intentionally excluded from the search area, and then the block vector mvL0 is restricted using a one-step restriction process to determine whether mvL0 is a valid block vector pointing to a reference block in intra-block copy mode and whether the reference block is fully stored in the reference sample memory.
[0149] In the fifth embodiment, as in the third embodiment, the CTU size is CtbLog2SizeY in the Log2 domain, and therefore the reconstructed sample stored in the reference sample memory is one of the current CTU, the furthest left CTU, and (multiple) intermediate left CTUs located between the current CTU and the furthest left CTU. In the fifth embodiment, block mvL0 is checked to determine whether the block vector mvL0 points to a search range that includes the current CTU, the furthest left CTU, and (multiple) intermediate left CTUs. Note that in the fifth embodiment, left CTUs are excluded from the search range. In some embodiments, the constraints on the block vector mvL0 are expressed by equations 11 to 14: (yCb+(mvL0[1]>>4))>>CtbLog2SizeY=yCb>>CtbLog2SizeY Formula (11) (yCb+(mvL0[1]>>4)+cbHeight-1)>>CtbLog2SizeY=yCb>>CtbLog2SizeY Formula (12) (xCb+(mvL0[0]>>4))>>CtbLog2SizeY>(xCb>>CtbLog2SizeY)-1<<(2*(MaxCtbLog2SizeY-CtbLog2SizeY)) Equation (13) (xCb+(mvL0[0]>>4)+cbWidth-1)>>CtbLog2SizeY>(xCb>>CtbLog2SizeY)-1<<(2*(MaxCtbLog2SizeY-CtbLog2SizeY)) Equation (14)
[0150] If equation (11) is satisfied, the top of the referenced block is in the same CTU row as the current block. If equation (12) is satisfied, the bottom of the referenced block is in the same CTU row as the current block. If equation (13) is satisfied, the left side of the referenced block is in the same CTU column as the current CTU and one of the (multiple) intermediate left CTUs. If equation (14) is satisfied, the right side of the referenced block is in the same CTU column as the current CTU and one of the (multiple) intermediate left CTUs. In that case, if equations 11 to 14 are satisfied in the embodiment, the reference block is within the search range and the block vector mvL0 is a valid block vector.
[0151] Figure 13 shows a flowchart illustrating the process (1300) according to one embodiment of the present disclosure. Process (1300) can be used to reconstruct blocks coded in intra-mode and thus generate a predicted block for the block being reconstructed. In various embodiments, process (1300) is performed by processing circuits such as processing circuits in terminal devices (310), (320), (330) and (340), processing circuits that perform the functions of a video encoder (403), processing circuits that perform the functions of a video decoder (410), processing circuits that perform the functions of a video decoder (510), and processing circuits that perform the functions of a video encoder (603). In some embodiments, process (1300) is implemented with software instructions and thus, when a processing circuit executes a software instruction, the processing circuit executes process (1300). The process begins at (S1301) and proceeds to (S1310).
[0152] In (S1310), the prediction information for the current block in the current CTU is decoded from the coded video bitstream. The prediction information represents the intra-block copy mode. The size of the current CTU is smaller than the maximum size corresponding to the storage capacity of the reference sample memory. In some embodiments, the reference sample memory has a faster access rate than the main memory for storing samples reconstructed from the coded video bitstream. For example, the reference sample memory is on-chip memory located on the same chip as the decoder circuit, while the main memory is off-chip memory located outside the chip containing the decoder circuit. Note that in some examples, the reference sample memory can be implemented using off-chip memory.
[0153] In (S1320), a block vector is determined. The block vector points to a reference block in the same image as the current block, the reference block is a reconstructed sample buffered in the reference sample memory. In some embodiments, the search region is defined to include CTUs having reconstructed samples buffered in the reference sample memory, such as the current CTU, the middle left CTU, and the farthest left CTU. The farthest left CTU has at least one reconstructed sample that is overwritten by the reconstructed sample of the current CTU in the reference sample memory.
[0154] In (S1330), the current block is reconstructed based on the reconfigured sample of the reference block read from the reference sample memory. For example, the reference sample memory is accessed to read the reconfigured sample of the reference block, and then the sample of the current block is reconstructed based on the reconfigured sample read from the reference sample memory. The process then proceeds to (S1399) and terminates.
[0155] The above techniques can be implemented as computer software using computer-readable instructions and can be physically stored in one or more computer-readable media. For example, Figure 14 shows a computer system (1400) suitable for carrying out a particular embodiment of the disclosed subject matter.
[0156] Computer software can be coded using any suitable machine code or computer language that may be subject to assembly, compilation, linking, or similar mechanisms, and can be executed directly or by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc., via execution, microcode execution, etc.
[0157] Instructions can be executed on various types of computers or their components, including, for example, personal computers, tablet computers, servers, smartphones, game devices, and the Internet of Things.
[0158] The components shown in Figure 18 for the computer system (1400) are illustrative in nature and are not intended to imply any limitations on the scope or functionality of computer software implementing embodiments of the present disclosure. Furthermore, the configuration of the components should not be construed as having any dependencies or requirements relating to any one or combination of the components shown in the exemplary embodiments of the computer system (1400).
[0159] The computer system (1400) may include certain human interface input devices. Such human interface input devices may respond to input from one or more human users, for example, via tactile input (e.g., keystrokes, swapping, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), or olfactory input (not shown). The human interface devices may also be used to capture certain media that are not necessarily directly related to conscious human input, such as audio (e.g., voices, music, ambient sounds), images (e.g., scanned images, photographic images obtained from still image cameras), or video (e.g., two-dimensional video, three-dimensional video including stereoscopic images).
[0160] Input human interface devices may include one or more of the following: keyboard (1401), mouse (1402), trackpad (1403), touchscreen (1410), data glove (not shown), joystick (1405), microphone (1806), scanner (1407), and camera (1408).
[0161] The computer system (1400) may also include certain human interface output devices. Such human interface output devices may stimulate the senses of one or more human users, for example, through tactile output, sound, light, and smell / taste. Such human interface output devices may be tactile output devices (e.g., touchscreens (1410), data gloves (not shown), or joysticks (1405) for tactile feedback), but may also be tactile feedback devices that do not function as input devices), audio output devices (e.g., speakers (1409), headphones (not shown)), visual output devices (e.g., screens (1410) including CRT screens, LCD screens, plasma screens, and OLED screens, each having or not having tactile feedback capabilities, some of which may enable two-dimensional visual output or three-dimensional or more output via means such as stereoscopic output such as virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and This may include a printer (not shown).
[0162] The computer system (1400) may also include human-accessible storage devices and media on which they are accessible, the media being, for example, optical media drives (1420) including CD / DVD ROM / RW media (1421), USB memory (1422), removable head drives or solid-state drives (1423), conventional magnetic media such as tape and floppy disks (not shown), and specialized ROM / ASIC / PLD-based devices such as security dongles.
[0163] Those skilled in the art should also understand that the term “computer-readable medium” as used in connection with the subject matter currently disclosed does not include a transmission medium, carrier wave, or other transient signal.
[0164] The computer system (1400) may also include interfaces to one or more communication networks. These networks may be, for example, wireless, wired, or optical. They may also be local, wide-area, metropolitan, vehicle, and industrial, real-time, latency-tolerant, etc. Examples of networks include cellular networks such as Ethernet, Wi-Fi, GSM, 3G, 4G, 5G, LTE, etc., cable TV, satellite TV, and terrestrial TV, and industrial and vehicle networks including CANBus. Certain networks generally require an external network interface adapter (e.g., a USB port on the computer system (1400)) connected to a specific general-purpose data port or peripheral bus (1449), while other networks are generally integrated into the core of the computer system (1400) by connecting to the system bus described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks, the computer system (1400) may communicate with other entities. Such communications can be unidirectional communications, receive-only communications (e.g., broadcast television communications), unidirectional transmit-only communications (e.g., CAN bus communications to specific CAN bus devices), or bidirectional communications to other computer systems using, for example, local or wide-area digital networks. Specific protocols and protocol stacks can be used for each of these networks and network interfaces, as described above.
[0165] The aforementioned human interface devices, human-accessible memory devices, and network interfaces can be connected to the core (1440) of the computer system (1400).
[0166] A core (1440) may include one or more central processing devices (CPUs) (1441), graphics processing devices (GPUs) (1442), specialized programmable processing devices in the form of field-programmable gate areas (FPGAs) (1443), hardware accelerators for specific tasks (1444), etc. These devices may be connected via a system bus (1448) along with read-only memory (ROM) (1445), random access memory (1446), internal mass storage devices such as internal non-user-accessible hard drives, SSDs, etc. (1447). In some computer systems, the system bus (1448) is accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices can be connected directly to the core's system bus (1448) or via a peripheral bus (1449). Peripheral bus architectures include PCI, USB, etc.
[0167] The CPU (1441), GPU (1442), FPGA (1443), and accelerator (1444) can be combined to execute specific instructions that constitute the aforementioned computer code. This computer code can be stored in ROM (1445) or RAM (1446). Transition data can also be stored in RAM (1446), while permanent data can be stored, for example, in an internal mass storage device (1447). By using cache memory that can be closely associated with one or more CPUs (1441), GPUs (1442), mass storage devices (1447), ROMs (1445), RAM (1446), etc., high-speed storage and retrieval to any of the memory devices can be enabled.
[0168] Computer-readable media may have computer code on them to perform various computer operations. The media and computer code may be specially designed, created for this disclosure, or they may be of a type that is well known and available to those with computer software technology skills.
[0169] As an example, but not limited to, a computer system having an architecture (1400), specifically a core (1440), can provide functionality as a result of a processor (including CPUs, GPUs, FPGAs, accelerators, etc.) that runs software embodied in one or more tangible computer-readable media. Such computer-readable media may be media related to user-accessible mass storage devices as described above, as well as specific storage devices of the core (1440) that are not transient, such as a core-internal mass storage device (1447) or ROM (1445). Software implementing various embodiments of this disclosure may be stored in such devices and executed by the core (1440). A computer-readable medium may include one or more memory devices or chips, depending on the specific needs. The software may cause a core (1440) and specifically a processor (including a CPU, GPU, FPGA, etc.) within it to execute a specific process or a specific part thereof as described herein, including defining data structures stored in RAM (1446) and modifying such data structures according to a process defined by the software. Additionally or alternatively, a computer system may provide functionality as a result of logic wired in or otherwise embodied within a circuit (e.g., an accelerator (1444)), which may operate in place of or with the software to execute a specific process or a specific part thereof as described herein. References to software include logic, and vice versa, as appropriate. References to a computer-readable medium may include a circuit (such as an integrated circuit (IC)) that stores software for execution, a circuit that embodies logic for execution, or both, where appropriate. This disclosure encompasses any appropriate combination of hardware and software.
[0170] Appendix A: Abbreviations JEM: Joint Exploration Model VVC: Versatile Video Coding BMS: Benchmark Set MV: Motion Vector HEVC: High-Efficiency Video Coding SEI: Additional Enhancement Information VUI: Video Usability Information GOP: Image Group TU: Conversion Unit PU: Prediction Unit CTU: Coding Tree Unit CTB: Coding Tree Block PB: Prediction Block HRD: Virtual Reference Decoder SNR: Signal-to-noise ratio CPU: Central Processing Unit GPU: Graphics Processing Unit CRT: cathode ray tube LCD: Liquid crystal display OLED: Organic Light-Emitting Diode CD: Compact Disc DVD: Digital Video Disc ROM: Read-only memory RAM: Random Access Memory ASIC: Application-Specific Integrated Circuit PLD: Programmable Logic Device LAN: Local Area Network GSM: Global System for Mobile Communications LTE: Long-Term Evolution CAN bus: Controller Area Network Bus USB: Universal Serial Bus PCI: Peripheral Component Interconnect FPGA: Field-Programmable Gate Area SSD: Solid State Drive IC: Integrated Circuit CU: Coding Unit
[0171] While this disclosure describes several exemplary embodiments, there are various modifications, substitutions, and equivalents that fall within the scope of the invention. Therefore, those skilled in the art will understand that they can implement the principles of the present invention and thus create numerous systems and methods that are not expressly shown or described herein but fall within its concept and scope.
Claims
1. A method performed by a processor for encoding the current block in the current coding tree unit (CTU) in an encoder, A step of determining predictive information for the current block in the current coding tree unit (CTU), wherein the predictive information represents an intra-block copy mode, the size of the current CTU is smaller than the size of the reference sample memory for storing the reconstructed samples, and the size of the reference sample memory is equal to the maximum allowed CTU size in terms of the number of samples, A step of determining a block vector that points to a reference block of the same image as the current block, wherein the reference block has reconstructed samples buffered in the reference sample memory. The steps include: reconstructing at least one sample of the current block based on the reconstructed sample of the reference block read from the reference sample memory; A method that includes this.
2. The method according to claim 1, wherein the size of the reference sample memory is N times the size of the current CTU, where N is an integer of 4 or more.
3. The method according to claim 1 or 2, wherein in the step of determining a block vector that points to a reference block of the same image as the current block, the reference block is in a predetermined search range, the predetermined search range is the range up to the (N-1)th CTU to the left of the current block.
4. Currently, the size of the CTU is 1 / 2 n When it doubles, N becomes 4 n The method according to claim 2 or 3, which doubles the amount.
5. The method according to any one of claims 2 to 4, wherein N is calculated from 4^(MaxCtbLog2SizeY - CtbLog2SizeY), where MaxCtbLog2SizeY is obtained as a base-2 logarithm of the maximum allowable CTU size, and CtbLog2SizeY is obtained as a base-2 logarithm of the current CTU size.
6. The steps include checking whether the top boundary of the reference block is within the same CTU column as the current CTU, The steps include checking whether the bottom boundary of the reference block is within the same CTU column, The steps include checking whether the left boundary of the reference block is to the right of the Nth CTU on the left, The step includes checking whether the right-hand boundary of the reference block is to the left of the current CTU, The method according to any one of claims 2 to 5.
7. The step of checking whether the reference block is at least partially located in the Nth leftmost CTU in the same CTU column as the current CTU, wherein the size of the reference sample memory is N times the size of the current CTU, where N is a positive number greater than 1, further comprising the step of checking The method according to claim 1.
8. The method further includes the step of checking whether the left boundary of the reference block lies within the Nth left CTU. The method according to claim 7.
9. The step further includes determining whether, if the reference block is at least partially located in the Nth leftmost CTU, the collocated blocks of the reference block have been at least partially reconfigured within the current CTU. The method according to claim 7.
10. The step further includes determining whether the upper left corner of the collocated block has been reconfigured. The method according to claim 9.
11. The step of invalidating the block vector pointing to the reference block if the collocated block in the current CTU has been reconfigured at least partially is further included. The method according to claim 9.
12. The steps of determining the reference block region of the leftmost Nth CTU, which includes the aforementioned reference block, and In the current CTU, the steps include determining whether the collocated block regions of the reference block region have been reconfigured at least partially. The step of invalidating the block vector pointing to the reference block if the collocated block region in the current CTU has been at least partially reconfigured, further comprising: The method according to claim 7.
13. The method according to any one of claims 1 to 12, wherein the samples stored in the reference sample memory include, if there are any blocks in the current CTU other than the current block that have not yet been reconfigured, samples of blocks in the CTU to the left of the current CTU that correspond to the blocks that have not yet been reconfigured.
14. A device for encoding video, The apparatus comprises a processing circuit configured to perform the method described in any one of claims 1 to 13 in order to obtain a reference sample used to calculate the residual of the current block in the current coding tree unit (CTU). Device.
15. A computer program for causing a computer to perform the method described in any one of claims 1 to 13.
16. A method performed by a processor for encoding the current block in the current coding tree unit (CTU) in an encoder, A step of determining predictive information for the current block in the current coding tree unit (CTU), wherein the predictive information represents an intra-block copy mode, the size of the current CTU is less than the size of the reference sample memory for storing the reconstructed samples, and the size of the reference sample memory is equal to the maximum allowable CTU size. A step of determining a block vector that points to a reference block of the same image as the current block, wherein the reference block has reconstructed samples buffered in the reference sample memory. The steps include: reconstructing at least one sample of the current block based on the reconstructed sample of the reference block read from the reference sample memory; A method that includes this.
17. A method performed by a processor for encoding the current block in the current coding tree unit (CTU) in an encoder and storing the encoded bitstream, A step of determining predictive information for the current block in the current coding tree unit (CTU), wherein the predictive information represents an intra-block copy mode, the size of the current CTU is smaller than the size of the reference sample memory for storing the reconstructed samples, and the size of the reference sample memory is equal to the maximum allowed CTU size in terms of the number of samples, A step of determining a block vector that points to a reference block of the same image as the current block, wherein the reference block has reconstructed samples buffered in the reference sample memory. The steps include: reconstructing at least one sample of the current block based on the reconstructed sample of the reference block read from the reference sample memory; A step of storing a bitstream generated based on a block encoded using the reconstructed at least one sample, and A method that includes this.
18. A method performed by a processor for encoding the current block in the current coding tree unit (CTU) in an encoder, A step of determining predictive information for the current block in the current coding tree unit (CTU), wherein the predictive information represents an intra-block copy mode, the size of the current CTU is less than the size of the reference sample memory for storing the reconstructed samples, and the size of the reference sample memory is equal to the maximum allowable CTU size. A step of determining a block vector that points to a reference block of the same image as the current block, wherein the reference block has reconstructed samples buffered in the reference sample memory. The steps include: reconstructing at least one sample of the current block based on the reconstructed sample of the reference block read from the reference sample memory; A step of storing a bitstream generated based on a block encoded using the reconstructed at least one sample, and A method that includes this.
Citation Information
Patent Citations
Intra-block copy-merge mode and padding for ibc reference regions not available
JP2018530249A
Method and apparatus for video coding
WO2020113156A1