Method and apparatus for intra block copy

Abstract

Methods, apparatus, and non-transitory computer-readable storage media for video decoding and encoding are provided. In one method for video coding, a decoder may one or more Intra Block Copy (IBC) control syntax elements that indicate whether an IBC mode is enabled at different granularities. In addition, the decoder may obtain one or more block vectors for the current block based on the IBC mode in response to determining that the IBC mode is enabled at the one or more granularities.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based upon and claims the benefit of priority of U.S. Provisional Application No. 63 / 403,699, filed on September 2, 2022, entitled “Method and Apparatus for Intra-Frame Block Copying,” the entire contents of which are incorporated by reference for all purposes. Technical Field

[0003] The present disclosure relates to video coding and compression, and in particular, but not limited to, methods and apparatus for improving intra-block copying methods in video encoding or decoding processes. Background Art

[0004] Digital video is supported by a variety of electronic devices, such as 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. Electronic devices send and receive digital video data across a communication network or otherwise transmit digital video data, and / or store digital video data on a storage device. Due to the limited bandwidth capacity of a communication network and the limited memory resources of a storage device, video coding can be used to compress video data according to one or more video coding standards before the video data is transmitted or stored. For example, video coding standards include general video coding (VVC), joint development test model (JEM), high efficiency video coding (HEVC / H.265), advanced video coding (AVC / H.264), moving picture expert group (MPEG) coding, etc. Video coding generally utilizes prediction methods (e.g., inter-frame prediction, intra-frame prediction, etc.), which utilize the redundancy inherent in video data. Video coding is intended to compress video data into a form using a lower bit rate while avoiding or minimizing the degradation of video quality. Summary of the invention

[0005] The present disclosure provides examples of techniques related to improving intra-block copying methods in video encoding or decoding processes.

[0006] According to a first aspect of the present disclosure, a method for video decoding is provided. In the method, a decoder may obtain one or more intra-block copy (IBC) control syntax elements indicating whether an IBC mode is enabled at different granularities. In addition, the decoder may obtain one or more block vectors of a current block based on the IBC mode in response to determining that the IBC mode is enabled at one or more granularities.

[0007] According to a second aspect of the present disclosure, a method for video encoding is provided. In the method, an encoder may determine one or more IBC control syntax elements indicating whether to enable an IBC mode at different granularities. In addition, the encoder may encode a current block into a bitstream based on the one or more IBC control syntax elements.

[0008] According to a third aspect of the present disclosure, a method for video decoding is provided. In the method, a decoder may obtain IBC control information based on local information associated with a current block, wherein the IBC control information indicates whether an IBC mode is enabled. In addition, the decoder may obtain one or more block vectors of the current block based on the IBC mode in response to determining that the IBC mode is enabled.

[0009] According to a fourth aspect of the present disclosure, a method for video encoding is provided. In the method, an encoder may obtain IBC control information based on local information associated with a current block, wherein the IBC control information indicates whether an IBC mode is enabled. In addition, the encoder may encode the current block into a bitstream based on the IBC control information.

[0010] According to a fifth aspect of the present disclosure, a method for video decoding is provided. In the method, a decoder may obtain a syntax element associated with an IBC mode, wherein the syntax element is context-adaptive binary arithmetic coding (CABAC) context coded. In addition, the decoder may determine a CABAC context window for each context model associated with the IBC mode based on a slice type or a frame type.

[0011] According to a sixth aspect of the present disclosure, a method for video encoding is provided. In the method, an encoder may determine a CABAC context window for each context model associated with an IBC mode based on a slice type or a frame type. In addition, the encoder may obtain a syntax element associated with the IBC mode, wherein the syntax element is CABAC context encoded. In addition, the encoder may transmit the syntax element to a bitstream using a signal.

[0012] According to a seventh aspect of the present disclosure, a device for video decoding is provided. The device may include one or more processors and a memory, the memory being coupled to the one or more processors and configured to store instructions executable by the one or more processors. In addition, when executing the instructions, the one or more processors are configured to perform the method according to the first aspect, the third aspect, or the fifth aspect.

[0013] According to an eighth aspect of the present disclosure, a device for video encoding is provided. The device may include one or more processors and a memory, the memory being coupled to the one or more processors and configured to store instructions executable by the one or more processors. In addition, when executing the instructions, the one or more processors are configured to perform the method according to the second aspect, the fourth aspect, or the sixth aspect.

[0014] According to the ninth aspect of the present disclosure, a non-temporary 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 the method according to the first aspect, the third aspect or the fifth aspect.

[0015] According to the tenth aspect of the present disclosure, a non-temporary 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 the method according to the second aspect, the fourth aspect or the sixth aspect.

[0016] According to an eleventh aspect of the present disclosure, a non-transitory computer-readable storage medium is provided for storing a bit stream to be decoded by the method according to the first aspect, the third aspect or the fifth aspect.

[0017] According to a twelfth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided for storing a bit stream generated by a method according to the second aspect, the fourth aspect or the sixth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] A more particular description of examples of the present disclosure will be presented by reference to specific examples shown in the accompanying drawings. Given that these drawings depict only some examples and are therefore not to be considered limiting in scope, the examples will be described and explained with additional specificity and detail through use of the accompanying drawings.

[0019] Figure 1A is a block diagram illustrating a system for encoding and decoding video blocks according to some examples of the present disclosure.

[0020] Figure 1B Some examples of the present disclosure are shown in FIG. Figure 1E 4. The quadtree data structure of the final result of the partitioning process of the CTU 400 depicted in FIG.

[0021] Figure 1C An encoded representation of a frame by first partitioning the frame into a set of CTUs according to some examples of the present disclosure is shown.

[0022] Figure 1DA CTU including one CTB of luma samples, two corresponding coding tree blocks of chroma samples, and syntax elements used to encode and decode the samples of the coding tree blocks according to some examples of the present disclosure is shown.

[0023] Figure 2A is a block diagram showing an exemplary video encoder according to some examples of the present disclosure

[0024] Figure 2B is a block diagram illustrating an exemplary video decoder according to some examples of the present disclosure.

[0025] Figure 3A is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0026] Figure 3B is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0027] Figure 3C is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0028] Figure 3D is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0029] Figure 3E is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0030] FIG. 4A to FIG. 4B Examples of 4-parameter affine models according to some examples of the present disclosure are shown.

[0031] Figure 5 An example of a 6-parameter affine model according to some examples of the present disclosure is shown.

[0032] Figure 6 Neighboring neighboring blocks for inheriting affine merge candidates according to some examples of the present disclosure are shown.

[0033] Figure 7 Neighboring neighboring blocks used to construct affine merge candidates according to some examples of the present disclosure are shown.

[0034] Figure 8 The current CTU processing order and its available reference samples in the current CTU and the left CTU according to some examples of the present disclosure are shown.

[0035] Fig. 9 Padding candidates for replacing zero vectors in an IBC list according to some examples of the present disclosure are shown.

[0036] Fig.10Reference regions for IBC when CTU(m,n) is encoded according to some examples of the present disclosure are shown.

[0037] Fig.11 IBC reference areas for camera-captured content are shown according to some examples of the present disclosure.

[0038] Figure 12A-12B Methods for dividing angle patterns according to some examples of the present disclosure are demonstrated.

[0039] Fig.13A Spatial neighboring blocks used by ATVMP according to some examples of the present disclosure are shown.

[0040] Fig. 13B An example of deriving a sub-CU motion field by applying a motion shift from spatial neighbors and scaling motion information from a corresponding co-located sub-CU according to some examples of the present disclosure is shown.

[0041] Fig.14 is a flowchart of decoding binary bits according to some examples of the present disclosure.

[0042] Fig.15 is a diagram illustrating a computing environment coupled to a user interface according to some examples of the present disclosure.

[0043] Fig.16 is a flowchart illustrating a method for video decoding according to some examples of the present disclosure.

[0044] Fig.17 is a diagram showing some examples according to the present disclosure. Fig.16 The method for video decoding shown in FIG. 1 corresponds to a flowchart of a method for video encoding.

[0045] Fig.18 is a flowchart illustrating a method for video decoding according to some examples of the present disclosure.

[0046] Fig.19 is a diagram showing some examples according to the present disclosure. Fig.18 The method for video decoding shown in FIG. 1 corresponds to a flowchart of a method for video encoding.

[0047] Fig. 20 is a flowchart illustrating a method for video decoding according to some examples of the present disclosure.

[0048] Fig.21 is a diagram showing some examples according to the present disclosure. Fig. 20 The method for video decoding shown in FIG. 1 corresponds to a flowchart of a method for video encoding. DETAILED DESCRIPTION

[0049] Reference will now be made in detail to specific embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous 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.

[0050] The terms used in this disclosure are used only for the purpose of describing specific embodiments and are not intended to limit the disclosure. The singular forms of "a / an", "said" and "the" in this disclosure and the appended claims are also intended to include plural forms, unless otherwise clearly indicated throughout the disclosure. It should also be understood that the term "and / or" used in this disclosure refers to and includes one or any or all possible combinations of the listed multiple related items.

[0051] References throughout this specification to "one embodiment," "an embodiment," "an example," "some embodiments," "some examples," or similar language mean that the particular features, structures, or characteristics being described are included in at least one embodiment or example. Unless explicitly stated otherwise, features, structures, elements, or characteristics described in conjunction with one or some embodiments are also applicable to other embodiments.

[0052] Throughout the disclosure, unless otherwise explicitly stated, the terms "first", "second", "third", etc. are used only as nomenclature for reference to related elements (e.g., devices, components, compositions, steps, etc.), without implying any spatial or temporal order. For example, "first device" and "second device" may refer to two separately formed devices, or two parts, components, or operating states of the same device, and may be named arbitrarily.

[0053] The terms "module", "sub-module", "circuit", "sub-circuit", "circuitry", "sub-circuitry", "unit", or "sub-unit" may include a memory (shared, dedicated, or group) that stores code or instructions that can be executed by one or more processors. A module may include one or more circuits with or without stored code or instructions. A module or circuit may include one or more components that are directly or indirectly connected. These components may or may not be physically attached to each other or positioned adjacent to each other.

[0054] As used herein, the terms "if" or "when..." may be understood to mean "at..." or "in response to...", depending on the context. These terms, if they appear in a claim, may not indicate that the associated limitation or feature is conditional or optional. For example, a method may include the following steps: i) when condition X exists or if condition X exists, perform function or action X', and ii) when condition Y exists or if condition Y exists, perform function or action Y'. The method may be implemented with the ability to perform function or action X' and the ability to perform function or action Y'. Therefore, functions X' and Y' may be performed at different times during multiple executions of the method.

[0055] A unit or module may be implemented purely by software, purely by hardware, or by a combination of hardware and software. In a pure software implementation, for example, a unit or module may include functionally related code blocks or software components linked together directly or indirectly to perform a specific function.

[0056] Figure 1A 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 1A As shown in , system 10 includes a source device 12 that generates and encodes video data to be later decoded by a destination device 14. Source device 12 and destination device 14 may include any of a wide variety of electronic devices, including 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 destination device 14 are equipped with wireless communication capabilities.

[0057] In some embodiments, the target device 14 may receive the encoded video data to be decoded via the link 16. The link 16 may include any type of communication medium or device capable of moving the encoded video data from the source device 12 to the target device 14. In one example, the link 16 may include a communication medium that enables the source device 12 to directly send the encoded video data to the target device 14 in real time. The encoded video data may be modulated according to a communication standard (e.g., a wireless communication protocol) and sent to the target device 14. The communication medium may include any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form a portion of a packet-based network (e.g., a local area network, a wide area network, or a global network such as the Internet). The communication medium may include a router, a switch, a base station, or any other device that may be beneficial to facilitate communication from the source device 12 to the target device 14.

[0058] In some other embodiments, the encoded video data may be sent from the output interface 22 to a 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. The storage device 32 may include any of a variety of distributed or local information access data storage media, such as a hard drive, a Blu-ray disc, a digital versatile disc (DVD), a compact disc read-only memory (CD-ROM), a flash memory, a volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. In another example, the storage device 32 may correspond to a file server or another intermediate storage device that may hold the encoded video data generated by the source device 12. The target device 14 may access the stored video data from the storage device 32 via streaming or downloading. The file server may be any type of computer capable of storing encoded video data and sending the encoded video data to the target device 14. Exemplary file servers include a network server (e.g., for a website), a file transfer protocol (FTP) server, a network attached storage (NAS) device, or a local information disk drive. Target device 14 may access the encoded video data through any standard data connection suitable for accessing encoded video data stored on a file server, including a wireless channel (e.g., a Wireless Fidelity (Wi-Fi) connection), a wired connection (e.g., a Digital Subscriber Line (DSL), a cable modem, etc.), or a combination of both wireless channels and wired connections. The transmission of the encoded video data from storage device 32 may be a streaming transmission, a download transmission, or a combination of both streaming and download transmissions.

[0059] like Figure 1A As shown in , source device 12 includes video source 18, video encoder 20 and 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. As an example, if video source 18 is a camera of a security monitoring system, source device 12 and target device 14 may form a camera phone or a video phone. However, the embodiments described in this application may be generally applicable to video encoding and decoding, and may be applied to wireless and / or wired applications.

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

[0061] 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.

[0062] In some implementations, the target device 14 may include a display device 34, which may be an integrated display device and an external display device configured to communicate with the target device 14. The display device 34 displays the decoded video data to a user and may include any of a variety of display devices, such as a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or another type of display device.

[0063] 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.

[0064] The video encoder 20 and the video decoder 30 can 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 can 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 can be included in one or more encoders or decoders, and any of the encoders or decoders can be integrated as part of a combined encoder / decoder (CODEC) in the corresponding device.

[0065] In some embodiments, at least a portion of the components of the source device 12 (e.g., the video source 18, the video encoder 20, or components included in the video encoder 20, and the output interface 22 as described below with reference to FIG. 1G ) and / or a component of the destination device 14 (e.g., the component described below with reference to FIG. 1G ) Figure 2BAt least a portion of the input interface 28, the video decoder 30 or a component included in the video decoder 30, and the display device 34 described herein may be operated in a cloud computing service network, which may provide software, platform and / or infrastructure, such as software as a service (SaaS), platform as a service (PaaS), or infrastructure as a service (IaaS). In some embodiments, one or more components of the source device 12 and / or the destination device 14 not included in the cloud computing service network may be set in one or more client devices, and the one or more client devices may communicate with a server computer in the cloud computing service network through a wireless communication network (e.g., a cellular communication network, a short-range wireless communication network, or a global navigation satellite system (GNSS) communication network) or a wired communication network (e.g., a local area network (LAN) communication network or a power line communication (PLC) network). In an embodiment, at least a portion of the operations described herein may be implemented as a cloud-based service provided by one or more server computers, which are implemented by at least a portion of the components of the source device 12 and / or at least a portion of the components of the destination device 14 in the cloud computing service network; and one or more other operations described herein may be implemented by one or more client devices. In some embodiments, the cloud computing service network may be a private cloud, a public cloud, or a hybrid cloud. Without departing from the scope of the present disclosure, terms such as "cloud", "cloud computing", "cloud-based", etc. may be used interchangeably as appropriate herein. It should be understood that the present disclosure is not limited to being implemented in the above-mentioned cloud computing service network. Instead, the present disclosure may also be implemented in any other type of computing environment currently known or developed in the future.

[0066] FIG. 3A to FIG. 3E is a schematic diagram illustrating multiple types of tree splitting modes according to some embodiments of the present disclosure. FIG. 3A to FIG. 3E Five split types are shown, including four-way split ( Figure 3A ), vertical binary segmentation ( Figure 3B ), horizontal binary segmentation ( Figure 3C ), vertical ternary segmentation ( Figure 3D ) and horizontal ternary segmentation ( Figure 3E ).

[0067] Figure 2Ais a block diagram illustrating another exemplary video encoder 20 according to some embodiments described in the present application. The video encoder 20 may perform intra-frame and inter-frame predictive coding and decoding of video blocks within a video frame. Intra-frame predictive coding and decoding relies on spatial prediction to reduce or remove spatial redundancy in video data within a given video frame or picture. Inter-frame predictive coding and decoding 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 the term "frame" may be used as a synonym for the term "image" or "picture" in the field of video coding and decoding.

[0068] like Figure 2A As shown in FIG. 1 , 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 segmentation 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. An in-loop filter 63 (e.g., a deblocking filter) may be located between the adder 62 and the DPB 64 to filter the block boundaries, thereby removing blockiness artifacts 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 in-loop filter (ALF)) may be used to filter the output of the adder 62. It should be noted that, for the CCSAO technology, the present application is not limited to the embodiments described herein, and alternatively, the present application may be applied to the case where an offset is selected for any one of the luminance component, the Cb chrominance component, and the Cr chrominance component according to any other of the luminance component, the Cb chrominance component, and the Cr chrominance component to modify the any one of the components based on the selected offset. In addition, it should be noted that the first component mentioned herein may be any one of the luminance component, the Cb chrominance component, and the Cr chrominance component, the second component mentioned herein may be any other of the luminance component, the Cb chrominance component, and the Cr chrominance component, and the third component mentioned herein may be the remaining one of the luminance component, the Cb chrominance component, and the Cr chrominance component. In some examples, the loop filter may be omitted, and the decoded video block may be provided directly to the DPB 64 by the adder 62. The video encoder 20 may take the form of a fixed or programmable hardware unit, or may be divided between one or more of the fixed or programmable hardware units shown.

[0069] Video data memory 40 may store video data to be encoded by components of video encoder 20. Figure 1A The video source 18 shown obtains video data in the video data memory 40. The DPB 64 is a buffer that stores reference video data (e.g., reference frames or pictures) for use by the video encoder 20 (e.g., in intra-frame or inter-frame prediction coding mode) when encoding the video data. The video data memory 40 and the DPB 64 can be formed by any of a variety of memory devices. In various examples, the video data memory 40 can be on-chip with other components of the video encoder 20, or off-chip relative to those components.

[0070] like Figure 2A As shown in , after receiving the video data, the segmentation unit 45 within the prediction processing unit 41 segments the video data into video blocks. This segmentation may also include segmenting 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 (e.g., a quadtree (QT) structure). A video frame is or can be viewed as a two-dimensional array or matrix of samples having sample values. The samples in the array may also be referred to as pixels or picture elements (pel). The number of samples in the horizontal and vertical directions (or axes) of the array or picture defines the size and / or resolution of the video frame. For example, a video frame may be divided into multiple video blocks by using QT segmentation. A video block is again or may be viewed as a two-dimensional array or matrix of samples having sample values, but its dimension is smaller than the dimension of a video frame. The number of samples in the horizontal and vertical directions (or axes) of a video block defines the size of the video block. The video block may be further partitioned into one or more block partitions or sub-blocks (which may again form blocks) by, for example, iteratively using QT partitioning, binary tree (BT) partitioning or ternary tree (TT) partitioning or any combination thereof. It should be noted that the term "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.

[0071] 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.

[0072] 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.

[0073] In some embodiments, the motion estimation unit 42 determines the inter-prediction mode for the current video frame by generating a motion vector according to a predetermined pattern within the 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 the motion estimation unit 42 is the process of generating a motion vector that estimates the motion for 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. The 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 the motion estimation unit 42 for inter prediction, or may utilize the motion estimation unit 42 to determine the block vector.

[0074] The prediction block for the video block may be or may correspond to a block or reference block of a reference frame that is considered to closely match the video block to be encoded in terms of pixel difference, which may be determined by the sum of absolute differences (SAD), the sum of squared differences (SSD), or other difference metrics. In some embodiments, the video encoder 20 may calculate values ​​for sub-integer pixel positions of the reference frame stored in the DPB 64. For example, the video encoder 20 may interpolate values ​​for quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference frame. Thus, the motion estimation unit 42 may perform a motion search relative to full pixel positions and fractional pixel positions and output a motion vector with fractional pixel accuracy.

[0075] Motion estimation unit 42 calculates a motion vector for a video block in an inter-prediction coded frame by comparing the position of the video block to the position of a prediction block of a reference frame selected from a first reference frame list (list 0) or a second reference frame list (list 1), each of which identifies one or more reference frames stored in DPB 64. Motion estimation unit 42 sends the calculated motion vector to motion compensation unit 44 and then to entropy encoding unit 56.

[0076] The motion compensation performed by the motion compensation unit 44 may involve obtaining or generating a prediction block based on the motion vector determined by the motion estimation unit 42. Upon receiving the motion vector for the current video block, the motion compensation unit 44 may locate the prediction block pointed to by the motion vector in one of the reference frame lists, retrieve the prediction block from the DPB 64, and forward the prediction block to the adder 50. The adder 50 then forms a residual video block of pixel difference values ​​by subtracting the pixel values ​​of the prediction block provided by the motion compensation unit 44 from the pixel values ​​of the current video block being encoded. The pixel difference values ​​forming the residual video block may include luminance component differences or chrominance component differences or both. The motion compensation unit 44 may also generate syntax elements associated with the video block of the video frame for use by the video decoder 30 when decoding the video block of the video frame. The syntax elements may include, for example, syntax elements defining motion vectors for identifying prediction blocks, any flags indicating prediction modes, or any other syntax information described herein. It should be noted that the motion estimation unit 42 and the motion compensation unit 44 may be highly integrated, but are described separately for conceptual purposes.

[0077] In some embodiments, the intra BC unit 48 may generate vectors and obtain prediction blocks in a manner similar to that described above in conjunction with the motion estimation unit 42 and the motion compensation unit 44, but these prediction blocks are in the same frame as the current block being encoded, and these vectors are referred to as block vectors rather than motion vectors. Specifically, the intra BC unit 48 may determine the intra prediction mode to be used to encode the current block. In some examples, the intra BC unit 48 may encode the current block using various intra prediction modes, for example, during separate encoding passes, and test their performance through rate-distortion analysis. Next, the intra BC unit 48 may select a suitable intra prediction mode to use among the various tested intra prediction modes and generate an intra mode indicator accordingly. For example, the intra BC unit 48 may calculate rate-distortion values ​​for the various tested intra prediction modes using rate-distortion analysis, and select an intra prediction mode with the best rate-distortion characteristic among the tested modes as a suitable intra prediction mode to use. The rate-distortion analysis generally determines the amount of distortion (or error) between a coded block and the original uncoded block that was encoded to produce the coded block, as well as the bit rate (i.e., the number of bits) used to produce the coded block. Intra BC unit 48 may calculate ratios based on the distortion and rate for the various coded blocks to determine which intra-prediction mode exhibits the best rate-distortion value for the block.

[0078] In other examples, intra BC unit 48 may use, in whole or in part, motion estimation unit 42 and motion compensation unit 44 to perform such functions for intra BC prediction in accordance with embodiments described herein. In either case, for intra block copying, the prediction block may be a block that is considered to closely match the block to be encoded in terms of pixel differences, which may be determined by SAD, SSD, or other difference metrics, and identifying the prediction block may include calculating values ​​for sub-integer pixel positions.

[0079] 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.

[0080] As an alternative to the inter-frame prediction performed by the motion estimation unit 42 and the motion compensation unit 44 or the intra-frame block copy prediction performed by the intra BC unit 48 as described above, the intra-frame prediction processing unit 46 can perform intra-frame prediction on the current video block. Specifically, the intra-frame prediction processing unit 46 can determine the intra-frame prediction mode for encoding the current block. To this end, the intra-frame prediction processing unit 46 can use various intra-frame prediction modes to encode the current block, for example, during separate encoding passes, and the intra-frame prediction processing unit 46 (or in some examples, the mode selection unit) can select a suitable intra-frame prediction mode from the tested intra-frame prediction modes to use. The intra-frame prediction processing unit 46 can provide information indicating the intra-frame prediction mode selected for the block to the entropy coding unit 56. The entropy coding unit 56 can encode the information indicating the selected intra-frame prediction mode into the bitstream.

[0081] 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).

[0082] 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.

[0083] 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 1A The video decoder 30 shown, or archived as Figure 1A 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.

[0084] 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.

[0085] 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.

[0086] Figure 2B 1 is a block diagram showing another 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 operations in combination with the above-mentioned operations. Figure 2A 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.

[0087] In some examples, units of the video decoder 30 may be tasked to perform embodiments of the present application. In addition, 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 (e.g., 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 (e.g., the motion compensation unit 82).

[0088] The video data memory 79 may store video data, such as an encoded video bitstream, to be decoded by other components of the video decoder 30. The video data stored in the video data memory 79 may be obtained, for example, from the storage device 32, from a local information video source (e.g., a camera), via a wired or wireless network communication of video data, or by accessing a physical data storage medium (e.g., a flash drive or hard drive). The video data memory 79 may include a coded picture buffer (CPB) that stores encoded video data from an encoded video bitstream. The DPB 92 of the video decoder 30 stores reference video data for use by the video decoder 30 (e.g., in intra-frame or inter-frame prediction coding mode) when decoding the video data. The video data memory 79 and the DPB 92 may be formed by any of a variety of memory devices, such as dynamic random access memory (DRAM) (including synchronous DRAM (SDRAM)), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. For illustrative purposes, the video data memory 79 and the DPB 92 are shown in FIG. Figure 2B 92 are depicted as two different components of the video decoder 30. However, it will be apparent to those skilled in the art that the video data memory 79 and the DPB 92 can be provided by the same memory device or separate memory devices. In some examples, the video data memory 79 can be on-chip with other components of the video decoder 30, or off-chip relative to those components.

[0089] 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 video decoder 30 may receive syntax elements at the video frame level and / or the video block level. 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.

[0090] 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.

[0091] When the video frame is encoded as an inter-frame prediction coded (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 within a reference frame list in the reference frame list. The video decoder 30 can construct the reference frame lists, i.e., List 0 and List 1, using a default construction technique based on the reference frames stored in the DPB 92.

[0092] In some examples, when the 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 reconstruction region of the same picture as the current video block as defined by video encoder 20.

[0093] The motion compensation unit 82 and / or the intra BC unit 85 determine prediction information for a video block of the current video frame by parsing the motion vector and other syntax elements, and then use the prediction information to generate a prediction block for the current video block being decoded. For example, the motion compensation unit 82 uses some of the received syntax elements to determine a prediction mode (e.g., intra prediction or inter prediction) for encoding a video block of a video frame, an inter prediction frame type (e.g., B or P), construction information for one or more of the reference frame lists for the frame, motion vectors for each inter prediction encoded video block of the frame, inter prediction states for each inter prediction encoded video block of the frame, and other information for decoding a video block in the current video frame.

[0094] Similarly, the intra BC unit 85 may use some of the received syntax elements, such as flags, to determine whether the current video block is predicted using intra BC mode, construction information of which video blocks of the frame are within the reconstruction region and should be stored in the DPB 92, block vectors for each intra BC predicted video block of the frame, intra BC prediction status for each intra BC predicted video block of the frame, and other information for decoding the video blocks in the current video frame.

[0095] 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 block.

[0096] 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.

[0097] 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 1A on a display device 34).

[0098] In a typical video encoding process, a video sequence usually includes an ordered set of frames or pictures. Each frame may include three sample arrays, denoted as SL, SCb, and SCr. SL is a two-dimensional array of luma samples. SCb is a two-dimensional array of Cb chroma samples. SCr is a two-dimensional array of Cr chroma samples. In other examples, a frame may be monochrome and therefore include only a two-dimensional array of luma samples.

[0099] like Figure 1C As shown in , the video encoder 20 (or more specifically, the segmentation unit of the pre-processing unit of the video encoder 20) generates an encoded representation of a frame by first segmenting the frame into a set of CTUs. A video frame may include an integer number of CTUs sequentially ordered from left to right and from top to bottom in a raster scan order. Each CTU is the largest logical coding unit, and the width and height of the CTU are signaled by the video encoder 20 in a sequence parameter set so that all CTUs in a video sequence have the same size, one of 128×128, 64×64, 32×32, and 16×16. It should be noted, however, that the present application is not necessarily limited to a particular size. As Figure 1DAs shown in , each CTU may include one CTB for luma samples, two corresponding coding tree blocks for chroma samples, and syntax elements for encoding the samples of the coding tree blocks. The syntax elements describe the properties of different types of units of coding pixel blocks and how the video sequence can be reconstructed at the video decoder 30, including inter-frame prediction or intra-frame prediction, intra-frame prediction mode, motion vectors, and other parameters. In a monochrome picture or a picture with three separate color planes, a CTU may include a single coding tree block and syntax elements for encoding the samples of the coding tree block. The coding tree block may be an N×N block of samples.

[0100] To achieve better performance, video encoder 20 may recursively perform tree partitioning, such as binary tree partitioning, ternary tree partitioning, quadtree partitioning, or a combination thereof, on a coding tree block of a CTU and divide the CTU into smaller CUs. Figure 1B-Figure 1E 2 is a diagram showing how a frame can be recursively partitioned into multiple video blocks of different sizes and shapes according to some embodiments of the present disclosure. Figure 1E As depicted in , a 64×64 CTU 400 is first divided into four smaller CUs, each CU having a block size of 32×32. Among the four smaller CUs, CU 410 and CU 420 are respectively divided into four CUs with a block size of 16×16. Two 16×16 CUs 430 and CU 440 are further divided into four CUs with a block size of 8×8. Figure 1B Depicted is a diagram showing Figure 1E The quadtree data structure of the final result of the partitioning process of the CTU 400 depicted in FIG. 4 corresponds to a CU of a corresponding size ranging from 32×32 to 8×8. Figure 1D Each CU may include a CB of luma samples and two corresponding coding blocks of chroma samples of the same size frame, and syntax elements for encoding the samples of the coding blocks. In a monochrome picture or a picture with three separate color planes, a CU may include a single coding block and syntax structures for encoding the samples of the coding block. It should be noted that Figure 1E and Figure 1B The quadtree partitioning depicted in FIG is for illustrative purposes only, and one CTU can be split into multiple CUs based on quadtree partitioning / ternary tree partitioning / binary tree partitioning to adapt to varying local characteristics. In a multi-type tree structure, one CTU is partitioned according to a quadtree structure, and each quadtree leaf CU can be further partitioned according to a binary and ternary tree structure. FIG. 3A to FIG. 3E As shown, there are five possible partitioning types for a coding block with width W and height H, namely, quadruple partitioning, horizontal binary partitioning, vertical binary partitioning, horizontal ternary partitioning, and vertical ternary partitioning.

[0101] In some embodiments, the video encoder 20 may further partition the coding block of the CU into one or more (M×N) PBs. A PB is a rectangular (square or non-square) sample block to which the same prediction (inter or intra) is applied. The PU of a CU may include a PB of luma samples, two corresponding PBs of chroma samples, and syntax elements for predicting the PBs. In a monochrome picture or a picture with three separate color planes, a PU may include a single PB and a syntax structure for predicting the PB. The video encoder 20 may generate a predicted luma block, a predicted Cb block, and a predicted Cr block for the luma PB, Cb PB, and Cr PB of each PU of the CU.

[0102] Video encoder 20 may use intra prediction or inter prediction to generate a prediction block for a PU. If video encoder 20 uses intra prediction to generate a prediction block for a PU, video encoder 20 may generate the prediction block for the PU based on decoded samples of a frame associated with the PU. If video encoder 20 uses inter prediction to generate a prediction block for a PU, video encoder 20 may generate the prediction block for the PU based on decoded samples of one or more frames other than the frame associated with the PU.

[0103] After the video encoder 20 generates the predicted luma block, the predicted Cb block, and the predicted Cr block for one or more PUs of a CU, the video encoder 20 may generate a luma residual block for the CU by subtracting the predicted luma block of the CU from the original luma coding block of the CU, so that each sample in the luma residual block of the CU indicates the difference between a luma sample in one of the predicted luma blocks of the CU and a corresponding sample in the original luma coding block of the CU. Similarly, the video encoder 20 may generate a Cb residual block and a Cr residual block for the CU, respectively, so that each sample in the Cb residual block of the CU indicates the difference between a Cb sample in one of the predicted Cb blocks of the CU and a corresponding sample in the original Cb coding block of the CU, and each sample in the Cr residual block of the CU may indicate the difference between a Cr sample in one of the predicted Cr blocks of the CU and a corresponding sample in the original Cr coding block of the CU.

[0104] In addition, if Figure 1EAs shown in , the video encoder 20 can use quadtree partitioning to decompose the luma residual block, Cb residual block and Cr residual block of the CU into one or more luma transform blocks, Cb transform blocks and Cr transform blocks, respectively. A transform block is a rectangular (square or non-square) sample block to which the same transform is applied. The TU of a CU may include a transform block of luma samples, two corresponding transform blocks of chroma samples, and syntax elements for transforming the transform block samples. Therefore, each TU of a CU may be associated with a luma transform block, a Cb transform block and a Cr transform block. In some examples, the luma transform block associated with the TU may be a sub-block of the luma residual block of the CU. The Cb transform block may be a sub-block of the Cb residual block of the CU. The Cr transform block may be a sub-block of the Cr residual block of the CU. In a monochrome picture or a picture with three separate color planes, a TU may include a single transform block and a syntax structure for transforming the samples of the transform block.

[0105] Video encoder 20 may apply one or more transforms to a luma transform block of a TU to generate a luma coefficient block of the TU. A coefficient block may be a two-dimensional array of transform coefficients. A transform coefficient may be a scalar. Video encoder 20 may apply one or more transforms to a Cb transform block of a TU to generate a Cb coefficient block of the TU. Video encoder 20 may apply one or more transforms to a Cr transform block of a TU to generate a Cr coefficient block of the TU.

[0106] The video encoder 20 may apply one or more transforms to the luma transform block of the TU to generate a luma coefficient block for the TU. The coefficient block may be a two-dimensional array of transform coefficients. The transform coefficient may be a scalar. The video encoder 20 may apply one or more transforms to the Cb transform block of the TU to generate a Cb coefficient block for the TU. The video encoder 20 may apply one or more transforms to the Cr transform block of the TU to generate a Cr coefficient block for the TU.

[0107] After generating a coefficient block (e.g., a luma coefficient block, a Cb coefficient block, or a Cr coefficient block), the video encoder 20 may quantize the coefficient block. Quantization generally refers to a process in which transform coefficients are quantized to potentially reduce the amount of data used to represent the transform coefficients, thereby providing further compression. After the video encoder 20 quantizes the coefficient block, the video encoder 20 may entropy encode syntax elements indicating the quantized transform coefficients. For example, the video encoder 20 may perform CABAC on the syntax elements indicating the quantized transform coefficients. Finally, the video encoder 20 may output a bitstream including a sequence of bits that form a representation of an encoded frame and associated data, and the bitstream is stored in the storage device 32 or sent to the target device 14.

[0108] After receiving the bitstream generated by the video encoder 20, the video decoder 30 can parse the bitstream to obtain syntax elements from the bitstream. The video decoder 30 can reconstruct the frame of the video data based at least in part on the syntax elements obtained from the bitstream. The process of reconstructing the video data is generally inverse to the encoding process performed by the video encoder 20. For example, the video decoder 30 can perform an inverse transform on the coefficient block associated with the TU of the current CU to reconstruct the residual block associated with the TU of the current CU. The video decoder 30 also reconstructs the coding block of the current CU by adding the samples of the prediction block for the PU of the current CU to the corresponding samples of the transform block of the TU of the current CU. After reconstructing the coding block for each CU of the frame, the video decoder 30 can reconstruct the frame.

[0109] As mentioned above, video coding mainly uses two modes, namely, intra-frame prediction (or intra-frame prediction) and inter-frame prediction (or inter-frame prediction) to achieve video compression. It should be noted that IBC can be regarded as intra-frame prediction or a third mode. Between the two modes, inter-frame prediction contributes more to coding efficiency than intra-frame prediction because motion vectors are used to predict the current video block based on the reference video block.

[0110] But with the ever-improving video data capture technology and finer video block sizes for retaining details in the video data, the amount of data required to represent the motion vector for the current frame has also increased significantly. One way to overcome this challenge benefits from the fact that not only a set of neighboring CUs in both the spatial and temporal domains have similar video data for prediction purposes, but also the motion vectors between these neighboring CUs are similar. Therefore, the motion information of spatially neighboring CUs and / or temporally co-located CUs can be used as an approximation of the motion information (e.g., motion vector) of the current CU (which is also called the "motion vector predictor" (MVP) of the current CU) by exploring their spatial and temporal correlations.

[0111] Instead of combining as above Figure 2A The actual motion vector of the current CU determined by the motion estimation unit is encoded into the video bitstream, and the motion vector predictor of the current CU is subtracted from the actual motion vector of the current CU to generate a motion vector difference (MVD) for the current CU. By doing so, the motion vector determined by the motion estimation unit for each CU of the frame does not need to be encoded into the video bitstream, and the amount of data used to represent the motion information in the video bitstream can be significantly reduced.

[0112] Similar to the process of selecting a prediction block in a reference frame during inter-frame prediction of a coding block, both the video encoder 20 and the video decoder 30 need to adopt a set of rules for constructing a motion vector candidate list (also called a "merge list") for the current CU using those potential candidate motion vectors associated with the spatial neighboring CUs and / or temporal co-located CUs of the current CU, and then selecting a member from the motion vector candidate list as the motion vector predictor for the current CU. By doing so, the motion vector candidate list itself does not need to be sent from the video encoder 20 to the video decoder 30, and the index of the selected motion vector predictor within the motion vector candidate list is sufficient for the video encoder 20 and the video decoder 30 to use the same motion vector predictor within the motion vector candidate list to encode and decode the current CU.

[0113] The present disclosure further enhances the intra block copy method by improving the coding efficiency and / or reducing its coding complexity.

[0114] Affine Model

[0115] In HEVC, only the translational motion model is applied to motion compensation prediction. In the real world, there are many kinds of motion, such as zooming in / out, rotation, perspective motion, and other irregular motions. In VVC, affine motion compensation prediction is applied by signaling a flag for each inter-frame coding block to indicate whether the translational motion model or the affine motion model is applied to the inter-frame prediction. In the current VVC, two affine modes including a 4-parameter affine mode and a 6-parameter affine mode are supported for one affine coding block.

[0116] The 4-parameter affine model has the following parameters: two parameters for translational movement in the horizontal and vertical directions respectively, one parameter for scaling movement, and one parameter for rotational movement in both directions. In this model, the horizontal scaling parameter is equal to the vertical scaling parameter, and the horizontal rotation parameter is equal to the vertical rotation parameter. In order to achieve a better adaptation of the motion vectors and affine parameters, those affine parameters are derived from two MVs located at the top left and top right corners of the current block, which are also called control point motion vectors (CPMVs). As FIG. 4A to FIG. 4B As shown in , the affine motion field of a block is described by two CPMVs (V0, V1). Based on the motion of the control points, an affine coded block motion field (v x ,v y ) is described as:

[0117]

[0118] The 6-parameter affine model has the following parameters: two parameters for horizontal and vertical translation, two parameters for horizontal scaling and rotation, and two parameters for vertical scaling and rotation. The 6-parameter affine motion model is encoded and decoded using three CPMVs. Figure 5 As shown in , the three control points of a 6-parameter affine block are located at the top left, top right, and bottom left corners of the block. The motion at the top left control point is associated with translational motion, and the motion at the top right control point is associated with rotation and scaling motion in the horizontal direction, and the motion at the bottom left control point is associated with rotation and scaling motion in the vertical direction. Compared with the 4-parameter affine motion model, the 6-parameter horizontal rotation and scaling motion can be different from the vertical rotation and scaling motion. Assume (V0, V1, V2) is Figure 5 The MVs of the upper left, upper right, and lower left corners of the current block in , using the three MVs at the control point, and the motion vector (v x ,v y ) is exported as:

[0119]

[0120] Affine merge mode

[0121] In affine merge mode, instead of explicitly signaling the CPMV for the current block, the CPMV for the current block is derived from neighboring blocks. Specifically, in this mode, the motion information of spatially neighboring blocks is used to generate the CPMV for the current block. The affine merge mode candidate list has a finite size. For example, in the current VVC design, there may be up to five candidates. The encoder may evaluate and select the best candidate index based on a rate-distortion optimization algorithm. The selected candidate index is then signaled to the decoder side. Affine merge candidates may be decided in three ways:

[0122] Inherited from neighboring affine encoding blocks

[0123] Constructed from translation MVs from neighboring blocks

[0124] Zero MV

[0125] For the inheritance method, there may be up to two candidates. From the neighboring block located at the lower left of the current block (e.g., Figure 6 As shown, the scanning order is to obtain candidates from A0 to A1), and if available, from the neighboring block located at the upper right of the current block (for example, Figure 6 As shown, the scanning order is from B0 to B2) to obtain candidates.

[0126] For the construction method, the candidate is a combination of the translated MVs of its neighbors, and the candidate can be generated in two steps.

[0127] • Step 1: Get four translation MVs from available neighbors.

[0128] oMV1: MV from one of the three neighboring blocks close to the upper left corner of the current block. Figure 7 As shown, the scanning order is B2, B3 and A2.

[0129] oMV2: MV from one of the two neighboring blocks close to the upper right corner of the current block. Figure 7 As shown, the scanning order is B1 and B0.

[0130] oMV3: MV from one of the two neighboring blocks close to the lower left corner of the current block. Figure 7 As shown, the scanning order is A1 and A0.

[0131] οMV4: The MV of the temporal co-located block from the neighboring block close to the lower right corner of the current block. As shown in the figure, the neighboring block is T.

[0132] • Step 2: Derive a combination based on the four translation MVs from step 1.

[0133] οCombination 1: MV1, MV2, MV3

[0134] ο Combination 2: MV1, MV2, MV4

[0135] ο Combination 3: MV1, MV3, MV4

[0136] ο Combination 4: MV2, MV3, MV4

[0137] ο Combination 5: MV1, MV2

[0138] ο Combination 6: MV1, MV3

[0139] When the merge candidate list is not full after populating with inherited candidates and constructed candidates, a zero MV is inserted at the end of the list.

[0140] Affine AMVP mode

[0141] Affine AMVP (Advanced Motion Vector Prediction) mode can be applied to CUs with width and height both greater than or equal to 16. An affine flag in the CU level is signaled in the bitstream to indicate whether the affine AMVP mode is used, and then another flag is signaled to indicate whether it is 4-parameter affine or 6-parameter affine. In this mode, the difference between the CPMV of the current CU and its predictor CPMVP is signaled in the bitstream. The affine AMVP candidate list size is 2 and the affine AMVP candidate list is generated by using the following four types of CPMV candidates in order:

[0142] – Inherited affine AMVP candidates extrapolated from the CPMV of neighboring CUs

[0143] – Constructed affine AMVP candidate CPMVP derived using the translation MV of the neighboring CU

[0144] –Translated MV from neighboring CU

[0145] – Time MV from the same CU

[0146] –Zero MV

[0147] The order of checking inherited affine AMVP candidates is the same as that of checking inherited affine merge candidates. The only difference is that for AMVP candidates, only affine CUs with the same reference picture as the current block are considered. No pruning is applied when inserting inherited affine motion predictors into the candidate list.

[0148] The constructed AMVP candidates are derived from the same spatial neighbors as the affine merge mode. The same check order as performed in the affine merge candidate construction is used. In addition, the reference picture index of the neighboring blocks is also checked. The first block in the check order is used, which is inter-coded and has the same reference picture as the current CU. When the current CU is encoded in 4-parameter affine mode and both mv0 and mv1 are available, mv0 and mv1 are added as a candidate in the affine AMVP candidate list. When the current CU is encoded in 6-parameter affine mode and all three CPMVs are available, it is added as a candidate in the affine AMVP candidate list. Otherwise, the constructed AMVP candidate is set to unavailable.

[0149] If the number of affine AMVP list candidates is still less than 2 after inserting valid inherited affine AMVP candidates and constructed AMVP candidates, mv0, mv1, and mv2 will be added in order as translation MVs to predict all control point MVs of the current CU (when available). Finally, if the affine AMVP list is still not full, the affine AMVP list is filled with zero MVs.

[0150] Intra-block copying in Versatile Video Coding (VVC)

[0151] Intra-block copying (IBC) is a tool adopted in the HEVC extension regarding SCC. As we all know, it significantly improves the encoding and decoding efficiency of screen content materials. Since the IBC mode is implemented as a block-level coding mode, block matching (BM) is performed at the encoder to find the optimal block vector (or motion vector) for each CU. Here, the block vector is used to indicate the displacement from the current block to the reference block that has been reconstructed in the current picture. The luminance block vector of the IBC-encoded CU is integer precision. The chrominance block vector is also rounded to integer precision. When combined with AMVR, the IBC mode can switch between 1 pixel and 4 pixel motion vector precision. The IBC-encoded CU is regarded as a third prediction mode in addition to the intra prediction mode or the inter prediction mode. The IBC mode is applicable to CUs with both width and height less than or equal to 64 luminance samples.

[0152] On the encoder side, hash-based motion estimation is performed for IBC. The encoder performs RD checks on blocks with a width or height no greater than 16 luma samples. For non-merge mode, a block vector search is first performed using a hash-based search. If the hash search does not return a valid candidate, a local search based on block matching is performed.

[0153] In hash-based search, the hash key matching (32-bit CRC) between the current block and the reference blocks is extended to all allowed block sizes. The hash key calculation for each position in the current image is based on 4×4 sub-blocks. For larger-sized current blocks, the hash key is determined to match the hash key of the reference block when all hash keys of all 4×4 sub-blocks match the hash keys in the corresponding reference positions. If the hash keys of multiple reference blocks are found to match the hash key of the current block, the block vector cost of each matching reference is calculated and the block vector cost with the minimum cost is selected.

[0154] In the block matching search, the search range is set to cover both the previous CTU and the current CTU.

[0155] At CU level, the IBC mode is signaled and it can be signaled as IBC AMVP mode or IBC Skip / Merge mode as follows:

[0156] IBC skip / merge mode: The merge candidate index is used to indicate which block vectors from the list of neighboring candidate IBC coded blocks are used to predict the current block. The merge list consists of spatial candidates, HMVP candidates, and pairwise candidates.

[0157] IBC AMVP mode: Block vector differences are encoded in the same way as motion vector differences. The block vector prediction method uses two candidates as predictors, one from the left neighbor and one from the top neighbor (if IBC encoded). When either neighbor is not available, the default block vector will be used as the predictor. A flag is signaled to indicate the block vector predictor index.

[0158] IBC Reference Area

[0159] In order to reduce memory consumption and decoder complexity, IBC in VVC only allows the reconstruction of predefined areas including the area of ​​the current CTU and some areas of the left CTU. Figure 8 Except for the reference area of ​​IBC mode, each block represents a 64×64 luma sample unit.

[0160] Depending on the location of the current coded CU position within the current CTU, the following applies:

[0161] If the current block falls into the upper left 64×64 block of the current CTU, in addition to the reconstructed samples in the current CTU, it can also use the CPR mode to refer to the reference samples in the lower right 64×64 block of the left CTU. The current block can also use the CPR mode to refer to the reference samples in the lower left 64×64 block of the left CTU and the reference samples in the upper right 64×64 block of the left CTU.

[0162] If the current block falls into the upper right 64×64 block of the current CTU, in addition to the samples that have been reconstructed in the current CTU, if the brightness position (0,64) relative to the current CTU has not been reconstructed, the current block can also use the CPR mode to refer to the reference samples in the lower left 64×64 block and the lower right 64×64 block of the left CTU; otherwise, the current block can also refer to the reference samples in the lower right 64×64 block of the left CTU.

[0163] If the current block falls into the lower left 64×64 block of the current CTU, in addition to the samples that have been reconstructed in the current CTU, if the luma position (64,0) relative to the current CTU has not been reconstructed, the current block can also use the CPR mode to refer to the reference samples in the upper right 64×64 block and the lower right 64×64 block of the left CTU. Otherwise, the current block can also use the CPR mode to refer to the reference samples in the lower right 64x64 block of the left CTU.

[0164] If the current block falls into the lower right 64×64 block of the current CTU, it can use the CPR mode to refer only to the already reconstructed samples in the current CTU.

[0165] This restriction allows the IBC mode to be implemented using local information on-chip memory for hardware implementation.

[0166] Interaction of IBC with other coding tools

[0167] The interaction between IBC mode and other inter-coding tools in VVC, such as pairwise merge candidates, history-based motion vector predictor (HMVP), combined intra / inter prediction mode (CIIP), merge mode with motion vector difference (MMVD), and geometric partitioning mode (GPM), is as follows:

[0168] – IBC can be used with pairwise merge candidates and HMVP. A new pairwise IBC merge candidate can be generated by averaging two IBC merge candidates. For HMVP, IBC motion is inserted into the history buffer for future reference.

[0169] – IBC cannot be used in combination with the following interframe tools: Affine Motion, CIIP, MMVD, and GPM.

[0170] – When DUAL_TREE partitioning is used, IBC is not allowed for chroma coded blocks.

[0171] Unlike the HEVC screen content coding extension, the current picture is no longer included as one of the reference pictures in the reference picture list 0 for IBC prediction. The derivation process of motion vectors for IBC mode excludes all neighboring blocks in inter mode, and vice versa. The following IBC design aspects apply:

[0172] – IBC shares the same process as in regular MV merging including pairwise merging candidates and history-based motion predictors, but TMVP and zero vectors are not allowed since they are invalid for IBC mode.

[0173] – Separate HMVP buffers (5 candidates each) for regular MV and IBC.

[0174] – Block vector constraints are implemented in the form of bitstream consistency constraints, the encoder needs to ensure that there are no invalid vectors in the bitstream, and if the merge candidate is invalid (out of range or zero), then the merge should not be used. This bitstream consistency constraint is expressed in terms of a virtual buffer as described below.

[0175] – For deblocking, IBC is treated as inter mode.

[0176] – If the current block is encoded using IBC prediction mode, AMVR does not use quarter pixels; instead,

[0177] AMVR is signaled to indicate only whether the MV is inter-pixel or 4-integer-pixel.

[0178] - The number of IBC merge candidates may be signaled in the slice header separately from the number of regular merge candidates, sub-block merge candidates, and geometric merge candidates.

[0179] The virtual buffer concept is used to describe the allowable reference area and valid block vectors for the IBC prediction mode. Denoting the CTU size as ctbSize, the virtual buffer ibcBuf has a width of wIbcBuf=128×128 / ctbSize and a height of hIbcBuf=ctbSize. For example, for a CTU size of 128×128, the size of ibcBuf is also 128×128; for a CTU size of 64×64, the size of ibcBuf is 256×64; for a CTU size of 32×32, the size of ibcBuf is 512×32.

[0180] The size of the VPDU is min(ctbSize, 64) in each dimension, Wv = min(ctbSize, 64).

[0181] The virtual IBC buffer ibcBuf is maintained as follows.

[0182] – At the start of decoding each CTU line, flush the entire ibcBuf with an invalid value of -1.

[0183] – At the start of decoding the VPDU (xVPDU, yVPDU) relative to the upper left corner of the picture, set ibcBuf[x][y] = -1, where x = xVPDU% wIbcBuf, ..., xVPDU% wIbcBuf + wV-1; y = yVPDU% ctbSize, ..., yVPDU% ctbSize + WV-1.

[0184] - After decoding the CU containing (x, y) relative to the top left corner of the picture, set ibcBuf[x% wIbcBuf][y% ctbSize] = recSample[x][y].

[0185] For a block covering coordinates (x,y), it is valid if the following is true for the block vector bv = (bv[0], bv[1]); otherwise, it is invalid:

[0186] ibcBuf[(x+bv[0])%wIbcBuf][(y+bv[1])%ctbSize] should not be equal to -1.

[0187] Intra-frame block copying in Enhanced Compression Model (ECM)

[0188] In ECM, IBC is improved in the following aspects.

[0189] IBC merger / AMVP list construction

[0190] IBC merge / AMVP list construction is modified as follows:

[0191] • Only if the IBC merge / AMVP candidate is valid, it can be inserted into the IBC merge / AMVP candidate list.

[0192] • Top-right, bottom-left, and top-left spatial candidates and a pair-wise average candidate may be added to the IBC merge / AMVP candidate list.

[0193] Adaptive reordering based on template (ARMC-TM) is applied to the IBC merge list.

[0194] The HMVP table size for IBC is increased to 25. Up to 20 IBC merge candidates are re-ranked together after being derived using full pruning. After re-ranking, the top 6 candidates with the lowest template matching cost are selected as the final candidates in the IBC merge list.

[0195] The candidates for zero vectors used to populate the IBC merge / AMVP list are replaced with a set of BVP candidates located in the IBC reference region. The zero vector is invalid as a block vector in IBC merge mode, and therefore, it is discarded as a BVP in the IBC candidate list.

[0196] Three candidates are located at the nearest corners of the reference region, and three additional candidates are determined in the middle of the three sub-regions (A, B, and C), whose coordinates are determined by the width and height of the current block and the ΔX and ΔY parameters, as Fig. 9 shown.

[0197] IBC with Template Matching

[0198] Template matching is used in IBC for both IBC Merge mode and IBC AMVP mode.

[0199] Compared to the IBC-TM merge list used by the conventional IBC merge mode, the IBC-TM merge list is modified so that candidates are selected according to a pruning method with motion distances between candidates as in the conventional TM merge mode. The ending zero motion implementation is replaced by motion vectors of the left (-W, 0), top (0, -H), and top-left (-W, -H), where W is the width of the current CU and H is the height of the current CU.

[0200] In IBC-TM merge mode, the selected candidates are refined with template matching method before RDO or decoding process.IBC-TM merge mode has been made competitive with regular IBC merge mode and TM merge flag is signaled.

[0201] In IBC-TM AMVP mode, up to 3 candidates are selected from the IBC-TM merge list. Each of those 3 selected candidates is refined using a template matching method and ranked according to their resulting template matching cost. Only the first 2 are then typically considered in the motion estimation process.

[0202] Template matching refinement for both IBC-TM merge and AMVP modes is straightforward because IBC motion vectors are constrained to be (i) integers and (ii) within the reference region, e.g. Figure 8 . Therefore, in IBC-TM merge mode, all refinements are performed with integer precision, and in IBC-TM AMVP mode, refinements are performed with integer or 4-pixel precision depending on the AMVR value. Such refinements only access samples without interpolation. In both cases, the refined motion vectors and the template used in each refinement step must respect the constraints of the reference region.

[0203] IBC Reference Area

[0204] The reference area for IBC extends to the upper two CTU rows. Fig.10 The reference region for encoding CTU(m,n) is shown. Specifically, for the CTU(m,n) to be encoded, the reference region includes CTUs with indices (m-2,n-2)...(W,n-2),(0,n-1)...(W,n-1),(0,n)...(m,n), where W represents the maximum horizontal index within the current tile, slice or picture. This setting ensures that for CTUs of size 128, IBC does not require additional memory in the current ETM platform. The per-sample block vector search (or local search) range is limited horizontally to [-(C<<1),C>>2] and vertically to [-C,C>>2] to accommodate the reference region extension, where C represents the CTU size.

[0205] IBC merge mode with block vector difference

[0206] The IBC merge mode with block vector difference is adopted in ECM. The distance set is {1 pixel, 2 pixels, 4 pixels, 8 pixels, 12 pixels, 16 pixels, 24 pixels, 32 pixels, 40 pixels, 48 ​​pixels, 56 pixels, 64 pixels, 72 pixels, 80 pixels, 88 pixels, 96 pixels, 104 pixels, 112 pixels, 120 pixels, 128 pixels}, and the BVD directions are two horizontal directions and two vertical directions.

[0207] The base candidate is selected from the first five candidates in the reordered IBC merge list. And all possible MBVD refinement positions (20×4) for each base candidate are reordered based on the SAD cost between the template (one row above the current block and one column to the left) and its reference for each refinement position. Finally, the first 8 refinement positions with the lowest template SAD cost are kept as available positions for MBVD index encoding.

[0208] IBC adaption to what the camera captures

[0209] When adapting IBC to the content captured by the camera, the IBC reference range is reduced from 2 CTU rows to 2×128 rows, e.g. Fig.11 As shown in . On the encoder side, in order to reduce complexity, the local search range is set to horizontal [-8, 8] and vertical [-8, 8] centered on the first block vector predictor of the current CU. This encoder modification is not applicable to SCC sequences. Sub-block based Temporal Motion Vector Prediction (SbTMVP)

[0210] VVC supports a sub-block based temporal motion vector prediction (SbTMVP) method. Similar to the temporal motion vector prediction (TMVP) in HEVC, SbTMVP uses the motion field in the co-located picture to improve the motion vector prediction and merge mode of the CU in the current picture. The same co-located pictures used by TMVP are used for SbTVMP. SbTMVP differs from TMVP in the following two main aspects:

[0211] – TMVP predicts motion at CU level, but SbTMVP predicts motion at sub-CU level;

[0212] –While TMVP extracts temporal motion vectors from co-located blocks in co-located pictures (co-located blocks are the bottom-right or center blocks relative to the current CU), SbTMVP applies motion shifting before extracting temporal motion information from co-located pictures, where the motion shifting is obtained from the motion vector from one of the spatially neighboring blocks of the current CU.

[0213] The SbTVMP process Figure 13A-13B SbTMVP predicts the motion vector of a sub-CU within the current CU in two steps. In the first step, check Fig.13A If A1 has a motion vector that uses the co-located picture as its reference picture, then this motion vector is selected as the motion shift to be applied. If no such motion is identified, the motion shift is set to (0,0).

[0214] In the second step, the motion shift identified in step 1 is applied (i.e., added to the coordinates of the current block) to obtain sub-CU level motion information (motion vectors and reference indices) from the co-located picture, as Fig. 13B shown. Fig. 13B The example in assumes that the motion shift is set to the motion of block A1. Then, for each sub-CU, the motion information of its corresponding block in the co-located picture (the minimum motion grid covering the center sample) is used to derive the motion information of the sub-CU. After identifying the motion information of the co-located sub-CU, it is converted into a motion vector and reference index of the current sub-CU in a manner similar to the TMVP process of HEVC, where temporal motion scaling is applied to align the reference picture of the temporal motion vector with the reference picture of the current CU.

[0215] In VVC, a sub-block based merge list containing a combination of both SbTVMP candidates and affine merge candidates is used for signaling of sub-block based merge mode. SbTVMP mode is enabled / disabled by a sequence parameter set (SPS) flag. If SbTMVP mode is enabled, the SbTMVP predictor is added as the first entry of the list of sub-block based merge candidates, followed by the affine merge candidates. The size of the sub-block based merge list is signaled in the SPS, and the maximum allowed size of the sub-block based merge list is 5 in VVC.

[0216] The sub-CU size used in SbTMVP is fixed to 8×8, and as performed for affine merge mode, SbTMVP mode is only applicable to CUs whose width and height are both greater than or equal to 8.

[0217] The encoding logic for the additional SbTMVP merge candidates is the same as for other merge candidates, ie, for each CU in a P or B slice, an additional RD check is performed to decide whether to use the SbTMVP candidate.

[0218] Probability Estimation Techniques for CABAC in AVC and HEVC

[0219] CABAC (Context-Based Adaptive Binary Arithmetic Coding) was originally introduced in the H.264 / AVC standard as one of the two supported entropy coding schemes. In CABAC, arithmetic coding consists of two modules: codeword mapping (also called binarization) and probability estimation. In the process of codeword mapping, syntax elements are mapped into binary bit strings. The mapping is implemented by a so-called binarizer, which converts syntax elements into several groups of binary bits based on different binarization schemes. In practice, various binarization schemes can be applied to this translation, such as fixed-length codes, unary codes, truncated unary codes, and k-order exponential Golomb codes. The purpose of the probability estimation module is to determine the probability that a binary bit has a value of 1 or 0. In AVC, the probability of a binary bit is calculated based on an exponential aging model, in which the probability that a current binary bit is equal to 1 or 0 depends on the value of the previous binary bit that was previously encoded. In addition, according to common data statistics, the influence of the binary bit immediately before a current binary bit is usually greater than the binary bit that was encoded a long time ago. Taking this into account, a parameter α is introduced in CABAC, which controls the number N of previously coded bits used to estimate the probability of the current bit, i.e., N=1 / α. This parameter translates into an adaptation speed, with which the probability is updated along with the added coded bits. Specifically, with the adaptive parameter α, the probability that a bit is the least probable symbol (LPS) is recursively calculated as

[0220] p(t+1)=p(t)·(1-α)+x(t)·α (1)

[0221] where p(t) is the probability of the LPS symbol at time t; p(t+1) is the updated probability of the LPS symbol at time t+1; x(t) is equal to 1 when the current bin is an LPS symbol and equal to 0 when the current bin is a maximum probable symbol (MPS). In the CABAC engine of AVC and HEVC, for each syntax element with a fixed value of α≈119.69, the probability is updated independently according to (1), i.e., about 19.69 previously coded bins are considered when estimating the probability of one current bin. In addition, in order to avoid multiplication during probability estimation, the probability p(t) in (1), which is a real number and ranges from 0 to 1, is quantized into a set of fixed probability states. For example, in both AVC and HEVC, the probability has 7 bits of precision, corresponding to 128 probability states.

[0222] In AVC and HEVC, a video bitstream is usually composed of one or more independently decodable slices. At the beginning of each slice, the probabilities of all contexts are initialized to some predefined values. In theory, if the statistical properties of a given context are known, a uniform distribution (i.e., p init= 0.5) to initialize the context probabilities. However, in order to make the probability of a context catch up with its corresponding statistical distribution more quickly, it is found that it is beneficial to provide some appropriate initial probability values ​​(which may not be equally likely) for each context. Specifically, in AVC and HEVC, given a slice SliceQP Y The initial QPsliceQpY, the initial probability state of a context InitProbState is calculated as follows:

[0223]

[0224] Where SlopeIdx and OffsetIdx (both in the range from 0 to 15) are two initialization parameters that are predefined and stored as a lookup table (LUT) to calculate the initial probability of a context. As shown in (2), the initial probability state is modeled by a linear function with a slice QP equal to the slope (m>>4) and an offset equal to n.

[0225] Probability estimation technology of CABAC in VVC

[0226] The probability estimation module applied in VVC remains almost the same as that in AVC and HEVC, except for the following key differences:

[0227] 1. VVC maintains two probability estimates for each context, each with its own probability adaptation rate α in (1). The final probability actually used for arithmetic coding is the average of the two estimates.

[0228] 2. In VVC, multiple probability LUTs are predefined and used to initialize the probabilities of different contexts of a slice. In addition, similar to AVC and HEVC, the initial estimate of the probability is based on a linear model that takes the slice QP as input. However, in VVC, the derived value represents the actual probability value; while in AVC / HEVC, it represents the index of the probability state.

[0229] Multiple hypothesis probability estimation

[0230] Obviously, using a fixed adaptive parameter for all syntax elements may not be optimal due to their different statistical properties. On the other hand, it has been shown in several scientific studies that better estimation accuracy can be achieved by using multiple probability estimators compared to a single estimator. Therefore, a multi-hypothesis probability estimation scheme is applied in the CABAC design of VVC, in which two different adaptive parameters α0 and α1 are used, which corresponds to a slow and fast speed for probability adaptation. In this way, two different probabilities can be calculated for each binary bit using two adaptive parameters, and then averaged to generate the final probability of the binary bit, that is,

[0231]

[0232] Where α0 and α1 are two adaptive parameters associated with two probability hypotheses. In VVC, the values ​​of α0 and α1 are selected independently for each context using a training algorithm designed to jointly optimize the adaptive parameters as well as the initial probabilities. Specifically, according to the current design, each context is allowed to select α0 from a set of predefined values ​​{1 / 4, 1 / 8, 1 / 16, 1 / 32} and α1 from another set of predefined values ​​{1 / 32, 1 / 64, 1 / 128, 1 / 256, 1 / 512}.

[0233] Initial probability calculation

[0234] As in AVC / HEVC, VVC's CABCA process also calls a QP-dependent probability initialization process at the beginning of each stripe. However, in contrast to AVC / HEVC, which initializes the states of a probability state machine, the actual values ​​of the initial probabilities are derived directly, as described by

[0235]

[0236] Where SlopeIdx and OffsetIdx are two initialization parameters used to calculate the slope and offset of the linear model, and each initialization parameter is represented with 3 bits of precision; and are the two initial probabilities calculated for the two probability estimators.

[0237] Entropy Coding in ECM

[0238] Extended Precision

[0239] The intermediate precision used in the arithmetic coding engine is increased to include three elements. First, the precision of both probability states is increased to 15 bits, compared to 10 bits and 14 bits in VVC. Second, the LPS range update process is modified as follows,

[0240] if q>=16384

[0241] q=2 15 –1–q

[0242] R LPS =((range*(q>>6))>>9)+1,

[0243] Where range is a 9-bit variable representing the width of the current interval, q is a 15-bit variable representing the probability state of the current context model, and R LPSis the update range of LPS. This operation can also be implemented by looking up 512×256 entries in a 9-bit lookup table. Third, at the encoder side, the 256-entry lookup table used for bit estimation in VTM is expanded to 512 entries.

[0244] Window size based on stripe type

[0245] Since the statistics vary for different slice types, it is beneficial to update the probability state of the context at a rate that can provide a more accurate probability estimate for a given slice type (e.g., to more accurately predict the likelihood of a binary bit having a value of 1 or 0). Therefore, for each context model, three window sizes are predefined for I slices, B slices, and P slices, respectively, as are the initialization parameters.

[0246] The context initialization parameters and window size are retrained.

[0247] Improved CABAC probability estimation method

[0248] Multi-hypothesis probability estimation with adaptive weights

[0249] The probability based on multiple hypotheses is estimated based on adaptive weights (MHP-AW). Specifically, two separate probability estimates p0 and p1 are maintained for each context and updated according to their own adaptation rates. However, instead of using a simple average, multiple weights are introduced to derive the resulting probability for binary arithmetic coding as follows:

[0250] p=(ω0·p0+ω1·p1)>>s

[0251] Wherein, ω0 and ω1 are weights selected from a predefined set {10, 12, 16, 20, 22}; s is a bitwise right shift value, which is equal to 5 when (ω0+ω1)≤32, otherwise equal to 6. Three different weight sets are pre-determined for each context model under I slice type, B slice type and P slice type. The weight of I slice type is only allowed to be used for intra-frame slices, while the weights of B slice type and P slice type are allowed to be switched at the slice level for inter-frame slices.

[0252] CABAC initialization and window adjustment from previous inter-frame slice

[0253] The context initialization stored at the previously coded picture after encoding the last CTU can be used to initialize the inter slices with the same slice type, QP and temporal ID. The buffer size for storing the previous initialization is set equal to 5 for each slice type, and when the buffer is full, the entry with the smallest QP and temporal ID is removed first before storing the initialization.

[0254] CABAC employs two probability states updated with short and long window sizes respectively. The predefined window size for each context model is not optimal for the varying statistics in different regions, so the window size is adjusted based on the previously encoded bins of each context.

[0255] The short window size and long window size used in the CABAC update are adjusted by two delta parameters stored in a lookup table per context and retrieved by a previously encoded binary bit used as an index. The previously encoded binary bit is used as an index to obtain the adjustment parameters from the lookup table: delta0 for the short window and delta1 for the long window. The original short window size and long window size stored in the existing initialization table and defined for the context model are denoted as shift0 and shift1, respectively. The actual window sizes used to encode the current binary bit after adjustment are (shift0+delta0) and (shift1+delta1), respectively, where shift0 and shift1 are the existing predefined window sizes stored in the context initialization table.

[0256] Problem Statement

[0257] In video codecs, it is well known that intra block copy accurately predicts screen content and artificially generated content where patterns and edges can repeat within a frame. Intra block copy may also be beneficial for natural content prediction where the current frame has repeated textures. For coding scenarios without much repeated content, it may be possible to not select the intra block copy mode but still transmit the minimum signaling bits of intra block copy. In this case, in order to further enhance the coding efficiency of intra block copy, it is desirable to provide a more flexible on / off control mechanism at different granularities.

[0258] In the present disclosure, the coding and decoding tools of intra-frame block replication are improved from the following aspects:

[0259] Flexible on / off control mechanism

[0260] CABAC context window

[0261] Flexible on / off control mechanism

[0262] In this section, several methods are proposed to perform on / off control for the application of IBC mode. The on / off control indicates whether to allow the IBC mode to be enabled for the current sequence, frame, slice, CTU or block, which may be at different granularities. If the IBC mode is enabled, other flags (e.g., whether the IBC mode is enabled or disabled for a specific block) or / and information (e.g., block vector) may be signaled. If the IBC mode is off, no flags or information are signaled.

[0263] In some embodiments, on / off control of intra block copy may be based on an explicit signaling method.

[0264] In one embodiment, the on / off control is based on one or more sequence level, or frame level, or slice level or coding tree unit (CTU) level, or block level flags, or any combination of different level flags. When any combination of different level flags is used, the transmission of lower level flags depends on the on / off of higher level flags. In one example, if the frame level flag indicates the closure of IBC mode, no flags are transmitted at the slice or block level. Otherwise, further lower level flags are sent.

[0265] In another embodiment, the on / off control is based on different zones. The purpose of the zone concept is to provide a more flexible granularity for IBC on / off control.

[0266] In one embodiment, a region here may be defined as a non-overlapping region within a frame or slice or CTU. For all blocks within a specific region, a single on / off control flag may be signed to indicate whether the IBC mode is turned off for all these blocks. The size of a region may be predefined as a set of fixed values ​​such as M×N or a group of values ​​transmitted with a signal.

[0267] In some other embodiments, on / off control of intra block copy may be based on local information and no explicit signaling is required.

[0268] In some embodiments, the on / off control is based on predictive information.

[0269] In one embodiment, IBC mode is always turned off for inter-frame predicted blocks (e.g., in inter-frame coded frames such as B frames and P frames). For intra-frame coded blocks, IBC mode may be always enabled in inter-frame coded frames (e.g., B frames and P frames) or intra-frame coded frames (e.g., I frames).

[0270] In another embodiment, the IBC mode is always turned off for uni-directionally predicted or / and bi-directionally predicted inter blocks.

[0271] In yet another embodiment, for blocks encoded in sub-block mode, IBC mode is always off. Sub-block mode is a mode that divides the current block into sub-blocks and each sub-block may have its own motion information. For example, affine mode, SbTMVP mode.

[0272] In another embodiment, the IBC mode is always off for blocks not encoded in sub-block mode.

[0273] In some other embodiments, the on / off control is based on other encoded information.

[0274] In one embodiment, the IBC mode is always off when one or more other coding modes are applied to the current block. For example, the IBC mode is always off when the affine mode is enabled.

[0275] In some other embodiments, the on / off control is based on the frame type.

[0276] In one embodiment, IBC mode is always off for B frames and / or P frames.

[0277] In some other embodiments, the on / off control is based on block information.

[0278] In one embodiment, IBC mode is always off for coding blocks smaller than a certain size (eg, 8×8 blocks) or larger than a certain size (eg, 64×64).

[0279] In one embodiment, IBC mode is always turned off for wide blocks (e.g., blocks whose width is M times longer than their height) or long blocks (e.g., blocks whose height is N times longer than their width), while the values ​​of M and N can be fixed (e.g., M=2, N=3) or signaled at the sequence or frame level.

[0280] CABAC Context Window

[0281] In the current IBC design, there may be one or more IBC mode related flags that are CABAC context encoded. For example, the IBC enable flag at the block level is context encoded. Since the statistics may be different for different slices or frame types, it is desirable to update the probability state of the context at a rate that can provide a more accurate probability estimate (e.g., to more accurately predict the likelihood of a binary bit having a value of 1 or 0) under a given slice / frame type.

[0282] In some embodiments, for each context model associated with the IBC mode, three windows may be predefined for three different slices (including an I slice, a B slice, and a P slice, respectively).

[0283] In some embodiments, for each context model associated with the IBC mode, two windows may be predefined for different slices with two different prediction modes, including intra-predicted slices (I slices) and inter-predicted slices (B slices and P slices), respectively.

[0284] When multiple windows are defined for different slices or frames, the context window size and initialization parameters may also be retrained individually or jointly.

[0285] Fig.15A computing environment (or computing device) 1610 coupled to a user interface 1650 is shown. The computing environment 1610 may be part of a data processing server. In some embodiments, the computing device 1610 may perform any of the various methods or processes (such as encoding / decoding methods or processes) described above according to various examples of the present disclosure. The computing environment 1610 includes a processor 1620, a memory 1630, and an input / output (I / O) interface 1640.

[0286] 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 to execute instructions to perform all or some 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.

[0287] 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 static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0288] I / O interface 1640 provides an interface between processor 1620 and peripheral interface modules such as a 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.

[0289] Fig.16 is a flow chart illustrating a method for video decoding according to an example of the present disclosure. Fig.16 In the method shown, the on / off control of intra block copying can be based on an explicit signaling method.

[0290] At step 1601 , the processor 1620 at the decoder side may obtain one or more IBC control syntax elements indicating whether the IBC mode is enabled at different granularities.

[0291] In some examples, the different granularities may include multiple coding levels, and one or more IBC control syntax elements indicate whether IBC mode is enabled at the multiple coding levels.

[0292] In some examples, when any combination of flags at different levels is used, the sending of flags at the lower level depends on the on / off of flags at the higher level. For example, if the frame level flag indicates that the IBC mode is turned off, the flag is no longer sent at the slice or block level. Otherwise, the lower level flag is further sent. In some examples, multiple coding levels may include a sequence level, a frame level, a slice level, a coding tree unit level, and a block level, each control syntax element indicates whether the IBC mode is enabled at at least one level of the multiple coding levels, and the one or more IBC control syntax elements may include a first control syntax element and a second control syntax element, the first control syntax element indicates whether the IBC mode is enabled at the first coding level, the second control syntax element indicates whether the IBC mode is enabled at the second coding level, and the first coding level is higher than the second coding level.

[0293] In addition, the processor 1620 may perform at least one of the following steps: obtaining a second control syntax element, and in response to determining that the first control syntax element indicates that the IBC mode is enabled at the first coding level, determining whether the second control syntax element indicates that the IBC mode is enabled at the second coding level; or determining that the second control syntax element is not sent in response to determining that the first control syntax element indicates that the IBC mode is not enabled at the first coding level.

[0294] In some examples, flexible on / off control for applications of IBC mode is based on different regions. For example, different granularities may include different regions, and the processor 1620 on the decoder side may predefine different regions as non-overlapping regions within one of the following: a frame, a slice, or a CTU. For example, the processor 1620 may predefine the sizes of different regions to a set of fixed values.

[0295] At step 1602 , the processor 1620 at the decoder side may obtain one or more block vectors of the current block based on the IBC mode in response to determining that the IBC mode is enabled at one or more granularities.

[0296] Fig.17 is shown as Fig.16 The method for video decoding shown corresponds to a flowchart of the method for video encoding.

[0297] At step 1701 , the processor 1620 at the encoder side may determine one or more IBC control syntax elements indicating whether an IBC mode is enabled at different granularities.

[0298] In some examples, the different granularities may include multiple coding levels, and one or more IBC control syntax elements indicate whether IBC mode is enabled at the multiple coding levels.

[0299] In some examples, when any combination of flags at different levels is used, the sending of flags at the lower level depends on the on / off of flags at the higher level. For example, if the frame level flag indicates the closure of the IBC mode, the flag is no longer sent at the slice or block level. Otherwise, the lower level flag is further sent. In some examples, multiple coding levels may include a sequence level, a frame level, a slice level, a coding tree unit level, and a block level, each control syntax element indicates whether the IBC mode is enabled at at least one level in the multiple coding levels, and one or more IBC control syntax elements may include a first control syntax element and a second control syntax element, the first control syntax element indicates whether the IBC mode is enabled at the first coding level, the second control syntax element indicates whether the IBC mode is enabled at the second coding level, and the first coding level is higher than the second coding level.

[0300] In addition, the processor 1620 may perform at least one of the following steps, including: determining a second control syntax element, and sending a second control syntax element indicating whether the IBC mode is enabled at the second coding level in response to determining that the first control syntax element indicates that the IBC mode is enabled at the first coding level; or determining not to send the second control syntax element in response to determining that the first control syntax element indicates that the IBC mode is not enabled at the first coding level.

[0301] In some examples, flexible on / off control for application of IBC mode is based on different regions. For example, different granularities may include different regions, and the processor 1620 on the encoder side may predefine different regions as non-overlapping regions within one of the following: frame, slice, or CTU. For example, the processor 1620 may predefine the size of different regions to a set of fixed values.

[0302] At step 1702 , the processor 1620 at the encoder side may encode the current block into a bitstream based on one or more IBC control syntax elements.

[0303] Fig.18 1 is a flowchart showing a method for video decoding according to an example of the present disclosure. Fig.18 In the method illustrated in , on / off control of intra block copy can be based on local information and no explicit signaling is required.

[0304] In step 1801 , the processor 1620 at the decoder side may obtain IBC control information according to local information associated with a current block, wherein the IBC control information indicates whether an IBC mode is enabled.

[0305] In some examples, the local information may include at least one of the following: prediction information, encoding information, frame type, or block information.

[0306] In some examples, on / off control of the IBC mode may be based on prediction information. For example, processor 1620 may perform one of the following steps: in response to determining that the current block is an inter-frame prediction block, for example, in an inter-frame coded frame such as a B frame or a P frame, determining that the IBC control information indicates that the IBC mode is not enabled; in response to determining that the current block is an intra-frame prediction block in an inter-frame coded frame (e.g., B and P frames) or an intra-frame coded frame (e.g., I frame), determining that the IBC control information indicates that the IBC mode is enabled; in response to determining that the current block is a unidirectionally predicted inter-frame block, determining that the IBC control information indicates that the IBC mode is not enabled; in response to determining that the current block is encoded in a sub-block mode, determining that the IBC control information indicates that the IBC mode is not enabled; in response to determining that the current block The IBC control information indicates that the IBC mode is not enabled because the block is not encoded in the sub-block mode; in response to determining that a coding mode other than the IBC mode is applied to the current block, the IBC control information indicates that the IBC mode is not enabled; in response to determining that the current block is a B frame block or a P frame block, the IBC control information indicates that the IBC mode is not enabled; in response to determining that the size of the current block is smaller than or larger than a specific size (for example, smaller than a specific size such as 8×8 or larger than a specific size such as 64×64), the IBC control information indicates that the IBC mode is not enabled; or in response to determining that the current block is a wide block or a long block, the IBC control information indicates that the IBC mode is not enabled.

[0307] In some examples, the wide block has a first width and a first height, and the first width is M times longer than the first height, the long block has a second width and a second height, and the second height is N times longer than the first width, and M and N are fixed values ​​or are signaled at the sequence level or the frame level.

[0308] In step 1802 , the processor 1620 at the decoder side may obtain one or more block vectors of the current block based on the IBC mode in response to determining that the IBC mode is enabled.

[0309] Fig.19 is shown as Fig.18 The method for video decoding shown is a flowchart of a method for video encoding corresponding to that shown.

[0310] In step 1901 , the processor 1620 at the encoder side may obtain IBC control information according to local information associated with a current block, wherein the IBC control information indicates whether an IBC mode is enabled.

[0311] In some examples, the local information may include at least one of the following: prediction information, encoding information, frame type, or block information.

[0312] In some examples, the on / off control of the IBC mode may be based on the prediction information. For example, the processor 1620 may perform one of the following steps: in response to determining that the current block is an inter-frame prediction block, such as in an inter-frame coded frame such as a B frame or a P frame, determining that the IBC control information indicates that the IBC mode is not enabled; in response to determining that the current block is an intra-frame prediction block in an inter-frame coded frame (such as a B frame and a P frame) or an intra-frame coded frame (such as an I frame), determining that the IBC control information indicates that the IBC mode is enabled; in response to determining that the current block is a unidirectionally predicted inter-frame block, determining that the IBC control information indicates that the IBC mode is not enabled; in response to determining that the current block is encoded in a sub-block mode, determining that the IBC control information indicates that the IBC mode is not enabled; in response to determining that the current block is encoded in a sub-block mode, determining that the IBC control information indicates that the IBC mode is not enabled; The block is not encoded in the sub-block mode and the IBC control information indicates that the IBC mode is not enabled; in response to determining that a coding mode other than the IBC mode is applied to the current block, the IBC control information indicates that the IBC mode is not enabled; in response to determining that the current block is a B frame block or a P frame block, the IBC control information indicates that the IBC mode is not enabled; in response to determining that the size of the current block is less than or greater than a specific size (for example, less than a specific size such as 8×8 or greater than a specific size such as 64×64), the IBC control information indicates that the IBC mode is not enabled; or in response to determining that the current block is a wide block or a long block, the IBC control information indicates that the IBC mode is not enabled.

[0313] In some examples, the wide block has a first width and a first height, and the first width is M times longer than the first height, the long block has a second width and a second height, and the second height is N times longer than the first width, and M and N are fixed values ​​or are signaled at the sequence level or the frame level.

[0314] At step 1902 , the processor 1620 at the encoder side may encode the current block into a bitstream based on the IBC control information.

[0315] Fig. 20 1 is a flowchart showing a method for video decoding according to an example of the present disclosure. Fig. 20 In the method shown in , multiple windows may be predefined based on different slice types and / or frame types.

[0316] In step 2001, the processor 1620 at the decoder side may obtain a syntax element related to the IBC mode, wherein the syntax element is encoded by the CABAC context.

[0317] In step 2002, the processor 1620 at the decoder side may determine a CABAC context window for each context model associated with the IBC mode based on a slice type or a frame type.

[0318] In some examples, the processor 1620 may determine that a plurality of CABAC context windows are predefined for different slice types or different frame types based on the slice type or the frame type. For example, the processor 1620 may determine that three different CABAC context windows are predefined for three different slice types, where the three different slice types may include I, B, and P. In another example, the processor 1620 may determine that two different CABAC context windows are predefined for different slices with different slice types and different prediction modes.

[0319] In some examples, processor 1620 may determine a first CABAC context window for the current slice in response to determining that the current slice is an intra-prediction I slice, and determine a second CABAC context window for the current slice in response to determining that the current slice is an inter-prediction B slice or an inter-prediction P slice, wherein the first CABAC context window and the second CABAC context window are two different CABAC context windows.

[0320] In some examples, when multiple windows are defined for different slices or frames, the context window size and initialization parameters may also be retrained individually or jointly.

[0321] Fig.21 is shown as Fig. 20 The method for video decoding shown corresponds to a flowchart of the method for video encoding.

[0322] In step 2101 , the processor 1620 at the encoder side may determine a CABAC context window for each context model associated with the IBC mode based on a slice type or a frame type.

[0323] At step 2102 , the processor 1620 at the encoder side may obtain a syntax element related to the IBC mode, wherein the syntax element is encoded by the CABAC context.

[0324] At step 2103, the processor 1620 at the encoder side may signal the syntax elements into the bitstream.

[0325] In some examples, the processor 1620 may determine that a plurality of CABAC context windows are predefined for different slice types or different frame types based on the slice type or the frame type. For example, the processor 1620 may determine that three different CABAC context windows are predefined for three different slice types, where the three different slice types may include I, B, and P. In another example, the processor 1620 may determine that two different CABAC context windows are predefined for different slices with different slice types and different prediction modes.

[0326] In some examples, processor 1620 may determine a first CABAC context window for the current slice in response to determining that the current slice is an intra-prediction I slice, and determine a second CABAC context window for the current slice in response to determining that the current slice is an inter-prediction B slice or an inter-prediction P slice, wherein the first CABAC context window and the second CABAC context window are two different CABAC context windows.

[0327] In some examples, when multiple windows are defined for different slices or frames, the context window size and initialization parameters may also be retrained individually or jointly.

[0328] In some examples, a device for video encoding and decoding is provided. The device includes a processor 1620 and a memory 1640 configured to store instructions executable by the processor; wherein the processor is configured to perform the following when executing the instructions: Figure 16-Figure 21 Any method shown.

[0329] In an embodiment, a non-transitory computer-readable storage medium is also provided, including, for example, a plurality of programs in a memory 1630, which can be executed by a processor 1620 in a computing environment 1610 to perform the above method and / or store a bitstream generated by the above encoding method or a bitstream to be decoded by the above decoding method. In an example, the plurality of programs can be executed by a processor 1620 in a computing environment 1610 to (for example, from Figure 2A The 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-described 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 encoding method described above 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 send the bit stream or data stream (e.g., to a Figure 2B Alternatively, the non-transitory computer-readable storage medium may store therein 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.), the encoded video information being encoded by an encoder (e.g., Figure 2A The video encoder 20 in FIG. 1 generates a video signal for a decoder (eg, Figure 2BThe video decoder 30 in the example is used when decoding video data. The non-transitory computer-readable storage medium may be, for example, a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, or the like.

[0330] 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 is provided, including the encoded video information generated by the above encoding method or the encoded video information to be decoded by the above decoding method.

[0331] In an embodiment, a computing device is also provided, comprising: one or more processors (e.g., processor 1620); and a non-transitory computer-readable storage medium or memory 1630 storing therein a plurality of programs executable by the one or more processors, wherein the one or more processors are configured to perform the above-mentioned method when executing the plurality of programs.

[0332] 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 is also provided, which includes, for example, a plurality of programs in the memory 1630, which can be executed by the processor 1620 in the computing environment 1610 for performing the above method. For example, the computer program product may include a non-transitory computer-readable storage medium.

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

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

[0335] 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.

[0336] The description of the present disclosure has been presented for purposes of illustration and is not intended to be exhaustive or limiting of 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.

[0337] Unless otherwise specifically stated, the order of the 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 requirements.

[0338] 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 should be understood that the scope of the present disclosure is not limited to the specific examples of the disclosed implementations, and modifications and other implementations are intended to be included within the scope of the present disclosure.

Claims

1. A method for video decoding, comprising: Obtaining, by a decoder, one or more intra block copy (IBC) control syntax elements, the one or more IBC control syntax elements indicating whether an IBC mode is enabled at different granularities; as well as In response to determining that the IBC mode is enabled at the one or more granularities, one or more block vectors for the current block are obtained, by the decoder, based on the IBC mode.

2. The method according to claim 1, wherein: The different granularities include multiple coding levels, and the one or more IBC control syntax elements indicate whether an IBC mode is enabled at the multiple coding levels.

3. The method according to claim 2, wherein: The multiple coding levels include a sequence level, a frame level, a slice level, a coding tree unit level, and a block level, each control syntax element indicates whether an IBC mode is enabled at at least one coding level among the multiple coding levels, the one or more IBC control syntax elements include a first control syntax element and a second control syntax element, the first control syntax element indicates whether the IBC mode is enabled at a first coding level, the second control syntax element indicates whether the IBC mode is enabled at a second coding level, and the first coding level is higher than the second coding level, The method further comprises at least one of the following steps: In response to determining that the first control syntax element indicates that the IBC mode is enabled at the first coding level, obtaining, by the decoder, a second control syntax element and determining, by the decoder, whether the second control syntax element indicates that the IBC mode is enabled at the second coding level; or In response to determining that the first control syntax element indicates that the IBC mode is not enabled at the first coding level, determining, by the decoder, that the second control syntax element is not sent.

4. The method according to claim 1, wherein: The different particle sizes include different regions, and wherein the method further comprises: The different regions are predefined as non-overlapping regions within one of the following: a frame, a slice, or a CTU.

5. The method according to claim 4, further comprising: The sizes of the different regions are predefined as a set of fixed values.

6. A method for video encoding, comprising: Determining, by an encoder, one or more intra block copy (IBC) control syntax elements, the one or more IBC control syntax elements indicating whether an IBC mode is enabled at different granularities; as well as The current block is encoded into a bitstream by the encoder based on the one or more IBC control syntax elements.

7. The method according to claim 6, wherein: The different granularities include multiple coding levels, and the one or more IBC control syntax elements indicate whether an IBC mode is enabled at the multiple coding levels.

8. The method according to claim 7, wherein: The multiple coding levels include a sequence level, a frame level, a slice level, a coding tree unit level, and a block level, each control syntax element indicates whether an IBC mode is enabled at at least one coding level among the multiple coding levels, the one or more IBC control syntax elements include a first control syntax element and a second control syntax element, the first control syntax element indicates whether the IBC mode is enabled at a first coding level, the second control syntax element indicates whether the IBC mode is enabled at a second coding level, and the first coding level is higher than the second coding level, The method further comprises at least one of the following steps: In response to determining that the first control syntax element indicates that the IBC mode is enabled at the first coding level, determining, by the encoder, a second control syntax element and sending, by the encoder, the second control syntax element indicating whether the IBC mode is enabled at the second coding level; or In response to determining that the first control syntax element indicates that the IBC mode is not enabled at the first coding level, determining, by the encoder, not to send a second control syntax element.

9. The method according to claim 6, wherein: The different particle sizes include different regions, and wherein the method further comprises: The different regions are predefined as non-overlapping regions within one of the following: a frame, a slice, or a CTU.

10. The method according to claim 9, further comprising: The sizes of the different regions are predefined as a set of fixed values.

11. A method for video decoding, comprising: Obtaining, by the decoder, intra block copy (IBC) control information according to local information associated with the current block, wherein the IBC control information indicates whether an IBC mode is enabled; and In response to determining that the IBC mode is enabled, one or more block vectors for the current block are obtained by the decoder based on the IBC mode.

12. The method according to claim 11, wherein: The local information includes at least one of the following information: Prediction information, coding information, frame type or block information.

13. The method according to claim 11, further comprising one of the following steps: In response to determining that the current block is an inter-frame predicted block, determining, by the decoder, that the IBC control information indicates that the IBC mode is not enabled; In response to determining that the current block is an intra-prediction block, determining, by the decoder, that the IBC control information indicates that an IBC mode is enabled; In response to determining that the current block is a unidirectionally predicted inter block, determining, by the decoder, that the IBC control information indicates that the IBC mode is not enabled; In response to determining that the current block is a bi-predicted inter block, determining, by the decoder, that the IBC control information indicates that the IBC mode is not enabled; In response to determining that the current block is encoded in the sub-block mode, determining, by the decoder, that the IBC control information indicates that the IBC mode is not enabled; or In response to determining that the current block is not encoded in the sub-block mode, determining, by the decoder, that the IBC control information indicates that the IBC mode is not enabled.

14. The method according to claim 11, further comprising: In response to determining that a coding mode other than the IBC mode is applied to the current block, determining, by the decoder, that the IBC control information indicates that the IBC mode is not enabled.

15. The method according to claim 11, further comprising: In response to determining that the current block is a B frame block or a P frame block, it is determined by the decoder that the IBC control information indicates that the IBC mode is not enabled.

16. The method according to claim 11, further comprising one of the following steps: In response to determining that the size of the current block is smaller than or larger than a certain size, determining, by the decoder, that the IBC control information indicates that the IBC mode is not enabled; or In response to determining that the current block is a wide block or a long block, determining, by the decoder, that the IBC control information indicates that the IBC mode is not enabled.

17. The method according to claim 16, wherein: The wide block has a first width and a first height, and the first width is M times longer than the first height, The long block has a second width and a second height, and the second height is N times longer than the first width, and Here, M and N are fixed values ​​or are signaled at the sequence level or frame level.

18. A method for video encoding, comprising: Obtaining, by the encoder, intra block copy (IBC) control information according to local information associated with the current block, wherein the IBC control information indicates whether an IBC mode is enabled; and The current block is encoded into the bitstream by the encoder based on the IBC control information.

19. The method according to claim 18, wherein: The local information includes at least one of the following information: Prediction information, coding information, frame type or block information.

20. The method according to claim 18, further comprising one of the following steps: In response to determining that the current block is an inter-frame prediction block, determining, by the encoder, that the IBC control information indicates that the IBC mode is not enabled; In response to determining that the current block is an intra-prediction block, determining, by the decoder, that the IBC control information indicates that an IBC mode is enabled; In response to determining that the current block is a unidirectionally predicted inter block, determining, by the encoder, that the IBC control information indicates that the IBC mode is not enabled; In response to determining that the current block is a bidirectionally predicted inter-frame block, determining, by the encoder, that the IBC control information indicates that the IBC mode is not enabled; In response to determining that the current block is encoded in the sub-block mode, determining, by the encoder, that the IBC control information indicates that the IBC mode is not enabled; or In response to determining that the current block is not encoded in the sub-block mode, determining, by the encoder, that the IBC control information indicates that the IBC mode is not enabled.

21. The method of claim 18, further comprising: In response to determining that a coding mode other than the IBC mode is applied to the current block, determining, by the encoder, that the IBC control information indicates that the IBC mode is not enabled.

22. The method of claim 18, further comprising: In response to determining that the current block is a B frame block or a P frame block, it is determined by the encoder that the IBC control information indicates that the IBC mode is not enabled.

23. The method according to claim 18, further comprising one of the following steps: In response to determining that the size of the current block is smaller than or larger than a specific size, determining, by the encoder, that the IBC control information indicates that the IBC mode is not enabled; or In response to determining that the current block is a wide block or a long block, determining, by the encoder, that the IBC control information indicates that the IBC mode is not enabled.

24. The method of claim 23, wherein the wide block has a first width and a first height, and the first width is M times longer than the first height, in, The long block has a second width and a second height, and the second height is N times longer than the first width, and Here, M and N are fixed values ​​or are signaled at the sequence level or frame level.

25. A method for video decoding, comprising: Obtaining, by a decoder, syntax elements associated with an intra block copy (IBC) mode, wherein the syntax elements are context-adaptive binary arithmetic coding (CABAC) context-coded; and The CABAC context window for each context model associated with the IBC mode is determined by the decoder and based on the slice type or frame type.

26. The method according to claim 25, further comprising: A plurality of CABAC context windows are predefined for different slice types or different frame types and are determined by the decoder based on the slice type or the frame type.

27. The method according to claim 26, further comprising: It is determined by the decoder that three different CABAC context windows are predefined for three different slice types, wherein the three different slice types include I, B, and P.

28. The method of claim 26, further comprising: It is determined by the decoder that two different CABAC context windows are predefined for different slices with different slice types and different prediction modes.

29. The method according to claim 28, further comprising: In response to determining that the current slice is an intra-prediction I slice, determining, by the decoder, a first CABAC context window for the current slice; as well as In response to determining that the current slice is an inter-predicted B slice or an inter-predicted P slice, a second CABAC context window is determined by the decoder for the current slice, wherein the first CABAC context window and the second CABAC context window are two different CABAC context windows.

30. The method of claim 26, further comprising: The sizes and initialization parameters of the plurality of CABAC context windows are retrained jointly or individually.

31. A method for video encoding, comprising: Determining, by the encoder and based on the slice type or the frame type, a context adaptive binary arithmetic coding (CABAC) context window for each context model associated with the intra block copy (IBC) mode; Obtaining, by an encoder, a syntax element associated with an IBC mode, wherein the syntax element is encoded by a CABAC context; as well as The syntax elements are signaled into the bitstream by the encoder.

32. The method of claim 31 further comprising: A plurality of CABAC context windows are predefined for different slice types or different frame types, determined by the encoder and based on the slice type or the frame type.

33. The method of claim 32, further comprising: It is determined by the encoder that three different CABAC context windows are predefined for three different slice types, wherein the three different slice types include I, B, and P.

34. The method of claim 32, further comprising: Two different CABAC context windows are predefined for different slices with different slice types and different prediction modes as determined by the encoder.

35. The method of claim 34, further comprising: In response to determining that the current slice is an intra-prediction I slice, determining, by the encoder, a first CABAC context window for the current slice; as well as In response to determining that the current slice is an inter-prediction B slice or an inter-prediction P slice, the encoder determines a second CABAC context window for the current slice, wherein the first CABAC context window and the second CABAC context window are two different CABAC context windows.

36. The method of claim 35, further comprising: The sizes and initialization parameters of the plurality of CABAC context windows are retrained jointly or individually by the encoder.

37. An apparatus for video 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-5, 11-17 and 25-30.

38. An apparatus for video encoding, 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 6-10, 18-24 and 31-36.

39. A non-transitory computer-readable storage medium for storing computer-executable instructions that, when executed by one or more computer processors, cause the one or more computer processors to perform the method of any one of claims 1-5, 11-17, and 25-30.

40. A non-transitory computer-readable storage medium for storing computer-executable instructions that, when executed by one or more computer processors, cause the one or more computer processors to perform the method of any one of claims 6-10, 18-24, and 31-36.

41. A non-transitory computer-readable storage medium for storing a bit stream to be decoded by the method of any one of claims 1-5, 11-17, and 25-30.

42. A non-transitory computer-readable storage medium for storing a bitstream generated by the method of any one of claims 6-10, 18-24, and 31-36.

Images