RU2793708C1 - Method and device for transmitting predictor candidate list size for intra-frame block compensation - Google Patents

Abstract

FIELD: video coding.

SUBSTANCE: video decoding method is provided, and comprises the receipt of an encoded video bitstream including a current image, and also includes determining a predetermined condition associated with transmission data included in the encoded video bitstream; determining, based on a predetermined condition, of an index size included in the transmission data for the vector predictor candidate list based on the number of merge mode candidates and the number of intrablock copy candidates (IBC); building a list of candidates with vector predictors; extracting a vector predictor from the list of candidates according to an index whose value does not exceed a certain index size; and decoding the current block in accordance with the extracted vector predictor.

EFFECT: increase in the efficiency of video coding/decoding.

7 cl, 21 dwg, 2 tbl

Description

INCLUSION BY LINK

[1] This disclosure claims the benefit of priority of U.S. Patent Application No. 16/863,661 "METHOD AND APPARATUS FOR TRANSMITTING THE SIZE OF A PREDICTOR CANDIDATE LIST FOR INTRA-FRAME BLOCK COMPENSATION", filed April 30, 2020, which claims the benefit of priority of U.S. Provisional Application No. 62 /904,307 “PREDICTION METHODS FOR INTRAFRAME BLOCK EVENT” filed September 23, 2019 and U.S. Provisional Application No. 62/873,044 “TRANSFER OF PREDICTOR CANDIDATE LIST SIZE FOR INTRAFRAME BLOCK EVENT” filed July 11, 2019 Full disclosure of prior applications in full included in the present description by reference.

FIELD OF TECHNOLOGY TO WHICH THE INVENTION RELATES

[2] The present disclosure describes embodiments primarily related to video coding.

BACKGROUND OF THE INVENTION

[3] The description of the prior art provided herein is intended to provide a general overview of the context of the disclosure. The work of the currently named inventors, to the extent that it is described in this section of the description of the prior art, as well as aspects of the description that would otherwise not be considered prior art at the time of filing, are neither expressly nor impliedly recognized in as prior art with respect to the present disclosure.

[4] Video encoding and decoding may be performed using motion-compensated inter-picture prediction. Uncompressed digital video may include a series of images, each image having a spatial size of, for example, 1920×1080 luma samples and associated chrominance samples. A series of images can have a fixed or variable image rate (informally also known as frame rate), such as 60 images per second or 60 Hz. Uncompressed video has significant bitrate requirements. For example, 1080p60 4:2:0 video at 8 bits per sample (1920x1080 brightness sample resolution at 60Hz frame rate) requires bandwidth close to 1.5Gbps. An hour of such video requires more than 600 GB of disk space.

[5] One of the goals of video encoding and decoding may be to reduce the redundancy of the input video signal through compression. Compression can help reduce the aforementioned bandwidth or storage requirements, in some cases by two orders of magnitude or more. Both lossless and lossy compression, as well as a combination of both, can be used. Lossless compression refers to techniques where an exact copy of the original signal can be reconstructed from the compressed original signal. When lossy compression is used, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signals is small enough to make the reconstructed signal useful for the intended application. In the case of video, lossy compression is widely used. The amount of distortion allowed depends on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio may reflect the following: higher distortion resolution/tolerance may result in a higher compression ratio.

[6] Motion compensation may be a lossy compression technique and may refer to techniques in which a block of sample data from a previously reconstructed image or part of it (reference image) after a spatial shift in the direction indicated by the motion vector (hereinafter MV) is used for prediction newly reconstructed image or part of an image. In some cases, the reference image may be the same as the image currently being restored. The MVs may have two X and Y dimensions, or three dimensions, with the third being indicative of the reference picture used (the latter, indirectly, may be a time dimension).

[7] In some video compression techniques, the MV applicable to a certain region of the sample data can be predicted from other MVs, for example, those belonging to another region of the sample data, spatially adjacent to the region being reconstructed and preceding this MV in decoding order. This can greatly reduce the amount of data required for MV encoding, thereby eliminating redundancy and increasing the compression rate. MV prediction can work efficiently, for example, because when encoding a video input signal received from a camera (known as natural video), there is a statistical probability that areas larger than the area to which a single MV is applied move in a similar direction and, therefore, in some cases, can be predicted using a similar motion vector obtained from the MV of the neighboring area. This results in the MV found for a given region being similar or identical to the MV predicted from the surrounding MVs, which in turn can be represented after entropy encoding in fewer bits than what would be used in MV encoding directly. In some cases, MV prediction may be an example of lossless compression of a signal (namely MV) derived from the original signal (namely a stream of samples). In other cases, the MV prediction itself may be lossy, for example, due to rounding errors when computing a predictor from multiple surrounding MVs.

[8] Various MV prediction mechanisms are described in H.265/HEVC (ITU-T Rec. H.265, "High Efficiency Video Coding", December 2016). Of the many MV prediction mechanisms that H.265 offers, a method hereinafter referred to as "spatial fusion" is described.

[9] As shown in FIG. 1, the current block (101) contains samples that were detected by the encoder during the motion search process as being predicted from a previous block of the same size that was spatially shifted. Instead of encoding this MV directly, the MV can be obtained from the metadata associated with one or more reference pictures, for example, from the most recent (in decoding order) reference picture, using the MV associated with one of the five surrounding samples, denoted A0 , A1 and B0, B1, B2 (102-106 respectively). In H.265, MV prediction may use predictors from the same reference picture as the neighboring block uses. The procedure for generating a list of candidates can be

DISCLOSURE OF THE INVENTION

[10] According to an exemplary embodiment, a video decoding method includes receiving an encoded video bitstream including a current picture. The method includes determining a predetermined condition associated with transmission data included in an encoded video bitstream. The method includes determining, based on a predetermined condition, an index size included in the transmission data for the vector predictor candidate list based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates. The method includes constructing a candidate list with vector predictors. The method includes extracting a vector predictor from the candidate list according to an index whose value does not exceed a certain index size. The method further includes decoding the current block in accordance with the extracted vector predictor.

[11] According to an exemplary embodiment, a video decoding method includes receiving an encoded video bitstream including a current picture. The method further includes extracting transmission data from the encoded video bitstream for the current block. The method further includes determining whether the maximum number of merge candidates is included in the extracted transmission data for the current block. The method further includes setting a maximum number of intra-block copy candidates (IBC) based on determining whether the maximum number of merge candidates is included in the transmission data for the current block.

[12] According to an exemplary embodiment, a video decoding apparatus for decoding a video includes a processing circuit configured to receive an encoded video bitstream including a current picture. The processing circuit is further configured to determine a predetermined condition associated with transmission data included in the encoded video bitstream. The processing circuit is further configured to determine, based on a predetermined condition, an index size included in the transmission data for the vector predictor candidate list based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates. The processing circuit is further configured to build a candidate list with vector predictors, extract a vector predictor from the candidate list according to an index whose value does not exceed a certain index size. The processing circuit is further configured to decode the current block in accordance with the extracted vector predictor.

[13] According to an exemplary embodiment, a video decoder apparatus for decoding video includes a processing circuit configured to receive an encoded video bitstream including a current picture. The processing circuit is further configured to extract transmission data from the encoded video bitstream for the current block. The processing circuit is further configured to determine whether the maximum number of merge candidates is included in the extracted transmission data for the current block. The processing circuit is further configured to set a maximum number of intra-block copy candidates (IBC) based on determining whether the maximum number of merge candidates is included in the transmission data for the current block.

[14] A non-transitory computer-readable storage medium containing instructions stored thereon that, when executed by a processor in a video decoder, cause the processor to perform a method that includes receiving an encoded video bitstream including a current picture. The method includes determining a predetermined condition associated with transmission data included in an encoded video bitstream. The method includes determining, based on a predetermined condition, an index size included in the transmission data for the vector predictor candidate list based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates. The method includes constructing a candidate list with vector predictors. The method includes extracting a vector predictor from the candidate list according to an index whose value does not exceed a certain index size. The method further includes decoding the current block in accordance with the extracted vector predictor.

[15] A non-transitory computer-readable storage medium having instructions stored thereon that, when executed by a processor in a video decoder, cause the processor to perform a method that includes receiving an encoded video bitstream including a current picture. The method further includes extracting transmission data from the encoded video bitstream for the current block. The method further includes determining whether the maximum number of merge candidates is included in the extracted transmission data for the current block. The method further includes setting a maximum number of intra-block copy candidates (IBC) based on determining whether the maximum number of merge candidates is included in the transmission data for the current block.

BRIEF DESCRIPTION OF THE DRAWINGS

[16] Additional features, essence and various advantages of the disclosed subject matter will be more apparent from the following detailed description and the accompanying drawings, in which:

[17] - in Fig. 1 is a schematic illustration of the current block and its surrounding spatial merge candidates in one example;

[18] - in Fig. 2 is a schematic illustration of a simplified block diagram of a communications system (200) in accordance with an embodiment;

[19] - in Fig. 3 is a schematic illustration of a simplified block diagram of a communications system (300) in accordance with an embodiment;

[20] - in Fig. 4 is a schematic illustration of a simplified block diagram of a decoder according to an embodiment;

[21] - in Fig. 5 is a schematic illustration of a simplified block diagram of an encoder according to an embodiment;

[22] - in Fig. 6 is a block diagram of an encoder according to another embodiment;

[23] - in Fig. 7 is a block diagram of a decoder according to another embodiment;

[24] - in Fig. 8 is a schematic illustration of an intra-frame block compensation according to an embodiment;

[25] - in Fig. 9A-9D are schematic illustrations of intra-frame block compensation with a search range of one coding tree unit (CTU) size, according to an embodiment;

[26] - in Fig. 10A-10D show a schematic illustration of how a buffer is updated, in accordance with embodiments;

[27] - in Fig. 11A is an illustration of a decoding block diagram for a history-based MV prediction buffer (HMVP);

[28] - in Fig. 11B is a schematic illustration of an HMVP buffer update;

[29] - in Fig. 12 is an illustration of an exemplary decoding process according to an embodiment;

[30] - in Fig. 13 is an illustration of an exemplary decoding process according to an embodiment;

[31] - in Fig. 14 is a schematic illustration of a computer system in accordance with an embodiment of the present disclosure.

IMPLEMENTATION OF THE INVENTION

[32] FIG. 2 illustrates a simplified block diagram of a communications system (200) according to an embodiment of the present disclosure. The communication system (200) includes a plurality of terminal devices that can communicate with each other, for example, via a network (250). For example, the communication system (200) includes a first pair of terminals (210) and (220) interconnected via a network (250). In the example of FIG. 2, the first pair of terminals (210) and (220) performs a unidirectional data transfer. For example, terminal (210) may encode video data (eg, a video stream that is captured by terminal (210)) for transmission to another terminal (220) over network (250). The encoded video data may be transmitted in the form of one or more encoded video bitstreams. The terminal device (220) may receive the encoded video data from the network (250), decode the encoded video data to recover the video images, and display the video images in accordance with the recovered video data. One-way communication may be common in media serving applications and the like.

[33] In another example, the communication system (200) includes a second pair of terminals (230) and (240) that perform bidirectional transmission of encoded video data, which may occur, for example, during a video conference. For bidirectional data transfer, in the example, each terminal of terminals (230) and (240) can encode video data (for example, a video stream that is captured by the terminal) for transmission to another terminal of terminals (230) and (240). ) through the network (250). Each terminal of terminals (230) and (240) can also receive encoded video data transmitted by another terminal from terminals (230) and (240) and can decode the encoded video data to reconstruct video images, and can display video images on an accessible device. display according to the recovered video data.

[34] In the example of FIG. 2 terminal devices (210), (220), (230), and (240) can be illustrated as servers, personal computers, and smartphones, but the principles of the present disclosure cannot be limited to this. Embodiments of the present disclosure find application in laptop computers, tablet computers, media players, and/or specialized video conferencing equipment. Network (250) is any number of networks that transmit encoded video data between terminals (210), (220), (230) and (240), including, for example, wired (wired) and/or wireless communication networks. The communication network (250) may communicate on circuit-switched and/or packet-switched channels. Representative networks include telecommunications networks, local area networks, wide area networks and/or the Internet. For the purposes of this discussion, the architecture and topology of the network (250) may not be essential to the operation of this disclosure, unless explained herein below.

[35] FIG. 3 illustrates, as an example of application for the disclosed subject matter, the placement of a video encoder and a video decoder in a streaming environment. The disclosed subject matter may be equally applicable to other video-enabled applications including, for example, videoconferencing, digital television, storage of compressed video on digital media including CD, DVD, memory card, etc., and so on. .

[36] The streaming system may include a capture subsystem (313), which may include a video source (301), such as a digital camera, producing, for example, a video stream (302) that is not compressed. In an example, the video stream (302) includes samples taken by a digital camera. The video stream (302), shown in bold to emphasize the large amount of data compared to the encoded video data (304) (or encoded video bitstreams), may be processed by an electronic device (320) that includes a video encoder (303) connected to the video source (301). The video encoder (303) may include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter, as described in more detail below. Encoded video data (304) (or encoded video bitstream (304)), depicted with a thin line to emphasize the smaller amount of data compared to the video stream (302), can be stored on the streaming server (305) for future use. One or more streaming client subsystems, such as client subsystems (306) and (308) in FIG. 3 can access the streaming server (305) to extract copies (307) and (309) of the encoded video data (304). The client subsystem (306) may include a video decoder (310), such as in an electronic device (330). The video decoder (310) decodes the incoming copy (307) of the encoded video data and creates an outgoing stream (311) of video images that can be rendered on a display (312) (eg, a display screen) or other rendering device (not shown). In some streaming systems, encoded video data (304), (307), and (309) (eg, video bitstreams) may be encoded according to certain video coding/compression standards. Examples of these standards include ITU-T Recommendation H.265. In one example, the video coding standard under development is informally known as Universal Video Coding (VVC). The expanded object can be used in a VVC context.

[37] It should be noted that the 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).

[38] FIG. 4 shows a block diagram of a video decoder (410) according to an embodiment of the present disclosure. The video decoder (410) may be included in the electronic device (430). The electronic device (430) may include a receiver (431) (eg, receiver circuitry). Video decoder (410) may be used instead of video decoder (310) in the example of FIG. 3.

[39] The receiver (431) may receive one or more encoded video sequences to be decoded by the video decoder (410); in the same or different embodiment, one coded video sequence at a time, where the decoding of each coded video sequence is independent of other coded video sequences. An encoded video sequence may be received from a channel (401), which may be a hardware/software connection to a storage device that stores the encoded video data. The receiver (431) may receive encoded video data with other data, such as encoded audio data and/or ancillary data streams, which may be sent to their respective using entities (not shown). The receiver (431) may separate the encoded video sequence from other data. A buffer memory (415) can be connected between the receiver (431) and the entropy decoder/parser (420) (hereinafter "parser (420)") to combat jitter in the network. In some applications, the buffer memory (415) is part of the video decoder (410). In other cases, it may be outside the video decoder (410) (not shown). In other cases, there may be a buffer memory (not shown) outside the video decoder (410), for example, to combat network jitter, and, in addition, another buffer memory (415) inside the video decoder (410), for example, to handle playback time. When the receiver (431) receives data from a storage/transfer device with sufficient bandwidth and controllability, or from an isosynchronous network, buffer memory (415) may not be needed or may be small. For use in best quality packet networks such as the Internet, a buffer memory (415) may be required, which may be relatively large and may preferably be of an adaptive size, and may be at least partially implemented in an operating system or similar elements (not shown) outside the video decoder (410).

[40] The video decoder (410) may include a parser (420) for recovering the symbols (421) from the encoded video sequence. The categories of these symbols include information used to control the operation of the video decoder (410) and potentially information to control a rendering device such as a rendering device (412) (e.g., a display screen) that is not an integral part of the electronic device (430), but may be connected to an electronic device (430) as shown in FIG. 4. The control information for the rendering device(s) may be in the form of additional extended information (SEI messages) or video usability information (VUI) parameter set fragments (not shown). The parser (420) may parse/entropy decode the received encoded video sequence. Encoding of the encoded video sequence may be in accordance with a video coding technology or standard and may follow various principles including variable length coding, Huffman coding, arithmetic coding with or without context sensitivity, and so on. The parser (420) may extract from the encoded video sequence a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder based on at least one parameter corresponding to the group. Subgroups may include groups of pictures (GOPs), pictures, tiles, slices, macroblocks, coding units (CUs), blocks, transform units (TUs), prediction units (PUs), and so on. The parser (420) may also extract information from the encoded video sequence, such as transform coefficients, quantizer parameter values, motion vectors, and so on.

[41] The parser (420) may perform an entropy decoding/parsing operation of the video sequence received from the buffer memory (415) to create symbols (421).

[42] Symbol recovery (421) may include many different modules depending on the type of encoded video image or parts thereof (such as: external and internal image, external and internal block) and other factors. Which modules are involved and how can be controlled by the subgroup control information that has been parsed from the encoded video sequence by the parser (420). The flow of such subgroup control information between the parser (420) and the plurality of modules is not shown below for clarity.

[43] In addition to the functional blocks already mentioned, the video decoder (410) can be conceptually subdivided into a number of functional modules, as described below. In a practical implementation operating under commercial constraints, many of these modules interact closely with each other and can be at least partially integrated into each other. However, for purposes of describing the disclosed subject matter, the conceptual division into functional modules below is appropriate.

[44] The first module is the scaling/inverse transform module (451). The scaling/inverse transform module (451) receives the quantized transform coefficient, as well as control information, including which transform to use, block size, quantization factor, quantization scaling matrices, and so on, in the form of symbol(s) (421) from the parser ( 420). The scaling/inverse transform module (451) may output blocks containing sample values that may be input to the aggregator (455).

[45] In some cases, the output samples of the scaling/inverse transform module (451) may refer to an intra-coded block; that is, to a block that does not use prediction information from previously restored images, but can use prediction information from previously restored portions of the current image. Such prediction information may be provided by the intra prediction module (452). In some cases, the intra-prediction module (452) generates a block of the same size and shape as the reconstructed block, using the already recovered surrounding information retrieved from the current image buffer (458). The current picture buffer (458) buffers, for example, a partially restored current picture and/or a fully restored current picture. The aggregator (455), in some cases, adds for each sample the prediction information generated by the intra prediction module (452) to the sample output information provided by the scaling/inverse transform module (451).

[46] In other cases, the output samples of the scaling/inverse transform module (451) may refer to an inter-coded block and potentially motion-compensated. In such a case, the motion compensation prediction module (453) may access the reference picture memory (457) to retrieve samples used for prediction. After compensating for the movement of the selected samples according to the symbols (421) associated with the block, these samples can be added by the aggregator (455) to the output of the scaling/inverse transform module (451) (in this case called residual samples or residual signal) to generate output information. The addresses in the reference picture memory (457) from where the motion compensation prediction module (453) selects prediction samples may be controlled by the motion vectors available to the motion compensation prediction module (453) in the form of symbols (421), which may have, for example, components X, Y and reference image. Motion compensation may also include interpolation of sample values retrieved from the reference picture memory (457) when accurate sub-sample motion vectors are used, motion vector prediction mechanisms, and so on.

[47] The output samples of the aggregator (455) may be subjected to various loop filtering methods in the loop filter module (456). The video compression technologies may include in-loop filtering technologies that are controlled by parameters included in the encoded video sequence (also referred to as the encoded video bitstream) and provided to the loop filtering module (456) as symbols (421) from the parser (420), but may also respond to the metainformation received during the decoding of the previous (in the order of decoding) parts of the encoded image or encoded video sequence, as well as to respond to the sample values previously restored and filtered by the loop.

[48] The output of the loop filter module (456) may be a stream of samples that can be output to the renderer (412) and also stored in the reference picture memory (457) for use in future inter-picture prediction.

[49] Certain encoded pictures after full recovery can be used as reference pictures for future prediction. For example, after the encoded picture corresponding to the current picture is completely restored and the encoded picture has been identified as a reference picture (eg, by the parser (420)), the current picture buffer (458) may become part of the reference picture memory (457), and the buffer of the fresh current picture may be reallocated before starting the reconstruction of the next encoded picture.

[50] The video decoder (410) may perform decoding operations according to a predetermined video compression technology in a standard such as ITU-T Rec. H.265. The encoded video sequence may conform to the syntax specified by the video compression technology or standard being used, in the sense that the encoded video sequence conforms to both the syntax of the video compression technology or standard and the profiles documented in the video compression technology or standard. In particular, a profile may select certain tools as the only tools available for use in that profile, from among all the tools available in a video compression technology or standard. It may also be necessary for compliance that the complexity of the encoded video sequence be within limits defined by the level of technology or video compression standard. In some cases, levels limit the maximum image size, the maximum frame rate, the maximum recovery sampling rate (measured in megasamples per second, for example), the maximum reference image size, and so on. The limits set by the layers may, in some cases, be further constrained by hypothetical reference decoder (HRD) specifications and metadata for managing the HRD buffer transmitted in the encoded video sequence.

[51] In an embodiment, the receiver (431) may receive additional (redundant) data with encoded video. Additional data may be included as part of the encoded video sequence(s). The additional data may be used by the video decoder (410) to correctly decode the data and/or to more accurately reconstruct the original video data. The additional data may be in the form of, for example, temporal, spatial or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant images, forward error correction codes, and so on.

[52] FIG. 5 shows a block diagram of a video decoder (503) according to an embodiment of the present disclosure. The video encoder (503) is included in the electronic device (520). The electronic device (520) includes a transmitter (540) (eg, a transmission circuit). Video encoder (503) may be used instead of video encoder (303) in the example of FIG. 3.

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

[54] The video source (501) may provide the source video sequence for encoding by the video encoder (503) in the form of a digital stream of video samples, which may have any suitable bit depth (eg: 8 bit, 10 bit, 12 bit, ...), any color space (eg BT.601 Y CrCB, RGB, …) and any suitable sample structure (eg Y CrCb 4:2:0, Y CrCb 4:4:4). In the media serving system, the video source (501) may be a storage device storing pre-rendered video. In a videoconferencing 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 plurality of individual images that, when viewed sequentially, convey motion. The images themselves can be organized as a spatial array of pixels, in which each pixel can contain one or more samples depending on the sample structure used, color space, and so on. One skilled in the art can easily understand the relationship between pixels and samples. The description below is based on readings.

[55] According to an embodiment, the video encoder (503) may encode and compress images of the source video sequence into the encoded video sequence (543) in real time or with any other time constraints as required by the application. Providing an appropriate coding rate is one of the functions of the controller (550). In some embodiments, the controller (550) controls other functional modules, as described below, and is operatively linked to other functional modules. The connection is not shown for clarity. Parameters set by the controller (550) may include parameters related to speed control (picture skip, quantizer, speed-distortion optimization methods lambda value, ...), image size, group of pictures (GOP) layout, maximum motion vector search range and so on. The controller (550) may be configured to have other suitable functions that are related to the video encoder (503) optimized for a particular system design.

[56] In some embodiments, the video encoder (503) is configured to operate in a coding loop. As a simplified description, in an example, an encoding loop may include a source encoder (530) (eg, responsible for creating symbols, such as a stream of symbols, based on an input image to be encoded and reference image(s)), and a (local) decoder (533) embedded in the video encoder (503). The decoder (533) decompresses the symbols to create sample data in a manner similar to how a (remote) decoder would also create (because any compression between the symbols and the encoded video bitstream is lossless in the video compression technologies discussed in the disclosed subject matter). The reconstructed sample stream (sample data) is entered into the reference picture memory (534). Since the decoding of the symbol stream results in bit-accurate results, regardless of the location of the decoder (local or remote), the contents in the reference picture memory (534) are also bit-accurate between the local encoder and the remote encoder. In other words, the prediction portion of the encoder "sees" as reference picture samples exactly the same sample values that the decoder would "see" if using prediction during decoding. This fundamental principle of reference picture synchronism (and the resulting drift if synchronism cannot be maintained due to, for example, channel errors) is also used in some related fields of technology.

[57] The operation of the "local" decoder (533) may be the same as that of the "remote" decoder, such as the video decoder (410), which has already been described in detail above in connection with FIG. 4. Briefly referring also to FIG. 4, however, since symbols are available and encoding/decoding of symbols into the encoded video sequence by the entropy encoder (545) and parser (420) can be lossless, the entropy decoding parts of the video decoder (410), including the buffer memory (415) and the parser (420) , cannot be fully implemented in the local decoder (533).

[58] At this point, it can be observed that any decoding technology other than parsing/entropy decoding that is present in a decoder must also necessarily be present in substantially identical functional form in the corresponding encoder. For this reason, the disclosed subject matter focuses on the operation of the decoder. The description of encoding technologies can be abbreviated as they are the inverse of fully described decoding technologies. Only in some areas a more detailed description is required, which is given below.

[59] During operation, in some examples, source encoder (530) may perform motion-compensated predictive encoding that predictively encodes an input picture with reference to one or more previously encoded pictures from a video sequence that have been designated "reference pictures". Thus, the coding engine (532) encodes the differences between the pixel blocks of the input image and the pixel blocks of the reference image(s) that can be selected as the prediction reference(s) for the input image.

[60] The local video decoder (533) may decode the encoded video data of pictures that can be designated as reference pictures based on the symbols generated by the source encoder (530). The operations of the encoding engine (532) may preferably be lossy processes. When the encoded video data can be decoded in a video decoder (not shown in FIG. 5), the reconstructed video sequence can typically be a copy of the original video sequence with some errors. The local video decoder (533) replicates the decoding processes that may be performed by the video decoder on the reference pictures and may cause the recovered reference pictures to be stored in the reference picture cache (534). Thus, the video encoder (503) can locally store copies of the reconstructed reference pictures that share the same content as the reconstructed reference pictures to be received by the far-end video decoder (in the absence of transmission errors).

[61] The predictor (535) may perform predictive searches for the encoding engine (532). That is, for a new picture to be encoded, the predictor (535) may search the reference picture memory (534) for sample data (as reference pixel block candidates) or certain metadata such as reference picture motion vectors, block shapes, and so on. further, which can serve as a suitable reference for prediction for new images. The predictor (535) may operate on a block-by-pixel basis to find appropriate references for prediction. In some cases, as determined by the search results obtained by the predictor (535), the input image may have prediction references taken from a plurality of reference pictures stored in the reference picture memory (534).

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

[63] The output signals of all the above functional modules can be entropy encoded in an entropy encoder (545). An entropy encoder (545) translates symbols generated by various functional units into an encoded video sequence by lossless symbol compression according to techniques such as Huffman coding, variable length coding, arithmetic coding, and so on.

[64] The transmitter (540) may buffer the encoded video sequences generated by the entropy encoder (545) to prepare for transmission over a communication channel (560), which may be a hardware/software connection to a storage device that will store the encoded video data. The transmitter (540) may combine the encoded video data from the video encoder (503) with other data to be transmitted, such as encoded audio data and/or ancillary data streams (sources not shown).

[65] The controller (550) may control the operation of the video encoder (503). During encoding, the controller (550) may assign to each encoded picture a certain type of encoded picture, which may affect the encoding methods that can be applied to the corresponding picture. For example, images can often be categorized as one of the following image types:

[66] An intra-picture (I-picture) may be one that can be encoded and decoded without using any other picture in the sequence as a prediction source. Some video codecs allow various types of internal pictures, including, for example, independent decoder update ("IDR") pictures. The person skilled in the art will be aware of these variants of I-images and their respective applications and features.

[67] A predictive picture (P-picture) may be one that can be encoded and decoded using intra prediction or inter prediction using at most one motion vector and a reference index to predict sample values of each block.

[68] A bidirectional predictive picture (B-picture) may be one that can be encoded and decoded using intra prediction or inter prediction using no more than two motion vectors and reference indices to predict sample values of each block. Similarly, multi-prediction images may use more than two reference images and associated metadata to reconstruct a single block.

[69] Source images can typically be spatially divided into multiple blocks of samples (eg, blocks of 4x4, 8x8, 4x8, or 16x16 samples each) and encoded on a block-by-block basis. The blocks may be predictively encoded with reference to other (already encoded) blocks, as determined by the coding assignment applied to the corresponding block images. For example, blocks of I-pictures may be predictively encoded or they may be predictively encoded with reference to already encoded blocks of the same picture (spatial prediction or intra prediction). P-picture pixel blocks may be predictively encoded, spatially predicted, or temporally predicted with reference to one previously encoded reference picture. Blocks of B-pictures may be predictively coded, spatially predicted, or temporally predicted with reference to one or two previously encoded reference pictures.

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

[71] In an embodiment, transmitter (540) may transmit additional data with encoded video. The source encoder (530) may include such data as part of the encoded video sequence. The additional data may comprise temporal/spatial/SNR enhancement layers, other forms of redundant data such as redundant images and slices, SEI messages, VUI parameter set fragments, and so on.

[72] The video may be captured as a plurality of source images (video images) in time sequence. Intra-frame prediction (often abbreviated as intra-prediction) uses the spatial correlation in a given image, while inter-frame prediction uses (temporal or other) correlation between images. In the example, a specific image, when encoding/decoding, which is referred to as the current image, is divided into blocks. When a block in the current picture is similar to a reference block in a previously encoded and still buffered reference picture in a video, the block in the current picture may be encoded with a vector called a motion vector. The motion vector points to a reference block in the reference picture and may have a third dimension identifying the reference picture if multiple reference pictures are used.

[73] In some embodiments, a dual prediction technique may be used in inter-picture prediction. According to the double prediction method, two reference pictures are used, such as a first reference picture and a second reference picture, which both precede the current picture in the video in decoding order (but may be in the past and future, respectively, in display order). A block in the current picture may be encoded with a first motion vector that points to a first reference block in a first reference picture and a second motion vector that points to a second reference block in a second reference picture. The block may be predicted by the combination of the first reference block and the second reference block.

[74] In addition, the merge mode technique can be used in inter-picture prediction to improve coding efficiency.

[75] According to some embodiments of the invention, predictions such as inter predictions and intra predictions are performed in a unit of blocks. For example, according to the HEVC standard, an image in a video sequence is divided into coding tree units (CTUs) for compression, where the CTUs in the image are the same size, such as 64×64 pixels, 32×32 pixels, or 16×16 pixels. In general, a CTU includes three coding tree blocks (CTBs), which are one luminance CTB and two chrominance CTBs. Each CTU may be recursively split into a quadtree into one or multiple coding units (CUs). For example, a CTU of 64x64 pixels can be divided into one CU of 64x64 pixels, or 4 CUs of 32x32 pixels, or 16 CUs of 16x16 pixels. In the example, each CU is parsed to determine a prediction type for the CU, such as an inter prediction type or an intra prediction type. The CU is divided into one or more prediction units (PUs) depending on temporal and/or spatial predictability. Typically, each PU includes a Luma PB and two Chroma PBs. In an embodiment, an encoding (encoding/decoding) prediction operation is performed in a prediction block unit. Using the luminance prediction block as an example of the prediction block, the prediction block includes a matrix of values (e.g., luminance values) for pixels, such as 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc. P.

[76] FIG. 6 shows a diagram of a video encoder (603) according to another embodiment of the disclosure. The video encoder (603) is configured to receive a processing unit (eg, a prediction unit) of sample values in the current video image in the video sequence and encoding the processing unit into an encoded image that is part of the encoded video sequence. In one example, a video encoder (603) is used in place of the video encoder (303) in the example of FIG. 3.

[77] In the HEVC example, video encoder (603) receives a matrix of sample values for a processing block, such as an 8×8 sample prediction block, or the like. The video encoder (603) determines whether the processing unit is best encoded using intra mode, inter mode, or dual prediction mode, using rate-distortion optimization, for example. When the processing block is to be encoded in intra mode, the video encoder (603) may use an intra prediction technique to encode the processing block into an encoded picture; and when a processing block is to be encoded in an inter-prediction or dual-prediction mode, the video encoder (603) may use an inter-prediction or dual prediction method, respectively, to encode the processing block into an encoded picture. In some video coding technologies, the merge mode may be a sub-mode of inter-picture prediction in which a motion vector is derived from one or more motion vector predictors without taking advantage of the motion vector coded component outside of the predictors. In some other video coding technologies, there may be a motion vector component applicable to the block in question. In one example, the video encoder (603) includes other components such as a mode selector (not shown) to determine the mode of the processing units.

[78] In the example of FIG. 6, the video encoder (603) includes an outer encoder (630), an inner encoder (622), a residual calculator (623), a switch (626), a residual encoder (624), a common controller (621), and an entropy encoder (625), connected together as shown in Fig. 6.

[79] The outer encoder (630) is configured to receive samples of the current block (e.g., processing block), compare the block with one or more reference blocks in the reference pictures (e.g., blocks in previous pictures and next pictures), generate inter prediction information (e.g., , descriptions of redundant information according to the inter coding method, motion vectors, merge mode information), and calculation of inter prediction results (eg, predicted block) based on the inter prediction information using any suitable method. In some examples, the reference pictures are decoded reference pictures that are decoded based on the encoded video information.

[80] The inner encoder (622) is configured to receive samples of the current block (e.g., processing block), in some cases comparing the block with blocks already coded in the same picture, generating quantized post-transform coefficients, and in some cases also intra prediction information. (eg, intra prediction direction information according to one or more intra coding methods). In one example, intra encoder 622 also calculates intra prediction results (eg, predicted block) based on intra prediction information and reference blocks in the same picture.

[81] The common controller (621) is configured to determine the common control data and control other components of the video encoder (603) based on the common control data. In one example, the common controller (621) determines the mode of the block and provides a control signal to the switch (626) based on the mode. For example, when the mode is an intra mode, the common controller (621) controls the switch (626) to select the result of the intra mode for use by the residual calculator (623), and controls the entropy encoder (625) to select the intra prediction information and turn on the intra prediction information into the bitstream; and when the mode is inter mode, the common controller (621) controls the switch (626) to select the inter prediction result to be used by the residual calculator (623), and controls the entropy encoder (625) to select the inter prediction information and include the inter prediction information in bitstream.

[82] The residual calculator (623) is configured to calculate the difference (residual data) between the received block and the prediction results selected from the inner encoder (622) or the outer encoder (630). The residual encoder (624) is configured to operate based on the residual data to encode the residual data to generate transform coefficients. In one example, the residual encoder (624) is configured to transform residual data from the spatial domain to the frequency domain and generate transform coefficients. The transform coefficients are then subjected to quantization processing to obtain quantized transform coefficients. In various embodiments, video encoder (603) also includes a residual decoder (628). The residual decoder (628) is configured to perform inverse transformation and generate decoded residual data. The decoded residual data may be appropriately used by the inner encoder (622) and the outer encoder (630). For example, intra encoder (630) may generate decoded blocks based on decoded residual data and inter prediction information, and intra encoder (622) may generate decoded blocks based on decoded residual data and intra prediction information. The decoded blocks are suitably processed to generate decoded pictures, and the decoded pictures may be buffered in a memory circuit (not shown) and used as reference pictures in some examples.

[83] The entropy encoder (625) is configured to format the bitstream to include a coded block. The entropy encoder (625) is configured to include various information according to an appropriate standard such as the HEVC standard. In one example, entropy encoder 625 is configured to include common control data, selected prediction information (eg, intra prediction information or inter prediction information), residual information, and other pertinent information in the bitstream. Note that, according to the disclosed subject matter, when encoding a block in the merge sub-mode of either the inter-mode or the dual-prediction mode, there is no residual information.

[84] FIG. 7 shows a diagram of a video decoder (710) according to another embodiment of the disclosure. The video decoder (710) is configured to receive encoded pictures that are part of the encoded video sequence and decode the encoded pictures to create reconstructed pictures. In one example, video decoder (710) is used in place of video decoder (310) in the example of FIG. 3.

[85] In the example of FIG. 7, the video decoder (710) includes an entropy decoder (771), an external decoder (780), a residual decoder (773), a reconstruction unit (774), and an internal decoder (772) connected together as shown in FIG. 7.

[86] The entropy decoder (771) may be configured to recover from the encoded image certain symbols that represent the syntax elements that make up the encoded image. Such symbols may include, for example, the mode in which the block is encoded (such as, for example, intra mode, inter mode, dual prediction mode, the latter two in a merge submode or another submode), prediction information (such as, for example, intra prediction information or inter prediction information) that can identify a specific sample or metadata that is used for prediction by the intra decoder (772) or the outer decoder (780), respectively, residual information in the form of, for example, quantized transform coefficients, and the like. In one example, when the prediction mode is an inter mode or a bidirectional prediction mode, inter prediction information is provided to an external decoder (780); and when the prediction type is an intra prediction type, the intra prediction information is provided to the intra decoder (772). The residual information may be inverse quantized and provided to the residual decoder (773).

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

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

[89] The residual decoder (773) is configured to perform inverse quantization to extract the dequantized transform coefficients and process the dequantized transform coefficients to transform the residual from the frequency domain to the spatial domain. The residual decoder (773) may also require certain control information (to include a quantizer parameter (QP)), and this information may be provided by the entropy decoder (771) (data path not shown as this may only be small control information).

[90] The recovery module (774) is configured to combine in the spatial domain the residual output by the residual decoder (773) and the prediction results (output by the inter or intra prediction modules, as the case may be) to form a reconstructed block that may be part of the reconstructed image , which in turn can be part of the recovered video. It should be noted that other suitable operations, such as a release operation and the like, may be performed to improve the visual quality.

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

[92] Compensation based on blocks from another image may be referred to as motion compensation. Block compensation may also be performed from a previously reconstructed area within the same picture, which may be referred to as intra-frame block compensation, intra-block copy (IBC), or current picture reference (CPR). For example, an offset vector that specifies the offset between the current block and the reference block is called a block vector. In some embodiments, the block vector points to a reference block that has already been recovered and is available for reference. Also, to consider parallel processing, the block vector reference to a reference area that is outside the tile/slice boundary or the wavefront ladder boundary can be excluded. Because of these limitations, the block vector may differ from the motion vector in motion compensation, where the motion vector can be any value (positive or negative, in the x or y direction).

[93] Block vector encoding may be explicit or implicit. In the explicit mode, which is sometimes called the AMVP (Advanced Motion Vector Prediction) mode in intercoding, the difference between the block vector and its predictor is transmitted. In implicit mode, the block vector is reconstructed from the block vector predictor, similar to the motion vector in merge mode. The block vector resolution in some embodiments is limited to integer positions. In other embodiments, the block vector resolution may indicate fractional positions.

[94] The use of intra-block copy at the block level can be conveyed using a block level flag called the IBC flag. In one embodiment, the IBC flag is transmitted when the current block is not merge-encoded. The IBC flag may also be transmitted by the reference index method, which is performed by treating the current decoded picture as a reference picture. In HEVC Screen Content Coding (SCC), such a reference picture is placed in the last position of the list. This special reference picture can also be managed along with other temporary reference pictures in the DPB. IBC may also include options such as flipped IBC (eg, a reference block is flipped horizontally or vertically before being used to predict the current block) or linear (IBC) (eg, each compensation unit within an M×N coding block is line M×1 or 1×N).

[95] FIG. 8 illustrates an embodiment of intra-frame block compensation (eg, intra-block copy mode). As shown in FIG. 8, the current picture 800 includes a set of block areas that have already been coded/decoded (ie, gray squares) and a set of block areas that have yet to be coded/decoded (ie, white boxes). Block 802 of one of the block regions yet to be coded/decoded may be associated with a block vector 804 that points to another block 806 that has previously been coded/decoded. Accordingly, any motion information associated with block 806 may be used to encode/decode block 802.

[96] In some embodiments, the CPR mode search range is limited to be within the current CTU. The effective memory requirement for storing reference samples for CPR mode is 1 sample CTU size. Considering the existing reference memory to store the recovered samples in the current 64×64 area, 3 more reference sample memories of 64×64 are required. Embodiments of the present disclosure extend the effective search range of the CPR mode to some portion of the left CTU while the overall memory requirements for storing reference pixels remain unchanged (1 CTU size, total 4 64x64 reference sample memories).

[97] As shown in FIG. 9A, the upper left area of the CTU 900 is the current decodable area. When the upper left region of the CTU 900 is decoded, the reference sample memory entry [1] is overwritten with samples from this region, as illustrated in FIG. 10A (for example, the overwritten memory cell(s) has diagonal hatching). As shown in FIG. 9B, the upper right area of the CTU 900 is the next current decodable area. When the upper right region of the CTU 900 is decoded, the reference sample memory entry [2] is overwritten with samples from this region, as shown in FIG. 10b. As shown in FIG. 9C, the lower left area of CTU 900 is the next current decodable area. When the lower left region of the CTU 900 is decoded, the reference sample memory entry [3] is overwritten with samples from this region, as shown in FIG. 10C. As shown in FIG. 9D, the lower right region of the CTU 900 is the next current decodable region. When the lower right region of the CTU 900 is decoded, the reference sample memory entry [3] is overwritten with samples from this region, as shown in FIG. 10D.

[98] In some embodiments, the bitstream matching conditions are that the actual block vector (mvL, in 1/16 - pel resolution) must meet the following conditions. In some embodiments, the luminance motion vector mvL is subject to the following constraints A1, A2, B1, C1, and C2.

[99] In the first constraint ( A1 ), when an inference process for block availability (eg, a neighbor block availability check process) is invoked with the current luminance location (xCurr, yCurr) set to (xCb, yCb) and the adjacent luminance location (xCb + (mvL[0] >> 4) + cbWidth - 1, yCb + (mvL [1] >> 4) + cbHeight - 1) as input, output must be TRUE.

[100] In the second constraint ( A2 ), when an inference process for block availability (e.g., a neighbor block availability check process) is invoked with the current luma location (xCurr, yCurr) set to (xCb, yCb) and the neighboring luma location (xCb + (mvL[0] >> 4) + cbWidth - 1, yCb + (mvL [1] >> 4) + cbHeight - 1) as input, output must be TRUE.

[101] The third constraint ( B1 ) has one or both of the following conditions:

(i) The value of (mvL[0] >> 4) + cbWidth is less than or equal to 0.

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

[102] The fourth constraint ( C1 ) has the following conditions:

(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)

[103] In the fifth constraint ( C2 ), when (xCb + (mvL [0] >> 4)) >> CtbLog2SizeY is equal to (xCb >> CtbLog2SizeY) - 1, the inference process for block availability (e.g., neighbor block availability check process ) is called with the current brightness location (xCurr, yCurr) set to (xCb, yCb) and the adjacent brightness location (((xCb + (mvL[0] >> 4) + CtbSizeY) >> (CtbLog2SizeY - 1)) << (CtbLog2SizeY - 1), ((yCb + (mvL [1] >> 4)) >> (CtbLog2SizeY - 1)) << (CtbLog2SizeY - 1)) as input, and the output must be FALSE.

[104] In the equations above, xCb and yCb are the x and y coordinates of the current block, respectively. The cbHeight and cbWidth variables are the height and width of the current block, respectively. The variable CtbLog2sizeY refers to the size of the CTU in 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 mvL0 block vector, respectively. If the output value is FALSE, then the samples for the reference block are determined to be available (for example, the adjacent block is available for in-block copy use). If the output is TRUE, then the samples for the reference block are defined as unavailable.

[105] According to some embodiments, a history-based MVP (HMVP) method includes an HMVP candidate, which is defined as motion information of a previously encoded block. A table with multiple HMVP candidates is maintained during the encoding/decoding process. The table is cleared when a new slice is found. Each time there is an externally encoded non-affine block, the corresponding motion information is added to the last table entry as a new HMVP candidate. The encoding sequence of the HMVP method is shown in FIG. 11A.

[106] The size S of the table is set to 6, indicating that up to 6 HMVP candidates can be added to the table. When inserting a new motion candidate into a table, the restricted FIFO rule is used so that a redundancy check is first applied to determine if there is an identical HMVP in the table. When found, the identical HMVP is removed from the table, and all HMVP candidates are subsequently moved forward (i.e., decrementing indexes by 1). In FIG. 11B shows an example of inserting a new motion candidate into the HMVP table.

[107] HMVP candidates may be used in the process of constructing a merge candidate list. The last few HMVP candidates in the table are checked in order and inserted into the list of candidates after the TMVP candidate. For HMVP candidates, clipping may be applied to the spatial or temporal merge candidate, with the exclusion of the subblock motion candidate (ie, ATMVP).

[108] In some embodiments, in order to reduce the number of pruning operations, the number of HMVP candidates to be tested (denoted L) is set to L = (N <= 4) ? M: (8 - N) where N indicates the number of non-subblock merge candidates available and M indicates the number of available HMVP candidates in the table. In addition, once the total number of available merge candidates reaches the transmitted maximum allowed merge candidates minus 1, the process of constructing the merge candidate list from the HMVP list ends. In addition, the number of pairs for combined derivation of dual prediction merge candidates has been reduced from 12 to 6.

[109] HMVP candidates can also be used in the AMVP candidate list building process. The motion vectors of the last K HMVP candidates in the table are inserted after the TMVP candidate. Only HMVP candidates with the same reference picture as the target AMVP reference picture are used to construct the list of AMVP candidates. A pruning is applied to HMVP candidates. In some applications, K is set to 4 while the size of the AMVP list remains unchanged (ie, 2).

[110] According to some embodiments, when intra-block copy operates as a mode separate from external mode, a separate history buffer called HBVP can be used to store previously encoded vectors of blocks of intra-block copy. As a separate mode from inter-prediction, it is desirable to have a simplified block vector derivation process for the intra-block copy mode. The IBC BV prediction candidate list in AMVP mode can share the one used in the IBC merge mode (Merge Candidate List) with 2 spatial candidates + 5 HBVP candidates.

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

[112] In some examples, the maximum number of MVP merge candidates, MaxNumMergeCand, can be obtained as:

Equation (1): MaxNumMergeCand = 6 - six_minus_max_num_merge_cand

[113] The MaxNumMergeCand value can range from 1 to 6 inclusive. In some video coding systems, the merge list size for the IBC mode is reported separately from the merge list size in the outer merge mode for all I/P/B slices. The range of this size can be the same as in external merge mode (for example, from 1 to 6 inclusive). In some examples, the maximum number of IBC candidates, MaxNumIbcMergeCand can be obtained as:

Equation (2): MaxNumIBCMergeCand = 6 - six_minus_max_num_ibc_merge_cand

[114] In Equation (2), the variable six_minus_max_num_ibc_merge_cand specifies the maximum number of IBC motion vector prediction (MVP) merge candidates supported in a slice subtracted from 6. The value of MaxNumIBCMergeCand can range from 1 to 6 inclusive. In some video coding systems, the merge index transmission for the IBC merge mode may still share the merge index transmission used for the outer merge mode. In this regard, the IBC merge mode and the external merge mode may share the same syntax element for the merge index. Since the merge index is binarized using the truncated rice (TR) code, the maximum length of the merge index is MaxNumMergeCand - 1. However, there is a need for a solution for passing the merge index when MaxNumIbcMergeCand is not equal to MaxNumMergeCand.

[115] Embodiments of the present disclosure may be used singly or combined in any order. In addition, each of the methods, encoder and decoder according to embodiments of the present disclosure may be implemented by a processing circuit (eg, one or more processors or one or more integrated circuits). In one example, one or more processors execute a program that is stored on a non-transitory computer-readable medium. In some embodiments, the term "block" may be interpreted as a prediction block, coding block, or coding unit (ie, CU).

[116]

[117] According to some embodiments, the maximum merge size number for binarization of the merge index is set to switch between MaxNumMergeCand and MaxNumIbcMergeCand numbers. For example, when the current block is encoded in IBC mode, the maximum merge size for the merge index is MaxNumIbcMergeCand. However, when the current block is not encoded in IBC mode, the maximum merge size for the merge index is MaxNumMergeCand. Table 1 shows examples of syntax elements and associated binarizations.

merge_data() regular_merge_flag [ ][ ] FL cMax = 1 mmvd_merge_flag [ ][ ] FL cMax = 1 mmvd_cand_flag [ ][ ] FL cMax = 1 mmvd_distance_idx [ ][ ] TR cMax=7, cRiceParam=0 mmvd_direction_idx [ ][ ] FL cMax = 3 ciip_flag[][] FL cMax = 1 merge_subblock_flag [ ][ ] FL cMax = 1 merge_subblock_idx [ ][ ] TR cMax = MaxNumSubblockMergeCand - 1, cRiceParam = 0 merge_triangle_split_dir [ ][ ] FL cMax = 1 merge_triangle_idx0 [ ][ ] TR cMax = MaxNumTriangleMergeCand - 1, cRiceParam = 0 merge_triangle_idx1 [ ][ ] TR cMax = MaxNumTriangleMergeCand - 2, cRiceParam = 0 merge_idx [ ][ ] TR cMax = (CuPredMode[0][x0][y0] != MODE_IBC? MaxNumMergeCand : MaxNumIbcMergeCand) - 1, cRiceParam = 0

Table 1

[118] As illustrated in Table 1, the binarization of the merge index (ie, merge_idx [][]) is based on whether the current block is encoded in IBC mode. Also, FL refers to a fixed length; cMax refers to the maximum possible value of a variable length code; eRiceParam is a variable length code rice parameter. The "rice" parameter can be used to determine the binary code of each input value. In truncated binary, the rice parameter is 0.

[119] According to some embodiments, the maximum merge size number for binarization of the merge index is set to the maximum number between MaxNumMergeCand and MaxNumIbcMergeCand. Since no MaxNumMergeCand value is passed in the I-slice/tile group, MaxNumMergeCand can be assumed to be 1 (ie the minimum possible value for MaxNumIbcMergeCand). Accordingly, when MaxNumMergeCand is not transmitted, the value of six_minus_max_num_merge_cand is assumed to be 5, since the value of MaxNumMergeCand is assumed to be 1. Therefore, in equation (1), MaxNumMergeCand is 1, since six_minus_max_num_merge_cand is 5. In equation (2), the value of MaxNumIbcMergeCand is in the range of 1 to 6 inclusive.

[120] Table 2 shows examples of syntax and associated binarizations.

merge_data() regular_merge_flag [ ][ ] FL cMax = 1 mmvd_merge_flag [ ][ ] FL cMax = 1 mmvd_cand_flag [ ][ ] FL cMax = 1 mmvd_distance_idx [ ][ ] TR cMax=7, cRiceParam=0 mmvd_direction_idx [ ][ ] FL cMax = 3 ciip_flag[][] FL cMax = 1 merge_subblock_flag [ ][ ] FL cMax = 1 merge_subblock_idx [ ][ ] TR cMax = MaxNumSubblockMergeCand - 1, cRiceParam = 0 merge_triangle_split_dir [ ][ ] FL cMax = 1 merge_triangle_idx0 [ ][ ] TR cMax = MaxNumTriangleMergeCand - 1, cRiceParam = 0 merge_triangle_idx1 [ ][ ] TR cMax = MaxNumTriangleMergeCand - 2, cRiceParam = 0 merge_idx [ ][ ] TR cMax = Max(MaxNumMergeCand, MaxNumIbcMergeCand) - 1, cRiceParam = 0

table 2

[121] As illustrated 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) exceeds the maximum number of IBC candidates (t .e. MaxNumIbcMergeCand).

[122] In some embodiments, the range of MaxNumIbcMergeCand must be less than or equal to MaxNumMergeCand. Since MaxNumMergeCand is not transmitted in the I-slice/tile group, MaxNumMergeCand is assumed to be 6. Accordingly, in Equation (1), six_minus_max_num_merge_cand is assumed to be 0, since MaxNumMergeCand is assumed to be 6. In some embodiments, when the transmitted value of MaxNumIbcMergeCand is greater than MaxNumMergeCand, MaxNumIbcMergeCand is limited to MaxNumMergeCand. Accordingly, in equation (2), if the slice type is I, the value of MaxNumIbcMergeCand must be in the range from 1 to 6 inclusive. However, if the slice type is P or B, the MaxNumIbcMergeCand value is between 1 and MaxNumMergeCand inclusive. Accordingly, when the slice type is P or B (ie, MaxNumMergeCand is not passed), the value of MaxNumIbcMergeCand can be determined as follows: MaxNumIbcMergeCand = min(MaxNumIbcMergeCand, MaxNumMergeCand).

[123] FIG. 12 illustrates an embodiment of a video decoding process performed by a video decoder, such as video decoder (710). The process may start at step (S1200) where an encoded video bitstream including the current picture is received. The process proceeds to step (S1202) in which a predetermined condition associated with the transmission data included in the encoded video bitstream is determined.

[124] The process proceeds to step (S1204) where, based on a predetermined condition, the index size included in the transmission data for the vector predictor candidate list is set to one of the maximum number of merge mode candidates and the number of IBC candidates. As an example, the index may be a merge index included in the encoded video bitstream. As an example, the predetermined condition includes determining whether the current block is encoded in IBC mode. If the current block is encoded in IBC mode, the index size is set to MaxNumIbcMergeCand. However, if the current block is not encoded in IBC mode, the index size is set to MaxNumMergeCand.

[125] As another example, the predetermined condition includes determining whether the maximum number of merge mode candidates exceeds the maximum number of IBC candidates. If the maximum number of merge mode candidates exceeds 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.

[126] The process proceeds from step (S1204) to (S1206), where the list of candidates is built using vector predictors. For example, if the current block is encoded in merge mode, the candidate list is a merge list and the predictor vectors are motion vectors. In another example, if the current block is encoded in IBC mode, the candidate list is a list of vector block predictors. The process continues from (S1208) where a vector predictor from the candidate list is extracted according to an index whose value does not exceed a certain index size. For example, the value of the index that is used to extract the vector predictor from the candidate list cannot exceed the size of the index that is determined in step (S1204). The process proceeds to step (S1210) where the current block is decoded according to the extracted vector predictor.

[127] FIG. 13 illustrates an embodiment of a video decoding process performed by a video decoder, such as video decoder (710). The process may start at step (S1300) where an encoded video bitstream including the current picture is received. The process proceeds to a step (S1302) in which transmission data from the encoded video bitstream is extracted for the current block. The process proceeds to step (S1304) to determine whether the maximum number of merge candidates is included in the extracted transmission data for the current block. For example, it is determined whether the MaxNumMergeCand signal is transmitted. As discussed above, in some examples MaxNumMergeCand is not passed for I-slice/tile types and is passed for P- or B-slice/tile types.

[128] The process proceeds to step (S1306) where the maximum number of intra-block copy candidates (IBC) is set based on determining whether the maximum number of merge candidates is included in the transmission data for the current block. For example, if MaxNumMergeCand is not passed, the value of MaxNumIbcMergeCand is between 1 and 6, inclusive. However, if MaxNumMergeCand is passed, the value of MaxNumIbcMergeCand changes from 1 to MaxNumMergeCand inclusive.

[129] In some examples, the coding unit contains samples of the luminance and chrominance components. These chrominance component samples may have an independent or separate split tree structure compared to one of the luma components. In some examples, a separate coding tree structure starts at the CTU level. Therefore, it is possible that a chrominance CU (eg, a CU that contains only two chrominance components) may be larger than the luminance counterpart of the chrominance CU at the corresponding sample location.

[130] According to some embodiments, in the first method, when a binary tree structure is used, chrominance blocks may be encoded in IBC mode when at least the following conditions are met:

1. For each sub-block area in the chrominance CU, the combined luminance area is encoded in IBC mode.

2. All aligned luma region samples for the chroma CU have the same block vector.

3. The resulting common block vector for the entire chroma CU is a valid BV. This means that this BV points to an already reconstructed area in the current image and within the specified clipping area for the chrominance components.

[131] Based on the first method, the decoder side will be able to process the chrominance CU as an entire CU rather than as a CU based on a subblock. Therefore, using a single received BV from the aligned luminance region (eg, typically the top left corner of the CU) to decode the CU is sufficient.

[132] According to some embodiments, in the second method, when a dual tree structure is used, various conditions may be used to allow the use of the IBC chroma mode with the dual tree structure. In one embodiment, chrominance blocks may be encoded in IBC mode when (i) all corresponding luma samples of all chrominance samples belong to the same luminance coding block; and (ii) the same luminance coding block is encoded in IBC mode. For example, this condition is tested by evaluating two chroma angles CU. If the luminance correspondence of the upper left chrominance sample and the luma correspondence of the lower right chrominance sample belong to the same luminance coding block, then the entire corresponding luminance region CU of the chroma belongs to the same luminance coding block. In another embodiment, chrominance blocks may be encoded in IBC mode with appropriate luma coding.

[133] Based on the second method, the decoder side will be able to process the chrominance CU as an entire CU rather than as a CU based on a subblock. Therefore, using a single received BV from the aligned luminance region (typically the upper left corner of the CU) for decoding the CU is sufficient.

[134] According to some embodiments of either the first method or the second method related to the dual tree structure, the following disclosed non-limiting embodiments show how to transmit dual tree IBC chroma mode usage data when the above conditions occur either in the first method, or in the second method.

[135] In one embodiment, the above restrictions for using the IBC mode for a dual-tree chroma CU are implemented such that a usage flag (eg, ibc_flag) is transmitted for each chroma CU, when applicable. However, in this embodiment, only when all conditions for the first method or all conditions for the second method are met, ibc_flag is transmitted as true. Otherwise, ibc_flag is passed as false. In some examples, when all conditions are met for either the first or the second method, ibc_flag may also be passed as false depending on how the encoder is implemented.

[136] In another embodiment, the above restrictions for using the IBC mode for a chroma CU with a dual tree structure are implemented such that a usage flag (eg, ibc_flag) is not transmitted at all. For example, for a chroma CU with a double tree structure, when all conditions for the first method or the second method are met, the CU is encoded in IBC mode and ibc_flag is output as true. Otherwise, ibc_flag is not passed and is considered false.

[137] The methods described above may be implemented in computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, in FIG. 14 shows a computer system (1400) suitable for implementing certain embodiments of the disclosed subject matter.

[138] Computer software may be coded using any suitable machine code or computer language, which may be the object of assembly, compilation, linking, or similar mechanisms to produce code containing instructions that can be executed directly or through interpretation, execution of microcode, etc. .p., one or more computer central processing units (CPUs), graphics processing units (GPUs), and the like.

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

[140] The components shown in FIG. 14 for the computer system (1400) are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing embodiments of the present disclosure. The configuration of the components is also not to be interpreted as having any dependency or requirement relating to any one or combination of the components illustrated in the exemplary embodiment of the computer system (1400).

[141] The computer system (1400) may include certain human-machine interface input devices. Such a human-machine interface input device may respond to input by one or more human users through, for example, tactile input (e.g., keystrokes, swipes, movement of a control glove), audio input (e.g., voice, handclaps), visual input (for example: gestures), olfactory input (not shown). HMI devices can also be used to capture certain media not necessarily directly related to conscious human input, such as sound (e.g. speech, music, ambient sound), images (e.g. scanned images, photographic images taken from a camera for still images), video (eg 2D video, 3D video including stereoscopic video).

[142] HMI input devices may include one or more of the following (only one of each depicted): keyboard (1401), mouse (1402), trackpad (1403), touch screen (1410), control glove (not shown), joystick (1405)), microphone (1406), scanner (1407), camera (1408).

[143] The computer system (1400) may also include certain human-machine interface output devices. Such human interface output devices can stimulate the senses of one or more human users through, for example, tactile output, sound, light, and smell/taste. Such human interface output devices may include tactile output devices (e.g., tactile feedback from a touch screen (1410), operating glove (not shown), or joystick (1405), but there may also be tactile feedback devices that do not serve as input devices), audio output devices (for example: speakers (1409), headphones (not shown)), image output devices (for example, screens (1410), including CRT screens, LCD screens, plasma screens, OLED -screens, each with or without touchscreen input capability, each with or without tactile feedback capability - some of which may be capable of outputting 2D visual output or more than 3D output by means such as stereographic output ; virtual reality goggles (not shown), holographic displays and smoke tanks (not shown)) and printers (not shown).

[144] The computer system (1400) may also include human accessible storage devices and associated media such as optical media including CD/DVD ROM/RW (1420) with CD/DVD or similar media (1421), flash drive (1422), removable hard drive or solid state drive (1423), previously developed magnetic media such as tape and floppy disk (not shown), dedicated ROM/ASIC/PLD based devices such as dongles (not shown) and so on.

[145] Those skilled in the art should also understand that the term "computer-readable medium" as used in connection with the subject matter disclosed herein does not encompass transmission media, carrier waves, or other time signals.

[146] The computer system (1400) may also include an interface to one or more communication networks. Networks can be, for example, wireless, wired, optical. In addition, networks can be LAN, WAN, metropolitan, automotive, industrial, real-time, delay tolerant, etc. Examples of networks include LANs such as Ethernet, wireless LANs, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., wired TV or wireless wide area digital networks, including cable TV, satellite TV and terrestrial TV, automotive and industrial equipment, including CAN bus, etc. Some networks usually require external network interface adapters that are connected to certain general purpose data ports or peripheral buses (1449) (for example, computer system USB ports (1400)); others are typically integrated into the computer system core (1400) by being attached to a system bus as described below (eg, 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 communication can be unidirectional, receive-only (for example, broadcast television), unidirectional, send-only (for example, CAN bus to certain CAN-bus devices), or bidirectional, for example, to other computer systems using a local or wide area digital network. . Each of these networks and network interfaces may use specific protocols and protocol stacks as described above.

[147] The above human-machine interface devices, human-accessible storage devices, and network interfaces may be attached to the core (1440) of the computer system (1400).

[148] The core (1440) may include one or more central processing units (CPUs) (1441), graphics processing units (GPUs) (1442), dedicated field programmable gate array processors (FPGAs) (1443), hardware accelerators for specific tasks (1444), etc. These devices, along with Read Only Memory (ROM) (1445), Random Access Memory (1446), high capacity internal storage such as internal hard drives that are not accessible to the user, solid state drives and etc. (1447) can be connected via the system bus (1448). In some computer systems, the system bus (1448) may be available as one or more physical connectors to allow expansion with additional CPUs, GPUs, or the like. Peripherals can be connected either directly to the system bus (1448) of the kernel, or via a peripheral bus (1449). Peripheral bus architecture includes PCI, USB, etc.

[149] The CPU (1441), GPU (1442), FPGA (1443), and accelerators (1444) may execute certain instructions, which in combination may constitute the aforementioned computer code. This computer code may be stored in ROM (1445) or RAM (1446). Transient data may also be stored in RAM (1446), while persistent data may be stored in, for example, internal mass storage (1447). Fast storage and retrieval to any of the storage devices can be achieved through the use of cache memory, which can be closely associated with one or more CPU (1441), GPU (1442), mass storage (1447), ROM (1445), RAM (1446), etc.

[150] The computer-readable medium may contain computer code for performing various computer-implemented operations. The media and computer code may be specially designed and constructed for the purposes of this disclosure, or they may be well known and available to those skilled in the art of computer software.

[151] By way of example, and not limitation, a computer system having an architecture (1400), and in particular a core (1440), may provide functionality as a result of execution by processor(s) (including CPUs, GPUs, FPGAs, accelerators, etc.). .p.) software placed on one or more tangible, machine-readable media. Such computer-readable media can be media associated with user accessible mass storage as described above, as well as certain kernel storage (1440) that is non-transitory in nature, such as internal kernel mass storage (1447) or ROM (1445). Software implementing various embodiments of the present disclosure may be stored on such devices and executed by the kernel (1440). The computer-readable medium may include one or more memory devices or microchips, as appropriate. The software may cause the core (1440), and in particular the processors within it (including the CPU, GPU, FPGA, etc.) to execute certain processes or certain parts of the specific processes described herein, including the definition of data structures stored in RAM (1446) and changing such data structures in accordance with the processes defined by the software. In addition or alternatively, a computer system may provide functionality as a result of logic embedded in or otherwise embodied in hardware circuitry (e.g., an accelerator (1444)) that may operate in place of or in conjunction with software to perform certain processes or individual parts of the specific processes described in this document. The link to the software may include logic and vice versa where appropriate. A reference to a computer-readable medium may include circuitry (eg, an integrated circuit (IC)) storing software to execute, circuitry embodying logic to execute, or both, where appropriate. The present disclosure includes any suitable combination of hardware and software.

Appendix A: Abbreviations

JEM: Joint Research Model

VVC: Universal Video Coding

BMS: test suite

MV: motion vector

HEVC: High Efficiency Video Coding

SEI: additional extended information

VUI: video property information

GOP: group of images

TU: conversion unit

PU: prediction unit

CTU: coding tree unit

CTB: coding tree block

PB: prediction block

HRD: Hypothetical Reference Decoder

SNR: signal to noise ratio

CPU (CPU): central processing unit

GPU (GPU): graphics processing unit

CRT (CRT): cathode ray tube

LCD (LCD): liquid crystal display

OLED: organic light emitting diode

CD: CD

DVD: Digital Video Disc

ROM (ROM): Read Only Memory

RAM (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 development

CANBus (CAN-bus): LAN bus of the controller

USB: Universal Serial Bus

PCI: Peripheral Component Connection

FPGA (FPGA): Field Programmable Gate Arrays

SSD: solid state drive

IC: integrated circuit

CU: coding unit

[152] Although this disclosure describes several exemplary embodiments, there are variations, permutations, and various replacement equivalents that fall within the scope of the disclosure. Thus, it will be appreciated that those skilled in the art will be able to develop numerous systems and methods that, although not explicitly shown or described herein, embody the principles of the disclosure and thus fall within its spirit and scope.

[153] (1) A video decoding method includes receiving an encoded video bitstream including a current picture; determining a predetermined condition associated with transmission data included in the encoded video bitstream; determining, based on a predetermined condition, an index size included in transmission data for the vector predictor candidate list based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates; building a list of candidates with vector predictors; extracting a vector predictor from the list of candidates according to an index whose value does not exceed a certain index size; and decoding the current block in accordance with the extracted vector predictor.

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

[155] (3) The video decoding method according to feature (2), wherein, in response to determining that the current block is encoded in IBC mode, setting the index size to the maximum number of IBC candidates, and in response to determining that the current block is not encoded in IBC mode, set the index size to the maximum number of merge mode candidates.

[156] (4) The video decoding method according to any of (1) to (3), wherein the predetermined condition includes determining whether the maximum number of merge mode candidates exceeds the maximum number of IBC candidates.

[157] (5) The video decoding method according to feature (4), wherein, in response to determining that the maximum number of merge mode candidates is greater than the maximum number of IBC candidates, setting the index size to the maximum number of merge mode candidates, and in response to determining that the maximum number of merge mode candidates is less than the maximum number of IBC candidates, setting the index size to the maximum number of IBC candidates.

[158] (6) A video decoding method includes receiving an encoded video bitstream including a current picture; extracting transmission data from the encoded video bitstream for the current block; determining whether a maximum number of merge candidates is included in the extracted transmission data for the current block; and setting a maximum number of intra-block copy candidates (IBC) based on determining whether the maximum number of merge candidates is included in the transmission data for the current block.

[159] (7) The video decoding method according to feature (6), in which, in response to determining that the maximum number of fusion candidates is not included in the transmission data, the maximum number of IBC candidates is set to 1 to 6.

[160] (8) The video decoding method according to feature (7), in which, in response to determining that the maximum number of merge candidates are included in transmission data, the maximum number of IBC candidates is set to 1 to the maximum number of merge candidates.

[161] (9) A video decoding apparatus for decoding a video includes a processing circuit configured to receive an encoded video bitstream including a current picture, determine a predetermined condition associated with transmission data included in the encoded video bitstream, determine , based on a predetermined condition, the index size included in the transmission data for the vector predictor candidate list based on the number of merge mode candidates and the number of intra-block copy (IBC) candidates, constructing the candidate list with vector predictors, extracting the vector predictor from the candidate list according to an index whose value does not exceed a certain index size, and decoding the current block in accordance with the extracted vector predictor.

[162] (10) The video decoding apparatus according to the feature (9), wherein the predetermined condition includes a processing circuit configured to determine whether the current block is encoded in the IBC mode.

[163] (11) The video decoding apparatus according to feature (10), in which, in response to determining that the current block is encoded in the IBC mode, the processing circuit is configured to set the index size to the maximum number of IBC candidates, and in response to determining that the current block is not encoded in IBC mode, the processing scheme is configured to set the index size to the maximum number of merge mode candidates.

[164] (12) The video decoding apparatus according to any of (9) to (12), wherein the predetermined condition includes determining whether the maximum number of merge mode candidates exceeds the maximum number of IBC candidates.

[165] (13) The video decoding apparatus according to the feature (12), in which, in response to determining that the maximum number of merge mode candidates is larger than the maximum number of IBC candidates, the processing circuit is further configured to set the index size to the maximum number of merge mode candidates , and in response to determining 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 index size to the maximum number of IBC candidates.

[166] (14) A video decoder apparatus for decoding video, including a processing circuit configured to receive an encoded video bitstream including a current picture, extract transmission data from the encoded video bitstream for the current block, determine whether the maximum number of merge candidates in the extracted transmission data for the current block, and setting a maximum number of intra-block copy candidates (IBC) based on determining whether the maximum number of merge candidates is included in the transmission data for the current block.

[167] (15) The video decoder according to feature (14), in which, in response to determining that the maximum number of merge candidates is not included in transmission data, the maximum number of IBC candidates is set to 1 to 6.

[168] (16) The video decoder according to feature (15), in which, in response to determining that the maximum number of merge candidates are included in the transmission data, the maximum number of IBC candidates is set to 1 to the maximum number of merge candidates.

[169] (17) A non-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by a processor in a video decoder, cause the processor to perform a method comprising receiving an encoded video bitstream including a current picture; determining a predetermined condition associated with transmission data included in the encoded video bitstream; determining, based on a predetermined condition, an index size included in the transmission data for the vector predictor candidate list based on the number of merge mode candidates and the number of intrablock copy (IBC) candidates; building a list of candidates with vector predictors; extracting a vector predictor from the list of candidates according to an index whose value does not exceed a certain index size; and decoding the current block in accordance with the extracted vector predictor.

[170] (18) The non-temporal computer-readable storage medium according to feature (17), wherein the predetermined condition includes determining whether the current block is encoded in IBC mode.

[171] (19) A non-transitory computer-readable storage medium containing instructions stored thereon that, when executed by a processor in a video decoder, cause the processor to perform a method comprising: receiving an encoded video bitstream including a current picture; extracting transmission data from the encoded video bitstream for the current block; determining whether a maximum number of merge candidates is included in the extracted transmission data for the current block; and setting a maximum number of intra-block copy candidates (IBC) based on determining whether the maximum number of merge candidates is included in the transmission data for the current block.

[172] (20) The non-transient computer-readable storage medium according to feature (19), in which, in response to determining that the maximum number of merge candidates is not included in the transmission data, the maximum number of IBC candidates is set to 1 to 6.

Claims (27)

1. Video decoding method, comprising: - receiving an encoded video bitstream including the current picture; determining a predetermined condition associated with transmission data included in the encoded video bitstream, the predetermined condition including determining whether a maximum number of merge mode candidates exceeds a maximum number of intrablock copy (IBC) candidates; - in response to determining that the maximum number of merge mode candidates is greater than the maximum number of IBC candidates, setting the size of the index included in the transmission data for the vector predictor candidate list to the maximum number of merge mode candidates, and in response to determining that the maximum number merge mode candidates less than the maximum number of IBC candidates, setting the index size to the maximum number of IBC candidates; - building a list of candidates with vector predictors; - extracting a vector predictor from the list of candidates in accordance with the index, the value of which does not exceed a certain size of the index; And - decoding the current block in accordance with the extracted vector predictor. 2. Video decoding method, comprising: - receiving an encoded video bitstream including the current picture; - extracting transmission data from the encoded video bitstream for the current block; - determining whether the maximum number of merge candidates is included in the extracted transmission data for the current block; And - in response to determining that the maximum number of merge candidates are included in the transfer data, setting the maximum number of intra-block copy candidates (IBC) to a value from 1 to the maximum number of merge candidates. 3. The video decoding method of claim 2, wherein, in response to determining that the maximum number of merge candidates is not included in the transmission data, the maximum number of IBC candidates is set to a value of 1 to 6. 4. A video decoding device for video decoding, comprising a processing circuit configured to: - receiving an encoded video bitstream including the current picture, determining a predetermined condition associated with transmission data included in the encoded video bitstream, the predetermined condition including determining whether the maximum number of merge mode candidates exceeds the maximum number of intrablock copy (IBC) candidates, - in response to determining that the maximum number of merge mode candidates is greater than the maximum number of IBC candidates, setting the index size included in the transmission data for the vector predictor candidate list to the maximum number of merge mode candidates, and in response to determining that the maximum number merge mode candidates are less than the maximum number of IBC candidates, setting the index size to the maximum number of IBC candidates, - building a list of candidates with vector predictors, - extracting a vector predictor from the list of candidates according to an index whose value does not exceed a certain index size, and - decoding the current block in accordance with the extracted vector predictor. 5. A video decoder device for video decoding, comprising a processing circuit configured to: - receiving an encoded video bitstream including the current picture, - extracting transmission data from the encoded video bitstream for the current block, - determining whether the maximum number of merge candidates is included in the extracted transfer data for the current block, and - in response to determining that the maximum number of merge candidates are included in the transfer data, setting the maximum number of intra-block copy candidates (IBC) to a value from 1 to the maximum number of merge candidates. 6. The video decoder apparatus for decoding video according to claim 5, wherein in response to determining that the maximum number of merging candidates is not included in the transmission data, the maximum number of IBC candidates is set to a value of 1 to 6. 7. A non-transitory computer-readable storage medium containing instructions stored thereon which, when executed by a processor in a video decoder, cause the processor to perform the method of any one of claims 1-3.

Images