Prediction method and device for intra block copy mode

Abstract

A prediction method and apparatus for an intra block copy mode are provided. A prediction method for an intra block copy mode may comprise: obtaining a first hash table for a current coding tree unit (CTU); executing hash matching of a current coding unit (CU) in the current CTU based on the first hash table; and determining a candidate block vector of the current CU based on the hash match.

Description

Technical Field

[0001] The present disclosure relates to video coding and compression, and more particularly to a prediction method and apparatus for an intra-block copy mode, an electronic device, a non-transitory computer-readable storage medium, and a computer program product. Background Art

[0002] Various electronic devices (e.g., digital televisions, laptop or desktop computers, tablet computers, digital cameras, digital recording devices, digital media players, video game consoles, smart phones, video teleconferencing devices, video streaming devices, etc.) support digital video. Electronic devices send and receive or otherwise transmit digital video data through a communication network, and / or store digital video data on a storage device. Due to the limited bandwidth capacity of the communication network and the limited storage resources of the storage device, before the video data is transmitted or stored, the video data can be compressed using a video codec according to one or more video codec standards. For example, video codec standards include general video codec (VVC), joint exploration test model (JEM), high efficiency video codec (HEVC / H.265), advanced video codec (AVC / H.264), moving picture expert group (MPEG) codec, etc. Video codecs generally use prediction methods (e.g., inter-frame prediction, intra-frame prediction, etc.) that utilize the inherent redundancy in video data. Video codecs are intended to compress video data into a form that uses a lower bit rate while avoiding or minimizing the degradation of video quality. Summary of the invention

[0003] Examples of the present disclosure provide a prediction method and apparatus for an intra block copy mode, an electronic device, a non-transitory computer-readable storage medium, and a computer program product.

[0004] According to a first aspect of the present disclosure, a prediction method for an intra-block copy mode is provided, comprising: obtaining a first hash table for a current coding tree unit CTU; performing hash matching of a current coding unit CU in the current CTU based on the first hash table; and determining a candidate block vector of the current CU based on the hash matching.

[0005] Optionally, when the current CTU is the first CTU in the current CTU row, performing hash matching of the current coding unit CU in the current CTU based on the first hash table includes: performing hash matching of the current CU in the first hash table.

[0006] Optionally, when the current CTU is not the first CTU in the current CTU row, hash matching of the current coding unit CU in the current CTU is performed based on the first hash table, including: obtaining a second hash table for the first CTU on the left side of the current CTU; and performing hash matching of the current CU in the first hash table and the second hash table.

[0007] Optionally, performing hash matching of the current CU in the first hash table and the second hash table includes: performing hash matching of the current CU in the first hash table; and after performing hash matching of the current CU in the first hash table, performing hash matching of the current CU in the second hash table.

[0008] Optionally, two empty hash tables are pre-allocated for the current CTU row, and when the current CTU is the first CTU or the second CTU in the current CTU row, a first hash table for the current coding tree unit CTU is obtained, including: calculating a hash value corresponding to each pixel position in the current CTU; and saving each pixel position and the corresponding hash value in the current CTU in an empty hash table to obtain the first hash table.

[0009] Optionally, two empty hash tables are pre-allocated for the current CTU row, and when the current CTU is the CTU after the second CTU in the current CTU row, the two hash tables have been filled based on each pixel and the corresponding hash value in the first CTU on the left and the second CTU on the left of the current CTU, respectively, wherein obtaining the first hash table for the current coding tree unit CTU includes: clearing the hash table for the second CTU on the left of the current CTU; calculating the hash value corresponding to each pixel position in the current CTU; and saving each pixel position and the corresponding hash value in the cleared hash table to obtain the first hash table.

[0010] According to a second aspect of the present disclosure, a prediction device for an intra-block copy mode is provided, comprising: a hash table construction module, configured to: obtain a first hash table for a current coding tree unit CTU; a block vector acquisition module, configured to: perform hash matching of a current coding unit CU in the current CTU based on the first hash table; and determine a candidate block vector of the current CU based on the hash matching.

[0011] Optionally, when the current CTU is the first CTU in the current CTU row, the block vector obtaining module is configured to perform hash matching of the current CU in the first hash table.

[0012] Optionally, when the current CTU is not the first CTU in the current CTU row, the hash table construction module is configured to obtain a second hash table for the first CTU on the left side of the current CTU; and the block vector acquisition module is configured to perform hash matching of the current CU in the first hash table and the second hash table.

[0013] Optionally, the block vector obtaining module is configured to: perform hash matching of the current CU in the first hash table; and after performing hash matching of the current CU in the first hash table, perform hash matching of the current CU in the second hash table.

[0014] Optionally, the hash table construction module is configured to: pre-allocate two empty hash tables for the current CTU row; when the current CTU is the first CTU or the second CTU in the current CTU row, calculate the hash value corresponding to each pixel position in the current CTU; save each pixel position and the corresponding hash value in the current CTU in an empty hash table to obtain the first hash table.

[0015] Optionally, the hash table construction module is configured to: pre-allocate two empty hash tables for the current CTU row; when the current CTU is the CTU after the second CTU in the current CTU row, the two hash tables have been filled based on the pixels and corresponding hash values ​​in the first CTU on the left and the second CTU on the left of the current CTU, respectively, and the hash table for the second CTU on the left of the current CTU is cleared; calculate the hash value corresponding to each pixel position in the current CTU; save each pixel position and the corresponding hash value in the current CTU in the cleared hash table to obtain the first hash table.

[0016] According to a third aspect of the present disclosure, an electronic device for video encoding and decoding is provided, comprising: one or more processors; and a memory, coupled to the one or more processors and configured to store instructions that can be executed by the one or more processors, wherein the one or more processors are configured to execute the method according to the present disclosure when executing the instructions.

[0017] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium for storing computer-executable instructions is provided, wherein the computer-executable instructions, when executed by one or more computer processors, cause the one or more computer processors to perform a method according to the present disclosure.

[0018] According to a fifth aspect of the present disclosure, a computer program product is provided, having instructions for storing a bit stream, wherein when the instructions are executed by one or more processors, the one or more processors cause the one or more processors to perform the method according to the present disclosure.

[0019] It is to be understood that both the foregoing general description and the following detailed description are examples only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate examples according to the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0021] Figure 1 is a block diagram illustrating an exemplary system for encoding and decoding video blocks according to some embodiments of the present disclosure.

[0022] Figure 2 is a block diagram illustrating an exemplary video encoder according to some embodiments of the present disclosure.

[0023] Figure 3 is a block diagram illustrating an exemplary video decoder according to some embodiments of the present disclosure.

[0024] Figure 4 A schematic diagram showing the IBC reference area in HEVC.

[0025] Figure 5 A schematic diagram showing the IBC reference area in the VVC.

[0026] Figure 6 is a flowchart of a prediction method for an IBC mode according to an embodiment of the present disclosure.

[0027] Figure 7 It is a schematic diagram of constructing a Hash table according to an embodiment of the present disclosure.

[0028] Figure 8 is a flowchart of a prediction method for an IBC mode according to another embodiment of the present disclosure.

[0029] Fig. 9 is a block diagram of a prediction device for an IBC mode according to an embodiment of the present disclosure.

[0030] Fig.10 is a diagram illustrating a computing environment coupled with a user interface according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0031] Reference will now be made in detail to specific embodiments, examples of which are shown in the accompanying drawings. In the following detailed description, a number of non-limiting specific details are set forth to aid in understanding the subject matter presented herein. However, various alternatives may be used without departing from the scope of the claims, and the subject matter may be practiced without these specific details. For example, the subject matter presented herein may be implemented on many types of electronic devices having digital video capabilities.

[0032] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the drawings are used to distinguish objects, but not to describe any specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those shown in the drawings or described in the present disclosure.

[0033] Figure 1 is a block diagram illustrating an exemplary system 10 for encoding and decoding video blocks in parallel according to some embodiments of the present disclosure. Figure 1 As shown in , system 10 includes a source device 12 that generates and encodes video data to be later decoded by a target device 14. Source device 12 and target device 14 may include any of a wide variety of electronic devices, including cloud servers, server computers, desktop or laptop computers, tablet computers, smart phones, set-top boxes, digital televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, etc. In some implementations, source device 12 and target device 14 are equipped with wireless communication capabilities.

[0034] In some implementations, target device 14 may receive the encoded video data to be decoded via link 16. Link 16 may include any type of communication medium or device capable of moving the encoded video data from source device 12 to target device 14.

[0035] In some other embodiments, the encoded video data may be sent from the output interface 22 to the storage device 32. The encoded video data in the storage device 32 may then be accessed by the target device 14 via the input interface 28.

[0036] like Figure 1 , source device 12 includes a video source 18, a video encoder 20, and an output interface 22. Video source 18 may include sources such as, or a combination of such sources: a video capture device (e.g., a camera), a video archive containing previously captured video, a video feed interface for receiving video from a video content provider, and / or a computer graphics system for generating computer graphics data as source video.

[0037] The captured, pre-captured, or computer-generated video may be encoded by video encoder 20. The encoded video data may be sent directly to target device 14 via output interface 22 of source device 12. The encoded video data may also (or alternatively) be stored on storage device 32 for later access by target device 14 or other devices for decoding and / or playback.

[0038] Target device 14 includes input interface 28, video decoder 30, and display device 34. Input interface 28 may include a receiver and / or a modem and receives encoded video data via link 16. The encoded video data transmitted via link 16 or provided on storage device 32 may include various syntax elements generated by video encoder 20 for use by video decoder 30 in decoding the video data. Such syntax elements may be included within the encoded video data sent over a communication medium, stored on a storage medium, or stored on a file server.

[0039] The video encoder 20 and the video decoder 30 can operate according to a proprietary standard or an industry standard (e.g., VVC, HEVC, Part 10 of MPEG-4, AVC) or an extension of such a standard. It should be understood that the present application is not limited to a specific video encoding / decoding standard and can be applied to other video encoding / decoding standards. It is generally believed that the video encoder 20 of the source device 12 can be configured to encode the video data according to any of these current standards or future standards. Similarly, it is also generally believed that the video decoder 30 of the target device 14 can be configured to decode the video data according to any of these current standards or future standards.

[0040] The video encoder 20 and the video decoder 30 may be implemented as any of a variety of suitable encoder and / or decoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic devices, software, hardware, firmware, or any combination thereof. When partially implemented in software, the electronic device may store instructions for the software in a suitable non-transitory computer-readable medium, and use one or more processors to execute the instructions in the hardware to perform the video encoding / decoding operations disclosed in the present disclosure. Each of the video encoder 20 and the video decoder 30 may be included in one or more encoders or decoders, and either of the encoders or decoders may be integrated as part of a combined encoder / decoder (CODEC) in the corresponding device.

[0041] Figure 2is a block diagram illustrating an exemplary video encoder 20 according to some embodiments described in the present application. The video encoder 20 can perform intra-frame prediction coding and inter-frame prediction coding on video blocks within a video frame. Intra-frame prediction coding relies on spatial prediction to reduce or remove spatial redundancy in video data within a given video frame or picture. Inter-frame prediction coding relies on temporal prediction to reduce or remove temporal redundancy in video data within adjacent video frames or pictures of a video sequence. It should be noted that in the field of video coding and decoding, the term "frame" can be used as a synonym for the term "image" or "picture".

[0042] like Figure 2 As shown in , the video encoder 20 includes a video data memory 40, a prediction processing unit 41, a decoded picture buffer (DPB) 64, an adder 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. The prediction processing unit 41 further includes a motion estimation unit 42, a motion compensation unit 44, a partition unit 45, an intra-frame prediction processing unit 46, and an intra-frame block copy (BC) unit 48. In some embodiments, the video encoder 20 also includes an inverse quantization unit 58, an inverse transform processing unit 60, and an adder 62 for video block reconstruction. A loop filter 63 such as a deblocking filter can be located between the adder 62 and the DPB 64 to filter the block boundary to remove the block effect from the reconstructed video. In addition to the deblocking filter, another loop filter (e.g., a sample adaptive offset (SAO) filter, a cross-component sample adaptive offset (CCSAO) filter, and / or an adaptive loop filter (ALF)) can also be used to filter the output of the adder 62. In some examples, the loop filter may be omitted, and the decoded video blocks may be provided directly by adder 62 to DPB 64. Video encoder 20 may take the form of a fixed or programmable hardware unit, or may be distributed among one or more of the illustrated fixed or programmable hardware units.

[0043] Video data memory 40 may store video data to be encoded by components of video encoder 20. Figure 1 Video source 18 is shown obtaining video data in video data memory 40. DPB 64 is a buffer that stores reference video data (eg, reference frames or pictures) for use by video encoder 20 in encoding the video data (eg, in intra or inter prediction coding modes).

[0044] like Figure 2As shown in , after receiving the video data, the partitioning unit 45 within the prediction processing unit 41 partitions the video data into video blocks. This partitioning may also include partitioning the video frame into strips, tiles (e.g., a set of video blocks), or other larger coding units (CUs) according to a predefined splitting structure associated with the video data, such as a quadtree (QT) structure. It should be noted that the terms "block" or "video block" used herein may be a portion of a frame or picture, in particular a rectangular (square or non-square) portion. With reference to, for example, HEVC and VVC, a block or video block may be or correspond to a coding tree unit (CTU), a CU, a prediction unit (PU), or a transform unit (TU) and / or may be or correspond to a corresponding block (e.g., a coding tree block (CTB), a coding block (CB), a prediction block (PB), or a transform block (TB)) and / or a sub-block.

[0045] The prediction processing unit 41 may select one of a plurality of feasible prediction coding modes for the current video block based on the error results (e.g., coding rate and distortion level), such as one of one or more inter-frame prediction coding modes in a plurality of intra-frame prediction coding modes. The prediction processing unit 41 may provide the resulting intra-frame prediction coding block or inter-frame prediction coding block to the adder 50 to generate a residual block, and to the adder 62 to reconstruct the coding block for subsequent use as part of a reference frame. The prediction processing unit 41 also provides syntax elements (e.g., motion vectors, intra-frame mode indicators, partition information, and other such syntax information) to the entropy coding unit 56.

[0046] To select an appropriate intra-prediction coding mode for the current video block, intra-prediction processing unit 46 within prediction processing unit 41 may perform intra-prediction coding of the current video block in relation to one or more neighboring blocks in the same frame as the current block to be encoded to provide spatial prediction. Motion estimation unit 42 and motion compensation unit 44 within prediction processing unit 41 may perform inter-prediction coding of the current video block in relation to one or more prediction blocks in one or more reference frames to provide temporal prediction. Video encoder 20 may perform multiple encoding passes, for example, to select an appropriate coding mode for each block of video data.

[0047] In some embodiments, motion estimation unit 42 determines an inter-prediction mode for a current video frame by generating a motion vector according to a predetermined pattern within a sequence of video frames, the motion vector indicating the displacement of a video block within the current video frame relative to a prediction block within a reference video frame. Motion estimation performed by motion estimation unit 42 is the process of generating a motion vector that estimates the motion of a video block. For example, a motion vector may indicate the displacement of a video block within a current video frame or picture relative to a prediction block within a reference frame associated with a current block being encoded within the current frame. The predetermined pattern may designate a video frame in a sequence as a P frame or a B frame. Intra BC unit 48 may determine a vector (e.g., a block vector) for intra BC coding in a manner similar to the motion vector determined by motion estimation unit 42 for inter prediction, or may utilize motion estimation unit 42 to determine a block vector.

[0048] Regardless of whether the prediction block is from the same frame according to intra-frame prediction or from a different frame according to inter-frame prediction, the video encoder 20 can form a residual video block by subtracting the pixel values ​​of the prediction block from the pixel values ​​of the current video block being encoded. The pixel difference values ​​forming the residual video block may include both luma component differences and chroma component differences.

[0049] Intra-prediction processing unit 46 may encode the current block using various intra-prediction modes, for example, during separate encoding passes, and intra-prediction processing unit 46 (or, in some examples, mode selection unit) may select an appropriate intra-prediction mode to use from the tested intra-prediction modes. Intra-prediction processing unit 46 may provide information indicating the intra-prediction mode selected for the block to entropy encoding unit 56. Entropy encoding unit 56 may encode the information indicating the selected intra-prediction mode into the bitstream.

[0050] After prediction processing unit 41 determines a prediction block for the current video block via inter-prediction or intra-prediction, adder 50 forms a residual video block by subtracting the prediction block from the current video block. The residual video data in the residual block may be included in one or more TUs and provided to transform processing unit 52. Transform processing unit 52 transforms the residual video data into residual transform coefficients using a transform (e.g., a discrete cosine transform (DCT) or a conceptually similar transform).

[0051] The transform processing unit 52 may send the resulting transform coefficients to a quantization unit 54. The quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization process may also reduce the bit depth associated with some or all of the coefficients. The degree of quantization may be modified by adjusting a quantization parameter. In some examples, the quantization unit 54 may then perform a scan on the matrix including the quantized transform coefficients. Alternatively, the entropy coding unit 56 may perform the scan.

[0052] After quantization, entropy coding unit 56 entropy encodes the quantized transform coefficients into a video bitstream using, for example, context adaptive variable length coding (CAVLC), context adaptive binary arithmetic coding (CABAC), syntax-based context adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or another entropy coding method or technique. The encoded bitstream may then be sent to a video bitstream such as a Figure 1 The video decoder 30 shown, or archived as Figure 1 The video frame may be stored in storage device 32 as shown for later transmission to or retrieval by video decoder 30. Entropy encoding unit 56 may also entropy encode motion vectors and other syntax elements for the current video frame being encoded.

[0053] Inverse quantization unit 58 and inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual video block in the pixel domain for use in generating reference blocks for predicting other video blocks. As noted above, motion compensation unit 44 may generate a motion compensated prediction block from one or more reference blocks of a frame stored in DPB 64. Motion compensation unit 44 may also apply one or more interpolation filters to the prediction block to calculate sub-integer pixel values ​​for use in motion estimation.

[0054] Adder 62 adds the reconstructed residual block to the motion compensated prediction block generated by motion compensation unit 44 to generate a reference block for storage in DPB 64. The reference block may then be used as a prediction block by intra BC unit 48, motion estimation unit 42, and motion compensation unit 44 to inter-predict another video block in a subsequent video frame.

[0055] Figure 3 1 is a block diagram showing an exemplary video decoder 30 according to some embodiments of the present application. The video decoder 30 includes a video data memory 79, an entropy decoding unit 80, a prediction processing unit 81, an inverse quantization unit 86, an inverse transform processing unit 88, an adder 90, and a DPB 92. The prediction processing unit 81 further includes a motion compensation unit 82, an intra-frame prediction unit 84, and an intra-frame BC unit 85. The video decoder 30 may perform the above-mentioned Figure 2 The encoding process is substantially the inverse of the decoding process described with respect to video encoder 20. For example, motion compensation unit 82 may generate prediction data based on motion vectors received from entropy decoding unit 80, and intra-prediction unit 84 may generate prediction data based on intra-prediction mode indicators received from entropy decoding unit 80.

[0056] Furthermore, in some examples, embodiments of the present disclosure may be dispersed in one or more of the units of the video decoder 30. For example, the intra BC unit 85 may perform embodiments of the present application alone or in combination with other units of the video decoder 30, such as the motion compensation unit 82, the intra prediction unit 84, and the entropy decoding unit 80. In some examples, the video decoder 30 may not include the intra BC unit 85, and the functions of the intra BC unit 85 may be performed by other components of the prediction processing unit 81, such as the motion compensation unit 82.

[0057] Video data memory 79 may store video data, such as an encoded video bitstream, to be decoded by other components of video decoder 30. Video data stored in video data memory 79 may be obtained, for example, from storage device 32, from a local video source (e.g., a camera), via wired or wireless network communication of video data, or by accessing a physical data storage medium (e.g., a flash drive or hard disk).

[0058] During the decoding process, the video decoder 30 receives an encoded video bitstream representing video blocks of an encoded video frame and associated syntax elements. The entropy decoding unit 80 of the video decoder 30 entropy decodes the bitstream to generate quantization coefficients, motion vectors or intra-frame prediction mode indicators, and other syntax elements. The entropy decoding unit 80 then forwards the motion vectors or intra-frame prediction mode indicators, and other syntax elements to the prediction processing unit 81.

[0059] When a video frame is encoded as an intra-prediction coded (I) frame or for intra-coded prediction blocks in other types of frames, the intra-prediction unit 84 of the prediction processing unit 81 can generate prediction data for a video block of the current video frame based on the intra-prediction mode transmitted by the signal and reference data from a previously decoded block of the current frame.

[0060] When the video frame is encoded as an inter-frame prediction coding (i.e., B or P) frame, the motion compensation unit 82 of the prediction processing unit 81 generates one or more prediction blocks for the video block of the current video frame based on the motion vector and other syntax elements received from the entropy decoding unit 80. Each of the prediction blocks can be generated from a reference frame in one of the reference frame lists. The video decoder 30 can construct the reference frame lists, i.e., List 0 and List 1, based on the reference frames stored in the DPB 92 using a default construction technique.

[0061] In some examples, when a video block is encoded according to the intra BC mode described herein, intra BC unit 85 of prediction processing unit 81 generates a prediction block for the current video block based on the block vector and other syntax elements received from entropy decoding unit 80. The prediction block may be within a reconstructed region of the same picture as the current video block as defined by video encoder 20.

[0062] Motion compensation unit 82 and / or intra BC unit 85 determine prediction information for a video block of the current video frame by parsing motion vectors and other syntax elements, and then use the prediction information to generate a prediction block for the current video block being decoded.

[0063] Motion compensation unit 82 may also perform interpolation using interpolation filters as used by video encoder 20 during encoding of the video blocks to calculate interpolated values ​​for sub-integer pixels of reference blocks. In this case, motion compensation unit 82 may determine the interpolation filters used by video encoder 20 based on the received syntax elements and use these interpolation filters to produce the prediction blocks.

[0064] Inverse quantization unit 86 inverse quantizes the quantized transform coefficients provided in the bitstream and entropy decoded by entropy decoding unit 80, using the same quantization parameters calculated by video encoder 20 for each video block in the video frame to determine the degree of quantization. Inverse transform processing unit 88 applies an inverse transform (e.g., an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process) to the transform coefficients to reconstruct the residual block in the pixel domain.

[0065] After the motion compensation unit 82 or the intra BC unit 85 generates a prediction block for the current video block based on the vector and other syntax elements, the adder 90 reconstructs the decoded video block for the current video block by adding the residual block from the inverse transform processing unit 88 to the corresponding prediction block generated by the motion compensation unit 82 and the intra BC unit 85. A loop filter 91 (e.g., a deblocking filter, an SAO filter, a CCSAO filter, and / or an ALF) may be located between the adder 90 and the DPB 92 to further process the decoded video block. In some examples, the loop filter 91 may be omitted, and the decoded video block may be provided directly to the DPB 92 by the adder 90. The decoded video blocks in a given frame are then stored in the DPB 92, which stores reference frames for subsequent motion compensation of the next video block. The DPB 92 or a memory device separate from the DPB 92 may also store the decoded video for later presentation on a display device (e.g., Figure 1 on a display device 34).

[0066] Intra Block Copy (IBC) is an extremely efficient video coding technology used in the Screen Content Coding (SCC) scenario. It allows a block in the current frame to use other encoded blocks in the same frame as a reference. The minimum offset is in positive pixels (no subpixel), called a block vector (BV). This technology first appeared in the screen content coding extension of H.265 / High Efficiency Video Coding (HEVC). The new generation of video coding standards-H.266 / Versatile Video Coding (VVC) has improved IBC to adapt to the Virtual Pipeline Data Units (VPDU) memory management mechanism introduced by VVC.

[0067] VPDU is a hardware memory unit, and its storage capacity is fixed to 64×64 pixels. For example, if the CTU size is 128×128, one VPDU can only store 1 / 4 of the pixels of the CTU, if the CTU size is 64×64, one VPDU can store the pixels of one CTU, and if the CTU size is 32×32, one VPDU can store the pixels of four CTUs. Generally, multiple VPDUs (e.g., at least 4) can be designed to store at least one 128×128 CTU, or four 64×64 pixels, or 16 32×32 pixels.

[0068] For IBC in HEVC, the current prediction unit (PU) can refer to most of the reconstructed area, and only considers restrictions such as slices, tiles, and wavefront parallel processing (WPP), such as Figure 4 shown.

[0069] Figure 4 A schematic diagram showing the IBC reference area in HEVC.

[0070] Reference Figure 4 ,The light red area is the current CTU, the blue area is the reference area, and the white area is the non-reference area.,Therefore, when IBC performs block matching search, it needs to search in a large capacity memory buffer, which results in low memory access efficiency.

[0071] For IBC in VVC, the current coding unit (CU) can only refer to the reconstructed pixels in the VPDU. VPDU is a basic unit of on-chip memory in VVC. Each VPDU is 64×64 pixels in size and is used to store the reconstructed pixels of the current CTU and its surrounding areas. Therefore, the search range of IBC is small, and memory access is only performed in the VPDU unit, which is very efficient.

[0072] Taking the most common Coding Tree Unit (CTU) in VVC as 128 as an example, the search range of IBC is as follows: Figure 5 shown.

[0073] Figure 5 A schematic diagram showing the IBC reference area in the VVC.

[0074] Reference Figure 5 , the thick border represents a CTU, and the thin border represents a VPDU. For different positions of the current CU in the same CTU, the reference area of ​​the current CU can be divided into the following Figure 5 The four situations are shown.

[0075] exist Figure 5 In the figure, the red block represents the CU currently being encoded (it also needs to occupy a VPDU). The blue block represents the encoded pixels that the CU being encoded can refer to, and these pixels can be obtained from the VPDU. The blue block with an × indicates that although it is located in the adjacent CTU of the current CTU, due to the limitation of the VPDU, it has been overwritten in the VPDU and written to the frame-level large-capacity memory. Therefore, the current CU cannot access the pixels in these blocks from the VPDU. Since accessing pixels in the frame-level large-capacity memory will result in low memory access efficiency, the VVC standard fixes IBC that the current CU cannot refer to these blue blocks with ×.

[0076] At present, the encoding end based on hash matching is usually implemented in a serial manner, calculating the hash value of each block pixel by pixel, and only one hash table is saved for the entire frame. Therefore, when performing hash matching of the current unit to be encoded, it is possible to match an unencoded unit, or it is possible to match an encoded unit but the encoded unit is not in the VPDU. In addition, since hash matching conflicts (such as similar hash values ​​of two dissimilar pixels) cannot be avoided, even if the encoded unit in the VPDU is matched, its similarity may be very poor, resulting in invalid BVs.

[0077] Usually, in order to reduce the encoding time overhead, the number of candidate BVs matched by the encoding end can be limited (for example, in VVC's reference software VTM, the limit is up to 5 candidates). In this way, invalid BVs may be added to the candidate BVs while valid BVs cannot be searched, which leads to a high probability of invalid candidate BVs, and thus low encoding efficiency. In addition, this whole frame serial block-by-block calculation of hash values ​​also has a high time overhead.

[0078] Since the VVC standard imposes stricter restrictions on the search range of IBC, this provides favorable conditions for the parallel implementation of the encoding end. Therefore, the present invention designs an IBC parallel search architecture based on hash matching, which is highly adapted to the common WPP parallel architecture. While improving the encoding speed, it also improves the accuracy of hash matching, thereby improving the encoding efficiency.

[0079] According to the embodiment of the present disclosure, the Hash table is constructed in units of CTU instead of the entire frame in series. This operation is completely consistent with the WPP parallelism. Therefore, the Hash matching of the present disclosure has high parallelism and is highly consistent with the existing coding framework. In addition, when performing Hash matching on each CU, only the Hash tables of the current CTU and the left CTU are selected for matching, reducing the probability of Hash matching conflicts and the existence of invalid BVs.

[0080] Figure 6 is a flowchart of a prediction method for an IBC mode according to an embodiment of the present disclosure.

[0081] Reference Figure 6 In step S101, a first hash table for a current coding tree unit CTU is obtained.

[0082] According to an embodiment of the present disclosure, two empty Hash tables may be pre-allocated to each CTU row for subsequent Hash table construction.

[0083] When the current CTU is the first CTU or the second CTU in the current CTU row, a hash value corresponding to each pixel position in the current CTU may be calculated, and each pixel position in the current CTU and the corresponding hash value may be saved in an empty hash table to obtain a first hash table.

[0084] In the case that the current CTU is the CTU after the second CTU in the current CTU row, the two hash tables have been filled based on the pixels and corresponding hash values ​​in the first CTU on the left and the second CTU on the left of the current CTU, respectively. When obtaining the hash table of the current CTU, the hash table for the second CTU on the left of the current CTU can be cleared, the hash values ​​corresponding to the pixel positions in the current CTU are calculated, and the pixel positions and corresponding hash values ​​in the current CTU are saved in the cleared hash tables to obtain the first hash table.

[0085] In step S102, hash matching of the current coding unit CU in the current CTU is performed based on the first hash table. In step S103, based on the hash matching, the candidate block vector of the current CU is determined. In the present disclosure, hash matching may also be referred to as hash search.

[0086] According to an embodiment of the present disclosure, in the case where the current CTU is the first CTU in the current CTU row, hash matching of the current CU may be performed only in the first hash table.

[0087] As an example, when constructing a hash table, two sets of data may be recorded in the hash table, one set of data including each hash value in the CTU and all corresponding positions thereof, and the other set of data including each position in the CTU and its corresponding hash value.

[0088] For example, suppose the hash value of position (x0,y0) in a CTU is v0, the hash value of position (x1,y1) is v1, the hash value of position (x2,y2) is v2, and the hash value of position (x3,y3) is v0. In this case, the hash value of position (x3,y3) is the same as (x0,y0). The two groups of data recorded in the hash table for this CTU are the first group of data [v0,<(x0,y0),(x3,y3)>], [v1,<(x1,y1)>], and [v2,<x2,y2> ]; and the second set of data [(x0,y0),v0], [(x1,y1),v1], [(x2,y2),v2], [(x3,y3),v0].

[0089] In the hash matching process, it is found that the corresponding hash value of the position (x3, y3) is v0 in the second set of data, and then it is matched in the first set of data, and it is found that v0 corresponds to two positions (x0, y0) and (x3, y3). After eliminating the current position (x3, y3), (x0, y0) will become a candidate, and its BV is equal to (x0-x3, y0-y3). The above examples are only exemplary, and the present disclosure is not limited thereto.

[0090] In the case that the current CTU is not the first CTU of the current CTU row, a second hash table for the first CTU on the left side of the current CTU may be obtained, and hash matching of the current CU may be performed in the first hash table and the second hash table.

[0091] As an example, hash matching of the current CU may be performed in a first hash table for the current CTU first, and after hash matching of the current CU is performed in the first hash table, hash matching of the current CU may be performed in a second hash table for the first CTU on the left.

[0092] According to an embodiment of the present disclosure, two hash tables (Hash tables) may be allocated for each CTU row, and a row-level variable curr may be maintained, which is initialized to 0. curr may indicate the hash table used by the current CTU. For example, hash table No. 0 and hash table No. 1 are allocated for each CTU row. When the value of curr is 0, it may indicate that the current CTU uses hash table No. 0. When the value of curr is 1, it may indicate that the current CTU uses hash table No. 1. A detailed description is given below using a CTU row as an example.

[0093] Figure 7 It is a schematic diagram of constructing a Hash table according to an embodiment of the present disclosure.

[0094] Reference Figure 7 For one CTU row, two Hash tables (HashMaps) may be allocated, such as Hash table No. 0 and Hash table No. 1.

[0095] When the first CTU begins to be encoded, the hash table of the first CTU is first constructed and saved in hash table No. 0, and curr is 0. During the encoding process of the first CTU, since there is no CTU on its left, hash matching is performed only in hash table No. 0 for the current CTU (i.e., the first CTU).

[0096] Assume that the hash value of position (x0,y0) in a CTU is v0, the hash value of position (x1,y1) is v1, the hash value of position (x2,y2) is v2, and the hash value of position (x3,y3) is v0. In this case, the hash value of position (x3,y3) is the same as (x0,y0). The two groups of data recorded in the hash table for this CTU are the first group of data [v0,<(x0,y0),(x3,y3)>], [v1,<(x1,y1)>], and [v2,<x2,y2> ]; and the second set of data [(x0,y0),v0], [(x1,y1),v1], [(x2,y2),v2], [(x3,y3),v0].

[0097] In the hash matching process, it is found that the corresponding hash value of the position (x3, y3) is v0 in the second set of data. Then, it is matched in the first set of data and it is found that v0 corresponds to two positions (x0, y0) and (x3, y3). After eliminating the current position (x3, y3), (x0, y0) will become a candidate, and its BV is equal to (x0-x3, y0-y3).

[0098] When the next CTU of the first CTU (i.e., the second CTU) is encoded, curr is updated to 1, and the hash table of the second CTU is constructed and saved in the first hash table. During the encoding of the second CTU, a hash match is first performed in the first hash table for the current CTU (i.e., the second CTU), and then a hash match is performed in the 0th hash table for the first CTU.

[0099] When encoding the third CTU, curr is updated to 0, and the content of Hash table No. 0 is cleared, and then the Hash table of the third CTU is constructed and saved in Hash table No. 0. During the encoding process of the third CTU, a Hash match is first performed in Hash table No. 0 for the current CTU (the third CTU), and then a Hash match is performed in Hash table No. 1 for the second CTU.

[0100] When encoding the 4th CTU, curr is updated to 1, and the content of Hash table No. 1 is cleared, and then the Hash table of the 4th CTU is constructed and saved in Hash table No. 1. During the encoding process of the 4th CTU, a Hash match is first performed in Hash table No. 1 for the current CTU (i.e., the 4th CTU), and then a Hash match is performed in Hash table No. 0 for the 3rd CTU.

[0101] When the 5th CTU is encoded, curr is updated to 0, and the content of Hash table No. 0 is cleared, and then the Hash table of the 5th CTU is constructed and saved in Hash table No. 0. During the encoding process of the 5th CTU, a Hash match is first performed in Hash table No. 0 for the current CTU (i.e., the 5th CTU), and then a Hash match is performed in Hash table No. 1 for the 4th CTU.

[0102] When the 6th CTU is encoded, curr is updated to 1, and the content of the No. 1 Hash table is cleared, and then the Hash table of the 6th CTU is constructed and saved in the No. 1 Hash table. When the 6th CTU is encoded, a Hash match is first performed in the No. 1 Hash table for the current CTU (i.e., the 6th CTU), and then a Hash match is performed in the No. 0 Hash table for the 5th CTU. And so on.

[0103] The following is a partial pseudo code for performing hash matching in accordance with the present disclosure.

[0104]

[0105] Figure 8 is a flowchart of a prediction method for an IBC mode according to another embodiment of the present disclosure.

[0106] Reference Figure 8 In step S201, two Hash tables are allocated for the current CTU row. For example, two Hash tables may be allocated for each CTU row, such as Hash table No. 0 and Hash table No. 1. At this time, the two Hash tables are empty, and each pixel position and corresponding Hash value in the CTU may be stored in the Hash table when a Hash table is subsequently constructed for each CTU.

[0107] In step S202, a first Hash table for the current CTU and a second Hash table for the first CTU on the left side of the current CTU are constructed based on two Hash tables.

[0108] In a CTU row, when performing hash matching on the current CU, the hash tables of the current CTU and the first CTU on the left may be selected for hash matching to reduce the probability of hash matching conflicts and the existence of invalid BVs.

[0109] The corresponding processing can be performed according to the position of the current CTU (such as whether there is a CTU on the left side of the current CTU). For example, when the current CTU is the first CTU in the CTU row, the hash table can be constructed only for the current CTU and saved in a previously allocated hash table. For another example, when the current CTU is the third CTU in the CTU row, since the pixel positions and corresponding hash values ​​in the first CTU and the second CTU have been stored in the allocated hash table, when constructing the hash table of the current CTU, the content in the hash table for the first CTU can be cleared, and then the pixel positions and corresponding hash values ​​in the current CTU can be stored in the cleared hash table. Please refer to the above for details. Figure 7The description is used to construct the first Hash table and the second Hash table.

[0110] In step S203, hash matching of the current CU in the current CTU is performed using the first Hash table and the second Hash table to obtain a candidate block vector of the current CU.

[0111] The parallel architecture design disclosed in this disclosure is consistent with WPP, improves the parallelism of building the Hash table, and saves time. In addition, since each CTU row saves the Hash table separately and only retains the Hash table of 2 CTUs, this method can greatly reduce the probability of Hash matching conflicts, save Hash table memory usage, and increase the probability of effective BV hits, thereby improving encoding compression performance.

[0112] Fig. 9 is a block diagram of a prediction device for an IBC mode according to an embodiment of the present disclosure.

[0113] Reference Fig. 9 , a prediction device 900 for an intra-frame block copy mode may include: a hash table construction module 901, configured to: obtain a first hash table for a current coding tree unit CTU; a block vector acquisition module 902, configured to: perform hash matching of a current coding unit CU in the current CTU based on the first hash table; and determine a candidate block vector of the current CU based on the hash matching.

[0114] Optionally, when the current CTU is the first CTU in the current CTU row, the block vector obtaining module 902 is configured to perform hash matching of the current CU in the first hash table.

[0115] Optionally, when the current CTU is not the first CTU in the current CTU row, the hash table construction module 901 is configured to obtain a second hash table for the first CTU on the left side of the current CTU; the block vector acquisition module 902 is configured to perform hash matching of the current CU in the first hash table and the second hash table.

[0116] Optionally, the block vector obtaining module 902 is configured to: perform hash matching of the current CU in the first hash table; and after performing hash matching of the current CU in the first hash table, perform hash matching of the current CU in the second hash table.

[0117] Optionally, the hash table construction module 901 is configured to: pre-allocate two empty hash tables for the current CTU row; when the current CTU is the first CTU or the second CTU in the current CTU row, calculate the hash value corresponding to each pixel position in the current CTU; save each pixel position and the corresponding hash value in the current CTU in an empty hash table to obtain the first hash table.

[0118] Optionally, the hash table construction module 901 is configured to: pre-allocate two empty hash tables for the current CTU row; when the current CTU is the CTU after the second CTU in the current CTU row, the two hash tables have been filled based on the pixels and corresponding hash values ​​in the first CTU on the left and the second CTU on the left of the current CTU, respectively, and the hash table for the second CTU on the left of the current CTU is cleared; calculate the hash value corresponding to each pixel position in the current CTU; save each pixel position and the corresponding hash value in the current CTU in the cleared hash table to obtain the first hash table.

[0119] The names and numbers of the modules included in the above-mentioned device 900 are only exemplary, and the modules may be adaptively reduced or increased.

[0120] According to an embodiment of the present disclosure, a prediction method for the IBC mode may include: obtaining a hash table for hash matching of a current coding unit CU; performing hash matching of the current CU based on the hash table; and determining a candidate block vector of the current CU based on the hash matching; wherein the hash table is constructed for a coding tree unit CTU, a virtual pipe data unit VPDU, or a coding unit of a preset size.

[0121] The above embodiment mainly describes the process of constructing a Hash table for CTU. Based on the concept of the present disclosure, a Hash table can also be constructed for VPDU or coding units of other sizes, thereby realizing parallel operation of Hash matching.

[0122] In addition, the above method can be implemented using an apparatus including one or more circuits, including an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a controller, a microcontroller, a microprocessor or other electronic components. The apparatus can use the circuit in combination with other hardware or software components to perform the above method. Each module, submodule, unit or subunit disclosed above can be implemented at least in part using one or more circuits.

[0123] Fig.10A computing environment 1610 is shown coupled to a user interface 1650. The computing environment 1610 may be part of a data processing server. The computing environment 1610 includes a processor 1620, a memory 1630, and an input / output (I / O) interface 1640.

[0124] The processor 1620 generally controls the overall operation of the computing environment 1610, such as operations associated with display, data acquisition, data communication, and image processing. The processor 1620 may include one or more processors for executing instructions to perform all or some of the steps in the above method. In addition, the processor 1620 may include one or more modules that facilitate the interaction between the processor 1620 and other components. The processor may be a central processing unit (CPU), a microprocessor, a single-chip microcomputer, a graphics processing unit (GPU), etc.

[0125] The memory 1630 is configured to store various types of data to support the operation of the computing environment 1610. The memory 1630 may include predetermined software 1632. Examples of such data include instructions for any application or method operating on the computing environment 1610, video data sets, image data, etc. The memory 1630 may be implemented by using any type of volatile or non-volatile memory device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk, or an optical disk.

[0126] I / O interface 1640 provides an interface between processor 1620 and peripheral interface modules (e.g., keyboard, click wheel, buttons, etc.). Buttons may include, but are not limited to, a home button, a start scan button, and a stop scan button. I / O interface 1640 may be coupled to an encoder and a decoder.

[0127] In an embodiment, a non-transitory computer-readable storage medium including, for example, a plurality of programs in a memory 1630 and / or storing a bit stream generated by the above encoding method or a bit stream to be decoded by the above decoding method is also provided, wherein the plurality of programs can be executed by a processor 1620 in a computing environment 1610 to perform the above method. In one example, the plurality of programs can be executed by a processor 1620 in a computing environment 1610 to (for example, from Figure 2The video encoder 20 in the computing environment 1610 receives a bit stream or data stream including encoded video information (e.g., video blocks representing encoded video frames, and / or one or more associated syntax elements, etc.), and can also be executed by the processor 1620 in the computing environment 1610 to perform the above-mentioned decoding method according to the received bit stream or data stream. In another example, the multiple programs can be executed by the processor 1620 in the computing environment 1610 to perform the above-mentioned encoding method to encode the video information (e.g., video blocks representing video frames, and / or one or more associated syntax elements, etc.) into a bit stream or data stream, and can also be executed by the processor 1620 in the computing environment 1610 to (e.g., to Figure 3 Alternatively, a non-transitory computer-readable storage medium may store the bit stream or data stream generated by the encoder (e.g., Figure 2 The video encoder 20 in FIG. 1 generates a video signal for a decoder (eg, Figure 3 A bitstream or data stream including encoded video information (e.g., video blocks representing encoded video frames, and / or associated one or more syntax elements, etc.) used by the video decoder 30 in the video decoder 30 when decoding video data. The non-transitory computer-readable storage medium can be, for example, a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0128] In an embodiment, a bit stream generated by the above encoding method or a bit stream to be decoded by the above decoding method is provided. In an embodiment, a bit stream including encoded video information generated by the above encoding method or encoded video information to be decoded by the above decoding method is provided.

[0129] In an embodiment, a computing device is also provided, which includes: one or more processors (e.g., processor 1620); and a non-transitory computer-readable storage medium or memory 1630 in which multiple programs that can be executed by the one or more processors are stored, wherein the one or more processors are configured to perform the above-mentioned method when executing the multiple programs.

[0130] In an embodiment, a computer program product having instructions for storing or transmitting a bitstream is also provided, wherein the bitstream includes the encoded video information generated by the above encoding method or the encoded video information to be decoded by the above decoding method. In an embodiment, a computer program product including, for example, a plurality of programs in a memory 1630 is also provided, wherein the plurality of programs can be executed by a processor 1620 in a computing environment 1610 for performing the above method. For example, the computer program product may include a non-transitory computer-readable storage medium.

[0131] In an embodiment, the computing environment 1610 may be implemented by one or more ASICs, DSPs, digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs, GPUs, controllers, microcontrollers, microprocessors, or other electronic components for performing the above methods.

[0132] In an embodiment, a method for storing a bit stream is also provided, comprising: storing the bit stream on a digital storage medium, wherein the bit stream comprises encoded video information generated by the above encoding method or encoded video information to be decoded by the above decoding method.

[0133] In an embodiment, a method for transmitting a bit stream generated by the above encoder is also provided. In an embodiment, a method for receiving a bit stream to be decoded by the above decoder is also provided.

[0134] The description of the present disclosure has been presented for purposes of illustration and is not intended to be exhaustive or limited to the present disclosure. Many modifications, variations, and alternative embodiments will be apparent to one of ordinary skill in the art having the benefit of the teachings presented in the foregoing description and the associated drawings.

[0135] Unless otherwise specifically stated, the order of steps of the method according to the present disclosure is intended to be illustrative only, and the steps of the method according to the present disclosure are not limited to the order specifically described above, but can be changed according to actual conditions. In addition, at least one of the steps of the method according to the present disclosure can be adjusted, combined or deleted according to actual needs.

[0136] The examples are chosen and described in order to explain the principles of the present disclosure and to enable other persons skilled in the art to understand the various embodiments of the present disclosure and to best utilize the basic principles and various embodiments with various modifications suitable for the specific use contemplated. Therefore, it will be understood that the scope of the present disclosure is not limited to the specific examples of the disclosed embodiments, and modifications and other embodiments are intended to be included within the scope of the present disclosure.

Claims

1. A prediction method for an intra block copy mode, comprising: Obtain a first hash table for a current coding tree unit CTU; Performing hash matching of a current coding unit CU in a current CTU based on the first hash table; and Based on the hash matching, a candidate block vector of the current CU is determined.

2. The method according to claim 1, wherein: In a case where the current CTU is the first CTU in the current CTU row, performing hash matching of a current coding unit CU in the current CTU based on the first hash table includes: A hash match of the current CU is performed in the first hash table.

3. The method according to claim 1, wherein: In a case where the current CTU is not the first CTU of the current CTU row, performing hash matching of the current coding unit CU in the current CTU based on the first hash table includes: Obtain a second hash table for the first CTU on the left side of the current CTU; and Hash matching of the current CU is performed in the first hash table and the second hash table.

4. The method according to claim 3, wherein: Performing hash matching of the current CU in the first hash table and the second hash table includes: Perform hash matching of the current CU in the first hash table; and After performing hash matching of the current CU in the first hash table, performing hash matching of the current CU in the second hash table.

5. The method according to claim 1, wherein: Pre-allocate two empty hash tables for the current CTU row, In a case where the current CTU is the first CTU or the second CTU in the current CTU row, obtaining a first hash table for the current coding tree unit CTU includes: Calculate the hash value corresponding to each pixel position in the current CTU; The pixel positions and corresponding hash values ​​in the current CTU are saved in an empty hash table to obtain the first hash table.

6. The method according to claim 1, wherein: Pre-allocate two empty hash tables for the current CTU row, In the case where the current CTU is a CTU following the second CTU in the current CTU row, the two hash tables are filled based on pixels and corresponding hash values ​​in the first CTU on the left and the second CTU on the left of the current CTU, respectively. Wherein, obtaining a first hash table for a current coding tree unit CTU includes: Clear the hash table for the second CTU to the left of the current CTU; Calculate the hash value corresponding to each pixel position in the current CTU; The pixel positions and corresponding hash values ​​in the current CTU are saved in the cleared hash table to obtain the first hash table.

7. A prediction device for an intra block copy mode, comprising: A hash table construction module is configured to: obtain a first hash table for a current coding tree unit CTU; The block vector obtaining module is configured to: perform hash matching of the current coding unit CU in the current CTU based on the first hash table; and determine a candidate block vector of the current CU based on the hash matching.

8. An electronic device for video encoding and decoding, comprising: one or more processors; as well as a memory coupled to the one or more processors and configured to store instructions executable by the one or more processors, Wherein, when executing the instructions, the one or more processors are configured to perform the method according to any one of claims 1-6.

9. A non-transitory computer-readable storage medium for storing computer-executable instructions, which when executed by one or more computer processors cause the one or more computer processors to perform the method according to any one of claims 1-6.

10. A computer program product having instructions for storing a bitstream, which instructions, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 6.

Images