Method, apparatus and program for video coding

Abstract

An apparatus and method including a processing circuit for video decoding is provided. The method includes decoding, from a coded bitstream, a first syntax element signaled at a first coding level. The first syntax element indicates a maximum number of merge motion vector prediction (MVP) candidates. The first coding level is higher than a picture parameter set (PPS) level. The method also determines the maximum number of merge MVP candidates based on the first syntax element, and reconstructs coding blocks associated with the first coding level based at least on the maximum number of merge MVP candidates. The first coding level is a sequence level, and the first syntax element is signaled in a sequence parameter set (PPS).

Description

[Technical Field]

[0001] Incorporation by Reference This application claims the benefit of priority to U.S. Patent Application No. 17 / 088,073, entitled "METHOD AND APPARATUS FOR VIDEO CODING," filed November 3, 2020, which claims the benefit of priority to U.S. Provisional Application No. 62 / 960,930, entitled "SIGNALING OF MAXIMUM NUMBER OF MERGE CANDIDATES FOR INTER PREDICTION," filed January 14, 2020. The entire disclosure of the prior application is incorporated herein by reference in its entirety.

[0002] Technical Field This disclosure generally describes embodiments related to video coding. [Background technology]

[0003] The background discussion provided herein is intended to generally present the context for the present disclosure. The work of the presently named inventors is not expressly or implicitly admitted as prior art to the present disclosure to the extent that that work is described in this background section, or in aspects of the description that may not otherwise qualify as prior art at the time of filing.

[0004] Video coding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can include a series of images, each having spatial dimensions of, for example, 1920x1080 luma samples and associated color samples. The series of images can have a fixed or variable image rate (e.g., 60 images / second or 60 Hz). Uncompressed video requires large bit rates. For example, 1080p60 4:2:0 video (1920x1080 luma sample resolution at a 60 Hz frame rate) with 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 Gbytes of storage space.

[0005] One goal of video coding and decoding is to reduce redundancy in an input video signal through compression. Compression can sometimes reduce bandwidth or storage space requirements by more than two orders of magnitude. Both lossless and lossy compression, as well as combinations of them, can be used. Lossless compression refers to techniques that allow an exact copy of the original signal to be reconstructed from a compressed version of the original signal. When lossy compression is used, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signal is small enough to make the reconstructed signal useful for its intended use. For video, lossy compression is widely used. The amount of acceptable distortion depends on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio can reflect a higher acceptable / acceptable distortion, which can result in a higher compression ratio.

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

[0007] In some video compression techniques, the MV applicable to an area of ​​sample data can be predicted from other MVs, for example, from an MV associated with another area of ​​sample data that is spatially adjacent to the area being reconstructed and precedes that MV in decoding order. In this way, the amount of data required for coding the MV can be significantly reduced, thereby eliminating redundancy and increasing compression. MV prediction can work efficiently because, for example, when coding an input video signal derived from a camera (known as natural video), areas larger than the area to which a single MV is applicable have a statistical likelihood of moving in a similar direction and can therefore, in some cases, be predicted using similar motion vectors derived from MVs in neighboring areas. As a result, the MV found for a given area will be similar or identical to the MV predicted from surrounding MVs, which, after entropy coding, can be represented with fewer bits than would be used if the MVs were coded directly. In some cases, MV prediction can be an example of lossless compression of a signal (i.e., an MV) derived from the original signal (i.e., a sample stream). In other cases, the MV prediction itself may be lossy, for example due to rounding errors in computing the predictor from some surrounding MVs.

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

[0009] Referring to Figure 1, a current block (101) contains samples that the encoder found during the motion search process to be predictable from a spatially shifted previous block of the same size. Instead of coding its MV directly, it can derive the MV from metadata associated with one or more reference pictures, e.g., from the most recent reference picture (in decoding order) using the MV associated with any of five surrounding samples denoted A0, A1, and B0, B1, B2 (102 to 106, respectively). In H.265, MV prediction can use predictors from the same reference picture as neighboring blocks. Summary of the Invention

[0010] Aspects of the present disclosure provide methods and apparatus for video encoding / decoding. In some embodiments, the apparatus for video decoding includes a processing circuit. The processing circuit can decode a first syntax element signaled at a first coding level from a coded bitstream. The first syntax element can indicate a maximum number of merge motion vector prediction (MVP) candidates. The first coding level can be higher than a picture parameter set (PPS) level. The processing circuit can determine the maximum number of merge MVP candidates based on the first syntax element. The processing circuit can reconstruct coding blocks associated with the first coding level based at least on the maximum number of merge MVP candidates.

[0011] In an embodiment, a processing circuit can decode from a coded video bitstream a fourth syntax element, a third syntax element, and a second syntax element signaled at a first coding level. The second syntax element can indicate a maximum number of geometric merge mode merge candidates, the third syntax element can indicate a maximum number of sub-block-based merge MVP candidates, and the fourth syntax element can indicate a maximum number of intra block copy (IBC) merge block vector prediction (BVP) candidates. The processing circuit can determine (i) the maximum number of geometric merge mode merge candidates based on the second syntax element, (ii) the maximum number of the sub-block-based merge MVP candidates based on the third syntax element, and (iii) the maximum number of the IBC merge BVP candidates based on the fourth syntax element.

[0012] In one embodiment, the first coding level is a sequence level and the first syntax element is signaled in a sequence parameter set (SPS).

[0013] In one embodiment, a processing circuit can decode from the coded video bitstream a second syntax element signaled at a second coding level based on a condition being met. The second syntax element can indicate a maximum number of merge candidates for one of a geometric merge mode, a sub-block-based mode, and an intra-block copy (IBC) merge mode. In an embodiment, the one of the geometric merge mode, the sub-block-based merge mode, and the IBC merge mode is a geometric merge mode. The maximum number of merge candidates is a maximum number of geometric merge mode merge candidates. The second syntax element indicates a maximum number of geometric merge mode merge candidates. The conditions are a geometric merge mode available at the second coding level and a maximum number of merge MVP candidates being three or greater. The processing circuit can determine the maximum number of geometric merge mode merge candidates based on the second syntax element.

[0014] In an embodiment, one of the geometric merge mode, the sub-block-based merge mode, and the IBC merge mode is a sub-block-based merge mode. The maximum number of merge candidates is a maximum number of sub-block-based merge MVP candidates. The second syntax element indicates a maximum number of sub-block-based merge MVP candidates. The condition is an affine mode that is enabled in the second coding level. The processing circuit can determine the maximum number of sub-block-based merge MVP candidates based on the second syntax element. In an embodiment, the second syntax element is changed at a coding level lower than the second coding level. In an embodiment, the first coding level and the second coding level are a sequence level, and the coding level lower than the second coding level is a picture level.

[0015] In an embodiment, one of the geometric merge mode, the sub-block-based merge mode, and the IBC merge mode is the IBC merge mode. The maximum number of merge candidates is the maximum number of IBC merge block vector prediction (BVP) candidates. The second syntax element indicates the maximum number of IBC merge BVP candidates. The condition is the IBC merge mode that is enabled at the second coding level. The processing circuit can determine the maximum number of IBC merge BVP candidates based on the second syntax element.

[0016] In an embodiment, the first coding level and the second coding level are sequence levels.

[0017] Aspects of the present disclosure also provide a non-transitory computer-readable medium storage storing instructions that, when executed by a computer for video decoding, cause the computer to perform a method for video coding. [Brief explanation of the drawings]

[0018] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings. [Figure 1] FIG. 1 is a diagram illustrating a current block and its surrounding spatial merge candidates in one embodiment. [Figure 2] FIG. 2 is a schematic diagram illustrating a simplified block diagram of a communication system (200) according to one embodiment. [Figure 3] FIG. 3 is a schematic diagram illustrating a simplified block diagram of a communication system (300) according to one embodiment. [Figure 4] FIG. 4 is a schematic diagram illustrating a simplified block diagram of a decoder according to one embodiment. [Figure 5] FIG. 5 is a schematic diagram illustrating a simplified block diagram of an encoder according to one embodiment. [Figure 6] FIG. 6 is a block diagram of an encoder according to another embodiment. [Figure 7] FIG. 7 is a block diagram of a decoder according to another embodiment. [Figure 8] FIG. 8 illustrates an exemplary geometric merge mode. [Figure 9] FIG. 9 shows an example syntax signaled in a picture parameter set (PPS). [Figure 10] FIG. 10 shows an example syntax signaled in the picture header. [Figure 11] FIG. 11 shows an example syntax signaled in a sequence parameter set (SPS). [Figure 12] FIG. 12 shows an example syntax signaled in the PPS. [Figure 13] FIG. 13 shows an example syntax signaled in the picture header. [Figure 14] FIG. 14 shows an example syntax signaled in the picture header. [Figure 15]FIG. 15 shows an example syntax within a picture header. [Figure 16] FIG. 16 shows an example syntax in SPS. [Figure 17] FIG. 17 shows an example syntax in SPS. [Figure 18A] FIG. 18A shows an example syntax in an SPS. [Figure 18B] FIG. 18B shows an exemplary syntax for a picture header. [Figure 19A] FIG. 19A shows an example syntax in an SPS. [Figure 19B] FIG. 19B shows an example syntax for a picture header. [Figure 20] FIG. 20 shows an example syntax of an SPS. [Figure 21] FIG. 21 shows a flow chart outlining a process (2100) according to one embodiment of the present disclosure. [Figure 22] FIG. 22 is a schematic diagram of a computer system according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0019] FIG. 2 illustrates a simplified block diagram of a communication system (200) according to one embodiment of the present disclosure. The communication system (200) includes multiple terminal devices that can communicate with each other, for example, via a network (250). For example, the communication system (200) includes a pair of terminal devices (210) and (220) interconnected via the network (250). In the example of FIG. 2, the pair of terminal devices (210) and (220) perform unidirectional data transmission. For example, the terminal device (210) can code video data (e.g., a stream of video images captured by the terminal device (210)) for transmission to another terminal device (220) via the network (250). The encoded image data can be transmitted in the form of one or more coded video bitstreams. The terminal device (220) can receive the coded video data from the network (250), decode the coded video data to reconstruct the video images, and display the video images according to the reconstructed video data. Unidirectional data transmission may be common in media serving applications and the like.

[0020] In another example, the communication system 200 includes a second pair of terminal devices 230 and 240 for bidirectional transmission of coded video data, such as may occur during a video conference. For bidirectional data transmission, for example, each of the terminal devices 230 and 240 can code video data (e.g., a stream of video images captured by the terminal device) for transmission to the other of the terminal devices 230 and 240 over the network 250. Each of the terminal devices 230 and 240 can receive coded video data transmitted by the other of the terminal devices 230 and 240, decode the coded video data to reconstruct the video images, and display the video images on an accessible display device in accordance with the reconstructed video data.

[0021] In the example of Figure 2, terminal devices 210, 220, 230, and 240 may be depicted as servers, personal computers, and smartphones, although the principles of the present invention are not limited thereto. Embodiments of the present invention find application in laptop computers, tablet computers, media players, and / or dedicated videoconferencing equipment. Network 250 represents any number of networks that convey coded video data between terminal devices 210, 220, 230, and 240, including, for example, wireline and / or wireless communication networks. Communications network 250 may exchange data within circuit-switched and / or packet-switched channels. Representative networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of this description, the architecture and topology of network 250 is not important to the operation of the present invention, unless otherwise described below.

[0022] 3 illustrates the placement of a video encoder and a video decoder in a streaming environment as an example application of the disclosed subject matter, which is equally applicable to other video-enabled applications including, for example, video conferencing, digital TV, and storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

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

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

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

[0026] The receiver (431) can receive one or more coded video sequences to be decoded by the video decoder (410), and in the same or another embodiment, can receive one coded video sequence at a time, where the decoding of each coded video sequence is independent of the other coded video sequences. The coded video sequences can be received from a channel (401), which can be a hardware / software link to a storage device that stores the encoded video data. The receiver (431) can receive the encoded video data along with other data, such as coded audio data and / or ancillary data streams, which can be transferred using respective entities (not shown). The receiver (431) can separate the coded video sequence from other data. To combat network jitter, a buffer memory (415) can be coupled between the receiver (431) and the entropy decoder / parser (420) (hereinafter "parser (420)"). In certain applications, the buffer memory (415) is part of the video decoder (410). In other cases, it can be external to the video decoder (410) (not shown). In yet other cases, a buffer memory (not shown) can exist outside the video decoder (410), for example, to combat network jitter, and another buffer memory (415) can exist inside the video decoder (410), for example, to handle playback timing. If the receiver (431) is receiving data from a store-and-forward device of sufficient bandwidth and controllability or from an isochronous network, the buffer memory (415) may be unnecessary or small. For use with best-effort packet networks such as the Internet, the buffer memory (415) may be required and may be relatively large, advantageously adaptively sized, and at least partially implemented in an operating system or similar element (not shown) outside the video decoder (410).

[0027] The video decoder (410) may include a parser (420) for reconstructing symbols (421) from the coded video sequence. These symbol categories include information used to manage the operation of the video decoder (410) and potential information for controlling a rendering device, such as a rendering device (412) (e.g., a display screen) that is not an integral part of the electronic device (430) but may be coupled to the electronic device (430), as shown in FIG. 4. The control information for the rendering device(s) may be in the form of a supplemental enhancement information (SEI) message or a video usability information (VUI) parameter set fragment (not shown). The parser (420) may parse / entropy decode the received coded video sequence. The coding of the coded video sequence may follow a video coding technique or standard and may follow various principles, including variable length coding, Huffman coding, arithmetic coding with or without context sensitivity, etc. The parser (420) may extract from the coded video sequence a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder based on at least one parameter corresponding to the group. The subgroups may include groups of pictures (GOPs), images, tiles, slices, macroblocks, coding units (CUs), blocks, transform units (TUs), prediction units (PUs), etc. The parser (420) may also extract information from the coded video sequence, such as transform coefficients, quantization parameter values, motion vectors, etc.

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

[0029] The reconstruction of the symbols (421) can include multiple different units, depending on the type of video image or portion thereof being coded (e.g., inter- and intra-image, inter- and intra-block) and other factors. Which units are included and how can be controlled by subgroup control information parsed from the coded video sequence by the parser (420). The flow of such subgroup control information between the parser (420) and the following units is not shown for clarity.

[0030] In addition to the functional blocks already mentioned, the video decoder (410) can be conceptually divided into several functional units, as described below. In a practical implementation operating under commercial constraints, many of these units will interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, a conceptual subdivision into the following functional units is appropriate:

[0031] The first unit is a scalar / inverse transform unit (451). The scaler / inverse transform unit (451) receives quantized transform coefficients as well as control information from the parser (420) as symbol(s), including the transform to be used, block size, quantization coefficients, quantization scaling matrix, etc. The scaler / inverse transform unit (451) can output blocks containing sample values ​​that can be input to the aggregator (455).

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

[0033] In other cases, the output samples of the scalar / inverse transform unit (451) may be related to inter-coding and potentially to a motion compensation block. In such cases, the motion compensated prediction unit 453 may access a reference picture memory 457 to fetch samples used for prediction. After motion compensating the fetched samples according to the block-related symbols (421), these samples may be added by an aggregator (455) to the output of the scalar / inverse transform unit (451) (referred to as residual samples or residual signals in this case) to generate output sample information. The addresses in the reference picture memory (457) from which the motion compensated prediction unit (453) fetches prediction samples may be controlled by a motion vector and available to the motion compensated prediction unit (453) in the form of symbols (421), which may have, for example, X, Y, and reference picture components. Motion compensation may also include interpolating sample values ​​to be fetched from the reference picture memory (457) when sub-sample accurate motion vectors are used, motion vector prediction mechanisms, etc.

[0034] The output samples of the aggregator (455) can be subjected to various loop filtering techniques in the loop filter unit (456). Video compression techniques can include in-loop filter techniques that are controlled by parameters contained in the coded video sequence (also referred to as the coded video bitstream) and made available to the loop filter unit (456) as symbols (421) from the parser (420), but can also be responsive to meta-information obtained during decoding of previous portions (in decoding order) of the coded image or coded video sequence, as well as to previously reconstructed, loop-filtered sample values.

[0035] The output of the loop filter unit (456) can be a sample stream that can be output to a rendering device (412) or stored in a reference image memory (457) for use in intra-prediction of future images.

[0036] Once a coded picture is fully reconstructed, it can be used as a reference picture for future prediction. For example, once a coded picture corresponding to a current picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (420)), the current picture buffer (458) can become part of the reference picture memory (457), and a new current picture buffer can be reallocated before starting the reconstruction of a subsequent coded picture.

[0037] The video decoder (410) may perform decoding operations according to a predetermined video compression technique, such as ITU-T Rec. H.265. A coded video sequence may conform to the syntax specified by the video compression technique or standard being used, in the sense that the coded video sequence conforms to both the syntax of the video compression technique or standard and the profile documented in the video compression technique or standard. Specifically, a profile may select certain tools from all tools available in the video compression technique or standard as the only tools that can be used under that profile. Compliance may also require that the complexity of the coded video sequence be within a range defined by a level of the video compression technique 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 limits set by the level may, in some cases, be further constrained by a hypothetical reference decoder (HRD) specification and HRD buffer management metadata signaled in the coded video sequence.

[0038] In one embodiment, the receiver (431) can receive additional (redundant) data along with the encoded video. The additional data may be included as part of the coded video sequence(s). The additional data may be used by the video decoder (410) to properly decode the data and / or to more accurately reconstruct the original video data. The additional data may be in the form of, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

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

[0040] The video encoder (503) may receive video samples from a video source (501) (not part of the electronic device (520) in the example of FIG. 5) that can capture the video footage(s) to be coded by the video encoder (503). In another example, the video source (501) is part of the electronic device (520).

[0041] The video source (501) may provide a source video sequence to be coded by the video encoder (503) in the form of a digital video sample stream, which may 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 distribution system, the video source (501) may be a storage device that stores prepared video. In a video conferencing system, the video source (501) may be a camera that captures local video information as a video sequence. The video data may be provided as multiple individual images that, when viewed in sequence, create motion. The images themselves may be organized as a spatial array of pixels, each of which 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 discussion focuses on samples.

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

[0043] In some embodiments, the video encoder (503) is configured to operate in a coding loop. As an oversimplified explanation, in one example, the coding loop can include a source coder (530) (e.g., responsible for generating symbols, such as a symbol stream, based on an input image to be coded and a reference image) and a (local) decoder (533) embedded in the video encoder (503). The decoder (533) reconstructs the symbols to create sample data in a manner similar to that of the (remote) decoder (so that any compression between the symbols and the coded video bitstream is lossless in the video compression techniques contemplated in the disclosed subject matter). The reconstructed sample stream (sample data) is input to a reference image memory (534). Because decoding of the symbol stream produces bit-exact results independent of the decoder location (local or remote), the contents in the reference image memory (534) are also bit-exact between the local and remote encoders. In other words, the prediction part of the encoder "sees" the exact same sample values ​​as the reference picture samples that the decoder "sees" when using the prediction during decoding. This basic principle of reference picture synchrony (and the resulting drift when synchrony cannot be maintained, e.g., due to channel errors) is used in several related technologies as well.

[0044] The operation of the "local" decoder (533) can be the same as a "remote" decoder, such as the video decoder (410), as already described in detail above in connection with Figure 4. However, briefly referring also to Figure 4, because symbols are available and the coding / decoding of symbols into a coded video sequence by the entropy coder (545) and parser (420) can be lossless, the entropy decoding portion of the video decoder (410), including the buffer memory (415), and the parser (420), may not be fully implemented in the local decoder (533).

[0045] An observation that can be made in this regard is that any decoder technology, except for parsing / entropy decoding, that exists in a decoder must also exist in substantially identical functional form in the corresponding encoder. For this reason, the disclosed subject matter focuses on decoder operation. The description of the encoder technology can be abbreviated, as they are the opposite of the decoder technology, which is described generically. Only in certain areas will more detailed descriptions be required and provided below.

[0046] During operation, in some examples, the source coder (530) may perform motion-compensated predictive coding, which predictively codes an input image with reference to one or more previously coded images from a video sequence designated as “reference images.” In this manner, the coding engine (532) codes differences between pixel blocks of the input image and pixel blocks of reference image(s) that may be selected as predictive reference(s) for the input image.

[0047] The local video decoder (533) may decode the coded video data of an image that may be designated as a reference image based on the symbols generated by the source coder (530). The operation of the coding engine (532) may advantageously be a lossy process. If the coded video data can be decoded by a video decoder (not shown in FIG. 5), the reconstructed video sequence may typically be a replica of the source video sequence, possibly with some errors. The local video decoder (533) repeats the decoding process performed by the video decoder on the reference image, which may result in a reconstructed reference image to be stored in the reference image cache (534). In this way, the video encoder (503) may locally store a copy of the reconstructed reference image that has common content with the reconstructed reference image that would be obtained by the far-end video decoder.

[0048] The predictor (535) may perform a prediction search for the coding engine (532). That is, for a new image to be coded, the predictor (535) may search the reference image memory (534) for specific metadata, such as reference image motion vectors, block shapes, or sample data (as candidate reference pixel blocks), that may serve as suitable prediction references for the new image. The predictor (535) may operate on a sample block-by-sample block basis to find suitable prediction references. In some cases, as determined by the search results obtained by the predictor (535), the input image may have prediction references drawn from multiple reference images stored in the reference image memory (534).

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

[0050] The outputs of all of the above-mentioned functional units may undergo entropy coding in an entropy coder (545), which converts the symbols produced by the various functional units into a coded video sequence by losslessly compressing the symbols according to techniques such as Huffman coding, variable length coding, or arithmetic coding.

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

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

[0053] Intra-pictures (I-pictures) can be coded and decoded without using other pictures in the sequence as prediction sources. Some video codecs allow for different types of intra-pictures, including, for example, Independent Decoder Refresh ("IDR") pictures. Those skilled in the art are aware of these variations of I-pictures and their respective uses and characteristics.

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

[0055] Bi-directionally predicted images (B-pictures) may be coded and decoded using inter- or intra-prediction, which uses up to two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multiple predicted images may use two or more reference images and associated metadata for the reconstruction of a block.

[0056] A source image is typically spatially divided into multiple sample blocks (e.g., 4x4, 8x8, 4x8, or 16x16 blocks of samples each) and coded block by block. Blocks may be predictively coded with reference to other (already coded) blocks, as determined by the coding assignment applied to each image of the block. For example, blocks of an I-image may be non-predictively coded, or they may be predictively coded with reference to previously coded blocks of the same image (spatial prediction or inter-prediction). Pixel blocks of a P-image may be predictively coded via spatial or temporal prediction with reference to one previously coded reference image. Blocks of a B-image may be predictively coded via spatial or temporal prediction with reference to one or two previously coded reference images.

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

[0058] In one embodiment, the transmitter (540) can transmit additional data along with the encoded video. The source coder (530) can include such data as part of the coded video sequence. The additional data can include temporal, spatial, and SNR enhancement layers, as well as other types of redundant data, such as redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

[0059] Video may be captured as multiple source images (video images) in a time sequence. Intra-picture prediction (often abbreviated as intra-prediction) uses spatial correlation within a given image, while inter-picture prediction or inter-picture prediction uses correlation (temporal or otherwise) between images. In one example, a particular image being coded / decoded, referred to as the current image, is partitioned into blocks. If a block in the current image is similar to a reference block in a previously coded and still buffered reference image in the video, the block in the current image may be coded by a vector referred to as a motion vector. The motion vector points to a reference block in the reference image and may have a third dimension that identifies the reference image if multiple reference images are used.

[0060] In some embodiments, a bi-prediction technique may be used in inter-picture prediction. Bi-prediction techniques use two reference pictures, such as a first reference picture and a second reference picture, both of which precede a current picture in decoding order (but may be past and future, respectively, in display order) in a video. A block in the current picture may be coded with 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. A block may be predicted by a combination of the first and second reference blocks.

[0061] Furthermore, merge mode techniques can be used for inter-image prediction to improve coding efficiency.

[0062] According to some embodiments of the present disclosure, prediction, such as inter-image prediction and intra-image prediction, is performed in units of blocks. For example, according to the HEVC standard, images in a video image sequence are partitioned into coding tree units (CTUs) for compression, and the CTUs in an image have the same size, such as 64×64 pixels, 32×32 pixels, or 16×16 pixels. Generally, a CTU includes three coding tree blocks (CTBs), one luma CTB and two chroma CTBs. Each CTU can be recursively quadtree partitioned into one or more coding units (CUs). For example, a 64×64 pixel CTU can be partitioned into one CU of 64×64 pixels, four CUs of 32×32 pixels, or 16 CUs of 16×16 pixels. In an example, each CU is analyzed to determine the prediction type of the CU, such as an inter prediction type or an intra prediction type. A CU is divided into one or more prediction units (PUs) depending on temporal and / or spatial predictability. Generally, each PU includes a luma prediction block (PB) and two chroma PBs. In one embodiment, prediction operations in coding (encoding / decoding) are 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 values ​​(e.g., luma values) for pixels, such as 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc.

[0063] 6 shows a diagram of a video encoder (603) according to another embodiment of the present disclosure. The video encoder (603) is configured to receive a processed block (e.g., a predictive block) of sample values ​​in a current video image in a video image sequence and encode the processed block into a coded image that is part of the coded video sequence. In one embodiment, the video encoder (603) is used in place of the example video encoder (303) of FIG. 3.

[0064] In an HEVC example, the video encoder (603) receives a matrix of sample values ​​for a processing block, such as an 8x8 sample prediction block. The video encoder (603) determines whether the processing block is best coded using intra-mode, inter-mode, or bi-prediction mode, e.g., using rate-distortion optimization. If the processing block is to be coded in intra-mode, the video encoder (603) can encode the processing block into a coded image using intra-prediction techniques; if the processing block is to be coded in inter-mode or bi-prediction mode, the video encoder (603) can encode the processing block into a coded image using inter-prediction or bi-prediction techniques, respectively. In certain video coding techniques, there may be a motion vector component applicable to the subject block, which is an inter-image prediction submode, where the motion vector is derived from one or more motion vector predictors without the benefit of coding the motion vector component outside of the predictors. In one embodiment, the video encoder (603) includes other components, such as a mode decision module (not shown), for determining the mode of the processing block.

[0065] In the example of Figure 6, the video encoder (603) includes an entropy encoder (625), an inter-encoder (630), an intra-encoder (622), a residual calculator (623), a switch (626), a residual encoder (624), and a general controller (621), coupled together as shown in Figure 6.

[0066] The inter-encoder (630) is configured to receive samples of a current block (e.g., a processing block), compare the block with one or more reference blocks in a reference image (e.g., blocks in a preceding image and a subsequent image), generate inter-prediction information (e.g., a description of redundant information due to the inter-encoding technique, motion vectors, merge mode information), and calculate an inter-prediction result (e.g., a predicted block) based on the inter-prediction information using any suitable technique. In some embodiments, the reference picture is a decoded reference picture that is decoded based on the coded video information.

[0067] The intra encoder (622) is configured to receive samples of a current block (e.g., a processing block), optionally compare the block with previously coded blocks in the same image, generate transformed and quantized coefficients, and optionally generate intra prediction information (e.g., intra prediction direction information according to one or more intra coding techniques). In one embodiment, the intra encoder (622) also calculates intra prediction results (e.g., predicted blocks) based on the intra prediction information and reference blocks in the same image.

[0068] The general controller (621) is configured to determine general control data and control other components of the video encoder (603) based on the general control data. In one embodiment, the general controller (621) determines the mode of the block and provides a control signal to the switch (626) based on the mode. For example, when the mode is intra mode, the general controller (621) controls the switch (626) to select the intra mode result for the residual calculator (623) and controls the entry peak coder (625) to select the advanced decoding information and include the advanced decoding information in the bitstream; and when the mode is inter mode, the general controller (621) controls the switch (626) to select the inter prediction result for the residual calculator (623) and controls the entry peak coder (625) to select the inter prediction information and include the inter prediction information in the bitstream.

[0069] The residual calculator (623) is configured to calculate the difference (residual data) between the received block and a prediction result selected from the intra-encoder (622) or inter-encoder (630). The residual encoder (624) operates on the residual data and is configured to encode the residual data to generate transform coefficients. In one embodiment, the residual encoder (624) is configured to convert the residual data from the spatial domain to the frequency domain to generate transform coefficients. The transform coefficients are then subjected to a quantization process to obtain quantized transform coefficients. In various embodiments, the video encoder (603) also includes a residual decoder (628). The residual decoder (628) is configured to perform an inverse transform and generate decoded residual data. The decoded residual data can be used by the intra-encoder (622) and inter-encoder (630) as appropriate. For example, the inter-encoder (630) can generate decoded blocks based on the decoded residual data and inter-prediction information, and the intra-encoder (622) can generate decoded blocks based on the decoded residual data and intra-prediction information. The decoded blocks, in some embodiments, are suitably processed to generate decoded images, which can be buffered in a memory circuit (not shown) and used as reference images.

[0070] The entropy encoder (625) is configured to format the bitstream to include the encoded blocks. The entropy encoder (625) is configured to include various information in accordance with an appropriate standard, such as the HEVC standard. In one embodiment, the entropy encoder (625) is configured to include general control data, selected prediction information (e.g., intra-prediction information or inter-prediction information), residual information, and other appropriate information in the bitstream. Note that when coding blocks in a merged sub-mode of either the inter mode or bi-prediction mode in accordance with the disclosed subject matter, no residual information is present.

[0071] 7 shows a diagram of a video decoder (710) according to another embodiment of the present disclosure. The video decoder (710) is configured to receive coded images that are part of a coded video sequence and to decode the coded images to generate reconstructed images. In one embodiment, the video decoder (710) is used in place of the video decoder (310) of the embodiment of FIG. 3.

[0072] In the FIG. 7 embodiment, the video decoder (710) includes an entropy decoder (771), an inter-decoder (780), a residual decoder (773), a reconstruction module (774), and an intra-decoder (772), which are coupled together as shown in FIG. 7.

[0073] The entropy decoder (771) can be configured to reconstruct, from the coded picture, specific symbols representing syntax elements that make up the coded picture. Such symbols can include, for example, the mode in which the block is coded (e.g., intra mode, inter mode, bidirectional prediction mode, inter mode in merged or another submode, bidirectional prediction mode, etc.), prediction information (e.g., intra prediction information or inter prediction information), which can identify specific samples or metadata, such as residual information in the form of quantized transform coefficients, to be used by the intra decoder (722) or inter decoder (780), respectively. In an embodiment, when the prediction mode is inter or bi-predicted mode, the inter prediction information is provided to the inter decoder (780); and when the prediction type is a look-ahead decoding type, the look-ahead decoding information is provided to the intra decoder (772). The residual information can undergo inverse quantization and be provided to the residual decoder (773).

[0074] The inter decoder (780) is configured to receive the inter prediction information and generate an inter prediction result based on the inter prediction information.

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

[0076] The residual decoder (773) is configured to perform inverse quantization to extract dequantized transform coefficients and process the dequantized transform coefficients to convert the residual from the frequency domain to the spatial domain. The residual decoder (773) may require specific control information (to include a Quantizer Parameter (QP)), and that information may be provided by the entropy decoder (771) (a data path not depicted as this may only be low volume control information).

[0077] The reconstruction module (774) combines, in the spatial domain, the residual output by the residual decoder (773) with the prediction result (possibly output by an inter- or intra-prediction module) to form a reconstructed block, which may be part of the reconstructed image and, therefore, part of the reconstructed video. Note that other appropriate operations, such as deblocking, may be performed to improve visual quality.

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

[0079] Aspects of the present disclosure relate to signaling the length(s) of various merge candidate list(s) for each inter-predictive coding tool, such as regular merge mode, sub-block based merge mode, intra block copy (IBC) merge mode, and geometric merge mode (GEO), used in video coding techniques, e.g., VVC over HEVC.

[0080] The geometric merge mode (also referred to as the geometric partition mode) can support multiple different partitioning methods. Figure 8 shows an example geometric merge mode. In the geometric merge mode, the CU (800) can be partitioned into two partitions, and partitions 1 and 2 can be separated by a line or edge (810). Each of the two partitions can have any suitable shape, such as a triangle, a trapezoid, or a pentagon.

[0081] Merge candidates for inter prediction can be effective in video coding such as HEVC and VVC. In one embodiment, for example, in VVC, there are four different merge candidate lists (or merge lists) that can be constructed on the encoder and decoder sides. The four merge candidate lists include a merge candidate list (or first merge candidate) for regular merge mode, a merge candidate list (or second merge candidate) for geometric merge mode, a merge candidate list (or third merge candidate) for sub-block-based merge mode, and a merge candidate list (or fourth merge candidate) for IBC merge mode.

[0082] Compared with related technologies (such as certain technologies in HEVC), the first merge candidate list for the regular merge mode can be expanded to include more types of merge candidates. Furthermore, the maximum number of merge candidates (or merge motion vector prediction (MVP) candidates) in the first merge candidate list can be expanded, for example, from 5 to 6. The maximum number of merge MVP candidates in the first merge candidate list can be signaled in the PPS-level picture parameter set (PPS) or the picture-level picture header.

[0083] Figure 9 shows the first PPS level parameter signaled in the PPS (e.g., pps_six_minus_max_num_merge_cand_plus1). The first PPS level parameter may indicate the maximum number of merge MVP candidates. Figure 10 shows the first picture level parameter signaled in the picture header (e.g., pic_six_minus_max_num_merge_cand). The first picture level parameter may indicate the maximum number of merge MVP candidates (MaxNumMergeCand).

[0084] The first syntax element may indicate the maximum number of merged MVP candidates signaled at the corresponding coding level, e.g., the first syntax element may refer to a first PPS level parameter signaled at the PPS level or a first picture level parameter signaled at the picture level.

[0085] When the first PPS level parameter (e.g., pps_six_minus_max_num_merge_cand_plus1) is equal to 0, it can specify that the first picture level parameter (e.g., pic_six_minus_max_num_merge_cand) is present (or signaled) in the picture header that references the PPS. When the first PPS level parameter (e.g., pps_six_minus_max_num_merge_cand_plus1) is greater than 0, it can specify that the first picture level parameter (e.g., pic_six_minus_max_num_merge_cand) is not present (or not signaled) in the picture header that references the PPS. The value of the first PPS level parameter (e.g., pps_six_minus_max_num_merge_cand_plus1) can range from 0 to 6. If the first PPS level parameter (eg, pps_six_minus_max_num_merge_cand_plus1) is not present, then the first PPS level parameter (eg, pps_six_minus_max_num_merge_cand_plus1) is inferred to be equal to 0.

[0086] A first picture-level parameter (e.g., pic_six_minus_max_num_merge_cand) may specify the maximum number of merge MVP candidates (MaxNumMergeCand) supported in a slice associated with the picture header, subtracted from 6. The maximum number of merge MVP candidates (MaxNumMergeCand) may be determined using equation (1). MaxNumMergeCand = 6 - pic_six_minus_max_num_merge_cand (Equation 1)

[0087] The value of MaxNumMergeCand can be specified in the range of 1 to 6. If the first picture level parameter is not present, the value of the first picture level parameter (e.g., pic_six_minus_max_num_merge_cand) can be inferred to be equal to the first PPS level parameter (e.g., pps_six_minus_max_num_merge_cand_plus1)−1.

[0088] The geometric merge mode can be enabled or disabled at the sequence level using an SPS syntax element in the sequence parameter set (SPS). In the example, the SPS syntax element is the first sequence level flag (e.g., sps_geo_enabled_flag). Figure 11 shows the first sequence level flag (e.g., sps_geo_enabled_flag) signaled in the SPS.

[0089] A first sequence level flag (e.g., sps_geo_enabled_flag) may specify whether motion compensation based on geometric merge mode can be used for inter prediction. A first sequence level flag (e.g., sps_geo_enabled_flag) equal to 0 may specify that the syntax is constrained so that motion compensation based on geometric merge mode is not used in coding layer video sequence (CLVS) and that geometric merge mode-related syntax elements are not present in the coding unit syntax of CLVS. A first sequence level flag (e.g., sps_geo_enabled_flag) equal to 1 may specify that motion compensation based on geometric merge mode can be used in CLVS.

[0090] A parameter indicating the maximum number of geometric merge mode merge candidates (MaxNumGeoMergeCand) can be explicitly signaled at the PPS level or picture level.

[0091] Figure 12 shows an example syntax signaled in a PPS. The syntax includes a second PPS-level parameter (e.g., pps_max_num_merge_cand_minus_max_num_geo_cand_plus1) that indicates the maximum number of geometric merge mode merge candidates. Figure 13 shows an example syntax signaled in a picture header. The syntax includes a second picture-level parameter (e.g., pic_max_num_merge_cand_minus_max_num_geo_cand) that indicates the maximum number of geometric merge mode merge candidates.

[0092] The second syntax element may indicate the maximum number of geometric merge mode merge candidates signaled at the corresponding coding level, e.g., the second syntax element may refer to a second PPS level parameter signaled at the PPS level or a second picture level parameter signaled at the picture level.

[0093] When the second PPS level parameter (e.g., pps_max_num_merge_cand_minus_max_num_geo_cand_plus1) is equal to 0, it can specify that the second picture level parameter (e.g., pic_max_num_merge_cand_minus_max_num_geo_cand) is present or signaled in the picture header of the slice that references the PPS. When the second PPS level parameter (e.g., pps_max_num_merge_cand_minus_max_num_geo_cand_plus1) is greater than 0, it can specify that the second picture level parameter (e.g., pic_max_num_merge_cand_minus_max_num_geo_cand) is not present in the picture header that references the PPS. The value of the second PPS level parameter (e.g., pps_max_num_merge_cand_minus_max_num_geo_cand_plus1) can range from 0 to MaxNumMergeCand-1. If the second PPS level parameter (eg, pps_max_num_merge_cand_minus_max_num_geo_cand_plus1) is not present, the second PPS level parameter may be inferred to be equal to 0.

[0094] A second picture level parameter (eg, pic_max_num_merge_cand_minus_max_num_geo_cand) may specify the maximum number of geometric merge mode merge candidates supported in the slice associated with the picture header, minus the maximum number of merge MVP candidates (MaxNumMergeCand).

[0095] If the second picture level parameter is not present, if the first sequence level flag (e.g., sps_ge_enabled_flag) is 1 and the maximum number of merge MVP candidates (MaxNumMergeCand) is 2 or greater, the second picture level parameter (e.g., pic_max_num_merge_cand_minus_max_num_geo_cand) can be inferred to be equal to (second PPS level parameter - 1) (e.g., pps_max_num_merge_cand_minus_max_max_num_geo_cand_plus1-1).

[0096] The maximum number of geometric merge mode merge candidates (MaxNumGeoMergeCand) may be determined based on the maximum number of merge MVP candidates (MaxNumMergeCand) and a second picture level parameter (eg, pic_max_num_merge_cand_minus_max_num_geo_cand), for example, using equation (2). MaxNumGeoMergeCand=MaxNumMergeCand-pic_max_num_merge_cand_minus_max_num_geo_cand (Formula 2)

[0097] If a second picture level parameter (eg, pic_max_num_merge_cand_minus_max_num_geo_cand) is present (ie, signaled), the value of MaxNumGeoMergeCand can range from 2 to MaxNumMergeCand.

[0098] If the second picture level parameter (e.g., pic_max_num_merge_cand_minus_max_num_geo_cand) is not present (i.e., not signaled), and (i) the first sequence level flag (e.g., sps_geo_enabled_flag) is equal to 0, and (ii) it is satisfied that the maximum number of merge MVP candidates (MaxNumMergeCand) is less than 2, then the maximum number of geometric merge mode merge candidates (MaxmGeoMergeCand) can be set equal to 0.

[0099] If the maximum number of geometric merge mode merge candidates (MaxNumGeoMergeCand) is 0, geometric merge mode is not allowed for the slice associated with the picture header.

[0100] The second PPS level parameter (e.g., pps_max_num_merge_cand_minus_max_num_geo_cand_plus1), the second picture level parameter (e.g., pic_max_num_merge_cand_minus_max_num_geo_cand), and the maximum number of merge MVP candidates (e.g., MaxNumMergeCand) can be used to determine the maximum number of geometric merge mode merge candidates (e.g., MaxNumGeoMergeCand). The maximum number of geometric merge mode merge candidates (MaxNumGeoMergeCand) can be specified so as not to exceed the value of MaxNumMergeCand. The value of MaxNumGeoMergeCand can vary, for example, depending on the particular application. PPS signaling can be effective when the value of MaxNumGeoMergeCand does not change frequently, and therefore does not need to be signaled for each picture. On the other hand, if MaxNumGeoMergeCand changes frequently from picture to picture, picture header signaling becomes effective.

[0101] 14 shows an example syntax signaled in a picture header, which includes a third picture level parameter (e.g., pic_five_minus_max_num_subblock_merge_cand) signaled in the picture header that indicates the maximum number of subblock-based merge MVP candidates (MaxNumSubblockMergeCand) (also referred to as the maximum number of merge candidates for the subblock-based merge mode).

[0102] The third syntax element may indicate the maximum number of sub-block-based merge MVP candidates signaled at the corresponding coding level, e.g., the third syntax element may refer to a third picture-level parameter signaled at the picture level.

[0103] A third picture level parameter (e.g., pic_five_minus_max_num_subblock_merge_cand) may specify the maximum number of subblock-based merge MVP candidates supported in a slice, subtracted from the value of 5. If the third picture level parameter is not present (or not signaled), the value of the third picture level parameter (e.g., pic_five_minus_max_num_subblock_merge_cand) may be inferred to be equal to (5-(sps_sbtmvp_enabled_flag && pic_temporal_mvp_enabled_flag)). In an embodiment, sps_sbtmvp_enabled_flag is an SPS level flag that indicates whether SBTMVP mode is enabled at the SPS level. In an embodiment, pic_temporal_mvp_enabled_flag is a picture level flag that indicates whether the temporal MVP mode is enabled at the picture level.

[0104] The maximum number of subblock-based merge MVP candidates (MaxNumSubblockMergeCand) may be determined based on, for example, a third picture level parameter (eg, pic_five_minus_max_num_subblock_merge_cand) using equation (3). MaxNumSubblockMergeCand=5-pic_five_minus_max_num_subblock_merge_cand (Formula 3)

[0105] The maximum number of subblock-based merge MVP candidates (MaxNumSubblockMergeCand) ranges from 0 to 5.

[0106] 15 shows an example syntax signaled in a picture header, including a fourth picture-level parameter (e.g., pic_six_minus_max_num_ibc_merge_cand) that indicates the maximum number of IBC merge block vector prediction (BVP) candidates (MaxNumIbcMergeCand) for IBC merge mode.

[0107] The fourth syntax element may indicate the maximum number of IBC merge BVP candidates signaled at the corresponding coding level, e.g., the fourth syntax element may refer to a fourth picture level parameter signaled at the picture level.

[0108] A fourth picture level parameter (e.g., pic_six_minus_max_num_ibc_merge_cand) may specify the maximum number of BVP candidates supported in a slice associated with the picture header, subtracted from 6. The maximum number of IBC merge BVP candidates (MaxNumIbcMergeCand) may be determined based on the fourth picture level parameter (e.g., pic_six_minus_max_num_ibc_merge_cand), for example, using equation (4). MaxNumIbcMergeCand=6-pic_six_minus_max_num_ibc_merge_cand (Equation 4)

[0109] The maximum number of IBC merge BVP candidates (MaxNumIbcMergeCand) is in the range of 1 to 6.

[0110] The syntax elements may include a first syntax element, a second syntax element, a third syntax element, a fourth syntax element, etc. As described above, the first syntax element may indicate the maximum number of merge MVP candidates signaled at a corresponding coding level (e.g., a coding level higher than the slice level or the picture level), and thus the first syntax element may indicate the length of the merge MVP candidate list for the regular merge mode. The merge MVP candidate list may include merge MVP candidates for the regular merge mode. For example, the first syntax element may reference a first PPS level parameter signaled at the PPS level or a first picture level parameter signaled at the picture level.

[0111] The second syntax element may indicate the maximum number of geometric merge mode merge candidates signaled at a corresponding coding level (e.g., a coding level higher than the slice level or the picture level), and thus the second syntax element may indicate the length of the geometric merge mode merge candidate list for the geometric merge mode. The geometric merge mode merge candidate list may include geometric merge mode merge candidates for the geometric merge mode merge candidates. For example, the second syntax element may reference a second PPS level parameter signaled at the PPS level or a second picture level parameter signaled at the picture level.

[0112] The third syntax element may indicate the maximum number of sub-block-based merge MVP candidates at a corresponding coding level (e.g., a coding level higher than the slice level or the picture level), and thus the third syntax element may indicate the length of the sub-block-based merge MVP candidate list for the sub-block-based merge mode. The sub-block-based merge MVP candidate list may include the sub-block-based merge MVP candidates for the sub-block-based merge mode. For example, the third syntax element may refer to a third picture-level parameter signaled at the picture level.

[0113] The fourth syntax element may indicate the maximum number of IBC merge BVP candidates signaled at a corresponding coding level (e.g., a coding level higher than the slice level or the picture level), and thus the fourth syntax element may indicate the length of the IBC merge BVP candidate list (or IBC merge candidate list) for the IBC merge mode. The IBC merge BVP candidate list may include IBC merge BVP candidates for the IBC merge mode. For example, the fourth syntax element refers to a fourth picture-level parameter signaled at the picture level.

[0114] According to an aspect of the present disclosure, a first syntax element signaled at a first coding level can be decoded from a coded video bitstream. The first syntax element indicates a maximum number of merge MVP candidates. The first coding level may be any suitable coding level, for example, a level higher than the slice level. In an embodiment, the first coding level is higher than the PPS level. The maximum number of merge MVP candidates may be determined based on the first syntax element, for example, based on Equation (5). Then, coding blocks associated with the first coding level are reconstructed based at least on the maximum number of merge MVP candidates. In an embodiment, the first coding level is the sequence level, and the first syntax element is signaled at the SPS. When the first coding level increases from a lower coding level (e.g., the PPS level) to a higher coding level (e.g., the sequence level), coding efficiency can be increased and signaling overhead can be reduced.

[0115] According to aspects of the present disclosure, one or more syntax elements related to the length(s) of a corresponding merge candidate list (e.g., a merge MVP candidate list, a geometric merge mode merge candidate list, a sub-block-based merge MVP candidate list, an IBC merge BVP candidate list, and / or the like) may be signaled at a first coding level. The first coding level may be any suitable coding level. In embodiments, the first coding level is higher than a slice level or a picture level. In embodiments, the first coding level is higher than a PPS level. The one or more syntax elements may include the first syntax element.

[0116] In one embodiment, the one or more syntax elements, including a first syntax element, a second syntax element, a third syntax element, and a fourth syntax element, are signaled in the SPS at the sequence level. In an embodiment, the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element remain unchanged in the first coding level. In an embodiment, the first coding level is the sequence level. Certain syntax elements, such as one or more syntax elements including the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element, remain unchanged at the sequence level, and signaling certain syntax elements at the sequence level instead of at a lower coding level (e.g., the PPS level, the picture level, or the slice level) can improve coding efficiency and reduce signaling overhead.

[0117] In one embodiment, the second syntax element, the third syntax element, and the fourth syntax element can be signaled at a first coding level and decoded from a coded video bitstream. The second syntax element can indicate a maximum number of geometric merge mode merge candidates, the third syntax element can indicate a maximum number of sub-block-based merge MVP candidates, and the fourth syntax element can indicate a maximum number of IBC merge BVP candidates. The maximum number of geometric merge mode merge candidates can be determined based on the second syntax element, the maximum number of sub-block-based merge MVP candidates can be determined based on the third syntax element, and the maximum number of IBC merge BVP candidates can be determined based on the fourth syntax element.

[0118] 16 shows exemplary syntax elements in an SPS. The syntax elements include a first syntax element (e.g., six_minus_max_num_merge_cand), a second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand), a third syntax element (e.g., five_minus_max_num_subblock_merge_cand), and a fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand).

[0119] A first syntax element (e.g., six_minus_max_num_merge_cand) may specify the maximum number of merge MVP candidates supported in the SPS, subtracted from the value 6. The maximum number of merge MVP candidates (MaxNumMergeCand) may be determined based on the first syntax element (e.g., six_minus_max_num_merge_cand), for example, based on equation (5). MaxNumMergeCand=6-six_minus_max_num_merge_cand (Equation 5)

[0120] The value of MaxNumMergeCand can range from 1 to 6.

[0121] A second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand) can specify the maximum number of geometric merge mode merge candidates supported by the SPS, subtracted from MaxNumMergeCand.

[0122] The maximum number of geometric merge mode merge candidates (MaxNumGeoMergeCand) can be determined based on the second syntax element and the maximum number of merge MVP candidates, for example, using Equation 6: MaxNumGeoMergeCand=MaxNumMergeCand-max_num_merge_cand_minus_max_num_geo_cand Formula (6)

[0123] If a second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand) is present (or signaled), the value of the maximum number of geometric merge mode merge candidates (MaxNumGeoMergeCand) can range from 2 to the maximum number of merge MVP candidates (MaxNumMergeCand).

[0124] The third syntax element (e.g., five_minus_max_num_subblock_merge_cand) can specify the maximum number of subblock-based merge MVP candidates supported by the SPS, subtracted from the value five.

[0125] The maximum number of subblock-based merge MVP candidates (MaxNumSubblockMergeCand) may be determined based on a third syntax element (eg, five_minus_max_num_subblock_merge_cand), for example, using equation (7). MaxNumSubblockMergeCand=5-five_minus_max_num_subblock_merge_cand (Equation 7)

[0126] The value of MaxNumSubblockMergeCand can range from 0 to 5.

[0127] A fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand) may specify the maximum number of BVP candidates supported in the SPS, subtracted from the value 6. The maximum number of IBC merge BVP candidates (MaxNumIbcMergeCand) may be determined based on the fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand), for example, using equation (8). MaxNumIbcMergeCand = 6 -six_minus_max_num_ibc_merge_cand (Equation 8)

[0128] The value of MaxNumIbcMergeCand is in the range of 0 to 6.

[0129] In an embodiment, syntax elements including a first syntax element, a second syntax element, a third syntax element, and a fourth syntax element are signaled in a PPS. In this manner, the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element do not change within a PPS, but can change from a first PPS to a second PPS.

[0130] According to aspects of the present disclosure, one or more syntax elements related to the length(s) of the corresponding merge candidate list(s) may be conditionally signaled, for example, based on whether the corresponding inter-predictive coding tool (or inter-coding tool) is enabled. In one embodiment, a first syntax element indicates that the maximum number of merge MVP candidates (or the length of the merge MVP candidate list in the case of regular merge mode) is to be signaled, and the remaining syntax elements related to the lengths of other merge candidate lists (e.g., the second syntax element, the third syntax element, the fourth syntax element, etc.) may or may not be signaled. Accordingly, an enable flag for a particular inter-coding tool may be used to control the signaling of a corresponding syntax element related to the length of the merge candidate list for the particular inter-coding tool. Thus, in some embodiments, if an enable flag for a particular inter-coding tool indicates that the particular inter-coding tool is disabled, the corresponding syntax element is not signaled, thus increasing coding efficiency and / or reducing signaling overhead.

[0131] In one embodiment, a syntax element signaled at the second coding level can be decoded from the coded video bitstream based on a condition being satisfied. The syntax element can indicate a maximum number of merge candidates for one of a geometric merge mode, a sub-block-based merge mode, an IBC merge mode, etc.

[0132] In the examples, The one of the geometric merge mode, the sub-block-based merge mode, and the IBC merge mode is the geometric merge mode. The maximum number of merge candidates is the maximum number of geometric merge mode merge candidates. The syntax element is a second syntax element indicating the maximum number of geometric merge mode merge candidates. Referring to box 1712 of FIG. 17, the conditions are the geometric merge mode available in the second coding level and the maximum number of the merge MVP candidates being 3 or greater. The maximum number of geometric merge mode merge candidates can be determined based on the second syntax element.

[0133] In an embodiment, the one of the geometric merge mode, the sub-block-based merge mode, and the IBC merge mode is the sub-block-based merge mode. The maximum number of merge candidates is the maximum number of sub-block-based merge MVP candidates. The syntax element is a third syntax element indicating the maximum number of sub-block-based merge MVP candidates. Referring to box 1710 of Figure 17, the condition is the affine mode available in the second coding level. The maximum number of sub-block-based merge MVP candidates can be determined based on the third syntax element.

[0134] In an embodiment, the one of the geometric merge mode, the sub-block-based merge mode, and the IBC merge mode is the IBC merge mode. The maximum number of merge candidates is the maximum number of IBC merge BVP candidates. A syntax element may be a fourth syntax element indicating the maximum number of IBC merge BVP candidates. Referring to box 1711 in FIG. 17, a condition is that the IBC merge mode is enabled in the second coding level. The maximum number of IBC merge BVP candidates may be determined based on the fourth syntax element.

[0135] In an embodiment, a first syntax element indicating the length of the merge MVP candidate is signaled in the SPS, and a second syntax element indicating the length of the geometric merge mode merge candidate, a third syntax element indicating the length of the sub-block-based merge MVP candidate list, and a fourth syntax element indicating the length of the IBC merge candidate list are conditionally signaled at the sequence level as shown in FIG. 17.

[0136] 17, a first syntax element (e.g., six_minus_max_num_merge_cand) is signaled in the SPS. As described above, the first syntax element (e.g., six_minus_max_num_merge_cand) can specify the maximum number of merge MVP candidates supported in the SPS, subtracted from the value 6. The maximum number of merge MVP candidates (MaxNumMergeCand) can be determined based on the first syntax element (e.g., six_minus_max_num_merge_cand), for example, based on Equation (5). The value of MaxNumMergeCand can be specified within the range of 1 to 6.

[0137] 17, a second syntax element (e.g., max_num_merge_cand_minus_num_geo_cand) can be signaled when a first sequence-level flag (e.g., sps_geo_enabled_flag) is equal to 1 and the maximum number of merge MVP candidates (MaxNumMergeCand) is greater than or equal to 3. In an embodiment, the first sequence-level flag (e.g., sps_geo_enabled_flag) being equal to 1 indicates that the geometric merge mode is enabled at the sequence level.

[0138] A second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand) can specify the maximum number of geometric merge mode merge candidates supported by the SPS, subtracted from MaxNumMergeCand.

[0139] The maximum number of GEO merge mode candidates (MaxNumGeoMergeCand) can be determined using equation (6).

[0140] If a second syntax element (eg, max_num_merge_cand_minus_max_num_geo_cand) is present, the value of the maximum number of GEO merge mode candidates (MaxNumGeoMergeCand) ranges from 2 to the maximum number of merge MVP candidates (MaxNumMergeCand).

[0141] If the second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand) is not present, The first sequence-level flag (e.g., sps_geo_enabled_flag) is equal to 1, If the maximum number of merge MVP candidates (MaxNumMergeCand) is equal to 2, The maximum number of GEO merge mode candidates (MaxNumGeoMergeCand) can be set to 2.

[0142] If a second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand) is not present (or is not signaled), (i) the first sequence-level flag (e.g., sps_geo_enabled_flag) is equal to 0; (ii) If one of the following is satisfied: the maximum number of merge MVP candidates (e.g., MaxNumMergeCand) is less than 2; The maximum number of geometric merge mode merge candidates (e.g., MaxNumGeoMergeCand) can be set equal to 0.

[0143] Referring to box (1710) of FIG. 17, if a second sequence level flag (eg, sps_affine_enabled_flag) is equal to 1, a third syntax element (eg, five_minus_max_num_subblock_merge_cand) can be signaled. In an embodiment, a second sequence-level flag (eg, sps_affine_enabled_flag) equal to 1 indicates that affine mode is enabled at the sequence level.

[0144] The third syntax element (e.g., five_minus_max_num_subblock_merge_cand) can specify the maximum number of subblock-based merge MVP candidates supported by SPS, subtracted from the value 5. If the third syntax element is not present, the value of the third syntax element (e.g., five_minus_max_num_subblock_merge_cand) can be inferred to be equal to (5 - sps_sbtmvp_enabled_flag).

[0145] The maximum number of subblock-based merge MVP candidates (MaxNumSubblockMergeCand) may be determined based on equation (7).

[0146] The value of MaxNumSubblockMergeCand can range from 0 to 5.

[0147] 17, a fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand) can be signaled if a third sequence level flag (e.g., sps_ibc_enabled_flag) is equal to 1. In an embodiment, the third sequence level flag (e.g., sps_ibc_enabled_flag) being equal to 1 indicates that the IBC merge mode is enabled at the sequence level.

[0148] A fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand) may specify the maximum number of BVP candidates supported in the SPS, subtracted from the value 6. The maximum number of IBC merge BVP candidates (MaxNumIbcMergeCand) may be determined based on the fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand), for example, using equation (8).

[0149] If the fourth syntax element (eg, six_minus_max_num_ibc_merge_cand) is not present, MaxNumIbcMergeCand can be equal to 0.

[0150] The value of MaxNumIbcMergeCand is in the range of 0 to 6.

[0151] In an embodiment, as shown in Figure 17, the first syntax element is signaled at a first coding level (e.g., sequence level), and the second syntax element, the third syntax element, and the fourth syntax element are conditionally signaled at a second coding level (e.g., sequence level). Alternatively, the first syntax element is signaled at a first coding level (e.g., sequence level), and one or more of (i) the second syntax element, (ii) the third syntax element, (iii) the fourth syntax element, and / or other syntax elements are conditionally signaled at a second coding level (e.g., sequence level). The first coding level can be the same as or higher than the second coding level. In an embodiment, the first coding level and the second coding level are sequence levels.

[0152] In one embodiment, a first syntax element indicating the length of the merge MVP candidate list is signaled at a first coding level, and a second syntax element indicating the length of the geometric merge mode merge candidate, a third syntax element indicating the length of the sub-block-based merge MVP candidate list, and a fourth syntax element indicating the length of the IBC merge candidate are conditionally signaled at the first coding level. In an embodiment, the first coding level is higher than a slice level (or slice header), a picture level (or picture header), etc. In an embodiment, the first coding level is a sequence level.

[0153] A particular syntax element (e.g., a first syntax element) does not change at a first coding level (e.g., a sequence level) and remains constant for pictures, slices, and / or the like within a sequence. In this manner, a particular syntax element may be signaled at a first coding level (e.g., a higher coding level) instead of at a coding level lower than the first coding level, e.g., to improve coding efficiency and / or reduce signaling overhead. Another syntax element (e.g., a third syntax element) may change at the first coding level and thus may be signaled at a second coding level (e.g., a lower coding level) lower than the first coding level, e.g., for increased flexibility. For example, the first coding level is the sequence level, and the third syntax element changes within a sequence but not within a picture and therefore is signaled at the picture level (e.g., a second coding level).

[0154] In one embodiment, a first syntax element indicating the length of the merge MVP candidate list is signaled at a first coding level, and a second syntax element indicating the length of the geometric merge mode merge candidate list and a fourth syntax element indicating the length of the IBC merge candidate list are conditionally signaled at the first coding level. Other syntax elements indicating the length(s) of other merge candidate list(s), for example, a third syntax element indicating the length(s) of a subblock-based merge MVP candidate list, can be signaled at a second coding level lower than the first coding level. In an embodiment, the first coding level is the sequence level, and the second coding level is the PPS level, the picture level, or the slice level.

[0155] In an embodiment, only the first syntax element, the second syntax element, and the fourth syntax element are signaled in the SPS at the sequence level. Other syntax element(s) indicating the length(s) of other merge candidate lists are signaled at a level lower than the sequence level (e.g., the picture level). The other syntax element(s) may include the third syntax element. In an embodiment, the third syntax element changes within the SPS, for example, from the first picture to the second picture, and therefore the third syntax element is signaled at the picture level to have better flexibility for each picture.

[0156] Figure 18A shows that the first syntax element, the second syntax element, and the fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand) are signaled in the SPS at the sequence level. Figure 18B shows that the third syntax element is signaled at the picture level in the picture header. The syntax elements shown in Figures 18A-18B can be applied when the first syntax element (e.g., six_minus_max_num_merge_cand), the second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand), and the fourth syntax element do not change at the sequence level, and the third syntax element (e.g., five_minus_max_num_subblock_merge_cand) can change within the sequence.

[0157] In an embodiment, a first syntax element indicating the length of a merge MVP candidate list remains unchanged (e.g., cannot be updated, overridden, or modified) at coding levels lower than the first coding level. A second syntax element and a fourth syntax element conditionally signaled at a second coding level remain unchanged (e.g., cannot be updated, overridden, or modified) at coding levels lower than the second coding level. In an embodiment, only syntax elements indicating the length(s) of other merge candidate list(s), excluding any of a merge MVP candidate list, a geometric merge mode merge candidate list, and an IBC merge candidate list, may be updated, overridden, or modified at coding levels lower than the second coding level. In an embodiment, a third syntax element conditionally signaled at a second coding level is modified at coding levels lower than the second coding level. For example, a third syntax element conditionally signaled at a second coding level (e.g., the sequence level) is modified at the picture level.

[0158] In an embodiment, only the third syntax element indicating the length of the sub-block-based merging candidate list can be updated, overridden, or modified at a coding level (e.g., picture level) lower than the first coding level (sequence level).

[0159] Figure 19A shows that the first syntax element, the second syntax element, and the fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand) are signaled in the SPS at the sequence level and remain unchanged at the sequence level. Figures 19A-19B show that the third syntax element is signaled in the SPS at the sequence level and is further modified in the picture header at the picture level. The syntax elements shown in Figures 19A-19B can be applied when the first syntax element (e.g., six_minus_max_num_merge_cand), the second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand), and the fourth syntax element remain unchanged at the sequence level, and the third syntax element (e.g., five_minus_max_num_subblock_merge_cand) can be changed per picture.

[0160] If the third syntax element (e.g., five_minus_max_num_subblock_merge_cand) is not present in the SPS and both pic_temporal_mvp_enabled_flag and sps_sbtmvp_enabled_flag are equal to 1, the maximum number of subblock-based merge MVP candidates (MaxNumSubblockMergeCand) is equal to 1 for the slice associated with the current picture header.

[0161] According to aspects of the disclosure, one or more of the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element are signaled at a first coding level (e.g., a sequence level), which is higher than the slice level or the picture level, and one or more of the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element cannot be upgraded, overridden, or modified at a coding level (e.g., a PPS level, a picture level, a slice level, etc.) lower than the first coding level (e.g., a sequence level).

[0162] In an embodiment, the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element are signaled in the SPS at the sequence level, and the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element cannot be updated, overridden, or modified at a coding level lower than the sequence level (e.g., the PPS level, the picture level, or the slice level).

[0163] In an embodiment, the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element are signaled in a PPS at the PPS level, and the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element cannot be updated, overridden, or modified at a coding level lower than the PPS level (e.g., the picture level, the slice level).

[0164] According to aspects of the present disclosure, additional syntax elements may be used to further indicate the presence of one or more syntax elements related to the lengths of various merge candidate lists.

[0165] In an embodiment, as shown by box (2010) in Figure 20, a syntax element or flag indicating the presence of a fourth syntax element related to the length of the IBC merge BVP candidate list (e.g., six_minus_max_ibc_merge_cand_present flag) is used to further indicate whether the fourth syntax element is present, as shown in Figure 20. Thus, the presence of the fourth syntax element is conditionally determined based on the syntax element (e.g., six_minus_max_num_ibc_merge_cand_present flag) in addition to the third sequence-level flag (e.g., sps_ibc_enabled_flag). The fourth syntax element is conditionally signaled based on the syntax element (e.g., six_minus_max_num_ibc_merge_cand_present flag) and the third sequence-level flag (e.g., sps_ibc_enabled_flag). The above description may be adapted as appropriate to the signaling of other syntax elements, such as the second syntax element, the third syntax element, and / or the like.

[0166] A first syntax element (e.g., six_minus_max_num_merge_cand) can specify the maximum number of merge MVP candidates supported by the SPS, subtracted from the value 6. The maximum number of subblock-based merge MVP candidates (MaxNumSubblockMergeCand) can be determined based on Equation (5), as described above. The value of MaxNumMergeCand can be specified in the range of 1 to 6.

[0167] A second syntax element (e.g., max_num_merge_cand_minus_max_num_geo_cand) can specify the maximum number of geometric merge mode merge candidates supported by the SPS, subtracted from MaxNumMergeCand.

[0168] The maximum number of geometric merge mode merge candidates (MaxNumGeoMergeCand) can be determined based on equation (6) as described above.

[0169] If max_num_merge_cand_minus_max_num_geo_cand is present, the value of MaxNumGeoMergeCand can be in the range of 2 to MaxNumMergeCand.

[0170] If max_num_merge_cand_minus_max_num_geo_cand is not present, and sps_geo_enabled_flag is equal to 1, and MaxNumMergeCand is equal to 2, then MaxNumGeoMergeCand is set equal to 2.

[0171] If max_num_merge_cand_minus_max_num_geo_cand is not present (and sps_geo_enabled_flag is equal to 0 or MaxNumMergeCand is less than 2), then MaxNumGeoMergeCand is set equal to 0.

[0172] The third syntax element (e.g., five_minus_max_num_subblock_merge_cand) can specify the maximum number of subblock-based merge MVP candidates supported by the SPS, subtracted from the value 5. If the second syntax element is not present, the value of five_minus_max_num_subblock_merge_cand can be inferred to be equal to (5 - sps_sbtmvp_enabled_flag).

[0173] The maximum number of subblock-based merge MVP candidates (MaxNumSubblockMergeCand) can be determined based on equation (7), as described above.

[0174] The value of MaxNumSubblockMergeCand can range from 0 to 5.

[0175] The syntax element six_minus_max_num_ibc_merge_cand_present flag can specify the maximum number of IBC merge BVP candidates. If the six_minus_max_num_ibc_merge_cand_present flag is not present, the six_minus_max_num_ibc_merge_cand_present flag can be inferred to be 0. If the six_minus_max_num_ibc_merge_cand_present flag is present, a fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand) is present in the bitstream.

[0176] A fourth syntax element (e.g., six_minus_max_num_ibc_merge_cand) can specify the maximum number of BVP candidates supported in the SPS, subtracted from the value 6. The maximum number of IBC merge mode candidates (MaxNumIbcMergeCand) can be determined using equation (8).

[0177] If the fourth syntax element (eg, six_minus_max_num_ibc_merge_cand) is not present, MaxNumIbcMergeCand can be equal to 0.

[0178] The value of MaxNumMergeCand can range from 1 to 6.

[0179] FIG. 21 shows a flowchart outlining a process (2100) according to one embodiment of the present disclosure. The process (2100) can be used to signal various syntax elements indicating a maximum number of merge candidates, such as a maximum number of merge candidates, a maximum number of geometric merge mode merge candidates, a maximum number of sub-block-based merge MVP candidates, or a maximum number of IBC merge BVP candidates. In various embodiments, the process (2100) is performed by a processing circuit, such as the processing circuitry of the terminal devices (210), (220), (230), and (240), a processing circuit performing the functions of the video encoder (303), a processing circuit performing the functions of the video decoder (310), a processing circuit performing the functions of the video decoder (410), or a processing circuit performing the functions of the video encoder (503). In some embodiments, the process (2100) is implemented by software instructions, and thus, the processing circuit performs the process (2100) when the processing circuit executes the software instructions. The process begins at (S2101) and proceeds to (S2110).

[0180] At (S2110), a first syntax element signaled at a first coding level can be decoded from a coded video bitstream. The first syntax element can indicate a maximum number of merge motion vector prediction (MVP) candidates. The first coding level can be higher than a picture parameter set (PPS) level. In an embodiment, the first coding level is a sequence level.

[0181] At (S2120), the maximum number of merge MVP candidates can be determined based on the first syntax element.

[0182] At step S2130, the coding blocks associated with the first coding level may be reconstructed based at least on the maximum number of merged MVP candidates. The process 2100 then proceeds to step S2199 and ends.

[0183] The method 2100 can be adapted as appropriate. Steps of the process 2100 can be modified and / or omitted. Additional step(s) can be added. Any suitable order of execution can be used.

[0184] In some embodiments, additional syntax elements, such as one or more of a second syntax element, a third syntax element, and a fourth syntax element, may be signaled or conditionally signaled. Thus, the maximum number of geometric merge mode merge candidates may be determined based on the second syntax element, the maximum number of sub-block based merge MVP candidates may be determined based on the third syntax element, and the maximum number of IBC merge BVP candidates may be determined based on the fourth syntax element.

[0185] The disclosed methods can be used separately or in combination in any order. Furthermore, each of the methods (or embodiments), encoders, and decoders can be implemented by processing circuitry (e.g., one or more processors, or one or more integrated circuits). In one example, the one or more processors execute a program stored on a non-transitory computer-readable medium. The disclosed methods (or embodiments), encoders, and decoders can improve coding efficiency and / or reduce signaling overhead, as described above.

[0186] The techniques described above can be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, Figure 22 illustrates a computer system (2200) suitable for implementing certain embodiments of the disclosed subject matter.

[0187] Computer software can be coded using any suitable machine code or computer language that can be subject to assembly, compilation, linking, or similar mechanisms to create code including instructions that can be executed directly or via implementation, microcode execution, etc., by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc.

[0188] The instructions may be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smart phones, gaming devices, internet of things devices, and the like.

[0189] 17 for computer system 2200 are exemplary in nature and are not intended to suggest any limitation on the scope of use or functionality of the computer software implementing embodiments of the present disclosure, nor should the arrangement of components be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary embodiment of computer system 2200.

[0190] The computer system 2200 may include certain human interface input devices that may respond to input by one or more human users, for example, via tactile input (e.g., keystrokes, flipping, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), or olfactory input (not shown). Human interface devices may also be used to capture certain media that do not necessarily involve direct conscious human input, such as audio (e.g., voice, music, ambient sounds), images (e.g., scanned images, photographic images obtained from still image cameras), and video (e.g., two-dimensional video, three-dimensional video, including stereoscopic images).

[0191] The input human interface devices may include one or more of the following (only one of each is shown): a keyboard (2201), a mouse (2202), a trackpad (2203), a touchscreen (2210), a data glove (not shown), a joystick (2205), a microphone (2206), a scanner (2207), and a camera (2208).

[0192] The computer system (2200) may also include certain human interface output devices. Such human interface output devices may stimulate one or more of the human user's senses, for example, through tactile output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touchscreen (2210), data gloves (not shown), or joystick (2205)), which may also be haptic feedback devices that do not serve as input devices), audio output devices (e.g., speakers (1709), headphones (not shown)), visual output devices (e.g., screens (2210), including CRT screens, LCD screens, plasma screens, and OLED screens, each with or without haptic feedback capabilities, some of which may enable two-dimensional visual output or three-dimensional or higher output via means such as virtual reality glasses (not shown), holographic displays, and stereoscopic output such as smoke tanks (not shown)), and printers (not shown).

[0193] The computer system (2200) may also include human-accessible storage devices and their accessible media, such as optical media drives (2220) including CD / DVD ROM / RW with media (2221) such as CD / DVD, USB memory (2222), removable head drives or solid state drives (2223), conventional magnetic media such as tape, floppy disks (not shown), specialized ROM / ASIC / PLD-based devices such as security dongles, etc.

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

[0195] The computer system 2200 may also include interfaces to one or more communications networks. Networks may be, for example, wireless, wired, or optical. Networks may further be local, wide-area, metropolitan, vehicular, and industrial, real-time, delay-tolerant, and the like. Examples of networks include Ethernet, Wi-Fi, cellular networks including GSM, 3G, 4G, 5G, LTE, and the like; cable, satellite, and terrestrial broadcast TV; and industrial and vehicular networks including CANBus. Certain networks require external network interface adapters connected to specific general-purpose data ports or peripheral buses 2249 (e.g., USB ports on the computer system 2200); others are generally integrated into the core of the computer system 2200 by connecting to a system bus (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system), as described below. Using any of these networks, the computer system 2200 may communicate with other entities. Such communications can be unidirectional, receive-only (e.g., broadcast television), unidirectional transmit-only (e.g., a CAN bus to a particular CAN bus device), or bidirectional, e.g., to other computer systems using local or wide-area digital networks. Specific protocols and protocol stacks can be used with each of these networks and network interfaces, as described above.

[0196] The aforementioned human interface devices, human-accessible storage devices, and network interfaces can be connected to the core (2240) of the computer system (2200).

[0197] The cores 2240 may include one or more central processing units (CPUs) 2241, graphics processing units (GPUs) 2242, specialized programmable processing devices in the form of field programmable gate arrays (FPGAs) 2243, hardware accelerators for specific tasks 2244, etc. These devices, along with read-only memory (ROM) 2245, random access memory 2246, and internal mass storage devices such as internal non-user-accessible hard drives, SSDs, etc. 2247, may be connected via a system bus 2248. In some computer systems, the system bus 2248 is accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices may connect directly to the core's system bus 2248 or may be connected via a peripheral bus 2249. Peripheral bus architectures include PCI, USB, etc.

[0198] The CPU (2241), GPU (2242), FPGA (2243), and accelerator (2244) can combine to execute specific instructions that may constitute the aforementioned computer code. The computer code may be stored in ROM (2245) or RAM (2246). Transient data may also be stored in RAM (2246), while permanent data may be stored, for example, in an internal mass storage device (2247). Cache memory, which may be closely associated with one or more of the CPU (2241), GPU (2242), mass storage device (2247), ROM (2245), RAM (2246), etc., may be used to enable fast storage and retrieval in any of the memory devices.

[0199] The computer-readable medium can have computer code thereon for performing various computer-implemented operations. The media and computer code can be those specially designed and created for the present disclosure, or they can be of the type well known and available in the art of computer software technology.

[0200] As an example, and not by way of limitation, a computer system having the architecture (2200), and specifically the core (2240), can provide functionality as a result of a processor (including a CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media may be media associated with a user-accessible mass storage device, as described above, as well as specific storage devices of the core (2240) that are non-transitory in nature, such as the core-internal mass storage device (2247) or ROM (2245). Software implementing various embodiments of the present disclosure may be stored in such devices and executed by the core (2240). The computer-readable medium may include one or more memory devices or chips, depending on particular needs. The software may cause the core (2240), and specifically the processor (including a CPU, GPU, FPGA, etc.) therein, to perform certain processes or portions thereof described herein, including defining data structures stored in RAM (2246) and modifying such data structures according to processes defined by the software. Additionally or alternatively, the computer system may provide functionality as a result of logic hardwired or otherwise embodied in circuitry (e.g., accelerator (2244)), which may operate in place of or in conjunction with software to perform particular processes or portions of particular processes described herein. Reference to software includes logic, and vice versa, where appropriate. Reference to a computer-readable medium may include circuitry (such as an integrated circuit (IC)) that stores software for execution, circuitry that embodies logic for execution, or both, as appropriate. The present disclosure encompasses any suitable combination of hardware and software.

[0201] Appendix A Abbreviation JEM: Joint Search Model VVC: Universal Video Coding BMS: Benchmark Set MV: Motion Vector HEVC: High Efficiency Video Coding SEI: Additional reinforcement information VUI: Video Usability Information GOP: Group of Pictures TU: Conversion unit PU: Prediction Unit CTU: Coding Tree Unit CTB: coding tree block PB: Predicted Block HRD: Hypothetical Reference Decoder SNR: Signal to Noise Ratio CPU: Central Processing Unit GPU: Graphics Processing Unit CRT: cathode ray tube LCD: Liquid crystal display OLED: Organic Light Emitting Diode CD: Compact Disc DVD: Digital Video Disc ROM: Read-only memory RAM: Random Access Memory ASIC: Application Specific Integrated Circuit PLD: Programmable Logic Device LAN: Local Area Network GSM: Global System for Mobile Communications LTE: Long Term Evolution CAN bus: Controller Area Network bus USB: Universal Serial Bus PCI: Peripheral Component Interconnect FPGA: Field Programmable Gate Area SSD: Solid State Drive IC: Integrated Circuit CU: Coding Unit

[0202] While this disclosure describes several exemplary embodiments, there are alterations, permutations, and various equivalents that fall within the scope of this invention. It will thus be appreciated that those skilled in the art will be able to create numerous systems and methods that, although not explicitly shown or described herein, embody the principles of the invention and are therefore within its concept and scope.

[0203] [Appendix 1] 1. A method for decoding video performed by a decoder, comprising: decoding, from the coded bitstream, a first syntax element signaled at a first coding level, the first syntax element indicating a maximum number of merge motion vector prediction (MVP) candidates, the first coding level being higher than a picture parameter set (PPS) level; determining the maximum number of merged MVP candidates based on the first syntax element; reconstructing coding blocks associated with the first coding level based at least on the maximum number of merged MVP candidates; A method comprising: [Appendix 2] The method further comprises: decoding, from the coded video bitstream, second, third, and fourth syntax elements signaled at the first coding level, wherein the second syntax element indicates a maximum number of geometric merge mode merge candidates, the third syntax element indicates a maximum number of sub-block based merge MVP candidates, and the fourth syntax element indicates a maximum number of intra block copy (IBC) merge block vector prediction (BVP) candidates; (i) determining the maximum number of geometric merge mode merge candidates based on the second syntax element; (ii) determining the maximum number of sub-block-based merge MVP candidates based on the third syntax element; and (iii) based on the fourth syntax element, determining the maximum number of IBC merge BVP candidates, determining 2. The method of claim 1, comprising: [Appendix 3] the first coding level is a sequence level; The first syntax element is signaled in a sequence parameter set (SPS). The method described in Appendix 1. [Appendix 4] The method further comprises: determining, from the coded video bitstream, a second syntax element signaled at a second coding level based on a satisfied condition, the second syntax element indicating a maximum number of merge candidates for one of a geometric merge mode, a sub-block based merge mode, and an intra block copy (IBC) merge mode; 2. The method of claim 1, further comprising: [Appendix 5] the one of the geometric merge mode, the sub-block based merge mode, and the IBC merge mode is the geometric merge mode, the maximum number of merge candidates is the maximum number of merge candidates for the geometric merge mode; the second syntax element indicates a maximum number of merge candidates for the geometric merge mode; the conditions are the geometric merge mode available at the second coding level and the maximum number of merge MVP candidates being 3 or greater; The method further comprises: determining a maximum number of merge candidates for the geometric merge mode based on the second syntax element; 5. The method of claim 4, comprising: [Appendix 6] the one of the geometric merge mode, the sub-block-based merge mode, and the IBC merge mode is the sub-block-based merge mode, the maximum number of merging candidates is the maximum number of sub-block-based merging MVP candidates; the second syntax element indicates a maximum number of the sub-block-based merge MVP candidates; the condition being an affine mode available in the second coding level; The method further comprises: determining the maximum number of sub-block based merging MVP candidates based on the second syntax element; 5. The method of claim 4, comprising: [Appendix 7] the one of the geometric merge mode, the sub-block based merge mode, and the IBC merge mode is the IBC merge mode, the maximum number of merge candidates is a maximum number of IBC merge block vector prediction (BVP) candidates (IBC merge BVP candidates); The second syntax element indicates the maximum number of IBC merge BVP candidates; the condition is the IBC merge mode being enabled in the second coding level; The method further comprises: determining a maximum number of the IBC merge BVP candidates based on the second syntax element; The method described in Appendix 4. [Appendix 8] the first coding level and the second coding level are sequence levels; The method described in Appendix 4. [Appendix 9] the second syntax element is changed at a coding level lower than the second coding level; The method described in Appendix 6. [Appendix 10] the first coding level and the second coding level are sequence levels; the coding level lower than the second coding level is a picture level; The method described in Appendix 9. [Appendix 11] 1. An apparatus for video decoding, comprising: a processing circuit, the processing circuit comprising: Carrying out the method of any one of claims 1 to 10 It is configured as follows: Device. [Appendix 12] 1. A program comprising instructions that, when executed by a computer, cause the computer to: decoding, from the coded bitstream, a first syntax element signaled at a first coding level, the first syntax element indicating a maximum number of merge motion vector prediction (MVP) candidates, the first coding level being higher than a picture parameter set (PPS) level; determining the maximum number of merged MVP candidates based on the first syntax element; reconstructing coding blocks associated with the first coding level based at least on the maximum number of merged MVP candidates; Execute program. [Appendix 13] 1. A method for encoding video performed by an encoder, comprising: encoding a bitstream, wherein in the coded bitstream, a first syntax element is signaled at a first coding level, the first syntax element indicating a maximum number of merge motion vector prediction (MVP) candidates, the first coding level being higher than a picture parameter set (PPS) level; A method comprising:

Claims

[Claim 1] 1. A method for decoding video performed by a decoder, comprising: decoding, from a coded bitstream, a first syntax element signaled at a first coding level, the first syntax element indicating a maximum number of merge motion vector prediction (MVP) candidates, the first coding level being higher than a picture parameter set (PPS) level; determining the maximum number of merge MVP candidates based on the first syntax element; reconstructing coding blocks associated with the first coding level based at least on the maximum number of merge MVP candidates; A method comprising:

Images