Intra-predictive mode information propagation for geometric partition modes using IBC and intra-prediction.

Abstract

To provide a method for receiving encoded information for a current block in a current picture of a video from an encoded video bitstream.SOLUTION: An encoded information indicates that a current block is divided into at least a first partition and a second partition based on a geometric partition mode (GPM). The first partition is associated with an intra block copy (IBC) prediction mode, and the second partition is associated with an intra prediction mode. Prediction mode information of a first subblock of a plurality of subblocks of the current block is stored. The prediction mode information includes one of a DC mode, a planar mode, and an intra prediction mode based on whether the first subblock is associated with the IBC prediction mode, the intra prediction mode, and one of both the IBC prediction mode and the intra prediction mode.SELECTED DRAWING: Figure 15

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of priority to U.S. Patent Application No. 17 / 898,447, filed Aug. 29, 2022, entitled "INTRA PREDICTION MODE INFORMATION PROPAGATION FOR GEOMETRIC PARTITION MODE WITH IBC AND INTRA PREDICTION", which claims the benefit of priority to U.S. Provisional Application No. 63 / 239,221, filed Aug. 31, 2021, entitled "Intra Prediction Mode Information Propagation for Geometric Partition Mode with IBC and Intra Prediction". The disclosures of the prior applications are hereby incorporated by reference in their entirety.

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

Background Art

[0003] The description of the background art provided herein is for the purpose of generally presenting the context of the present disclosure. The work of the inventors named herein is not admitted as prior art to the present disclosure, either expressly or implicitly, to the extent that the work is described in this background art section and to the extent that aspects of the description might not otherwise be eligible as prior art at the time of filing.

[0004] Uncompressed digital images and / or videos can consist of a series of pictures, each picture having spatial dimensions of, for example, 1920 × 1080 luminance samples and associated saturation samples. The series of pictures can have a fixed or variable picture rate (also informally known as frame rate), for example, 60 pictures per second or 60 Hz. Uncompressed images and / or videos have specific bitrate requirements. For example, 1080p60 4:2:0 video with 8 bits per sample (1920 × 1080 luminance sample resolution at a frame rate of 60 Hz) requires a bandwidth of nearly 1.5 Gbit / s. One hour of such video requires more than 600 GB of storage space.

[0005] One purpose of image and / or video coding and decoding may be to reduce the redundancy of input image and / or video signals through compression. Compression can help reduce the aforementioned bandwidth and / or storage space requirements by two orders of magnitude or more, in some cases. While this description uses video coding / decoding as an example for illustrative purposes, the same techniques can be applied to image coding / decoding in a similar manner without departing from the spirit of this disclosure. Both lossless and lossy compression, as well as combinations thereof, can be employed. Lossless compression refers to techniques that allow an exact copy of the original signal to be reconstructed from the compressed original signal. When using lossy compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signals is small enough to make the reconstructed signal useful for its intended purpose. In the case of video, lossy compression is widely employed. The amount of acceptable distortion depends on the application; for example, users of a particular consumer streaming application may tolerate higher distortion than users of a television distribution application. The feasible compression ratio can reflect that a higher tolerance for distortion can lead to a higher compression ratio.

[0006] Video encoders and decoders can utilize techniques from several broad categories, including, for example, motion compensation, transformation processing, and entropy coding.

[0007] Video codec technology may include a technique known as intra coding. In intra coding, sample values ​​are represented without referencing samples or other data from a previously reconstructed reference picture. In some video codecs, the picture is spatially subdivided into blocks of samples. When all blocks of samples are coded in intra mode, the picture can be an intra picture. Intra pictures, and their derivatives such as independent decoder refresh pictures, can be used to reset the decoder state and can therefore be used as the first picture in a coded video bitstream and video session, or as a still image. Samples in intra blocks can undergo transformations, and the transformation coefficients can be quantized before entropy coding. Intra prediction may be a technique to minimize the sample values ​​in the pre-transformation region. In some cases, the smaller the post-transformation DC value and the smaller the AC coefficient, the fewer bits are required at a given quantization step size to represent the post-entropy-coded block.

[0008] For example, traditional intra-coding used in MPEG-2 generation coding techniques does not use intra-prediction. However, some newer video compression techniques include those that attempt to perform predictions based on surrounding sample data and / or metadata acquired during the encoding / decoding of data blocks. Such techniques will henceforth be referred to as “intra-prediction” techniques. It should be noted that, at least in some cases, intra-prediction uses only reference data from the current picture being reconstructed, and not from the reference picture.

[0009] Intra-prediction can take many different forms. If two or more of these techniques can be used in a given video coding technique, the specific technique being used can be coded as a specific intra-prediction mode that uses that particular technique. In certain cases, an intra-prediction mode may have sub-modes and / or parameters, which can be coded individually or included in a mode codeword that defines the prediction mode being used. The choice of codeword for a given combination of mode, sub-mode, and / or parameter can affect the efficiency of coding via intra-prediction, and therefore the entropy coding technique used to convert the codeword into a bitstream can also have an impact.

[0010] A specific mode of intra-prediction was introduced in H.264, improved in H.265, and further refined in newer coding techniques such as Joint Search Models (JEM), Versatile Video Coding (VVC), and Benchmark Sets (BMS). Predictor blocks can be formed using neighboring sample values ​​belonging to already available samples. The sample values ​​of neighboring samples are copied to the predictor block according to the direction. References to the direction in use can be coded within the bitstream or predicted themselves.

[0011] Referring to Figure 1A, the lower right shows a subset of nine predictor directions known from the 33 possible predictor directions defined in H.265 (corresponding to 33 of the 35 intra-modes, or angular modes). The point where the arrows converge (101) represents the predicted sample. The arrows indicate the direction from which the sample is predicted. For example, arrow (102) indicates that sample (101) is predicted from one or more samples located to the upper right at an angle of 45 degrees from the horizontal. Similarly, arrow (103) indicates that sample (101) is predicted from one or more samples located to the lower left of sample (101) at an angle of 22.5 degrees from the horizontal.

[0012] Referring further to Figure 1A, a 4x4 sample square block (104) is illustrated in the upper left (indicated by a thick dashed line). The square block (104) contains 16 samples, each labeled with "S", its position in the Y dimension (e.g., row index), and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample (from the top) in the Y dimension and the first sample (from the left) in the X dimension. Similarly, sample S44 is the fourth sample in both the Y and X dimensions within block (104). Since the block is 4x4 samples in size, S44 is in the lower right. Furthermore, a reference sample is shown that follows a similar numbering scheme. The reference sample is labeled with R, its Y position (e.g., row index) relative to block (104), and its X position (column index). In both H.264 and H.265, the predicted samples are adjacent to the block being reconstructed, and therefore negative values ​​do not need to be used.

[0013] Intra-picture prediction can function by copying a reference sample value from an adjacent sample indicated by a signaled prediction direction. For example, suppose the coded video bitstream includes signaling for this block indicating a prediction direction corresponding to arrow (102), i.e., the sample is predicted to be to the upper right of the sample at an angle of 45 degrees from the horizontal. In that case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Then, sample S44 is predicted from reference sample R08.

[0014] In certain cases, to calculate the reference sample, especially when the direction is not evenly divisible by 45 degrees, the values ​​of multiple reference samples may be combined, for example, by interpolation.

[0015] The number of possible directions has increased as video coding technology has advanced. H.264 (2003) could represent nine different directions. This increased to 33 in H.265 (2013). Currently, JEM / VVC / BMS can support up to 65 directions. Experiments are being conducted to identify the most likely directions, and certain entropy coding techniques are used to represent those likely directions with a small number of bits, accepting a certain penalty for less likely directions. Furthermore, the direction itself can sometimes be predicted from the adjacent directions used in adjacent, already decoded blocks.

[0016] Figure 1B shows a schematic diagram (110) illustrating 65 intra prediction directions by JEM to show the prediction directions of the number that increase over time.

[0017] The mapping of intra-predicted direction bits, which represent direction within a coded video bitstream, can vary depending on the video coding technique. Such mappings can range from simple direct mappings to complex adaptive schemes involving codewords, most probable modes, and similar techniques. However, in most cases, there can be certain directions that are statistically less likely to occur in video content than other directions. Since the goal of video compression is to reduce redundancy, these less likely directions will be represented with more bits than the more likely directions in well-functioning video coding techniques.

[0018] Image and / or video coding and decoding can be performed using interpicture prediction with motion compensation. Motion compensation may be a lossy compression technique and may relate to a technique used to predict a newly reconstructed picture or part of a picture after blocks of sample data from a previously reconstructed picture or part thereof (reference picture) have been spatially shifted in the direction indicated by a motion vector (hereinafter, MV). In some cases, the reference picture may be the same as the picture currently being reconstructed. The MV can have two dimensions, X and Y, or three dimensions, the third of which is a representation of the reference picture in use (the latter indirectly may be the time dimension).

[0019] In some video compression techniques, the motion vector (MV) applicable to a particular area of ​​sample data can be predicted from other MVs, for example, from MVs related to other areas of sample data that are spatially adjacent to the area being reconstructed and precede that MV in the decoding order. Doing so significantly reduces the amount of data required to code the MV, thereby eliminating redundancy and increasing the compression ratio. For example, when coding an input video signal derived from a camera (known as natural video), MV prediction can work effectively because there is a statistical probability that areas larger than the area to which a single MV is applicable will move in a similar direction, and therefore, in some cases, predictions can be made using similar motion vectors derived from the MVs of adjacent areas. As a result, the detected MV for a given area is similar to or identical to the MV predicted from the surrounding MVs and can be represented with fewer bits than would be used when directly coding the MV after entropy coding. In some cases, MV prediction can be an example of lossless compression of the signal (i.e., MV) derived from the original signal (i.e., sample stream). In other cases, MV prediction itself may be lossy, for example, due to rounding errors when calculating the predictor from some surrounding MVs.

[0020] 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 provided by H.265, the one described with reference to Figure 2 is the technique hereafter referred to as "spatial merging."

[0021] Referring to Figure 2, the current block (201) contains samples that, during the motion search process, the encoder has found to be predictable from a previous block of the same size that has been spatially shifted. Instead of directly coding its MV, the MV can be derived from metadata associated with one or more reference pictures, for example, from the most recent reference picture (in decoding order), using the MV associated with one of the five surrounding samples represented as A0, A1, and B0, B1, B2 (202-206, respectively). In H.265, the MV prediction can use predictors from the same reference pictures used by adjacent blocks. [Overview of the Initiative] [Means for solving the problem]

[0022] Aspects of this disclosure provide methods and apparatus for video coding / decoding. In some examples, the apparatus for video decoding includes a processing circuit.

[0023] According to one aspect of the present disclosure, a method for video decoding is provided which is implemented in a video decoder. The method can receive encoded information of the current block in the current picture of a video from an encoded video bitstream. The encoded information can indicate that the current block is divided into at least a first partition and a second partition based on a geometric partitioning mode (GPM). The first partition can be associated with an intrablock copy (IBC) prediction mode, and the second partition can be associated with an intra-prediction mode. Prediction mode information for the first subblock of a plurality of subblocks of the current block can be stored. The prediction mode information can include one of DC mode, Planar mode, and intra-prediction mode, depending on whether the first subblock is associated with an IBC prediction mode, an intra-prediction mode, or one of both IBC prediction mode and intra-prediction mode.

[0024] This method allows for the derivation of the most likely mode (MPM) for adjacent blocks of the current block using stored prediction mode information.

[0025] In some embodiments, the step of storing prediction mode information, based on the fact that a first subblock is associated with an IBC prediction mode, may include storing only the Planar mode in the prediction mode information of the first subblock among a plurality of subblocks of the current block.

[0026] In some embodiments, the step of storing prediction mode information, based on the fact that a first subblock is associated with an intra-prediction mode, may include storing only the intra-prediction mode in the prediction mode information of the first subblock among a plurality of subblocks of the current block.

[0027] In some embodiments, based on the fact that the first sub-block is associated with both the IBC prediction mode and the intra prediction mode, the step of storing prediction mode information may include storing only the intra prediction mode in the prediction mode information of the first sub-block among a plurality of sub-blocks of the current block.

[0028] In one embodiment, based on the fact that the first partition of the current block is associated with the IBC prediction mode and the second partition of the current block is associated with the intra prediction mode, for each of the plurality of sub-blocks of the current block, the DC mode can be stored.

[0029] In one embodiment, based on the fact that the first partition of the current block is associated with the IBC prediction mode and the second partition of the current block is associated with the intra prediction mode, for each of the plurality of sub-blocks of the current block, the Planar mode can be stored.

[0030] In one embodiment, based on the fact that the first partition of the current block is associated with the IBC prediction mode and the second partition of the current block is associated with the intra prediction mode, for each of the plurality of sub-blocks of the current block, the intra prediction mode can be stored.

[0031] In some embodiments, the prediction mode information of the first sub-block among the plurality of sub-blocks of the current block can be the propagation intra mode for MPM derivation of the adjacent block of the current block, and the adjacent block is predicted by the IBC prediction mode.

[0032] In some embodiments, each of the plurality of sub-blocks of the current block can be a unit of 4×4 pixels respectively.

[0033] According to another aspect of this disclosure, an apparatus is provided. The apparatus includes a processing circuit. The processing circuit may be configured to perform any of the methods for video coding / decoding.

[0034] In aspects of this disclosure, a non-temporary computer-readable medium is also provided that, when executed by a computer for video decoding, stores instructions causing the computer to perform either a method for encoding / decoding video.

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

[0036] [Figure 1A] This is a schematic diagram of an exemplary subset of intra-predictive modes. [Figure 1B] This is an example diagram of the intra-prediction direction. [Figure 2] This is a schematic diagram of the current block and its surrounding spatial merge candidates in one example. [Figure 3] This is a schematic diagram of a simplified block diagram of a communication system (300) according to one embodiment. [Figure 4] This is a schematic diagram of a simplified block diagram of a communication system (400) according to one embodiment. [Figure 5] This is a schematic diagram of a simplified block diagram of a decoder according to one embodiment. [Figure 6] This is a schematic diagram of a simplified block diagram of an encoder according to one embodiment. [Figure 7] Block diagram of an encoder according to another embodiment. [Figure 8] Block diagram of a decoder according to another embodiment. [Figure 9] This figure shows exemplary locations of spatial merge candidates according to another embodiment. [Figure 10] This figure shows an exemplary redundancy check for spatial merge candidates. [Figure 11] This figure shows a schematic diagram of the scaling of motion vectors of time merge candidates according to one embodiment. [Figure 12] This figure shows exemplary candidate positions for time merge candidates according to one embodiment. [Figure 13] This figure shows an exemplary angular distribution of geometric partition modes (GPM) according to one embodiment. [Figure 14] This figure shows an exemplary partition line of a GPM according to one embodiment. [Figure 15] This figure shows a flowchart illustrating an exemplary decoding process according to some embodiments of the present disclosure. [Figure 16] This figure shows a flowchart illustrating an exemplary coding process according to some embodiments of the present disclosure. [Figure 17] This is a schematic diagram of a computer system according to one embodiment. [Modes for carrying out the invention]

[0037] Figure 3 shows an exemplary block diagram of a communication system (300). The communication system (300) includes a plurality of terminal devices that can communicate with each other, for example, via a network (350). For example, the communication system (300) includes a first pair of terminal devices (310) and (320) interconnected via the network (350). In the example of Figure 3, the first pair of terminal devices (310) and (320) perform unidirectional transmission of data. For example, terminal device (310) may code video data (e.g., a stream of video pictures captured by terminal device (310)) for transmission to another terminal device (320) via the network (350). The coded video data may be transmitted in the form of one or more coded video bitstreams. Terminal device (320) may receive coded video data from the network (350), decode the coded video data to restore the video pictures, and display the video pictures according to the restored video data. Unidirectional data transmission can be common in applications such as media delivery.

[0038] In another example, the communication system (300) includes a second pair of terminal devices (330) and (340) that perform bidirectional transmission of coded video data, for example, during a video conference. In the case of bidirectional data transmission, in one example, each terminal device of terminal devices (330) and (340) can code video data (e.g., a stream of video pictures captured by the terminal device) for transmission to the other terminal device of terminal devices (330) and (340) via the network (350). Each terminal device of terminal devices (330) and (340) can also receive coded video data transmitted by the other terminal device of terminal devices (330) and (340), decode the coded video data to restore video pictures, and display video pictures on an accessible display device according to the restored video data.

[0039] In the example in Figure 3, terminal devices (310), (320), (330), and (340) are exemplified as a server, a personal computer, and a smartphone, respectively, but the principles of this disclosure are not limited thereto. Embodiments of this disclosure are applicable with laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network (350) represents any number of networks that transmit coded video data between terminal devices (310), (320), (330), and (340), including, for example, wired and / or wireless communication networks. Communication network (350) can exchange data over circuit-switched channels and / or packet-switched channels. Typical networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For the purposes of this description, the architecture and topology of network (350) may not be important to the operation of this disclosure unless described below herein.

[0040] Figure 4 shows a video encoder and video decoder in a streaming environment as an example of an application of the subject matter of disclosure. The subject matter of disclosure may be equally applicable to other video-enabled applications, including, for example, video conferencing, digital television, streaming services, and storage of compressed video on digital media such as CDs, DVDs, and memory sticks.

[0041] The streaming system may include, for example, a capture subsystem (413) which may include a video source (401), such as a digital camera, that creates a stream (402) of uncompressed video pictures. In one example, the stream (402) of video pictures includes samples captured by the digital camera. The stream (402) of video pictures, illustrated as a thick line to highlight the large amount of data compared to encoded video data (404) (or encoded video bitstream), can be processed by an electronic device (420) which includes a video encoder (403) coupled to the video source (401). The video encoder (403) may include hardware, software, or a combination thereof that enables or implements aspects of the disclosed subject, as will be described in more detail below. The encoded video data (404) (or encoded video bitstream), illustrated as a thin line to highlight the small amount of data compared to the stream (402), can be stored in a streaming server (405) for future use. One or more streaming client subsystems, such as client subsystems (406) and (408) in Figure 4, can access a streaming server (405) and retrieve copies (407) and (409) of the encoded video data (404). The client subsystem (406) may include, for example, a video decoder (410) within an electronic device (430). The video decoder (410) decodes the input copy (407) of the encoded video data and creates an output stream (411) of a video picture that can be rendered on a display (412) (e.g., a display screen) or other rendering device (not shown). In some streaming systems, the encoded video data (404), (407), and (409) (e.g., video bitstreams) can be encoded according to specific video coding / compression standards. Examples of such standards include ITU-T Recommendation H.265.For example, a video coding standard under development is informally known as Multipurpose Video Coding (VVC). The subject of this disclosure may be used in the context of VVC.

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

[0043] Figure 5 shows an exemplary block diagram of a video decoder (510). The video decoder (510) can be included in an electronic device (530). The electronic device (530) can include a receiver (531) (e.g., a receiving circuit). The video decoder (510) can be used in place of the video decoder (410) in the example of Figure 4.

[0044] The receiver (531) can receive one or more coded video sequences to be decoded by the video decoder (510). In one embodiment, one coded video sequence is received at a time, and the decoding of each coded video sequence is independent of the decoding of other coded video sequences. The coded video sequences may be received from a channel (501), which may be a hardware / software link to a storage device that stores coded video data. The receiver (531) can receive coded video data together with other data, such as coded audio data and / or auxiliary data streams, which may be transferred to their respective usage entities (not shown). The receiver (531) can isolate the coded video sequences from other data. To combat network jitter, a buffer memory (515) may be coupled between the receiver (531) and the entropy decoder / parser (520) (hereinafter, "Parser (520)"). In certain applications, the buffer memory (515) is part of the video decoder (510). In other applications, the buffer memory (515) may be located outside the video decoder (510) (not shown). In yet other applications, for example to counter network jitter, a buffer memory (not shown) may exist outside the video decoder (510), and in addition, another buffer memory (515) may exist inside the video decoder (510), for example to handle playout timing. When the receiver (531) is receiving data from a storage / transfer device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (515) may not be necessary or can be made small. For use in best-effort packet networks such as the Internet, the buffer memory (515) may be required, may be relatively large, may be advantageously adaptive in size, and may be at least partially implemented in the operating system or a similar element outside the video decoder (510) (not shown).

[0045] The video decoder (510) may include a parser (520) to reconstruct symbols (521) from the coded video sequence. These categories of symbols include information used to manage the operation of the video decoder (510), and potentially information for controlling rendering devices, such as a rendering device (512) (e.g., a display screen) which, as shown in Figure 5, is not an integral part of the electronic device (530) but can be coupled to the electronic device (530). Control information for rendering devices may be in the form of supplemental enhancement information (SEI) messages or parameter set fragments (not shown) of video usability information (VUI). The parser (520) can parse / entropy decode the received coded video sequence. The coding of the coded video sequence may conform to video coding techniques or standards and may follow various principles, including context-dependent or non-context-dependent variable-length coding, Huffman coding, arithmetic coding, etc. The parser(520) can extract from the coded video sequence a set of at least one subgroup parameters of a subgroup of pixels in the video decoder, based on at least one parameter corresponding to a group. Subgroups can include picture groups (GOP), pictures, tiles, slices, macroblocks, coding units (CU), blocks, transform units (TU), and predictive units (PU). The parser(520) can also extract information from the coded video sequence such as transform coefficients, quantizer parameter values, and motion vectors.

[0046] The parser (520) can perform entropy decoding / parsing operations on the video sequence received from buffer memory (515) in order to create symbols (521).

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

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

[0049] The first unit is the scaler / inverse unit (551). The scaler / inverse unit (551) receives control information from the parser (520) as symbols (521), including the quantization conversion coefficients, which conversion to use, block size, quantization coefficients, and quantization scaling matrix. The scaler / inverse unit (551) can output a block containing sample values ​​that can be input to the aggregator (555).

[0050] In some cases, the output samples of the scaler / inverse unit (551) may relate to intracoded blocks. Intracoded blocks are blocks that do not use prediction information from previously reconstructed pictures but can use prediction information from previously reconstructed portions of the current picture. Such prediction information can be provided by the intrapicture prediction unit (552). In some cases, the intrapicture prediction unit (552) generates a block of the same size and shape as the block being reconstructed, using surrounding already reconstructed information fetched from the current picture buffer (558). The current picture buffer (558) buffers, for example, partially reconstructed current pictures and / or fully reconstructed current pictures. The aggregator (555) may, sample by sample, add the prediction information generated by the intraprediction unit (552) to the output sample information provided by the scaler / inverse unit (551).

[0051] In other cases, the output samples of the scaler / inverse unit (551) may relate to an interconnected and potentially motion-compensated block. In such cases, the motion-compensated prediction unit (553) can access the reference picture memory (557) to fetch samples to be used for prediction. After motion-compensating the fetched samples according to the symbols (521) related to the block, these samples can be added to the output of the scaler / inverse unit (551) by the aggregator (555) to generate output sample information (in this case, called residual samples or residual signals). The address in the reference picture memory (557) from which the motion-compensated prediction unit (553) fetches the prediction samples can be controlled by motion vectors available to the motion-compensated prediction unit (553) in the form of symbols (521), which may have X, Y, and reference picture components, for example. Motion compensation may also include interpolation of sample values ​​fetched from the reference picture memory (557) when the exact motion vectors of the subsamples are used, motion vector prediction mechanisms, etc.

[0052] The output samples of the aggregator (555) can undergo various loop filtering techniques in the loop filter unit (556). The video compression technique may include in-loop filtering techniques, which are controlled by parameters contained in the coded video sequence (also called the coded video bitstream) and provided to the loop filter unit (556) as symbols (521) from the parser (520). Video compression may also be performed in response to metadata obtained during decoding of earlier portions (in decoding order) of the coded picture or coded video sequence, and in response to previously reconstructed and loop-filtered sample values.

[0053] The output of the loop filter unit (556) can be a sample stream that can be output to the rendering device (512) as well as stored in the reference picture memory (557) for use in future interpicture prediction.

[0054] Once fully reconfigured, a particular coded picture can be used as a reference picture for future predictions. For example, once the coded picture corresponding to the current picture has been fully reconfigured and the coded picture has been identified as a reference picture (e.g., by the parser (520)), the current picture buffer (558) can become part of the reference picture memory (557), and any unused current picture buffer can be reallocated before starting the reconfiguration of the next coded picture.

[0055] The video decoder (510) can perform decoding operations in accordance with a given video compression technology or standard, such as ITU-T Rec.H.265. The coded video sequence may conform to the syntax specified by the video compression technology or standard being used, in the sense that the coded video sequence adheres to both the syntax of the video compression technology or standard and the profile documented in the video compression technology or standard. Specifically, a profile may select several tools from all the tools available in the video compression technology or standard as the only tools available for use under that profile. Also, compliance may require that the complexity of the coded video sequence be within the range defined by the level of the video compression technology or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limitations set by the level may, in some cases, be further limited by the virtual reference decoder (HRD) specification and metadata for HRD buffer management signaled in the coded video sequence.

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

[0057] Figure 6 shows an exemplary block diagram of a video encoder (603). The video encoder (603) is contained within an electronic device (620). The electronic device (620) includes a transmitter (640) (e.g., a transmitting circuit). The video encoder (603) can be used in place of the video encoder (403) in the example of Figure 4.

[0058] The video encoder (603) can capture video images coded by the video encoder (603) and can receive video samples from a video source (601) which is not part of the electronic device (620) in the example in Figure 6. In another example, the video source (601) is part of the electronic device (620).

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

[0060] According to one embodiment, the video encoder (603) can encode and compress pictures of a source video sequence into an encoded video sequence (643) in real time or under any other time constraints required. One function of the controller (650) is to implement an appropriate coding speed. In some embodiments, the controller (650) controls and is functionally coupled to other functional units, which are described below. For clarity, the couplings are not illustrated. Parameters set by the controller (650) may include rate control-related parameters (such as picture skips, quantizers, lambda values ​​for rate distortion optimization techniques), picture size, picture group (GOP) layout, and maximum motion vector search range. The controller (650) can be configured to have other appropriate functions related to the video encoder (603) optimized for a particular system design.

[0061] In some embodiments, the video encoder (603) is configured to operate in a coding loop. In a simplified explanation, one example of a coding loop may include a source coder (630) (responsible for creating symbols, such as a symbol stream, based, for example, the input picture to be coded and a reference picture), as well as a (local) decoder (633) built into the video encoder (603). The decoder (633) reconstructs the symbols in a similar manner to how the (remote) decoder would create sample data. The reconstructed sample stream (sample data) is fed into the reference picture memory (634). Since decoding the symbol stream leads to bit-accurate results regardless of the decoder's location (local or remote), the contents of the reference picture memory (634) are also bit-accurate between the local and remote encoders. In other words, the predictive portion of the encoder "sees" the exact same sample values ​​as the reference picture samples that the decoder "sees" when using predictions during decoding. This fundamental principle of reference picture synchronization (and the resulting drift when synchronization cannot be maintained, for example, due to channel errors) is also used in several related technologies.

[0062] The operation of the “local” decoder (633) may be the same as that of a “remote” decoder, such as the video decoder (510), which has already been described in detail above with reference to Figure 5. However, referring again briefly to Figure 5, since symbols are available and the encoding / decoding of symbols to the coded video sequence by the entropy coder (645) and parser (520) may be reversible, the entropy decoding portion of the video decoder (510), including the buffer memory (515), and the parser (520) may not be fully implemented in the local decoder (633).

[0063] In one embodiment, the decoder technology, excluding parsing / entropy decoding present within the decoder, exists in the corresponding encoder in the same or substantially the same functional form. Therefore, the disclosed subject matter focuses on the operation of the decoder. A description of the encoder technology can be omitted, as it is the inverse of the comprehensively described decoder technology. More detailed descriptions are provided below in specific areas.

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

[0065] The local video decoder (633) can decode the coded video data of a picture that may be designated as a reference picture based on symbols created by the source coder (630). The operation of the coding engine (632) can, advantageously, be a lossy process. When the coded video data can be decoded by a video decoder (not shown in Figure 6), the reconstructed video sequence may typically be a replica of the source video sequence with some errors. The local video decoder (633) can replicate the decoding process that may be performed by the video decoder on the reference picture so that the reconstructed reference picture is stored in the reference picture memory (634). In this way, the video encoder (603) can locally store a copy of the reconstructed reference picture that has common content as the reconstructed reference picture acquired by the far-end video decoder (without transmission errors).

[0066] The predictor (635) can perform predictive searches for the coding engine (632). That is, for a new picture to be coded, the predictor (635) can search the reference picture memory (634) for sample data (as candidate reference pixel blocks) or reference picture motion vectors, block shapes, and other specific metadata that can serve as appropriate predictive references for the new picture. The predictor (635) can operate on sample blocks pixel by pixel to find appropriate predictive references. In some cases, the input picture may have predictive references drawn from multiple reference pictures stored in the reference picture memory (634), as determined by the search results obtained by the predictor (635).

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

[0068] The output of all the aforementioned functional units can undergo entropy coding within the entropy coder (645). The entropy coder (645) converts the symbols generated by the various functional units into coded video sequences by applying lossless compression to the symbols according to techniques such as Huffman coding, variable-length coding, and arithmetic coding.

[0069] The transmitter (640) can buffer the coded video sequence created by the entropy coder (645) and prepare it for transmission over the communication channel (660), which may be a hardware / software link to a storage device that stores the coded video data. The transmitter (640) can merge the coded video data from the video encoder (603) with other data to be transmitted, such as coded audio data and / or auxiliary data streams (sources not shown).

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

[0071] An intra-picture (I-picture) may be one that can be coded and decoded without using any other picture in the sequence as a prediction source. Some video codecs enable different types of intra-pictures, including, for example, independent decoder refresh ("IDR") pictures. Those skilled in the art are aware of their variations of I-pictures, as well as their respective uses and characteristics.

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

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

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

[0075] The video encoder (603) can perform coding operations in accordance with a specified video coding technique or standard, such as ITU-T Rec.H.265. In this operation, the video encoder (603) can perform various compression operations, including predictive coding operations that utilize temporal and spatial redundancy in the input video sequence. Therefore, the coded video data may conform to the syntax specified by the video coding technique or standard being used.

[0076] In one embodiment, the transmitter (640) may transmit additional data along with the encoded video. The source coder (630) may include such data as part of the coded video sequence. The additional data may include time / space / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, SEI messages, VUI parameter set fragments, and the like.

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

[0078] In some embodiments, a dual prediction technique may be used in interpicture prediction. According to the dual prediction technique, two reference pictures are used, such as a first reference picture and a second reference picture, both of which are earlier in the decoding order than the current picture in the video (but may be past and future in the display order, respectively). A block in the current picture can be coded by a first motion vector pointing to a first reference block in the first reference picture, and a second motion vector pointing to a second reference block in the second reference picture. The block can be predicted by a combination of the first and second reference blocks.

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

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

[0081] Figure 7 shows an illustrative diagram of a video encoder (703). The video encoder (703) is configured to receive a processing block (e.g., a prediction block) of sample values ​​in the current video picture within a sequence of video pictures, and to encode the processing block into a coded picture which is part of a coded video sequence. In one example, the video encoder (703) is used instead of the video encoder (403) in the example of Figure 4.

[0082] In the HEVC example, the video encoder (703) receives a matrix of sample values ​​for a processing block, such as an 8x8 sample prediction block. The video encoder (703) determines whether the processing block is best coded using intra-mode, inter-mode, or bi-prediction mode, for example, using rate-distortion optimization. When the processing block is coded in intra-mode, the video encoder (703) can encode the processing block into a coded picture using intra-prediction techniques, and when the processing block is coded in inter-mode or bi-prediction mode, the video encoder (703) can encode the processing block into a coded picture using inter-prediction techniques or bi-prediction techniques, respectively. In certain video coding techniques, merge mode may be an inter-picture prediction submode in which the motion vector is derived from one or more motion vector predictors, without the advantage of coded motion vector components outside the predictors. In certain other video coding techniques, there may be motion vector components applicable to the target block. In one example, the video encoder (703) includes other components, such as a mode determination module (not shown), to determine the mode of the processing block.

[0083] In the example shown in Figure 7, the video encoder (703) includes an interencoder (730), an intraencoder (722), a residual calculator (723), a switch (726), a residual encoder (724), a general-purpose controller (721), and an entropy encoder (725), all coupled together as shown in Figure 7.

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

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

[0086] The general-purpose controller (721) is configured to determine general-purpose control data and to control other components of the video encoder (703) based on the general-purpose control data. In one example, the general-purpose controller (721) determines the mode of a block and provides control signals to the switch (726) based on the mode. For example, when the mode is intra-mode, the general-purpose controller (721) controls the switch (726) to select intra-mode results for use by the residual calculator (723), controls the entropy encoder (725) to select intra-prediction information, and includes the intra-prediction information in the bitstream. When the mode is inter-mode, the general-purpose controller (721) controls the switch (726) to select inter-prediction results for use by the residual calculator (723), controls the entropy encoder (725) to select inter-prediction information, and includes the inter-prediction information in the bitstream.

[0087] The residual calculator (723) is configured to calculate the difference (residual data) between the receiving block and the prediction result selected from the intra-encoder (722) or inter-encoder (730). The residual encoder (724) is configured to operate on the residual data to encode the residual data and generate conversion coefficients. In one example, the residual encoder (724) is configured to convert the residual data from the spatial domain to the frequency domain and generate conversion coefficients. The conversion coefficients are then subjected to quantization to obtain quantized conversion coefficients. In various embodiments, the video encoder (703) also includes a residual decoder (728). The residual decoder (728) is configured to perform the inverse transform and generate decoded residual data. The decoded residual data can be appropriately used by the intra-encoder (722) and inter-encoder (730). For example, an interencoder (730) can generate a decoded block based on decoded residual data and interprediction information, and an intraencoder (722) can generate a decoded block based on decoded residual data and intraprediction information. In some examples, the decoded block is appropriately processed to generate a decoded picture, which can be buffered in a memory circuit (not shown) and used as a reference picture.

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

[0089] Figure 8 shows an exemplary diagram of a video decoder (810). The video decoder (810) is configured to receive a coded picture, which is part of a coded video sequence, and to decode the coded picture to produce a reconstructed picture. In one example, the video decoder (810) is used instead of the video decoder (410) in the example in Figure 4.

[0090] In the example shown in Figure 8, the video decoder (810) includes an entropy decoder (871), an interdecoder (880), a residual decoder (873), a reconfiguration module (874), and an intradecoder (872) coupled together as shown in Figure 8.

[0091] The entropy decoder (871) can be configured to reconstruct specific symbols from the coded picture that represent the syntactic elements comprising the coded picture. Such symbols may include, for example, the mode in which the block is coded (e.g., intra-mode, inter-mode, bi-prediction mode, merge sub-mode, or inter-mode and bi-prediction mode of other sub-modes), as well as prediction information (e.g., intra-prediction and inter-prediction information) that can be identified by the intra-decoder (872) or inter-decoder (880), respectively, as to specific samples or metadata used for prediction. The symbols may also include, for example, residual information in the form of quantization transformation coefficients. In one example, if the prediction mode is inter-mode or bi-prediction mode, inter-prediction information is provided to the inter-decoder (880), and if the prediction type is intra-prediction type, intra-prediction information is provided to the intra-decoder (872). The residual information may undergo inverse quantization and be provided to the residual decoder (873).

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

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

[0094] The residual decoder (873) is configured to perform inverse quantization to extract inverse quantization conversion coefficients, process these coefficients, and convert the residual information from the frequency domain to the spatial domain. The residual decoder (873) may also require certain control information (to include quantizer parameters (QP)), which may be provided by the entropy decoder (871) (the data path is not illustrated as this may only contain a small amount of control information).

[0095] The reconstruction module (874) is configured to combine residual information output by the residual decoder (873) and prediction results (which may be output by the inter-prediction module or intra-prediction module) in the spatial domain to form reconstruction blocks that may become part of a reconstructed picture, and the reconstructed picture may become part of a reconstructed video. Note that other appropriate operations, such as deblocking operations, may be performed to improve visual quality.

[0096] It should be noted that the video encoders (403), (603), and (703), and the video decoders (410), (510), and (810) can be implemented using any suitable technology. In one embodiment, the video encoders (403), (603), and (703), and the video decoders (410), (510), and (810) can be implemented using one or more integrated circuits. In another embodiment, the video encoders (403), (603), and (603), and the video decoders (410), (510), and (810) can be implemented using one or more processors that execute software instructions.

[0097] This disclosure includes embodiments relating to geometric partition modes (GPM) using intrablock copies (IBCs), such as signaling, processing, and storing IBC BV information, and processing a list of BV merge candidates for a GPM using IBCs.

[0098] ITU-T VCEG (Q6 / 16) and ISO / IEC MPEG (JTC 1 / SC 29 / WG 11) published the H.265 / HEVC (High Efficiency Video Coding) standard in 2013 (version 1), 2014 (version 2), 2015 (version 3), and 2016 (version 4). In 2015, the two standards bodies jointly formed JVET (Joint Video Research Team) to explore the possibility of developing the next video coding standard beyond HEVC. In October 2017, the two standards bodies published the Joint Call for Proposals on Video Compression with Capability beyond HEVC (CfP). By February 15, 2018, 22 CfP responses had been submitted for Standard Dynamic Range (SDR), 12 for High Dynamic Range (HDR), and 12 for the 360 ​​video category. In April 2018, all CfP responses received were evaluated at the 122nd MPEG / 10th JVET meeting. As a result of this meeting, JVET officially launched the standardization process for next-generation video coding beyond HEVC, the new standard was named Versatile Video Coding (VVC), and JVET was renamed Joint Video Expert Team. In 2020, ITU-T VCEG (Q 6 / 16) and ISO / IEC MPEG (JTC 1 / SC 29 / WG 11) published the VVC video coding standard (version 1).

[0099] In interpretation, motion parameters are required for each interpreted coding unit (CU) to code features of the VVC used for interpreted sample generation, for example. Motion parameters can include motion vectors, reference picture indices, reference picture list usage indices, and / or additional information. Motion parameters can be signaled explicitly or implicitly. If a CU is encoded in skip mode, it can be associated with one PU, and significance residual coefficients, encoded motion vector deltas, and / or reference picture indices may not be required. If a CU is encoded in merge mode, the motion parameters of the CU can be obtained from adjacent CUs. Adjacent CUs can include spatial and temporal candidates, as well as additional schedules (or additional candidates) as introduced in VVCs. Merge mode can be applied to any interpreted CU, not just skip mode. An alternative to merge mode is the explicit transmission of motion parameters, where motion vectors, corresponding reference picture indices for each reference picture list, reference picture list usage flags, and / or other necessary information can be explicitly signaled for each CU.

[0100] In VVC, the VVC Test Model (VTM) reference software may include several new and improved interpredictive coding tools, which may include one or more of the following: (1) Extended merge prediction (2) Merged motion vector difference (MMVD) (3) AMVP mode with symmetric MVD signaling (4) Affine motion compensation prediction (5) Subblock-based time-motion vector prediction (SbTMVP) (6) Adaptive motion vector resolution (AMVR) (7) Motion field memory: 1 / 16 luminance sample MV memory and 8x8 motion field compression (8) Biprediction (BCW) using CU-level weights (9) Bidirectional Optical Flow (BDOF) (10) Decoder-side motion vector improvement (DMVR) (11) Combination of inter-prediction and intra-prediction (CIIP) (12) Geometric Partition Mode (GPM)

[0101] The merge candidate list can be constructed to include five types of candidates, similar to VTM 4. The merge candidate list can be constructed in the following order: 1) Spatial MVP from spatially adjacent CUs, 2) Time MVP from collated CU, 3) History-based MVP from FIFO table, 4) Pairwise average MVP, and 5) Zero MV.

[0102] The size of the merge list can be signaled in the slice header. The maximum allowable size of the merge list can be 6, as in VTM 4. For each CU encoded in merge mode, the index of the best merge candidate can be encoded, for example, using truncation unary binarization. The first bin of the merge index can be encoded in context, while bypass encoding can be used for the other bins.

[0103] In spatial candidate derivation, for example in VVC, the derivation of spatial merge candidates may be the same as or similar to the derivation of spatial merge candidates in HEVC. A maximum number of merge candidates (e.g., four merge candidates) can be selected from candidates located at positions such as those shown in Figure 9. As shown in Figure 9, the current block (901) can contain adjacent blocks (902) to (906) located at positions A0, A1, B0, B1, and B2, respectively. The derivation order of spatial merge candidates can be B1, A1, B0, A0, B2. Position B2 may only be considered if none of the CUs (or blocks) at positions A0, B0, B1, or A1 are available (e.g., because the CU belongs to a different slice or tile) or are intra-encoded. After the candidate (or block) at position A1 is added, the addition of the remaining candidates (or blocks) may be subject to redundancy checks. Redundancy checks can ensure that candidates with the same motion information are excluded from the merge list so as to improve coding efficiency. To reduce computational complexity, redundancy checks do not need to consider all possible candidate pairs. Instead, only candidate pairs linked by the arrows in Figure 10 may be considered. For example, redundancy checks can be applied to five candidate pairs, such as the candidate pair A1 and B1, and the candidate pair A1 and A0. Candidates can only be added to the merge list if the corresponding candidate used in the redundancy check does not contain the same motion information. For example, candidate B0 can only be added to the merge list if the corresponding candidate B1 does not contain the same motion information.

[0104] In time candidate derivation, only one candidate may be added to the merge list. For example, as shown in Figure 11, the derivation of a time merge candidate for the current CU(1114) can derive a motion vector scaled based on a colocated CU(1104) belonging to a colocated reference picture(1112). The list of reference pictures used to derive the colocated CU(1104) can be explicitly signaled in the slice header. The scaled motion vector of the time merge candidate can be obtained as shown by the dotted line(1102) in Figure 11, which is scaled from the motion vector of the colocated CU(1104) using picture order count (POC) distances tb and td. tb can be defined as the POC difference between the current picture's reference picture (e.g., Curr_ref)(1106) and the current picture (e.g., Curr_pic)(1108). td can be defined as the POC difference between the collated picture's reference picture (e.g., Col_ref)(1110) and the collated picture (e.g., Col_pic)(1112). The reference picture index of the time merge candidate can be set to equal to 0.

[0105] The position of the time candidate can be selected between candidates C0 and C1, as shown in Figure 12. For example, if the CU at position C0 is unavailable, intra-encoded, or outside the current line of the CTU, position C1 can be used. Otherwise, position C0 can be used to derive the time merge candidate.

[0106] GPM can be applied to interpretation. GPM can only be applied to CUs of a specific size, e.g., 8x8 size or larger. GPM can be signaled using, for example, CU-level flags and function as one type of merge mode. Other merge modes may include normal merge mode, MMVD mode, CIIP mode, and / or subblock merge mode.

[0107] When GPM is used, a CU can be divided into two geometric partitions by using one of several partition schemes. Partition schemes can be distinguished by angles and / or edges. In one embodiment, 64 different partition schemes can be applied to GPM. The 64 different partition schemes can be distinguished by 24 angles that are quantized non-uniformly with a maximum of 4 edges, ranging from 0 to 360° with respect to the center of the CU. Figure 13 shows 24 exemplary angles applied to GPM. Figure 14 shows four exemplary possible partition edges associated with an angle in CU(1402) whose index is 3, and each partition edge may be associated with its respective distance index. The distance index may represent the distance with respect to the center of CU(1402). In GPM, each geometric partition in the CU can be mutually predicted using its respective motion vector. Furthermore, only single predictions may be allowed per partition. For example, each partition may have one motion vector and one reference index. The constraint that only single-prediction movements are allowed for each partition ensures that only two motion-compensated predictions are needed for each CU, and this also applies to conventional biprediction.

[0108] When GPM is used for the current CU, signals indicating the geometric partition index and two merge indices (one for each partition) can be further signaled. The maximum GPM candidate size can be explicitly signaled, for example, at the slice level. The maximum GPM candidate size can specify the syntax binarization of the GPM merge index. After each of the two geometric partitions has been predicted, the sample values ​​along the geometric partition edges can be adjusted using a blending process with adaptive weights. Thus, a predicted signal for the entire CU can be generated after blending. The transformation and quantization processes can be further applied to the entire CU in other prediction modes. Furthermore, the motion field of the CU predicted using GPM can be stored.

[0109] The implementation cost of IBC can be high for the entire already reconstructed area of ​​the current picture. For example, a drawback of the IBC concept in HEVC is the requirement for additional memory in the decoded picture butter (DPB). Therefore, hardware implementations of IBC typically use external memory. Access to additional external memory can result in increased memory bandwidth.

[0110] In certain implementations, it may be necessary to reduce implementation costs. For example, VVC can significantly reduce memory bandwidth requirements and hardware complexity by using fixed memory, which can implement IBC by using on-chip memory. Furthermore, in block vector (BV) coding of IBC, the concept of a merge list can be used for interpretation. The IBC list construction process can consider two spatially adjacent BVs and five history-based BVs (HBVPs), and if the first HBVP is added to the candidate list (or IBC list), only the first HBVP can be compared with spatial candidates (e.g., BVs of two spatial candidates).

[0111] To further improve compression efficiency in formats such as VVC, template matching (TM) can be used to improve motion on the decoder side. In TM mode, motion is improved by constructing a template from adjacent reconstructed samples to the left and above, and the closest match between the template in the current picture and the reference frame can be determined.

[0112] A TM can be applied to a GPM. Once a CU is encoded in a GPM, it can be determined whether a TM is applied to improve each motion of the geometric partition. If a TM is selected, a template can be constructed using adjacent samples to the left and above, and the motion can be further improved by finding the best match between the current template and a reference area in the reference frame that has the same template pattern. The improved motion can be used to perform motion compensation for the geometric partition and can also be stored in the motion field.

[0113] GPM can be applied to support inter-prediction and intra-prediction to improve coding performance beyond VVC. For example, in addition to motion vectors from a merge candidate list for each geometric partition in the GPM-applied CU, a predefined intra-prediction mode can be selected for (or relating to) the geometric partition lines. Based on a flag, the intra-prediction mode or inter-prediction mode can be determined for each geometric partition. If inter-prediction is selected, a single-prediction signal can be generated by MV from the merge candidate list. If, instead, intra-prediction mode is selected, a single-prediction signal can be generated from adjacent samples predicted from a specified index of the intra-prediction mode. Possible variations in the intra-prediction mode can be limited by the geometric shape. Finally, the two single-prediction signals can be blended in the same way as in a normal GPM.

[0114] To reduce complexity and signaling overhead, possible intra-predictive mode variations can be studied (or defined). For example, the impact of possible intra-predictive mode variations on GPMs using inter-predictive and intra-predictive methods was studied for two exemplary configurations. In the first configuration, only intra-directional modes parallel and perpendicular to (or with respect to) the geometric partition lines were tested. In addition to parallel and perpendicular intra-angle modes parallel to (or with respect to) the geometric partition lines, a Planar mode was also tested in the second configuration. Two or three possible intra-predictive modes were tested for geometric partitions in GPMs using inter-predictive and intra-predictive methods.

[0115] Template-based intra-mode derivation (TIMD), such as in JVET-V0098, allows for the calculation of the sum of absolute transformation differences (SATD) between the predicted and reconstructed samples in the template region of the current CU for each intra-mode within the MPM, and the intra-mode with the minimum SATD cost can be selected as the current CU. Instead of selecting only the single intra-mode with the minimum SATD cost, the first two modes with the minimum SATD costs derived using TIMD can also be selected as the current CU, for example in JVET-W0123. The two selected modes can be further fused using weights, and the weighted intra-prediction can be used as the intra-prediction for the current CU. Fusion can be applied if the cost of the selected intra-mode with the minimum SATD cost is greater than half the cost of the other selected intra-mode. Otherwise, only the intra-mode with the minimum SATD cost may be selected. When fusion is applied, weight values ​​can be derived from the SATD costs of the two modes.

[0116] This disclosure provides a GPM using IBC and intra-prediction modes, which can combine two geometric partitions generated for IBC and intra-prediction modes, respectively.

[0117] To improve coding efficiency, for example in JVET-W0123, the use of an intra-mode within a CU using inter-prediction (e.g., MODE_INTER predictive mode) can be stored and propagated as adjacent intra-information for MPM derivation of adjacent blocks of a CU. However, the use of an intra-mode within a CU using IBC can also be stored and propagated as adjacent intra-information for MPM derivation when an IBC block is coded as GPM and intra using IBC.

[0118] This disclosure allows for the storage of intra-prediction mode information and intra-predictions for a GPM using IBC. For example, a current block can be divided into a first partition and a second partition. The first partition can be IBC encoded, and the second partition can be intra-encoded. Intra-prediction mode information for the second partition can be stored, such as the intra-prediction mode applied to predict the second partition. The stored intra-mode information can be further used as adjacent intra-mode information when the prediction mode of the current adjacent block is IBC. This allows the stored intra-mode information to be used as a propagating intra-mode for an IBC-encoded adjacent block. If the adjacent block is a reference block of the block, the intra-mode for that block can be derived from the stored intra-prediction mode information. The stored intra-prediction mode information can also be applied to the MPM derivation of the current block encoded as a GPM using IBC and intra.

[0119] In one embodiment, intra-prediction mode information for GPM using IBC and intra can be stored in N×N units (e.g., 4×4 sample units) of the current block. For example, the current block can be divided into multiple N×N units. Intra-prediction mode information for each of the N×N units can be stored in the corresponding memory unit (or cell).

[0120] In one embodiment, either the PLANAR mode or a selected intra mode used for geometric partitioning using intra prediction within a CU (or current block) can be stored in an N×N unit (e.g., 4×4 unit) of the current block for each geometric partition. In one example, if the geometric partition of the current block based on the GPM is generated using an IBC (or if the geometric partition is predicted based on the IBC), the PLANAR mode can be stored in the corresponding N×N unit (e.g., 4×4 unit) of the geometric partition. This allows the PLANAR mode to be stored for each of the N×N units located within the geometric partition for the N×N units in the geometric partition generated by the IBC. In another example, if the geometric partition of the current block based on the GPM is generated using intra prediction, the encoded intra mode (or the intra mode applied to predict the geometric partition) can be stored in the corresponding N×N unit (e.g., 4×4 unit) of the geometric partition. This allows the encoded intra mode to be stored for each of the N×N units located within the geometric partition for the N×N units located within that geometric partition for the N×N units located within that geometric partition. The encoded intra-mode may be a DC mode, a PLANAR mode, or an angular mode. In yet another example, for N×N units along (or across) the geometric boundary of the current block based on the GPM, the encoded intra-mode used for a geometric partition having an intra-prediction in the current block may be stored for the N×N units along the geometric boundary. Thus, for N×N units across the geometric boundary of the current block where the first partition is IBC encoded and the second partition is intra-encoded, the intra-mode applied to predict the second partition can be stored.

[0121] In another embodiment, when the CU is encoded with GPM using IBC and intra-mode, the DC mode can be stored for all N×N units (e.g., 4×4 units) within the CU (or current block). Thus, the DC mode can be stored for each of the N×N units in the current block. The corresponding N×N units can be positioned along the geometric boundary between an IBC-encoded partition, an intra-mode-encoded partition, or an IBC-encoded partition and an intra-mode-encoded partition.

[0122] In another embodiment, when the CU is encoded with GPM using IBC and intra-mode, the PLANAR mode can be stored for all N×N units (e.g., 4×4 units) within the CU. Each of the N×N units may be positioned along the geometric boundary between an IBC-encoded partition, an intra-mode-encoded partition, or an IBC-encoded partition and an intra-mode-encoded partition.

[0123] In yet another embodiment, only the selected intra-mode used for geometric partitioning with intra-prediction within the CU can be stored for all N×N units (e.g., 4×4 units) within the CU. The CU can be encoded with GPM using IBC and intra-mode. The selected intra-mode can be DC mode, PLANAR mode, or angular mode applied to predict the geometric partition of the CU encoded with GPM using IBC and intra-mode. Thus, for each of the N×N units within the CU, the selected intra-mode for the corresponding N×N unit can be stored. The corresponding N×N unit can be positioned along the geometric boundary of an IBC-encoded partition, an intra-mode-encoded partition, or an IBC-encoded partition and an intra-mode-encoded partition.

[0124] Figure 15 shows a flowchart outlining an exemplary decoding process (1500) according to some embodiments of the present disclosure. Figure 16 shows a flowchart outlining an exemplary encoding process (1600) according to some embodiments of the present disclosure. The proposed processes may be used separately or combined in any order. Furthermore, each of the processes (or embodiments), encoder, and decoder may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored in a non-temporary computer-readable medium.

[0125] Any operation of the process (e.g., (1500) and (1600)) can be combined or arranged in any quantity or order as needed. In embodiments, two or more operations of the process (e.g., (1500) and (1600)) may be performed in parallel.

[0126] The process (e.g., (1500) and (1600)) can be used for reconstructing and / or encoding blocks to generate predicted blocks for the blocks being reconstructed. In various embodiments, the process (e.g., (1500) and (1600)) is performed by processing circuits such as processing circuits for terminal devices (310), (320), (330) and (340), processing circuits that perform the functions of a video encoder (403), processing circuits that perform the functions of a video decoder (410), processing circuits that perform the functions of a video decoder (510), and processing circuits that perform the functions of a video encoder (603). In some embodiments, the process (e.g., (1500) and (1600)) is implemented by software instructions, and so when a processing circuit executes a software instruction, the processing circuit performs the process (e.g., (1500) and (1600)).

[0127] As shown in Figure 15, process (1500) can start from (S1501) and proceed to (S1510). In (S1510), encoded information of the current block in the current picture of the video can be received from the encoded video bitstream. The encoded information can indicate that the current block is divided into at least a first partition and a second partition based on the geometric partitioning mode (GPM). The first partition can be associated with an intrablock copy (IBC) prediction mode, and the second partition can be associated with an intraprediction mode.

[0128] In (S1520), prediction mode information for a first subblock among multiple subblocks of the current block can be stored. The prediction mode information may include one of DC mode, Planar mode, and intra-prediction mode, depending on whether the first subblock is associated with an IBC prediction mode, an intra-prediction mode, or one of both IBC prediction mode and intra-prediction mode.

[0129] Process (1500) can use the stored predictive mode information to perform the derivation of the most likely mode (MPM) for the adjacent blocks of the current block.

[0130] In some embodiments, the step of storing prediction mode information, based on the fact that a first subblock is associated with an IBC prediction mode, may include storing only the Planar mode in the prediction mode information of the first subblock among a plurality of subblocks of the current block.

[0131] In some embodiments, the step of storing prediction mode information, based on the fact that a first subblock is associated with an intra-prediction mode, may include storing only the intra-prediction mode in the prediction mode information of the first subblock among a plurality of subblocks of the current block.

[0132] In some embodiments, based on the fact that the first subblock is associated with both IBC prediction mode and intra prediction mode, the step of storing prediction mode information may include storing only intra prediction mode in the prediction mode information of the first subblock among multiple subblocks of the current block.

[0133] In one embodiment, the DC mode can be stored for each of several subblocks of the current block, based on the fact that a first partition of the current block is associated with the IBC prediction mode and a second partition of the current block is associated with the intra prediction mode.

[0134] In one embodiment, a Planar mode can be stored for each of several subblocks of the current block, based on the fact that a first partition of the current block is associated with an IBC prediction mode and a second partition of the current block is associated with an intra prediction mode.

[0135] In one embodiment, based on the fact that a first partition of the current block is associated with an IBC prediction mode and a second partition of the current block is associated with an intra-prediction mode, an intra-prediction mode can be stored for each of several sub-blocks of the current block.

[0136] In some embodiments, the prediction mode information of a first subblock among a plurality of subblocks of the current block may be a propagation intramode for MPM derivation of adjacent blocks of the current block, and adjacent blocks are predicted by IBC prediction mode.

[0137] In some embodiments, each of the multiple subblocks of the current block can be a 4x4 pixel unit.

[0138] After (S1520), the process proceeds to (S1599) and terminates.

[0139] Process (1500) can be appropriately adapted. The steps of process (1500) can be modified and / or omitted. Additional steps can be added. Any appropriate implementation order can be used.

[0140] As shown in Figure 16, process (1600) can start from (S1601) and proceed to (S1610). In (S1610), the current block in the current picture can be divided into at least a first partition and a second partition based on the geometric partition mode (GPM). The first partition can be associated with an intrablock copy (IBC) prediction mode, and the second partition can be associated with an intraprediction mode.

[0141] In (S1620), prediction mode information for a first subblock among multiple subblocks of the current block can be stored. The prediction mode information may include one of DC mode, Planar mode, and intra-prediction mode, depending on whether the first subblock is associated with an IBC prediction mode, an intra-prediction mode, or one of both IBC prediction mode and intra-prediction mode.

[0142] In (S1630), encoding information for the current block can be generated. The encoding information can indicate that the current block is divided based on the GPM.

[0143] The process then proceeds to (S1699) and terminates.

[0144] Process (1600) can be appropriately adapted. Steps in Process (1600) can be modified and / or omitted. Additional steps can be added. Any appropriate implementation order can be used.

[0145] The technologies described above are implemented as computer software using computer-readable instructions and can be physically stored on one or more computer-readable media. For example, Figure 17 shows a computer system (1700) suitable for implementing a particular embodiment of the disclosed subject matter.

[0146] Computer software may be coded using any suitable machine code or computer language that can undergo assembly, compilation, linking, or similar mechanisms to generate code that includes instructions that can be executed directly by one or more computer central processing units (CPUs) and graphics processing units (GPUs), or through interpretation and microcode execution, etc.

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

[0148] The components shown in Figure 17 with respect to the computer system (1700) are essentially illustrative and are not intended to imply any limitation on the scope of use or functionality of computer software implementing embodiments of the present disclosure. The configuration of the components should not be construed as having any dependencies or requirements on any or any combination of components shown in the exemplary embodiments of the computer system (1700).

[0149] The computer system (1700) may include certain human interface input devices. Such human interface input devices may respond to input from one or more human users via, for example, tactile input (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, applause), visual input (e.g., gestures), or olfactory input (not shown). The human interface device may be used to capture certain media that are not necessarily directly related to conscious human input, such as voice (speech, music, ambient sounds, etc.), images (scanned images, photographic images acquired from still image cameras, etc.), and video (2D video, 3D video including stereoscopic video, etc.).

[0150] The input human interface device may include one or more (just one of each) of the following: keyboard (1701), mouse (1702), trackpad (1703), touch screen (1710), data glove (not shown), joystick (1705), microphone (1706), scanner (1707), and camera (1708).

[0151] The computer system (1700) may also include certain human interface output devices. Such human interface output devices may stimulate the senses of one or more human users, for example, by tactile output, sound, light, and smell / taste. Such human interface output devices may include tactile output devices (e.g., which may include tactile feedback via a touch screen (1710), data glove (not shown), or joystick (1705), but which may also be tactile feedback devices that do not function as input devices), audio output devices (e.g., speakers (1709), headphones (not shown)), visual output devices (screens (1710), including CRT screens, LCD screens, plasma screens, OLED screens, etc., each with or without touch screen input functionality, each with or without tactile feedback functionality, some of which may be capable of two-dimensional visual output or three-dimensional or more output via means such as stereographic output, virtual reality glass (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0152] The computer system (1700) may also include human-accessible storage devices and related media, such as optical media including CD / DVD ROM / RW (1720) with media such as CD / DVD (1721), thumb drives (1722), removable hard drives and solid-state drives (1723), legacy magnetic media such as tapes and floppy disks (not shown), and dedicated ROM / ASIC / PLD-based devices such as security dongles (not shown).

[0153] Those skilled in the art will also understand that the term “computer-readable medium” as used in relation to the subject matter now disclosed does not include a transmission medium, carrier wave, or other transient signal.

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

[0155] The aforementioned human interface device, human-accessible storage device, and network interface can be attached to the core (1740) of the computer system (1700).

[0156] The core (1740) may include one or more central processing units (CPUs) (1741), graphics processing units (GPUs) (1742), dedicated programmable processing units in the form of field-programmable gate areas (FPGAs) (1743), hardware accelerators for specific tasks (1744), graphics adapters (1750), and the like. These devices may be connected via a system bus (1748) along with read-only memory (ROM) (1745), random access memory (1746), and internal mass storage (1747) such as internal hard drives and SSDs that are not accessible to the user. In some computer systems, the system bus (1748) may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices may be connected directly to the core's system bus (1748) or via a peripheral bus (1749). For example, a screen (1710) may be connected to a graphics adapter (1750). Peripheral bus architectures include PCI, USB, and others.

[0157] The CPU (1741), GPU (1742), FPGA (1743), and accelerator (1744) can execute specific instructions that, in combination, can form the computer code described above. This computer code can be stored in ROM (1745) or RAM (1746). Transition data can also be stored in RAM (1746), but persistent data can be stored, for example, in internal mass storage (1747). The use of cache memory, which can be closely associated with one or more CPUs (1741), GPUs (1742), mass storage (1747), ROMs (1745), RAM (1746), etc., can enable high-speed storage and retrieval to any of the memory devices.

[0158] Computer-readable media may contain computer code for performing various computer implementation operations. The media and computer code may be specifically designed and constructed for the purposes of this disclosure, or they may be of a type that is well known and available to persons skilled in computer software technology.

[0159] For example, but not limited to, a computer system having architecture (1700), particularly core (1740), can provide functionality as a result of a processor (including CPUs, GPUs, FPGAs, accelerators, etc.) that runs software embodied in one or more tangible computer-readable media. Such computer-readable media may be user-accessible mass storage as described above, as well as media related to specific storage of core (1740) of a non-transient nature, such as core internal mass storage (1747) or ROM (1745). Software implementing various embodiments of this disclosure can be stored in such devices and executed by core (1740). The computer-readable media may include one or more memory devices or chips, depending on the specific needs. Software can cause a core (1740), in particular a processor within the core (1740) (including CPUs, GPUs, FPGAs, etc.), to execute a particular process or a particular part of a particular process, which includes determining data structures to be stored in RAM (1746) as described herein, and modifying such data structures according to a process defined by the software. In addition, or alternatively, a computer system may provide functionality as a result of logic wired to or otherwise embodied in circuits (e.g., accelerators (1744)) that can operate in place of or in conjunction with software to execute a particular process or a particular part of a particular process as described herein. References to software may, where appropriate, encompass logic, and vice versa. References to computer-readable media may, as necessary, encompass circuits that store software for execution (such as integrated circuits (ICs)), circuits that embody logic for execution, or both. This disclosure encompasses any appropriate combination of hardware and software. Note A: Acronym JEM: Collaborative Search Model VVC: Versatile Video Coding BMS: Benchmark Set MV: Motion Vector HEVC: High-Efficiency Video Coding SEI:Supplementary Enhancement Information VUI: Video Usability Information GOPs: Picture Group TUs: Conversion Unit PUs: Prediction Units CTUs: Coding Tree Units CTBs: Coding Tree Blocks PBs: Prediction Blocks HRD: Virtual Reference Decoder SNR: Signal-to-noise ratio CPUs: Central Processing Units GPUs: Graphics Processing Units CRT: Cathode Ray Tube LCD: Liquid crystal display OLED: Organic Light-Emitting Diode CD: Compact Disc DVD: Digital Video Disc ROM: Read-only memory RAM: Random Access Memory ASIC: Application-Specific Integrated Circuit PLD: Programmable Logic Device LAN: Local Area Network GSM: Global Mobile Communications System LTE: Long-Term Evolution CANBus: Controller Area Network Bus USB: Universal Serial Bus PCI: Peripheral component interconnection FPGA: Field-Programmable Gate Area SSD: Solid State Drive IC: Integrated Circuit CU: Coding Unit

[0160] While this disclosure has described several exemplary embodiments, there are many modifications, substitutions, and alternative equivalents within the scope of this disclosure. Therefore, those skilled in the art will understand that numerous systems and methods, not expressly illustrated or described herein, can be devised to embody the principles of this disclosure and thus fall within the spirit and scope of this disclosure. [Explanation of symbols]

[0161] 101 samples 102 Arrow 103 Arrow 104 blocks 110 Schematic Diagram 201 Current Block 202 samples 203 samples 204 samples 205 samples 206 samples 300 Communication Systems 310 Terminal devices 320 terminal devices 330 terminal devices 340 terminal devices 350 Networks 400 Communication Systems 401 Video Source 402 Video Picture 403 Video Encoder 404 encoded video data 405 Streaming Server 406 Client Subsystem 407 Input Copy 408 Client Subsystem 409 copies 410 Video Decoder 411 Output Stream 412 displays 413 Capture Subsystem 420 Electronic Devices 430 Electronic Devices 501 Channel 510 Video Decoder 512 Rendering Devices 515 buffer memory 520 Parser 521 Symbols 530 Electronic Devices 531 Receiver 551 Scaler / Inverse Unit 552 Intrapicture Prediction Units 553 Motion Compensation Prediction Unit 555 Aggregator 556 Loop Filter Unit 557 Reference Picture Memory 558 Current Picture Buffer 601 Video Sources 603 Video Encoder 620 Electronic Devices 630 Source Coder 632 Coding Engine 633 Decoder 634 Reference Picture Memory 635 Predictor 640 Transmitter 643 coded video sequence 645 Entropy Coder 650 Controller 660 communication channels 703 Video Encoder 721 General-purpose controller 722 Intra Encoders 723 Residual Calculator 724 Residual Encoder 725 Entropy Encoder 726 Switch 728 Residual Decoder 730 Interencoder 810 Video Decoder 871 Entropy Decoder 872 Intra Decoder 873 Residual Decoder 874 Reconfiguration Module 880 Interdecoder 901 Current Block 902 blocks 903 Block 904 blocks 905 blocks 906 blocks 1102 Dotted line 1104 Colocated CU 1106 Reference Picture 1108 Current Picture 1110 Colocated reference picture 1112 Colocated picture, colocated reference picture 1114 Current CU 1402 CU 1500 processes 1600 processes 1700 Computer Systems 1701 Keyboard 1702 Mouse 1703 Trackpad 1705 Joystick 1706 Microphone 1707 Scanner 1708 Camera 1709 Speaker 1710 Touchscreen 1720 CD / DVD ROM / RW 1721 CD / DVD and other media 1722 Sam Drive 1723 Removable hard drives, solid-state drives 1740 cores 1741 CPU 1742 GPU 1743 FGPA 1744 Accelerator 1745 ROM 1746 RAM 1747 Large-capacity storage 1748 System Bus 1749 Local buses 1750 Graphics Adapter 1754 Interface 1755 Communication Network

Claims

1. A video encoding method performed by a video encoder, A step of dividing the current block in the current picture of a video into at least a first partition and a second partition based on geometric partitioning mode (GPM), wherein the first partition is associated with intrablock copy (IBC) prediction mode and the second partition is associated with intraprediction mode, A step of storing prediction mode information for a first subblock among a plurality of subblocks of the current block, wherein the prediction mode information includes one of DC mode, Planar mode, and intra-prediction mode, based on whether the first subblock is associated with the IBC prediction mode, the intra-prediction mode, and one of both the IBC prediction mode and the intra-prediction mode. A step of encoding the current block and generating encoded information for the current block, wherein the encoded information indicates that the current block is divided into a first partition and a second partition based on the GPM, and the encoded current block and the generated encoded information are included in the video bitstream to be encoded. Methods that include...

2. The step of performing the derivation of the most likely mode (MPM) of an adjacent block of the current block using the stored prediction mode information. The method according to claim 1, further comprising:

3. If the first subblock is associated with the IBC prediction mode, the step of storing the prediction mode information includes storing only the Planar mode in the prediction mode information of the first subblock among the plurality of subblocks of the current block. The method according to claim 1.

4. If the first subblock is associated with the intra-prediction mode, the step of storing the prediction mode information includes storing only the intra-prediction mode in the prediction mode information of the first subblock among the plurality of subblocks of the current block. The method according to claim 1.

5. If the first subblock is associated with both the IBC prediction mode and the intra prediction mode, the step of storing the prediction mode information includes storing only the intra prediction mode in the prediction mode information of the first subblock among the plurality of subblocks of the current block. The method according to claim 1.

6. If the first partition of the current block is associated with the IBC prediction mode and the second partition of the current block is associated with the intra prediction mode, the step of storing the DC mode for each of the plurality of subblocks of the current block. The method according to claim 1, further comprising:

7. If the first partition of the current block is associated with the IBC prediction mode and the second partition of the current block is associated with the intra prediction mode, the step of storing the Planar mode for each of the plurality of subblocks of the current block. The method according to claim 1, further comprising:

8. If the first partition of the current block is associated with the IBC prediction mode and the second partition of the current block is associated with the intra prediction mode, the step of storing the intra prediction mode for each of the plurality of subblocks of the current block. The method according to claim 1, further comprising:

9. The method according to claim 2, wherein the prediction mode information of the first subblock among the plurality of subblocks of the current block is a propagating intramode for the MPM derivation of the adjacent block of the current block, and the adjacent block is predicted by the IBC prediction mode.

10. An apparatus comprising a processing circuit configured to perform the method described in any one of Claims 1 to 9.

11. A computer program for causing at least one processor to perform the method described in any one of claims 1 to 9.

12. A video encoding method performed by a video encoder, A step of generating a video bitstream, A step of dividing the current block in the current picture of a video into at least a first partition and a second partition based on geometric partitioning mode (GPM), wherein the first partition is associated with intrablock copy (IBC) prediction mode and the second partition is associated with intraprediction mode, A step of storing prediction mode information for a first subblock among a plurality of subblocks of the current block, wherein the prediction mode information includes one of DC mode, Planar mode, and intra-prediction mode, based on whether the first subblock is associated with the IBC prediction mode, the intra-prediction mode, and one of both the IBC prediction mode and the intra-prediction mode. A step of encoding the current block and generating encoded information for the current block, wherein the encoded information indicates that the current block is divided into a first partition and a second partition based on the GPM, and includes the encoded current block and the generated encoded information in the video bitstream to be encoded. The steps include generating a video bitstream, A step of storing the encoded video bitstream, including, method.

Images