Method and apparatus for predictive candidate list size signaling for intrapicture block compensation

Abstract

To provide a video coding method and an apparatus for a predictive candidate list size signaling for intra picture block compensation.SOLUTION: A video decoding method includes the steps of: receiving a coded video bitstream including a current picture; determining a predetermined condition associated with signaling data included in the coded video bitstream; determining size of an index included in the signaling data for a candidate list of vector prediction based on the number of merge mode candidates and the number of intra block copy (IBC) candidates based on the predetermined condition; creating a candidate list using the vector prediction; retrieving the vector prediction from the candidate list according to the index having a value not exceeding the determined size of the index; and decoding the current block according to the retrieved vector prediction.SELECTED DRAWING: Figure 12

Description

Technical Field

[0001] Incorporation by Reference This disclosure claims the benefit of priority under 35 U.S.C. § 119 based on U.S. Patent Application No. 16 / 863,661, filed Apr. 30, 2020, entitled “Methods and Apparatus for Prediction Candidate List Size Signaling for Intra Picture Block Compensation,” which claims the benefit of priority under 35 U.S.C. § 119 based on U.S. Provisional Application No. 62 / 904,307, filed Sep. 23, 2019, entitled “Prediction Methods for Intra Picture Block Compensation” and U.S. Provisional Application No. 62 / 873,044, filed Jul. 11, 2019, entitled “Prediction Candidate List Size Signaling for Intra Picture Block Compensation.” The entire disclosure of the prior applications is hereby incorporated by reference in its entirety.

[0002] This disclosure generally describes embodiments related to video coding.

Background Art

[0003] The description of the background art provided herein is for the purpose of generally presenting the context of the present disclosure. At the present time, the work of the inventors who are named has not been acknowledged as prior art to the present disclosure, either explicitly or implicitly, insofar as it is described in this background art section and in other cases where it may not qualify as prior art at the time of filing.

[0004] Video coding and decoding can be performed using interpicture prediction with motion compensation. Uncompressed digital video can contain a series of pictures, each picture having spatial dimensions of, for example, 1920x1080 luminance samples and associated chrominance samples. The series of pictures may have a fixed or variable picture rate (informally also known as frame rate), for example, 60 frames per second or 60 Hz. Uncompressed video has significant bitrate requirements. For example, 1080p60 4:2:0 video with 8 bits per sample (1920x1080 luminance sample resolution at a 60 Hz frame rate) requires a bandwidth of nearly 1.5 Gbit / s. One hour of such video requires more than 600 GB of storage space.

[0005] One of the purposes of video coding and decoding is to reduce the redundancy of the input video signal through compression. Compression can help reduce the aforementioned bandwidth or storage space requirements by more than two orders of magnitude, in some cases. Both lossless and lossy compression, as well as combinations thereof, can be employed. Lossless compression refers to a technique that allows for the reconstruction of an exact copy of the original signal from the compressed original signal. When using lossy compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original and the reconstructed signal is small enough that the reconstructed signal is still useful for the intended application. For video, lossy compression is widely used. The amount of distortion that is acceptable varies depending on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio may reflect that a higher acceptable / acceptable distortion may result in a higher compression ratio.

[0006] Motion compensation can be a lossy compression technique in which blocks of sample data from a previously reconstructed picture or a portion thereof (reference picture) are spatially shifted in the direction indicated by a motion vector (hereinafter MV), and then used to predict the newly reconstructed picture or portion of the picture. In some cases, the reference picture may be the same as the picture currently being reconstructed. The MV can have two dimensions, X and Y, or three dimensions, the third of which may be a representation of the reference picture in use (the latter indirectly being the time dimension).

[0007] In some video compression techniques, a motion vector (MV) applicable to a region of sample data can be predicted from other MVs, for example, those related to another region of sample data that is spatially adjacent to the region being reconstructed and precedes that MV in the decoding order. Doing so can significantly reduce the amount of data required to code the MV, thereby eliminating redundancy and increasing compression. MV prediction can work effectively, for example, when coding an input video signal derived from a camera (known as natural video), because there is a statistical likelihood that regions larger than the region to which a single MV is applicable will move in a similar direction, and therefore, in some cases, can be predicted using similar motion vectors derived from the MVs of neighboring regions. This makes the MV found for a given region similar to or identical to the MV predicted from the surrounding MVs, and after entropy coding, it can be represented with fewer bits than would be used if the MV were coded directly. In some cases, MV prediction can be an example of lossless compression of the signal (i.e., MV) derived from the original signal (i.e., sample stream). In other cases, the MV prediction itself may be lossy, for example, due to rounding errors when calculating the predictor from some surrounding MVs.

[0008] Various MV prediction mechanisms are described in H.265 / HEVC (ITU-T Rec.H.265, "High Efficiency Video Coding," December 2016). Here, we will describe one of the many MV prediction mechanisms provided by H.265, hereafter referred to as "spatial merging."

[0009] Referring to Figure 1, the current block (101) contains samples found by the encoder during the motion search process so that it is predictable from the previous block of the same size, which has been spatially shifted. Instead of directly coding its MV, the MV may be derived from metadata associated with one or more reference pictures, for example from the most recent reference picture (in decoding order), using the MV associated with one of the five surrounding samples indicated by A0, A1, and B0, B1, B2 (102 to 106, respectively). In H.265, the MV prediction can use a predictor from the same reference picture used by the neighboring blocks. The order in which the candidate list is formed may be A0 → B0 → B1 → A1 → B2. [Overview of the Initiative] [Means for solving the problem]

[0010] According to one exemplary embodiment, a video decoding method includes the step of receiving a coded video bitstream containing a current picture. The method includes the step of determining a predetermined condition associated with signaling data contained in the coded video bitstream. Based on the predetermined condition, the method includes the step of determining the size of the indices contained in the signaling data for a candidate list of vector predictors, based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates. The method includes the step of creating a candidate list using the vector predictors. The method includes the step of retrieving vector predictors from the candidate list according to indices having values ​​that do not exceed the determined size of the index. The method further includes the step of decoding the current block according to the retrieved vector predictors.

[0011] According to one exemplary embodiment, a video decoding method includes the step of receiving a coded video bitstream containing a picture. The method further includes the step of extracting signaling data from the coded video bitstream for the current block. The method further includes the step of determining whether the extracted signaling data for the current block contains the maximum number of merge candidates. Based on the determination of whether the maximum number of merge candidates is included in the signaling data for the current block, the method further includes the step of setting the maximum number of intra-block copy (IBC) candidates.

[0012] According to one exemplary embodiment, a video decoding device for video decoding includes a processing circuit configured to receive a coded video bitstream containing a picture. The processing circuit is further configured to determine predetermined conditions associated with signaling data contained in the coded video bitstream. Based on the predetermined conditions, the processing circuit is further configured to determine the size of the indices contained in the signaling data for a candidate list of vector predictions, based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates. The processing circuit is further configured to create a candidate list using the vector predictions and to extract vector predictions from the candidate list according to the indices having values ​​that do not exceed the determined size of the indices. The processing circuit is further configured to decode the current block according to the extracted vector predictions.

[0013] According to one exemplary embodiment, a video decoder device for video decoding includes a processing circuit configured to receive a coded video bitstream containing a picture. The processing circuit is further configured to extract signaling data from the coded video bitstream of the current block. The processing circuit is further configured to determine whether the extracted signaling data of the current block contains the maximum number of merge candidates. Based on the determination of whether the maximum number of merge candidates is contained in the signaling data of the current block, the processing circuit is further configured to set a maximum number of intra-block copy (IBC) candidates.

[0014] A non-temporary computer-readable medium containing instructions that, when executed by the processor of a video decoder, cause the processor to perform a method including the step of receiving a coded video bitstream containing a picture. The method includes the step of determining a predetermined condition associated with signaling data contained in the coded video bitstream. The method includes the step of determining the size of the indices contained in the signaling data for a candidate list of vector predictions, based on the predetermined condition and the number of merge mode candidates and the number of intrablock copy (IBC) candidates. The method includes the step of creating a candidate list using the vector predictions. The method includes the step of retrieving vector predictions from the candidate list according to indices having values ​​that do not exceed the determined size of the index. The method further includes the step of decoding the current block with the retrieved vector predictions.

[0015] A non-temporary computer-readable medium containing instructions that, when executed by the processor of a video decoder, cause the processor to perform a method that includes the step of receiving a coded video bitstream containing the current picture. The method further includes the step of extracting signaling data from the coded video bitstream for the current block. The method further includes the step of determining whether the extracted signaling data for the current block contains the maximum number of merge candidates. The method further includes the step of setting the maximum number of intra-block copy (IBC) candidates based on the determination whether the maximum number of merge candidates is contained in the signaling data for the current block.

[0016] Further features, properties, and various advantages of the disclosed subject matter will become clearer from the detailed description and accompanying drawings below. [Brief explanation of the drawing]

[0017] [Figure 1]Schematic diagram of the current block and its surrounding spatial merge candidates in one example. [Figure 2] Schematic diagram of a simplified block diagram of a communication system (200) according to one embodiment. [Figure 3] Schematic diagram of a simplified block diagram of a communication system (300) according to one embodiment. [Figure 4] Schematic diagram of a simplified block diagram of a decoder according to one embodiment. [Figure 5] Schematic diagram of a simplified block diagram of an encoder according to one embodiment. [Figure 6] Block diagram of an encoder according to another embodiment. [Figure 7] Block diagram of a decoder according to another embodiment. [Figure 8] Schematic diagram of intra picture block compensation according to one embodiment. [Figure 9A] Schematic diagram of intra picture block compensation using the search range of one coding tree unit (CTU) size according to one embodiment. [Figure 9B] Schematic diagram of intra picture block compensation using the search range of one coding tree unit (CTU) size according to one embodiment. [Figure 9C] Schematic diagram of intra picture block compensation using the search range of one coding tree unit (CTU) size according to one embodiment. [Figure 9D] Schematic diagram of intra picture block compensation using the search range of one coding tree unit (CTU) size according to one embodiment. [Figure 10A] Schematic diagram of how the buffer is updated according to an embodiment. [Figure 10B] Schematic diagram of how the buffer is updated according to an embodiment. [Figure 10C] Schematic diagram of how the buffer is updated according to an embodiment. [Figure 10D]Schematic diagram of how the buffer according to the embodiment is updated. [Figure 11A] Diagram of the decoding flowchart for the history-based MV prediction (HMVP) buffer. [Figure 11B] Schematic diagram of the update of the HMVP buffer. [Figure 12] Diagram of an exemplary decoding process according to one embodiment. [Figure 13] Diagram of an exemplary decoding process according to one embodiment. [Figure 14] Schematic diagram of a computer system according to one embodiment of the present disclosure.

Mode for Carrying Out the Invention

[0018] FIG. 2 shows a simplified block diagram of a communication system (200) according to one embodiment of the present disclosure. The communication system (200) includes a plurality of terminal devices that can communicate with each other via, for example, a network (250). For example, the communication system (200) includes a first pair (210) and (220) of terminal devices interconnected via the network (250). In the example of FIG. 2, the first pair (210) and (220) of terminal devices perform unidirectional data transmission. For example, the terminal device (210) can encode video data (e.g., a stream of video pictures captured by the terminal device (210)) for transmission to another terminal device (220) via the network (250). The encoded video data can be transmitted in the form of one or more encoded video bitstreams. The terminal device (220) can receive the encoded video data from the network (250), decode the encoded video data to restore the video picture, and display the video picture with the restored video data. Unidirectional data transmission can be common in media serving applications and the like.

[0019] In another example, the communication system (200) includes a second pair of terminal devices (230) and (240) that perform bidirectional transmission of coded video data, which may occur, for example, during a video conference. For bidirectional transmission of data, in one example, each terminal device of terminal devices (230) and (240) can encode video data (e.g., a stream of video pictures captured by the terminal device) for transmission to the other terminal device of terminal devices (230) and (240) via the network (250). Each terminal device of terminal devices (230) and (240) can also receive coded video data transmitted by the other terminal device of terminal devices (230) and (240), decode the coded video data to restore video pictures, and display the video pictures on a display device accessible by the restored video data.

[0020] In the example in Figure 2, terminals (210), (220), (230), and (240) may be represented as a server, a personal computer, and a smartphone, respectively, but the principles of this disclosure are not limited thereto. Embodiments of this disclosure are found to be applications with laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network (250) represents any number of networks that transmit coded video data between terminals (210), (220), (230), and (240), including, for example, wired (cable-wired) and / or wireless communication networks. Communication network (250) can exchange data over circuit-switched and / or packet-switched channels. Typical networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For the purposes of this description, the architecture and topology of network (250) may not be important to the operation of this disclosure unless described below herein.

[0021] Figure 3 shows an example of the application of the disclosed subject matter, illustrating the arrangement of a video encoder and video decoder in a streaming environment. The disclosed subject matter can be equally applied to other video-enabled applications, including, for example, video conferencing, digital TV, and the storage of compressed video on digital media such as CDs, DVDs, and memory sticks.

[0022] The streaming system may include a video source (301), such as a digital camera, and may include a capture subsystem (313) that creates a stream (302) of video pictures, such as uncompressed ones. In one example, the stream (302) of video pictures includes a sample captured by the digital camera. The stream (302) of video pictures, shown as a thick line to emphasize the higher data volume compared to coded video data (304) (or coded video bitstream), may be processed by an electronic device (320) including a video encoder (303) coupled to the video source (301). The video encoder (303) may include hardware, software, or a combination thereof, and may enable or implement embodiments of the disclosed subject as described in more detail below. The coded video data (304) (or coded video bitstream (304)), shown as a thin line to emphasize the lower data volume compared to the stream (302), may be stored in a streaming server (305) for future use. One or more streaming client subsystems, such as client subsystems (306) and (308) in Figure 3, can access a streaming server (305) to retrieve copies (307) and (309) of coded video data (304). Client subsystem (306) may include, for example, a video decoder (310) of an electronic device (330). The video decoder (310) decodes the input copy (307) of coded video data to create an output stream (311) of a video picture that can be rendered on a display (312) (e.g., a display screen) or another rendering device (not shown). In some streaming systems, coded video data (304), (307), and (309) (e.g., video bitstreams) may be encoded by specific video coding / compression standards. Examples of such standards include ITU-T Recommendation H.265.For example, a video coding standard under development is informally known as Multipurpose Video Coding (VVC). The disclosed subject matter may be used in the context of VVC.

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

[0024] Figure 4 shows a block diagram of a video decoder (410) according to one embodiment of the present disclosure. The video decoder (410) may be included in an electronic device (430). The electronic device (430) may include a receiver (431) (e.g., a receiving circuit). The video decoder (410) may be used in place of the video decoder (310) in the example of Figure 3.

[0025] The receiver (431) can receive one or more coded video sequences to be decoded by the video decoder (410), which in the same or different embodiments may be one coded video sequence at a time, and the decoding of each coded video sequence is independent of other coded video sequences. The coded video sequences can be received from the channel (401), which may be a hardware / software link to a storage device that stores coded video data. The receiver (431) can receive coded video data accompanied by other data, e.g., coded audio data and / or auxiliary data streams, which may be forwarded to their respective usage entities (not shown). The receiver (431) can isolate the coded video sequences from other data. To suppress network jitter, a buffer memory (415) may be coupled between the receiver (431) and the entropy decoder / parser (420) (hereafter, "Parser (420)"). In certain applications, the buffer memory (415) is part of the video decoder (410). In other cases, it may be located outside the video decoder (410) (not shown). In yet other cases, there may be a buffer memory (not shown) outside the video decoder (410), for example to suppress network jitter, and another buffer memory (415) inside the video decoder (410), for example to handle playback timing. When the receiver (431) is receiving data from a store / forward device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (415) may not be required or may be small. For use in best-effort packet networks such as the Internet, the buffer memory (415) may be required, may be relatively large, may be advantageously adaptive in size, and may be at least partially implemented in an operating system or similar element (not shown) outside the video decoder (410).

[0026] The video decoder (410) may include a parser (420) for reconstructing symbols (421) from the coded video sequence. The categories of these symbols may include information used to manage the operation of the video decoder (410), and potentially information for controlling rendering devices, such as rendering devices (412) (e.g., a display screen) that are not integral parts of the electronic device (430) but can be coupled to the electronic device (430), as shown in Figure 4. The rendering device control information may be in the form of supplemental extension information (SEI messages) or video usability information (VUI) parameter set fragments (not shown). The parser (420) can parse / entropy decode the received coded video sequence. The coding of the coded video sequence may be by video coding technique or standard and may follow various principles, including variable-length coding, Huffman coding, and arithmetic coding with or without context dependency. The parser (420) may extract from the coded video sequence, based on at least one parameter corresponding to a group, a set of at least one subgroup parameter for subgroups of pixels of the video decoder. Subgroups may include groups of pictures (GOP), pictures, tiles, slices, macroblocks, coding units (CU), blocks, transform units (TU), and predictive units (PU). The parser (420) can also extract information from coded video sequence information such as transform coefficients, quantization parameter values, and motion vectors.

[0027] The parser (420) can perform entropy decoding / parsing operations on the video sequence received from the buffer memory (415) to create symbols (421).

[0028] The reconstruction of symbol (421) may involve multiple different units, depending on the type of the encoded video picture or a part thereof (e.g., interpicture and intrapicture, interblock and intrablock), and other factors. Which units are involved and how they are involved may be controlled by subgroup control information parsed from the video sequence coded by parser (420). The flow of such subgroup control information between parser (420) and the following multiple units is not illustrated for clarity.

[0029] Beyond the functional blocks already mentioned, the video decoder (410) can be conceptually subdivided into several functional units, as described below. In actual implementations operating under commercial constraints, many of these units may interact closely with each other and be integrated, at least partially. However, for the purposes of illustrating the disclosed subject, the following conceptual subdivision into functional units is appropriate.

[0030] The first unit is the scaler / inverse unit (451). The scaler / inverse unit (451) receives control information from the parser (420) as symbols (421), including the quantized transformation coefficients, as well as the transformation to be used, block size, quantization coefficients, and quantization scaling matrix. The scaler / inverse unit (451) can output a block containing sample values ​​that can be input to the aggregator (455).

[0031] In some cases, the output samples of the scaler / inverse transform (451) may relate to an intra-encoded block, i.e., a block that does not use predictive information from a previously reconstructed picture but can use predictive information from a previously reconstructed portion of the current picture. Such predictive information may be provided by an intra-picture predictive unit (452). In some cases, the intra-picture predictive unit (452) generates a block of the same size and shape as the block being reconstructed, using the surrounding already reconstructed information fetched from the current picture buffer (458). The current picture buffer (458) buffers, for example, partially reconstructed current pictures and / or fully reconstructed current pictures. The aggregator (455) may, sample by sample, add the predictive information generated by the intra-predictive unit (452) to the output sample information provided by the scaler / inverse transform unit (451).

[0032] In other cases, the output samples of the scaler / inverse unit (451) may relate to intercoded and potentially motion-compensated blocks. In such cases, the motion-compensated prediction unit (453) can access the reference picture memory (457) to fetch samples to be used for prediction. After motion-compensating the samples fetched by the symbols (421) related to the blocks, these samples may be added by the aggregator (455) to the output of the scaler / inverse unit (451) (in this case, called residual samples or residual signals) to generate output sample information. The addresses in the reference picture memory (457) from which the motion-compensated prediction unit (453) fetches prediction samples may be controlled by motion vectors, which are available to the motion-compensated prediction unit (453) in the form of symbols (421) that may have, for example, X, Y, and reference picture components. Motion compensation may also include interpolation of sample values ​​fetched from the reference picture memory (457) when the exact motion vectors of the subsamples are used, motion vector prediction mechanisms, etc.

[0033] The output samples of the aggregator (455) may depend on various loop filtering techniques in the loop filter unit (456). The video compression technique may include in-loop filtering techniques controlled by parameters contained in the coded video sequence (also called the coded video bitstream) and made available to the loop filter unit (456) as symbols (421) from the parser (420), but may also respond to metadata obtained during decoding of previous (decoding order) parts of the coded picture or coded video sequence, or to previously reconstructed and loop-filtered sample values.

[0034] The output of the loop filter unit (456) may be a sample stream that can be output to the rendering device (412) or stored in reference picture memory (457) for use in future interpicture prediction.

[0035] A particular encoded picture, once fully reconstructed, can be used as a reference picture for future predictions. For example, once the encoded picture corresponding to the current picture is fully reconstructed and the encoded picture is identified as a reference picture (e.g., by the parser (420)), the current picture buffer (458) can become part of the reference picture memory (457), and the new current picture buffer can be reallocated before the reconstruction of the next encoded picture begins.

[0036] The video decoder (410) can perform decoding operations using a specified video compression technique of a standard such as ITU-T Rec.H.265. A coded video sequence may conform to the syntax specified in the video compression technique or standard used, in the sense that the coded video sequence conforms to both the syntax and profile of the video compression technique or standard, as documented in the video compression technique or standard. Specifically, a profile can select a particular tool from all the tools available in the video compression technique or standard as the only tool usable under that profile. Furthermore, compliance may require that the complexity of the coded video sequence be within the range defined by the level of the video compression technique or standard. In some cases, the level may limit the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limitations set by the level may, in some cases, be further limited by the virtual reference decoder (HRD) specification and the HRD buffer management metadata communicated in the coded video sequence.

[0037] In one embodiment, the receiver (431) may receive additional (redundant) data accompanying the encoded video. The additional data may be included as part of the encoded video sequence. The additional data may be used by the video decoder (410) to properly decode the data and / or to more accurately reconstruct the original video data. The additional data may take the form of, for example, a temporal, spatial, or signal-to-noise ratio (SNR) enhancement layer, redundant slices, redundant pictures, or forward error correction code.

[0038] Figure 5 shows a block diagram of a video encoder (503) according to one embodiment of the present disclosure. The video encoder (503) is included in an electronic device (520). The electronic device (520) includes a transmitter (540) (e.g., a transmitting circuit). The video encoder (503) may be used in place of the video encoder (303) in the example of Figure 3.

[0039] The video encoder (503) can receive video samples from a video source (501) (not part of the electronic device (520) in the example in Figure 5) which can capture video images encoded by the video encoder (503). In another example, the video source (501) is part of the electronic device (520).

[0040] The video source (501) can provide a source video sequence encoded by the video encoder (503) in the form of a digital video sample stream, which may be from any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, ...), any color space (e.g., BT.601 Y CrCB, RGB, ...), and any suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media serving system, the video source (501) may be a storage device that stores previously prepared video. In a video conferencing system, the video source (501) may be a camera that captures local image information as a video sequence. The video data may be provided as a series of separate pictures that give motion when viewed sequentially. The pictures themselves can be organized as a spatial array of pixels, and each pixel may contain one or more samples, depending on the sampling structure, color space, etc., in use. Those skilled in the art will readily understand the relationship between pixels and samples. The following description focuses on samples.

[0041] According to one embodiment, the video encoder (503) can encode pictures of a source video sequence in real time or under any other time constraints required by the application and compress them into a coded video sequence (543). Implementing an appropriate coding speed is one function of the controller (550). In some embodiments, the controller (550) controls and is functionally coupled to other functional units, as described below. For clarity, the couplings are not shown. Parameters set by the controller (550) may include rate control-related parameters (such as picture skip, quantizer, lambda value for rate distortion optimization technique), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. The controller (550) may be configured to have other appropriate functions for the video encoder (503) optimized for a particular system design.

[0042] In some embodiments, the video encoder (503) is configured to operate in a coding loop. In an overly simplified explanation, in one example, the coding loop may include a source coder (530) (responsible for generating symbols, such as a symbol stream, based, for example, the input picture to be encoded and a reference picture) and a (local) decoder (533) incorporated into the video encoder (503). The decoder (533) reconstructs the symbols to create sample data in a similar manner to how a (remote) decoder would also create it (since any compression between the symbols and the coded video bitstream is reversible in the video compression techniques considered in the disclosed subject). The reconstructed sample stream (sample data) is fed into the reference picture memory (534). Decoding the symbol stream yields bit-accurate results regardless of the decoder's location (local or remote), so the contents of the reference picture memory (534) are also bit-accurate between the local encoder and the remote encoder. In other words, the predictive part of the encoder "sees" the exact same sample values ​​as the reference picture samples that the decoder "sees" when using the predictions during decoding. This fundamental principle of reference picture synchronization (and the drift that occurs when synchronization cannot be maintained, for example, due to channel errors) is also used in several related techniques.

[0043] The operation of the “local” decoder (533) may be the same as that of a “remote” decoder, such as the video decoder (410), which has already been described in detail above in relation to Figure 4. However, even with a brief reference to Figure 4, since symbols are available and the encoding / decoding of symbols to the coded video sequence by the entropy coder (545) and parser (420) may be reversible, the entropy decoding portion of the video decoder (410), including the buffer memory (415) and parser (420), may not be adequately implemented in the local decoder (533).

[0044] One observation that can be made at this time is that decoder techniques other than analysis / entropy decoding present in the decoder must also be present in the corresponding encoder in substantially the same functional form. For this reason, the disclosed subject matter focuses on decoder operation. The description of encoder techniques can be omitted as it is the inverse of the comprehensively described decoder techniques. More detailed explanations are necessary only in specific areas and are provided below.

[0045] During operation, in some examples, the source coder (530) can perform motion-compensated predictive coding, which predictively encodes the input picture by referencing one or more previously encoded pictures from a video sequence designated as “reference pictures”. In this way, the coding engine (532) encodes the difference between the pixel blocks of the input picture and the pixel blocks of the reference picture which may be selected as a predictive reference to the input picture.

[0046] The local video decoder (533) can decode coded video data of a picture that may be designated as a reference picture based on symbols created by the source coder (530). The operation of the coding engine (532) may, advantageously, be a lossy process. When coded video data can be decoded by a video decoder (not shown in Figure 5), the reconstructed video sequence may be a replica of the source video sequence, usually with some errors. The local video decoder (533) can replicate the decoding process that may be performed by the video decoder on the reference picture and have the reconstructed reference picture stored in the reference picture cache (534). In this way, the video encoder (503) can locally store a copy of the reconstructed reference picture that has common content as a reconstructed reference picture (without transmission errors) acquired by the far-end video decoder.

[0047] The prediction (535) can perform a predictive search of the coding engine (532). That is, for a new picture to be encoded, the prediction (535) can retrieve the reference picture memory (534) and look for sample data (as candidate reference pixel blocks) or specific metadata such as reference picture motion vectors, block shapes, etc., which can serve as appropriate predictive references for the new picture. The prediction (535) can work on sample blocks pixel by pixel to find appropriate predictive references. In some cases, the input picture may have predictive references drawn from multiple reference pictures stored in the reference picture memory (534), as determined by the search results obtained by the prediction (535).

[0048] The controller (550) can manage the coding operations of the source coder (530), including, for example, setting parameters and subgroup parameters used to encode video data.

[0049] The outputs of all the aforementioned functional units can undergo entropy coding in the entropy coder (545). The entropy coder (545) converts the symbols generated by the various functional units into coded video sequences by lossless compression of the symbols using technologies such as Huffman coding, variable-length coding, and arithmetic coding.

[0050] The transmitter (540) can buffer the coded video sequence created by the entropy coder (545) and prepare it for transmission over the communication channel (560), which may be a hardware / software link to a storage device that stores the coded video data. The transmitter (540) can merge the coded video data from the video coder (503) with other data being transmitted, such as coded audio data and / or auxiliary data streams (source not shown).

[0051] The controller (550) can manage the operation of the video encoder (503). During coding, the controller (550) can assign a specific coded picture type to each coded picture, which may affect the coding technique that can be applied to each picture. For example, a picture may often be assigned as one of the following picture types:

[0052] An intra-picture (I-picture) may be one that can be encoded and decoded without using any other picture in the sequence as a source for prediction. Some video codecs can use various types of intra-pictures, such as independent decoder refresh ("IDR") pictures. Those skilled in the art are aware of these variations of I-pictures and their respective uses and characteristics.

[0053] A predictive picture (P-picture) may be one that can be encoded and decoded using intra-prediction or inter-prediction, which uses up to one motion vector and reference index to predict the sample value of each block.

[0054] A bidirectional predictive picture (B-picture) may be one that can be encoded and decoded using intra-prediction or inter-prediction, which uses up to two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multiple predictive pictures can use three or more reference pictures and associated metadata for the reconstruction of a single block.

[0055] A source picture is typically subdivided spatially into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each), and each block can be coded. Blocks can be coded predictively by referencing other (already coded) blocks, as determined by the coding assignment applied to each picture in the block. For example, blocks in picture I can be coded non-predictively, or they can be coded predictively by referencing already coded blocks of the same picture (spatial prediction or intra-prediction). Pixel blocks in picture P can be coded predictively via spatial prediction or via temporal prediction referencing one previously coded reference picture. Pixel blocks in picture B can be coded predictively via spatial prediction or via temporal prediction referencing one or two previously coded reference pictures.

[0056] The video encoder (503) can perform coding operations according to a predetermined video coding technique or standard, such as ITU-T Rec.H.265. In these operations, the video encoder (503) can perform various compression operations, including predictive coding operations that utilize temporal and spatial redundancy in the input video sequence. Thus, the coded video data may conform to the syntax specified by the video coding technique or standard being used.

[0057] In one embodiment, the transmitter (540) may transmit additional data accompanied by encoded video. The source coder (530) may include such data as part of the coded video sequence. The additional data may include temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, SEI messages, VUI parameter set fragments, and the like.

[0058] Video may be captured chronologically as multiple source pictures (video pictures). Intra-picture prediction (often abbreviated as intra-prediction) utilizes spatial correlations in a given picture, while inter-picture prediction utilizes (temporal or other) correlations in inter-pictures. In one example, a particular picture being encoded / decoded, called the current picture, is divided into blocks. When the blocks of the current picture are analogous to reference blocks of previously encoded and still buffered reference pictures in the video, the blocks of the current picture may be encoded by a vector called a motion vector. The motion vector points to the reference blocks of the reference pictures and may have a third dimension to identify the reference pictures if multiple reference pictures are used.

[0059] In some embodiments, a dual-prediction technique may be used for interpicture prediction. According to the dual-prediction technique, two reference pictures are used, such as a first reference picture and a second reference picture, both of which are prior to the decoding order of the current picture of the video (but may be past and future in display order, respectively). Blocks of the current picture may be encoded by a first motion vector pointing to a first reference block of the first reference picture and a second motion vector pointing to a second reference block of the second reference picture. Blocks may be predicted by combinations of the first and second reference blocks.

[0060] Furthermore, merge mode techniques can be used for interpicture prediction to improve coding efficiency.

[0061] According to some embodiments of this disclosure, predictions such as inter-picture prediction and intra-picture prediction are performed in block units. For example, according to the HEVC standard, the pictures in a sequence of video pictures are divided into coding tree units (CTUs) for compression, and the CTUs of a picture have the same size, such as 64x64 pixels, 32x32 pixels, or 16x16 pixels. Generally, a CTU contains three coding tree blocks (CTBs), which are one lumen CTB and two chroma CTBs. Each CTU can be recursively quadtree-partitioned into one or more coding units (CUs). For example, a 64x64 pixel CTU may be divided into one 64x64 pixel CU, or four 32x32 pixel CUs, or sixteen 16x16 pixel CUs. In one example, each CU is analyzed to determine the prediction type of the CU, such as inter-prediction type or intra-prediction type. The CU is divided into one or more prediction units (PUs) depending on its temporal and / or spatial predictability. Generally, each PU includes a Luma prediction block (PB) and two Chroma PBs. In one embodiment, the prediction operation in coding (encoding / decoding) is performed in units of prediction blocks. Using a Luma prediction block as an example of a prediction block, the prediction block includes a matrix of pixel values ​​(e.g., Luma values) such as 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc.

[0062] Figure 6 shows a diagram of a video encoder (603) according to another embodiment of the present disclosure. The video encoder (603) is configured to receive a processing block (e.g., a prediction block) of sample values ​​in the current video picture of a sequence of video pictures, and to encode the processing block into an encoded picture which is part of a coded video sequence. In one example, the video encoder (603) is used instead of the video encoder (303) in the example of Figure 3.

[0063] In the HEVC example, the video encoder (603) receives a matrix of sample values ​​for a processing block, such as an 8x8 sample prediction block. The video encoder (603) determines whether the processing block is best encoded using intra-mode, inter-mode, or bi-prediction mode, for example, using rate-distortion optimization. If the processing block is encoded in intra-mode, the video encoder (603) may use the intra-prediction technique to encode the processing block into an encoded picture; if the processing block should be encoded in inter-mode or bi-prediction mode, the video encoder (603) may use the inter-prediction technique or the bi-prediction technique, respectively, to encode the processing block into an encoded picture. In certain video coding techniques, the merge mode may be an inter-picture prediction submode in which the motion vector is derived from one or more motion vector predictions without benefiting from an encoded motion vector component outside the prediction. In certain other video coding techniques, there may be motion vector components applicable to the target block. In one example, the video encoder (603) includes other components, such as a mode determination module (not shown) for determining the mode of the processing block.

[0064] In the example shown in Figure 6, the video encoder (603) includes an interencoder (630), an intraencoder (622), a residual calculation unit (623), a switch (626), a residual encoder (624), a general controller (621), and an entropy encoder (625), all coupled together as shown in Figure 6.

[0065] The interencoder (630) is configured to receive a sample of the current block (e.g., a processing block), compare that block to one or more reference blocks of the reference picture (e.g., blocks of the previous and subsequent pictures), generate interprediction information (e.g., descriptions of redundant information by intercoding technique, motion vectors, and merge mode information), and compute an interprediction result (e.g., a predicted block) based on the interprediction information using any appropriate technique. In some examples, the reference picture is a decoded reference picture that is decoded based on encoded video information.

[0066] The intra encoder (622) is configured to receive a sample of the current block (e.g., a processing block), and optionally compare the block to a block already encoded in the same picture, generate quantization coefficients after the transformation, and optionally also generate intra prediction information (e.g., intra prediction direction information by one or more intra coding techniques). In one example, the intra encoder (622) also calculates an intra prediction result (e.g., a predicted block) based on the intra prediction information and a reference block in the same picture.

[0067] The general controller (621) is configured to determine general control data and control other components of the video encoder (603) based on the general control data. In one example, the general controller (621) determines the mode of a block and provides control signals to the switch (626) based on the mode. For example, if the mode is intra-mode, the general controller (621) controls the switch (626) to select the intra-mode result to be used by the residual calculation unit (623), and controls the entropy encoder (625) to select the intra-prediction information and include it in the bitstream. If the mode is inter-mode, the general controller (621) controls the switch (626) to select the inter-prediction result to be used by the residual calculation unit (623), and controls the entropy encoder (625) to select the inter-prediction information and include it in the bitstream.

[0068] The residual calculation unit (623) is configured to calculate the difference (residual data) between the received block and the prediction result selected from the intra-encoder (622) or inter-encoder (630). The residual encoder (624) is configured to operate on the residual data so as to encode the residual data in order to generate conversion coefficients. In one example, the residual encoder (624) is configured to convert the residual data from the spatial domain to the frequency domain and generate conversion coefficients. The conversion coefficients are then subjected to a quantization process to obtain quantized conversion coefficients. In various embodiments, the video encoder (603) also includes a residual decoder (628). The residual decoder (628) is configured to perform an inverse transform and generate decoded residual data. The decoded residual data can be appropriately used by the intra-encoder (622) and inter-encoder (630). For example, an interencoder (630) can generate a decoded block based on decoded residual data and interprediction information, and an intraencoder (622) can generate a decoded block based on decoded residual data and intraprediction information. In some examples, the decoded block is appropriately processed to generate a decoded picture, which can be buffered in a memory circuit (not shown) and used as a reference picture.

[0069] The entropy encoder (625) is configured to format the bitstream to include the encoded blocks. The entropy encoder (625) is configured to include various information according to an appropriate standard such as the HEVC standard. For example, the entropy encoder (625) is configured to include general control data, selected prediction information (e.g., intra-prediction information or inter-prediction information), residual information, and other appropriate information in the bitstream. Note that, according to the disclosed subject, when encoding blocks in either inter-mode or bi-prediction mode merge submode, residual information is not present.

[0070] Figure 7 shows a diagram of a video decoder (710) according to another embodiment of the present disclosure. The video decoder (710) is configured to receive an encoded picture, which is part of a coded video sequence, and to decode the encoded picture to produce a reconstructed picture. In one example, the video decoder (710) is used instead of the video decoder (310) in the example of Figure 3.

[0071] In the example shown in Figure 7, the video decoder (710) includes an entropy decoder (771), an interdecoder (780), a residual decoder (773), a reconfiguration module (774), and an intradecoder (772) coupled together as shown in Figure 7.

[0072] The entropy decoder (771) may be configured to reconstruct specific symbols from the encoded picture that represent the syntax elements that make up the encoded picture. Such symbols may include, for example, the mode in which the block is encoded (e.g., intra-mode, inter-mode, bi-prediction mode, merge sub-mode, or two of the latter two of another sub-mode), prediction information (e.g., intra-prediction information or inter-prediction information) that can identify specific samples or metadata used for prediction by the intra-decoder (772) or inter-decoder (780), respectively, and residual information, for example, in the form of quantization transformation coefficients. In one example, if the prediction mode is inter-prediction mode or bi-prediction mode, the inter-prediction information is provided to the inter-decoder (780), and if the prediction type is intra-prediction type, the intra-prediction information is provided to the intra-decoder (772). The residual information may undergo inverse quantization and be provided to the residual decoder (773).

[0073] The interdecoder (780) is configured to receive interprediction information and generate interprediction results based on the interprediction information.

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

[0075] The residual decoder (773) is configured to perform inverse quantization to extract the inversely quantized transformation coefficients, and to process the inversely quantized transformation coefficients to convert the residual from the frequency domain to the spatial domain. The residual decoder (773) may also require certain control information (including quantizer parameters (QP)), which may be provided by the entropy decoder (771) (data paths not shown here may only contain low-volume control information).

[0076] The reconstruction module (774) is configured to combine the residuals as output from the residual decoder (773) and the prediction results (possibly as output from the inter or intra prediction module) in the spatial domain to form a reconstruction block, which may be part of the reconstructed picture, which may then be part of the reconstructed video. Note that other appropriate operations, such as deblocking operations, may be performed to improve visual quality.

[0077] It should be noted that the video encoders (303), (503), and (603), as well as the video decoders (310), (410), and (710), may be implemented using any suitable technique. In one embodiment, the video encoders (303), (503), and (603), as well as the video decoders (310), (410), and (710), may be implemented using one or more integrated circuits. In another embodiment, the video encoders (303), (503), and (503), as well as the video decoders (310), (410), and (710), may be implemented using one or more processors that execute software instructions.

[0078] Block-based compensation from different pictures is sometimes called motion compensation. Block compensation can also be performed from a previously reconstructed region of the same intrapicture, which may be called intrapicture block compensation, intrablock copy (IBC), or current picture reference (CPR). For example, a displacement vector indicating the offset between the current block and the reference block is called a block vector. According to some embodiments, the block vector refers to a reference block that has already been reconstructed and is available for reference. Also, for consideration of parallel processing, reference regions beyond tile / slice boundaries or wavefront ladder boundaries may be excluded from being referenced by the block vector. Due to these constraints, the block vector may differ from the motion vector in motion compensation, which can be any value (positive or negative in either the x or y direction).

[0079] Block vector coding can be explicit or implicit. In explicit mode, sometimes called AMVP mode (Advanced Motion Vector Prediction) mode in intercoding, the difference between the block vector and its prediction is signaled. In implicit mode, the block vector is reconstructed from its prediction in a similar manner to motion vectors in merge mode. In some embodiments, the resolution of the block vector is limited to integer positions. In other embodiments, the resolution of the block vector can point to decimal positions.

[0080] The use of intrablock copying at the block level can be signaled using a block-level flag called the IBC flag. In one embodiment, the IBC flag is signaled when the block is not currently encoded in merge mode. The IBC flag can also be signaled by a reference indexing technique, which is performed by treating the currently decoded picture as a reference picture. In HEVC screen content coding (SCC), such a reference picture is placed at the end of the list. This special reference picture may be managed together with other time reference pictures in the DPB. The IBC can also include variations such as a flipped IBC (e.g., the reference block is flipped horizontally or vertically before being used to predict the current block) or a line-based (IBC) (e.g., each compensation unit in an MxN coding block is an Mx1 or 1xN line).

[0081] Figure 8 shows one embodiment of intra-picture block compensation (e.g., intra-block copy mode). In Figure 8, the current picture 800 includes a set of block regions that have already been encoded / decoded (i.e., gray squares) and a set of block regions that have not yet been encoded / decoded (i.e., white squares). One of the unencoded / decoded block regions, block 802, may be associated with a block vector 804 that points to another previously encoded / decoded block 806. Thus, any motion information associated with block 806 can be used to encode / decode block 802.

[0082] In some embodiments, the search range of the CPR mode is limited to the current CTU. The effective memory requirement for storing reference samples for the CPR mode is 1 CTU size of the sample. Considering existing reference sample memory to store samples reconstructed in the current 64x64 area, three or more 64x64 size reference sample memories are required. Embodiments of this disclosure extend the effective search range of the CPR mode to a portion of the left CTU while the total memory requirement for storing reference pixels remains unchanged (1 CTU size, a total of 4 64x64 reference sample memories).

[0083] In Figure 9A, the upper left region of the CTU 900 is the current region being decoded. When the upper left region of the CTU 900 is decoded, the entry [1] in the reference sample memory is overwritten with a sample from this region, as shown in Figure 10A (for example, the overwritten memory location has diagonal cross-hatching). In Figure 9B, the upper right region of the CTU 900 is the next current region being decoded. When the upper right region of the CTU 900 is decoded, the entry [2] in the reference sample memory is overwritten with a sample from this region, as shown in Figure 10B. In Figure 9C, the lower left region of the CTU 900 is the next current region being decoded. When the lower left region of the CTU 900 is decoded, the entry [3] in the reference sample memory is overwritten with a sample from this region, as shown in Figure 10C. In Figure 9D, the lower right region of the CTU 900 is the next current region being decoded. When the lower right region of CTU 900 is decoded, the entry in the reference sample memory [3] is overwritten with a sample from this region, as shown in Figure 10D.

[0084] In some embodiments, the valid block vector (mvL, 1 / 16-pel resolution) must conform to the bitstream compatibility conditions specified below. In some embodiments, the luma motion vector mvL must conform to the following constraints A1, A2, B1, C1, and C2.

[0085] Under the first constraint (A1), when a block availability derivation process (e.g., a neighbor block availability check process) is called with the current luma position (xCb, yCb) and the neighboring luma position (xCb+(mvL[0]>>4)+cbWidth-1, yCb+(mvL[1]>>4)+cbHeight-1) set to (xCb, yCb) as input, the output should be equal to TRUE.

[0086] Under the second constraint (A2), when a block availability derivation process (e.g., a neighbor block availability check process) is called with the current luma position (xCb, yCb) and the neighboring luma position (xCb+(mvL[0]>>4)+cbWidth-1, yCb+(mvL[1]>>4)+cbHeight-1) set to (xCb, yCb) as input, the output should be equal to TRUE.

[0087] The third constraint (B1) is that one or both of the following conditions are true: (i) The value of (mvL[0]>>4) + cbWidth is less than or equal to 0. (ii) The value of (mvL[1]>>4)+cbHeight is 0 or less.

[0088] The fourth constraint (C1) is true if the following condition is true: (i)(yCb+(mvL[1]>>4))>>CtbLog2SizeY=yCb>>CtbLog2SizeY (ii)(yCb+(mvL[1]>>4)+cbHeight-1)>>CtbLog2SizeY=yCb>>CtbLog2SizeY (iii)(xCb+(mvL[0]>>4))>>CtbLog2SizeY>=(xCb>>CtbLog2SizeY)-1 (iv)(xCb+(mvL[0]>>4)+cbWidth-1)>>CtbLog2SizeY<=(xCb>>CtbLog2SizeY)

[0089] Under the fifth constraint (C2), if (xCb+(mvL[0]>>4))>>CtbLog2SizeY is equal to (xCb>>CtbLog2SizeY)-1, then the current luma position (xCurr, yCb) set to equal (xCb, yCb) and the neighboring luma positions (((xCb+(mvL[0]>>4)+CtbSizeY)>>(CtbLog2SizeY-1))<<(CtbLog2SizeY-1), ((yCb+(mvL[1]>>4))>>(CtbLog2SizeY-1))<<(CtbLog2SizeY-1)) are inputs to a derivation process for block availability (e.g., a neighboring block availability check process), and the output is equal to FALSE.

[0090] In the above equation, xCb and yCb are the x and y coordinates of the current block, respectively. The variables cbHeight and cbWidth are the height and width of the current block, respectively. The variable CtbLog2sizeY refers to the CTU size of the log2 domain. For example, CtbLog2sizeY=7 means that the CTU size is 128×128. The variables mvL0[0] and mvL0[1] refer to the x and y components of the block vector mvL0, respectively. If the output is FALSE, it is determined that a sample of the referenced block is available (e.g., a neighboring block is available for intra-block copy use). If the output is TRUE, it is determined that a sample of the referenced block is not available.

[0091] According to some embodiments, a history-based MVP (HMVP) method includes HMVP candidates defined as motion information of previously encoded blocks. A table with multiple HMVP candidates is maintained during the encoding / decoding process. Whenever a new slice is encountered, the table is emptied. Whenever there are interencoded non-affine blocks, the associated motion information is added to the last entry in the table as a new HMVP candidate. The coding flow of the HMVP method is illustrated in Figure 11A.

[0092] The table size S is set to 6, indicating that a maximum of 6 HMVP candidates can be added to the table. When inserting a new move candidate into the table, a constrained FIFO rule is used so that a redundancy check is first applied to determine if the same HMVP already exists in the table. If found, the same HMVP is removed from the table, and then all HMVP candidates are moved forward (i.e., the index is reduced by 1). Figure 11B shows an example of inserting a new move candidate into the HMVP table.

[0093] In the merge candidate list construction process, HMVP candidates may be used. Several of the most recent HMVP candidates in the table are checked in order and inserted into the candidate list after TMVP candidates. Pruning may be applied to HMVP candidates for spatial or temporal merge candidates, excluding subblock movement candidates (i.e., ATMVP).

[0094] In some embodiments, to reduce the number of pruning operations, the number of HMVP candidates to be checked (indicated by L) is set to L = (N <= 4) ? M : (8 - N), where N is the number of available non-subblock merge candidates and M is the number of available HMVP candidates in the table. In addition, the merge candidate list construction process from the HMVP list is terminated when the total number of available merge candidates reaches the number obtained by subtracting 1 from the signaled maximum allowable merge candidate. Furthermore, the number of pairs for combined bipredictive merge candidate derivation is reduced from 12 to 6.

[0095] HMVP candidates can also be used in the AMVP candidate list construction process. After the TMVP candidates, the motion vectors of the last K HMVP candidates in the table are inserted. Only HMVP candidates with the same reference picture as the AMVP target reference picture are used in constructing the AMVP candidate list. Pruning is applied to HMVP candidates. In some applications, K is set to 4 while the AMVP list size remains unchanged (i.e., equal to 2).

[0096] According to some embodiments, when intrablock copy operates as a mode separate from intermode, a separate history buffer called HBVP may be used to store previously encoded intrablock copy block vectors. As a mode separate from interpretation, it is desirable to have a simplified block vector derivation process for intrablock copy mode. The candidate list for IBC BV prediction in AMVP mode can share the same list used in IBC merge mode (merge candidate list) with two spatial candidates + five HBVP candidates.

[0097] The merge candidate list size in IBC mode may be allocated as MaxNumMergeCand. MaxNumMergeCand may be determined by the intermode merge candidate list size MaxNumMergeCand, which in some examples is specified as six_minus_max_num_merge_cand. The variable six_minus_max_num_merge_cand may specify the maximum number of merge motion vector prediction (MVP) candidates supported in a slice subtracted from 6.

[0098] In some examples, the maximum number of merge MVP candidates, MaxNumMergeCand, can be derived as follows: Formula (1): MaxNumMergeCand=6-six_minus_max_num_merge_cand

[0099] The value of MaxNumMergeCand can be in the range of 1 to 6. In some video coding systems, the merge list size for IBC mode is signaled separately from the merge list size for intermerge mode for all I / P / B slices. This size range can be the same as the intermerge mode (e.g., 1 to 6). In some examples, the maximum number of IBC candidates, MaxNumIbcMergeCand, can be derived as follows: Formula (2): MaxNumIBCMergeCand=6-six_minus_max_num_ibc_merge_cand

[0100] In equation (2), the variable six_minus_max_num_ibc_merge_cand specifies the maximum number of IBC merge motion vector prediction (MVP) candidates supported in the slice subtracted from 6. The value of MaxNumIBCMergeCand can be in the range of 1 to 6. In some video coding systems, merge index signaling for IBC merge mode can still share the merge index signaling used for intermerge mode. In this regard, IBC merge mode and intermerge mode can share the same syntax elements for the merge index. Since the merge index is binarized using truncated rice (TR) code, the maximum length of the merge index is MaxNumMergeCand-1. However, if MaxNumIbcMergeCand is not equal to MaxNumMergeCand, a merge index signaling solution is required.

[0101] The embodiments of this disclosure may be used separately or combined in any order. Furthermore, each of the methods, encoders, and decoders according to the embodiments of this disclosure may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored in a non-temporary computer-readable medium. According to some embodiments, a term block may be interpreted as a prediction block, a coding block, or a coding unit (i.e., a CU).

[0102] According to some embodiments, the maximum merge size for merge index binarization is set to be switchable between a number of MaxNumMergeCand and a number of MaxNumIbcMergeCand. For example, if the block is currently encoded in IBC mode, the maximum merge size for the merge index is MaxNumIbcMergeCand. However, if the block is not currently encoded in IBC mode, the maximum merge size for the merge index is MaxNumMergeCand. Table 1 shows examples of syntax elements and their associated binarization.

[0103] [Table 1]

[0104] As shown in Table 1, the binarization of the merge index (i.e., merge_idx[][]) is based on whether the block is currently encoded in IBC mode. Furthermore, FL refers to a fixed length, cMax refers to the maximum possible value of a variable-length code, and eRiceParam is the rice parameter for a variable-length code. The rice parameter can be used to determine the binary code of each input value. For a truncated binary code, the rice parameter is 0.

[0105] According to some embodiments, the maximum merge size number for merge index binarization is set to the maximum number between MaxNumMergeCand and MaxNumIbcMergeCand. In an I-slice / tile group, the value of MaxNumMergeCand is not signaled, so MaxNumMergeCand can have an estimated value of 1 (i.e., the least likely value of MaxNumIbcMergeCand). Therefore, when MaxNumMergeCand is not signaled, its value is estimated to be 1, so the value of six_minus_max_num_merge_cand is estimated to be 5. Thus, in equation (1), since six_minus_max_num_merge_cand is 5, MaxNumMergeCand is equal to 1. In equation (2), the value of MaxNumIbcMergeCand is in the range of 1 to 6.

[0106] Table 2 shows the syntax and related binarization examples.

[0107] [Table 2]

[0108] As shown in Table 2, the binarization of the merge index (i.e., merge_idx[][]) is based on whether the maximum number of merge mode candidates (i.e., MaxNumMergeCand) is greater than the maximum number of IBC candidates (i.e., MaxNumIbcMergeCand).

[0109] According to some embodiments, the range of MaxNumIbcMergeCand is assumed to be less than or equal to MaxNumMergeCand. In I-slice / tile groups, the value of MaxNumMergeCand is not signaled, so the value of MaxNumMergeCand is inferred to be 6. Therefore, in equation (1), since MaxNumMergeCand is inferred to be 6, the value of six_minus_max_num_merge_cand is inferred to be 0. In some embodiments, if the signaled MaxNumIbcMergeCand value is greater than MaxNumMergeCand, MaxNumIbcMergeCand is clipped to MaxNumMergeCand. Therefore, in equation (2), when the slice type is I, the value of MaxNumIbcMergeCand is in the range of 1 to 6. However, when the slice type is P or B, the value of MaxNumIbcMergeCand is in the range of 1 to 6. Therefore, if the slice type is P or B (i.e., MaxNumMergeCand is not signaled), the value of MaxNumIbcMergeCand can be determined as follows: MaxNumIbcMergeCand = min(MaxNumIbcMergeCand, MaxNumMergeCand).

[0110] Figure 12 shows one embodiment of a video decoding process performed by a video decoder, such as a video decoder (710). The process can be started in step (S1200) when a coded video bitstream containing a picture is received. The process proceeds to step (S1202), where predetermined conditions associated with signaling data contained in the coded video bitstream are determined.

[0111] The process proceeds to step (S1204), where, based on predetermined conditions, the size of the index included in the signaling data of the vector prediction candidate list is set to either the maximum number of merge mode candidates or the number of IBC candidates. For example, the index may be a merge index included in the coded video bitstream. For example, the predetermined conditions include determining whether the current block is encoded in IBC mode. If the current block is encoded in IBC mode, the size of the index is set to MaxNumIbcMergeCand. However, if the current block is not encoded in IBC mode, the size of the index is set to MaxNumMergeCand.

[0112] As another example, a given condition includes determining whether the maximum number of merge mode candidates is greater than the maximum number of IBC candidates. If the maximum number of merge mode candidates is greater than the maximum number of IBC candidates, the index size is set to MaxNumMergeCand. However, if the maximum number of merge mode candidates is less than the maximum number of IBC candidates, the index size is set to MaxNumIbcMergeCand.

[0113] The process proceeds from step (S1204) to (S1206), where the candidate list is created with vector predictions. For example, if the current block is encoded in merge mode, the candidate list is a merge list and the vector predictions are motion vectors. In another example, if the current block is encoded in IBC mode, the candidate list is a list of block vector predictions. The process proceeds from step (S1208), where the vector predictions are retrieved from the candidate list according to an index whose value does not exceed the determined size of the index. For example, the index value used to retrieve the vector predictions from the candidate list cannot exceed the determined size of the index in step (S1204). The process proceeds to step (S1210), where the current block is decoded according to the retrieved vector predictions.

[0114] Figure 13 shows one embodiment of a video decoding process performed by a video decoder, such as a video decoder (710). The process can be started in step (S1300) when a coded video bitstream containing the current picture is received. The process proceeds to step (S1302), where signaling data is extracted from the coded video bitstream for the current block. The process proceeds to step (S1304), where it is determined whether the extracted signaling data for the current block contains the maximum number of merge candidates. For example, it is determined whether MaxNumMergeCand is signaled. As mentioned above, in some examples, MaxNumMergeCand is not signaled for I slice / tile group types, but is signaled for P or B slice / tile group types.

[0115] The process proceeds to step (S1306), where the maximum number of intrablock copy (IBC) candidates is set based on the determination of whether the signaling data for the current block contains the maximum number of merge candidates. For example, if MaxNumMergeCand is not signaled, the value of MaxNumIbcMergeCand is in the range of 1 to 6. However, if MaxNumMergeCand is signaled, the value of MaxNumIbcMergeCand is in the range of 1 to MaxNumMergeCand.

[0116] In some examples, a coding unit contains samples of both luma and chroma components. These samples of chroma components may have an independent or distinct split tree structure compared to one of the luma components. In some examples, the distinct coding tree structure starts at the CTU level. Thus, a chroma CU (e.g., a CU containing only two chroma components) can be larger than the luma-corresponding portion of the chroma CU at the corresponding sample positions.

[0117] According to some embodiments, in the first method, when a dual-tree structure is used, a chroma block can be encoded in IBC mode if at least the following conditions are met. 1. For each subblock region of the chroma CU, the collocaterum region is encoded in IBC mode. 2. All chromatic CU samples from the colocetolma region have the same block vector. 3. The derived common block vector for the entire chroma CU is a valid BV. That is, this BV points to the already reconstructed region of the current picture within a given constraint region for the chroma components.

[0118] Based on the first method, the decoder can treat the chroma CU as a whole rather than as a subblock-based CU. Therefore, it is sufficient to use a single derived BV from the collocator region (e.g., typically the upper left corner of the CU) to decode the CU.

[0119] According to some embodiments, in the second method, when a dual-tree structure is used, different conditions may be used to enable the use of chroma IBC mode in the dual-tree structure. In one embodiment, a chroma block can be encoded in IBC mode when (i) the corresponding luma samples of all chroma samples belong to the same luma coding block, and (ii) the same luma coding block is encoded in IBC mode. As an example, this condition is checked by evaluating two corners of the chroma CU. If the luma correspondence of the upper left chroma sample and the luma correspondence of the lower right chroma sample belong to the same luma coding block, then the entire corresponding luma region of the chroma CU belongs to the same luma coding block. In another embodiment, a chroma block can be encoded in IBC mode when the corresponding luma coding is performed.

[0120] Based on the second method, the decoder can treat the chroma CU as a whole rather than as a subblock-based CU. Therefore, it is sufficient to use a single derived BV from the collocatorum region (typically the upper left corner of the CU) to decode the CU.

[0121] According to some embodiments, with respect to either the first or second method relating to a dual-tree structure, the non-limiting embodiments disclosed below illustrate a method for signaling the use of chroma IBC mode in a dual tree when the above conditions in either the first or second method are met.

[0122] In one embodiment, the above constraints for using IBC mode with chroma CUs having a dual-tree structure are implemented such that a usage flag (e.g., ibc_flag) is signaled for each chroma CU when applicable. However, in this embodiment, ibc_flag is signaled as true only when all conditions of either the first method or the second method are met. Otherwise, ibc_flag is signaled as false. In some examples, if all conditions of either the first method or the second method are met, ibc_flag may also be signaled as false based on how the encoder is implemented.

[0123] In another embodiment, the above constraints for using IBC mode for chroma CUs with a dual-tree structure are implemented such that the usage flag (e.g., ibc_flag) is not signaled at all. For example, for a chroma CU with a dual-tree structure, if all conditions of the first or second method are met, the CU is encoded in IBC mode and ibc_flag is inferred to be true. Otherwise, ibc_flag is not signaled and is inferred to be false.

[0124] The techniques described above can be implemented as computer software that uses computer-readable instructions and is physically stored on one or more computer-readable media. For example, Figure 14 shows a computer system (1400) suitable for implementing a particular embodiment of the disclosed subject matter.

[0125] Computer software can be encoded using any suitable machine code or computer language, which may rely on assembly, compilation, linking, or similar mechanisms, to create code containing instructions that can be executed directly or through interpretation, microcode execution, etc., by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc.

[0126] Instructions can be executed on various types of computers or their components, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, and Internet of Things devices.

[0127] The components shown in Figure 14 for the computer system (1400) are substantially illustrative and are not intended to imply any limitations on the scope or functionality of computer software implementing embodiments of the present disclosure. The configuration of the components should not be construed as having any dependencies or requirements relating to any one or combination of components shown in the exemplary embodiments of the computer system (1400).

[0128] The computer system (1400) may include certain human interface input devices. Such human interface input devices can respond to input from one or more human users, for example, through tactile input (keystrokes, swipes, data glove movements, etc.), audio input (voices, applause, etc.), visual input (gestures, etc.), and olfactory input (not shown). Human interface devices may also be used to capture certain media that are not necessarily directly related to conscious human input, such as audio (voices, music, ambient sounds, etc.), images (scanned images, photographic images taken from still cameras, etc.), and video (2D video, 3D video including stereoscopic video, etc.).

[0129] Input human interface devices may include one or more of the following (only one of each is shown): keyboard (1401), mouse (1402), trackpad (1403), touchscreen (1410), data glove (not shown), joystick (1405), microphone (1406), scanner (1407), and camera (1408).

[0130] The computer system (1400) may also include certain human interface output devices. Such human interface output devices may stimulate the senses of one or more human users, for example, through tactile output, sound, light, and smell / taste. Such human interface output devices may include tactile output devices (e.g., tactile feedback via a touchscreen (1410), data glove (not shown), or joystick (1405), although there may also be tactile feedback devices that do not function as input devices), audio output devices (e.g., speakers (1409), headphones (not shown)), visual output devices (screens (1410), including CRT screens, LCD screens, plasma screens, and OLED screens, each with or without touchscreen input functionality, each with or without tactile feedback functionality, some of which may output two-dimensional visual output or output beyond three dimensions through means such as stereographic output, virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0131] The computer system (1400) may include human-accessible storage devices and associated media, such as optical media (1420) including CD / DVD ROM / RW with media such as CD / DVD (1421), thumb drives (1422), removable hard drives or solid-state drives (1423), legacy magnetic media such as tapes and floppy disks (not shown), and special ROM / ASIC / PLD-based devices such as security dongles (not shown).

[0132] Those skilled in the art will also understand that the term “computer-readable medium” as used in connection with the subject matter currently disclosed does not include transmission media, carrier waves, or other transient signals.

[0133] The computer system (1400) may also include interfaces to one or more communication networks. These networks may be, for example, wireless, wired, or optical. Networks may further be local, wide-area, metropolitan, vehicle and industrial, real-time, or latency-tolerant. Examples of networks include local area networks such as Ethernet, cellular networks such as Wi-Fi, GSM, 3G, 4G, 5G, and LTE, wired or wireless wide-area digital networks such as cable TV, satellite TV, and terrestrial broadcast TV, and vehicle and industrial networks such as CANBus. Certain networks generally require external network interface adapters connected to specific general data ports or peripheral buses (1449) (e.g., USB ports on the computer system (1400)), while others are generally integrated into the core of the computer system (1400) by connections to system buses, as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks, the computer system (1400) can communicate with other entities. Such communications can be unidirectional, receive-only (e.g., TV broadcasting), unidirectional transmit-only (e.g., CANbus to a specific CANbus device), or bidirectional, for example, for other computer systems using local or wide-area digital networks. As mentioned above, specific protocols and protocol stacks may be used for each of those networks and network interfaces.

[0134] The aforementioned human interface devices, human-accessible storage devices, and network interfaces may be connected to the core (1440) of the computer system (1400).

[0135] A core (1440) may include one or more central processing units (CPUs) (1441), graphics processing units (GPUs) (1442), specialized programmable processing units in the form of field-programmable gate areas (FPGAs) (1443), hardware accelerators for specific tasks (1444), and so on. These devices, along with read-only memory (ROM) (1445), random access memory (1446), and internal mass storage such as internal hard drives and SSDs (1447) that are not accessible to the user, may be connected via a system bus (1448). In some computer systems, the system bus (1448) may be accessible in the form of one or more physical plugs, allowing for expansion with additional CPUs, GPUs, etc. Peripheral devices may be connected directly to the core's system bus (1448) or via a peripheral bus (1449). Peripheral bus architectures include PCI, USB, and so on.

[0136] The CPU (1441), GPU (1442), FPGA (1443), and accelerator (1444) can work together to execute specific instructions that constitute the aforementioned computer code. This computer code may be stored in ROM (1445) or RAM (1446). Transitional data may also be stored in RAM (1446), while permanent data may be stored, for example, in internal mass storage (1447). By using cache memory that can be closely associated with one or more CPUs (1441), GPUs (1442), mass storage (1447), ROM (1445), RAM (1446), etc., high-speed storage and retrieval to any memory device may be enabled.

[0137] Computer-readable media may have computer code on them for performing various computer implementation operations. The media and computer code may be specifically designed and constructed for the purposes of this disclosure, or they may be of a type that is well known and available to people with skills in computer software technology.

[0138] As an example, and not as an limitation, an architecture, specifically a computer system (1400) having a core (1440), can provide functionality as a result of a processor (including a CPU, GPU, FPGA, accelerator, etc.) that runs software embodied in one or more tangible computer-readable media. Such computer-readable media may be user-accessible mass storage as described above, as well as media related to specific storage of the core (1440) of a non-transient nature, such as core internal mass storage (1447) or ROM (1445). Software implementing various embodiments of this disclosure may be stored in such devices and run by the core (1440). The computer-readable media may include one or more memory devices or chips, depending on the specific needs. The software may cause the core (1440), in particular the processor (including a CPU, GPU, FPGA, etc.) therein, to run specific processes or specific parts of specific processes described herein, including defining data structures stored in RAM (1446) and modifying such data structures by processes defined by the software. In addition, or as an alternative, a computer system may provide functionality as a result of logic wired to or otherwise embodied in circuits (e.g., accelerators (1444)) that can operate in place of or in conjunction with software to perform specific processes or specific parts of specific processes described herein. References to software may include logic, and vice versa, as may be permitted. References to computer-readable media may, as may be permitted, include circuits that house software for execution (such as integrated circuits (ICs)), circuits that embody logic for execution, or both. This disclosure encompasses any suitable combination of hardware and software.

[0139] Appendix A: Acronyms JEM Joint Exploration Model VVC Multipurpose Video Coding BMS Benchmark Set MV motion vector HEVC High Efficiency Video Coding SEI Supplemental Enhancement Information VUI (Video User Interface) Video Usability Information GOP Pictures group TU conversion unit, PU Prediction Unit CTU Coding Tree Unit CTBs (Coding Tree Blocks) PB prediction block HRD Virtual Reference Decoder SNR (Signal-to-Noise Ratio) CPU (Central Processing Unit) GPU (Graphics Processing Unit) CRT cathode ray tube LCD liquid crystal display OLED (Organic Light-Emitting Diode) CD Compact Disc DVD Digital Video Disc ROM (Read-only memory) RAM (Random Access Memory) ASIC (Application-Specific Integrated Circuit) PLD (Programmable Logic Device) LAN (Local Area Network) GSM (Global System for Mobile Communications) LTE Long-Term Evolution CANBus Controller Area Network Bus USB Universal Serial Bus PCI peripheral component interconnection FPGA Field Programmable Gate Area SSD Solid State Drive IC Integrated Circuit CU Coding Unit

[0140] While this disclosure describes several exemplary embodiments, there are many variations, permutations, and alternative equivalents that fall within the scope of this disclosure. Those skilled in the art will therefore understand that numerous systems and methods, not expressly shown or described herein, can be devised to embody the principles of this disclosure and thus fall within its spirit and scope.

[0141] (1) A video decoding method includes the steps of receiving a coded video bitstream containing a picture, determining a predetermined condition associated with signaling data contained in the coded video bitstream, determining the size of the index contained in the signaling data for a candidate list of vector predictions based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates, based on the predetermined condition, creating a candidate list of vector predictions, retrieving vector predictions from the candidate list according to the index having a value that does not exceed the determined size of the index, and decoding the current block with the retrieved vector predictions.

[0142] (2) A method for video decoding according to feature (1), wherein the predetermined condition includes the step of determining whether the current block is encoded in IBC mode.

[0143] (3) A video decoding method according to feature (2), wherein the size of the index is set to the maximum number of IBC candidates depending on whether it is determined that the block is currently encoded in IBC mode, and the size of the index is set to the maximum number of merge mode candidates depending on whether it is determined that the block is currently not encoded in IBC mode.

[0144] (4) A video decoding method according to any one of features (1) to (3), the predetermined condition comprising the step of determining whether the maximum number of merge mode candidates is greater than the maximum number of IBC candidates.

[0145] (5) A video decoding method according to feature (4), wherein the size of the index is set to the maximum number of merge mode candidates when it is determined that the maximum number of merge mode candidates is greater than the maximum number of IBC candidates, and the size of the index is set to the maximum number of IBC candidates when it is determined that the maximum number of merge mode candidates is less than the maximum number of IBC candidates.

[0146] (6) A video decoding method includes the steps of receiving a coded video bitstream containing the current picture, extracting signaling data from the coded video bitstream of the current block, determining whether the extracted signaling data for the current block contains the maximum number of merge candidates, and setting the maximum number of intrablock copy (IBC) candidates based on the determination of whether the signaling data for the current block contains the maximum number of merge candidates.

[0147] (7) A video decoding method by feature (6), wherein, in response to the determination that the signaling data does not contain the maximum number of merge candidates, the maximum number of IBC candidates is set to a value between 1 and 6.

[0148] (8) A video decoding method by feature (7), wherein, depending on the decision that the maximum number of merge candidates is included in the signaling data, the maximum number of IBC candidates is set to a value between 1 and the maximum number of merge candidates.

[0149] (9) A video decoding device for video decoding includes a processing circuit configured to receive a coded video bitstream containing a picture, determine a predetermined condition associated with signaling data contained in the coded video bitstream, determine the size of the indices contained in the signaling data for a candidate list of vector predictions based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates based on the predetermined condition, create a candidate list of vector predictions, extract vector predictions from the candidate list according to indices having values ​​that do not exceed the determined size of the index, and decode the current block according to the extracted vector predictions.

[0150] (10) A video decoding device according to feature (9), comprising a processing circuit configured to determine whether a given condition is currently encoding a block in IBC mode.

[0151] (11) A video decoding device according to feature (10), wherein, in response to a determination that a block is currently encoded in IBC mode, the processing circuit is configured to set the size of the index to the maximum number of IBC candidates, and in response to a determination that a block is not currently encoded in IBC mode, the processing circuit is configured to set the size of the index to the maximum number of merge mode candidates.

[0152] (12) A video decoding device according to any one of features (9) to (12), wherein the predetermined condition includes determining whether the maximum number of merge mode candidates is greater than the maximum number of IBC candidates.

[0153] (13) The video decoding device of feature (12), wherein, in response to a determination that the maximum number of merge mode candidates is greater than the maximum number of IBC candidates, the processing circuit is further configured to set the size of the index to the maximum number of merge mode candidates, and in response to a determination that the maximum number of merge mode candidates is less than the maximum number of IBC candidates, the processing circuit is further configured to set the size of the index to the maximum number of IBC candidates.

[0154] (14) A video decoder device for video decoding, comprising a processing circuit configured to receive a coded video bitstream containing a picture, extract signaling data from the coded video bitstream of the current block, determine whether the extracted signaling data of the current block contains the maximum number of merge candidates, and set the maximum number of intra-block copy (IBC) candidates based on the determination whether the maximum number of merge candidates is contained in the signaling data of the current block.

[0155] (15) A video decoder for feature (14), wherein, in response to the decision that the signaling data does not contain the maximum number of merge candidates, the maximum number of IBC candidates is set to a value between 1 and 6.

[0156] (16) A video decoder by feature (15), wherein, depending on the decision that the maximum number of merge candidates is included in the signaling data, the maximum number of IBC candidates is set to a value between 1 and the maximum number of merge candidates.

[0157] (17) A non-temporary computer-readable medium storing instructions that, when executed by the processor of a video decoder, cause the processor to perform a method including the steps of: receiving a coded video bitstream containing a current picture; determining a predetermined condition associated with signaling data contained in the coded video bitstream; determining the size of an index contained in the signaling data for a candidate list of vector predictions based on the predetermined condition, based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates; creating a candidate list of vector predictions; retrieving a vector prediction from the candidate list according to an index having a value not exceeding the determined size of the index; and decoding the current block according to the retrieved vector prediction.

[0158] (18) A non-temporary computer-readable medium according to feature (17), the step of determining whether a given condition is currently encoded in IBC mode.

[0159] (19) A non-temporary computer-readable medium storing instructions that, when executed by the processor of a video decoder, cause the processor to perform a method including the steps of receiving a coded video bitstream containing a current picture, extracting signaling data from the coded video bitstream of the current block, determining whether the extracted signaling data for the current block contains the maximum number of merge candidates, and setting the maximum number of intra-block copy (IBC) candidates based on the determination of whether the signaling data for the current block contains the maximum number of merge candidates.

[0160] (20) A non-temporary computer-readable medium by feature (19), wherein, in response to the decision that the signaling data does not contain the maximum number of merge candidates, the maximum number of IBC candidates is set to a value between 1 and 6. [Explanation of symbols]

[0161] 101 Currently Blocked 102 samples 103 samples 104 samples 105 samples 106 samples 200 Communication Systems 210 Terminal devices 220 terminal devices 230 terminal devices 240 terminal devices 250 Networks 300 Communication Systems 301 Video Sources 302 Video picture stream 303 Video Encoder 304 coded video data 305 Streaming Server 306 Client Subsystem 307 Coded video data 308 Client Subsystem 309 Coded video data 310 Video Decoder 311 Video picture output stream 312 displays 313 Capture Subsystem 320 Electronic Devices 330 Electronic Devices 401 Channel 410 Video Decoder 412 rendering devices 415 buffer memory 420 Parser 421 Symbols 430 Electronic Devices 431 Receiver 451 Scaler / Inverse Conversion Unit 452 Intra Prediction Units 453 Motion Compensation Prediction Unit 455 Aggregator 456 Loop Filter Unit 457 Reference Picture Memory 458 Current picture buffer 501 Video Sources 503 Video Encoder 520 Electronic Devices 530 Source Coder 532 Coding Engine 533 Decoder 534 Reference Picture Memory 535 Prediction 540 Transmitter 543 coded video sequences 545 Entropy Coder 550 Controller 560 channels 603 Video Encoder 621 General Controller 622 Intra Encoders 623 Residual calculation section 624 residual encoder 625 Entropy Encoder 626 switches 628 Residual Decoder 630 Interencoders 710 Video Decoder 771 Entropy Decoder 772 Intra Decoder 773 Residual Decoder 774 Reconfiguration Module 780 Interdecoder 800 Current Picture 802 blocks 804 Block Vectors 806 blocks 900 Coding Tree Unit (CTU) 1400 Computer Systems 1401 Keyboard 1402 Mouse 1403 Trackpad 1405 Joystick 1406 Mike 1407 Scanner 1408 Camera 1409 Output Device 1410 screen 1420 Optical media including CD / DVD ROM / RW 1421 DVDs and other media 1422 Thumb Drive 1423 Removable hard drive or solid state drive 1440 cores 1441 Central Processing Unit (CPU) 1442 Graphics Processing Units (GPUs) 1443 Field-Programmable Gate Area (FPGA) 1444 Hardware accelerators for specific tasks 1445 Read-only memory (ROM) 1446 random access memory 1447 Internal large-capacity storage 1448 System Bus 1449 Local buses 1450 Graphics Adapter 1454 Network Interface

Claims

1. A method of video decoding, The current step is to receive a coded video bitstream that includes a picture, A step of determining a merge index associated with signaling data contained in the coded video bitstream, A step of determining the maximum value of the merge index, cMax, wherein cMax is set to the larger of the maximum number of merge mode candidates (MaxNumMergeCand) or the maximum number of IBC merge candidates (MaxNumIbcMergeCand) minus 1. A step of determining the size of the index included in the signaling data for the candidate list of vector predictions based on the cMax, The steps include creating the aforementioned candidate list using vector prediction, The steps include: extracting a vector prediction from the candidate list according to the index having a value that does not exceed the determined size of the index; The steps include: decoding the current block contained in the current picture according to the extracted vector prediction; Video decoding methods, including [specific method / technique].

2. The method according to claim 1, wherein the value of MaxNumMergeCand is presumed to be 6 when the signaling data is an I-slice / tile group.

3. The method according to claim 1, wherein if MaxNumIbcMergeCand is greater than MaxNumMergeCand, then MaxNumIbcMergeCand is equal to MaxNumMergeCand.

4. The method according to claim 1, wherein, if the signaling data is a P slice or a B slice, the value of MaxNumIbcMergeCand is set to the smaller of MaxNumIbcMergeCand and MaxNumMergeCand.

5. A video decoding device configured to perform the method described in any one of claims 1 to 4.

6. A computer program for causing a computer to perform the method described in any one of claims 1 to 4.

Images