Method, apparatus and program for video coding

By signaling and determining the maximum number of merge candidates at specific coding levels, the video coding technique addresses inefficiencies in inter prediction, leading to improved coding efficiency and compression ratios.

JP7670443B2Active Publication Date: 2025-04-30TENCENT AMERICA LLC
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2021557681
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2020-11-03
Filing Date
2021-01-12
Publication Date
2025-04-30
Estimated Expiration
2041-01-12

Smart Images

  • Figure 0007670443000001
    Figure 0007670443000001
  • Figure 0007670443000002
    Figure 0007670443000002
  • Figure 0007670443000003
    Figure 0007670443000003
Patent Text Reader

Abstract

Aspects of the disclosure provide an apparatus and method including a processing circuit for video decoding. 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 is 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 reconstructs coding blocks associated with the first coding level based at least on the maximum number of merge MVP candidates. The first coding level can be a sequence level, and the first syntax element can be signaled in a sequence parameter set (SPS).
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

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

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

[0003] The background discussion provided herein is intended to generally present the context of the present disclosure. Work of the presently cited inventors is not expressly or impliedly admitted as prior art to the present disclosure to the extent that such 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 sequence of images, each having spatial dimensions of, for example, 1920x1080 luma samples and associated chrominance samples. The sequence of images can have a fixed or variable image rate (for example, 60 images / second or 60Hz). Uncompressed video requires large bit rates. For example, 1080p60 4:2:0 video (1920x1080 luma sample resolution at a frame rate of 60Hz) with 8 bits per sample requires a bandwidth approaching 1.5Gbit / s. One hour of such video requires more than 600Gbytes of storage space.

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

[0006] Motion compensation can be a lossy compression technique and can be related to a technique in which blocks of sample data from a previously reconstructed image or part thereof (reference image) are used for the prediction of a new reconstructed image or part thereof after being spatially shifted in a direction indicated by a motion vector (hereinafter also referred to as MV). In some cases, the reference image can be the same as the image currently being reconstructed. The 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 it in decoding order. In this way, the amount of data required for coding the MV can be significantly reduced, thereby removing 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 probability of moving in a similar direction and therefore, in some cases, can be predicted using similar motion vectors derived from MVs of neighboring areas. As a result, the MV found for a given area will be similar or identical to the MV predicted from the surrounding MVs, which, after entropy coding, can be represented with a smaller number of bits than would be used when coding the MVs 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 non-reversible, for example due to rounding errors in computing the predictor from several 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 called “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 previous block of the same size but spatially shifted. Instead of coding its MV directly, it can be derived from metadata associated with one or more reference pictures, e.g., from the most recent reference picture (in decoding order), using MVs associated with any of the 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 use. 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 merged motion vector prediction (MVP) candidates. The first coding level can be higher than a picture parameter set (PPS) level. The processing circuit can determine a maximum number of merged 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 merged MVP candidates.

[0011] In an embodiment, the processing circuitry can decode from the 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 circuitry can determine (i) a maximum number of geometric merge mode merge candidates based on the second syntax element, (ii) a maximum number of the sub-block based merge MVP candidates based on the third syntax element, and (iii) a 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, the processing circuitry comprises: The conditions are met Based on the second coding level signaling Syntax Elements of decision It is possible. The syntax elements may 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, 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 the maximum number of geometric merge mode merge candidates. The syntax elements denotes the maximum number of geometric merge mode merge candidates. The second syntax element is The conditions are: Geometric merge mode Available at the second coding level can be , and Maximum number of merge MVP candidates 3 or more do. The processing circuit is A second syntax element signalled at a second coding levelBased on this, the maximum number of geometric merge mode merge candidates can be determined. The processing circuit may set the maximum number of geometric merge mode merge candidates to two if there is no second syntax element signaled at the first coding level, the first sequence level flag is equal to one, and the maximum number of merge MVP candidates is equal to two.

[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 the maximum number of sub-block based merge MVP candidates. The syntax elements denotes the maximum number of subblock-based merging MVP candidates. The third syntax element is The condition is, at the second coding level, Affine modes are Available do. The processing circuit is Third syntax element signalled at the second coding level Based on the above, the maximum number of sub-block based merge MVP candidates can be determined. The syntax elements is modified at a coding level lower than the second coding level. In an embodiment, the first coding level and the second coding level are sequence level and the coding level lower than the second coding level is picture level.

[0015] In an embodiment, one of the geometric merge mode, the sub-block based merge mode, and the IBC merge mode is an IBC merge mode.The maximum number of merge candidates is the maximum number of IBC merge block vector prediction (BVP) candidates. The above The syntax element indicates the maximum number of IBC merge BVP candidates. The fourth syntax element is The condition is at the second coding level IBC merge mode Available do. The processing circuit is Fourth syntax element signalled at the second coding level Based on this, the maximum number of IBC merge BVP candidates can be determined.

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

[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 description 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 the accompanying drawings. [Figure 1] FIG. 1 is a schematic diagram illustrating a current block and its surrounding spatial merge candidates in one embodiment. [Diagram 2] FIG. 2 is a schematic diagram illustrating a simplified block diagram of a communication system (200) according to one embodiment. [Diagram 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 illustrates a simplified block diagram of a decoder according to one embodiment. [Diagram 5] FIG. 5 is a schematic diagram of 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 illustrates 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 illustrates 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 an image 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 a typical syntax for an image header. [Figure 19A] FIG. 19A shows an example syntax in an SPS. [Figure 19B] FIG. 19B shows an example syntax for an image 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 PREFERRED EMBODIMENTS

[0019] FIG. 2 illustrates a simplified block diagram of a communication system (200) according to an embodiment of the present disclosure. The communication system (200) includes a plurality of terminal devices that can communicate with each other, for example, via a network (250). For example, the communication system (200) includes a first pair of terminal devices (210) and (220) interconnected via the network (250). In the example of FIG. 2, the first pair of terminal devices (210) and (220) perform a one-way transmission of data. 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 image, and display the video image according to the reconstructed video data. Unidirectional data transmission may be common, such as in media serving applications.

[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 that may occur, for example, during a video conference. For bidirectional transmission of data, for example, each of the terminal devices (230) and (240) may 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) may 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 Fig. 2, the terminal devices (210), (220), (230), and (240) may be depicted as a server, a personal computer, and a smart phone, 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 video conferencing equipment. The network (250) represents any number of networks that convey coded video data between the terminal devices (210), (220), (230), and (240), including, for example, wireline and / or wireless communication networks. The communication network (250) may exchange data in circuit-switched and / or packet-switched channels. Exemplary 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 shows an arrangement 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) that generates a stream of uncompressed video images (302), 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 a digital camera. The stream of video images (302), depicted as a thick line to emphasize the high amount of data 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 to enable or implement aspects of the disclosed subject matter, as described in more detail below. The encoded video data (304) (or encoded video bitstream (304)), depicted as a thin line to emphasize the lower amount of data when compared to the stream of video images (302), may be stored in a streaming server (305) for future use. One or more streaming client subsystems, such as client subsystems (306) and (308) of FIG. 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 a video decoder (310), for example, in 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., a receiving circuit). The video decoder (410) can be used in place of the video decoder (310) of 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 together 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 the other data. To combat network jitter, a buffer memory (415) can be coupled between the receiver (431) and the entropy decoder / parser (420) (hereafter "parser (420)"). In certain applications, the buffer memory (415) is part of the video decoder (410). In other cases, it can be outside the video decoder (410) (not shown). In yet other cases, there can be a buffer memory (not shown) outside the video decoder (410), e.g., to combat network jitter, and there can also be another buffer memory (415) inside the video decoder (410), e.g., to handle playback timing. If the receiver (431) is receiving data from a store / forward device of sufficient bandwidth and controllability or from an isochronous network, then 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 of adaptive size, and may be implemented at least in part 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 categories of symbols include information used to manage the operation of the video decoder (410) and potential information to control a rendering device such as a rendering device (412) (e.g., a display screen) that is not an integral part of the electronic device (430) but may be 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 supplemental enhancement information (SEI messages) or video usability information (VUI) parameter set fragments (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 a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder from the coded video sequence based on at least one parameter corresponding to the group. The subgroups may include groups of pictures (GOPs), pictures, 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 an entropy decoding / parsing operation on the video sequence received from the buffer memory (415) to generate symbols (421).

[0029] The reconstruction of symbols (421) may include a number of different units, depending on the type of video image or portion thereof being coded (e.g., inter-picture and intra-picture, inter-block 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) may 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 scalar / inverse transform unit (451) receives the quantized transform coefficients as symbol(s) from the parser (420), as well as control information including the transform to be used, block size, quantization factor, quantization scaling matrix, etc. The scalar / 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 scalar / 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 image intra prediction unit (452). In some cases, the image intra prediction unit (452) generates a block 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) may, for example, buffer 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 scalar / 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 the reference picture memory 457 to fetch samples used for prediction. After motion compensating the fetched samples according to the symbols (421) associated with the block, these samples may be added by the 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 the prediction samples may be controlled by a motion vector and are available to the motion compensated prediction unit (453) in the form of symbols (421) that may have, for example, X, Y, and reference picture components. Motion compensation may also include 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, 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), that can 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 can be stored in a reference image memory (457) for use in future image intra prediction.

[0036] Once a coded picture is fully reconstructed, it can be used as a reference picture for future predictions. 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 given video compression technique of a standard, such as ITU-T Rec. H.265. The 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 to a profile documented in the video compression technique or standard. In particular, a profile may select a particular tool from all tools available in the video compression technique or standard as the only tool that may be used under that profile. Also, a requirement for compliance may be that the complexity of the coded video sequence is 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 be further limited in some cases 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 that 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 pre-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 a number of individual images that, when viewed in sequence, result in 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 may easily understand the relationship between pixels and samples. The following description 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 an 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 similar manner as the (remote) decoder does (so that any compression between the symbols and the coded video bitstream is lossless in the video compression techniques considered in the disclosed subject matter). The reconstructed sample stream (sample data) is input to a reference image memory (534). Since the decoding of the symbol stream results in bit-exact results that are 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" exactly the same sample values ​​as the reference image samples that the decoder "sees" when using the prediction during decoding. This basic principle of reference image 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, with brief reference 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 techniques, except for parsing / entropy decoding, present in the decoder must also be present in substantially identical functional form in the corresponding encoder. For this reason, the disclosed subject matter focuses on the decoder operation. The description of the encoder techniques can be abbreviated as they are the opposite of the decoder techniques, which are described generically. Only in certain areas are more detailed descriptions required and are 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 the images that may be designated as reference images 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 may be decoded in a video decoder (not shown in FIG. 5), the reconstructed video sequence may be a replica of the source video sequence, typically with some errors. The local video decoder (533) repeats the decoding process performed by the video decoder on the reference images, which may result in reconstructed reference images to be stored in the reference image cache (534). In this way, the video encoder (503) may locally store copies of reconstructed reference images that have a common content as the reconstructed reference images 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 certain metadata, such as reference image motion vectors, block shapes, or sample data (as candidates for 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 a suitable prediction reference. 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] All outputs 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, arithmetic coding, etc.

[0051] The transmitter (540) may buffer the coded video sequence produced by the entropy coder (545) and prepare it for transmission over a communication channel (560), which may be a hardware / software link to a storage device that may store the encoded video data. The transmitter (540) may 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 a sequence as prediction sources. Some video codecs allow 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 one that can 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 more than one reference picture and associated metadata for the reconstruction of a block.

[0056] A source image is usually spatially divided into several sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each) and coded block by block. Blocks can be predictively coded with reference to other (already coded) blocks determined by the coding assignment applied to the respective image of the block. For example, blocks of an I image can be non-predictively coded or they can be predictively coded with reference to already coded blocks of the same image (spatial prediction or inter prediction). Pixel blocks of a P image can be predictively coded via spatial or temporal prediction with reference to one previously coded reference image. Blocks of a B image can 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 in accordance with a given video coding technique or standard, such as ITU-T Rec. H.265. In its operations, 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 / SNR enhancement layers and other types of redundant data, such as redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

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

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

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

[0062] According to some embodiments of the present disclosure, predictions such as inter-image prediction and intra-image prediction are performed on a block-by-block basis. 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. In general, 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 CTU of 64×64 pixels 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 a 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. In general, 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. Taking 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 of sample values ​​(e.g., a predictive block) in a current video image in a video image sequence and to 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 a prediction block of 8×8 samples. The video encoder (603) determines whether the processing block is best coded using intra mode, inter mode, or bi-prediction mode, for example 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 motion vector components applicable to the subject block, which are inter image prediction submodes where the motion vector is derived from one or more motion vector predictors without the benefit of coding motion vector components 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 FIG. 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 FIG.

[0066] The inter-encoder (630) is configured to receive samples of a current block (e.g., a processing block), compare the block to 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 an inter-encoding technique, motion vectors, merge mode information), and calculate an inter-prediction result (e.g., a prediction 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), possibly compare the block to previously coded blocks in the same image, generate transformed and quantized coefficients, and possibly also 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., prediction 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 an intra mode, the general controller (621) controls the switch (626) to select an intra mode result for the residual calculator (623) and controls the entry peer coder (625) to select prior decoding information and include the prior decoding information in the bitstream; and when the mode is an inter mode, the general controller (621) controls the switch (626) to select an inter prediction result for the residual calculator (623) and controls the entry peer coder (625) to select 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 the 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 the inter-encoder (630) as appropriate. For example, the inter-encoder (630) can generate decoded blocks based on the decoded residual data and the inter-prediction information, and the intra-encoder (622) can generate decoded blocks based on the decoded residual data and the intra-prediction information. The decoded blocks, in some embodiments, are suitably processed to generate a decoded image, which may be buffered in a memory circuit (not shown) and used as a reference image.

[0070] The entropy encoder (625) is configured to format the bitstream to include the encoded block. The entropy encoder (625) is configured to include various information according to 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. It should be noted that when coding a block in a merged sub-mode of either the inter mode or the 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), coupled together as shown in FIG.

[0073] The entropy decoder (771) may be configured to reconstruct, from the coded picture, certain symbols that represent syntax elements of which the coded picture is made up. Such symbols may include, for example, the mode in which the block is coded (e.g., intra mode, inter mode, bi-predictive mode, inter mode in merged or another submode, bi-predictive mode, etc.), prediction information (e.g., intra prediction information or inter prediction information), which may identify certain samples or metadata, such as residual information in the form of quantized transform coefficients, to be used by the intra decoder (722) or the inter decoder (780), respectively. In an embodiment, when the prediction mode is an inter or bi-predictive 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 may undergo inverse quantization and is provided to the residual decoder (773).

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

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

[0076] The residual decoder (773) is configured to perform inverse quantization to extract de-quantized transform coefficients and process the de-quantized transform coefficients to convert the residual from the frequency domain to the spatial domain. The residual decoder (773) may also require certain control information (to include Quantizer Parameters (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 a 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. It should be noted that other suitable 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, 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. FIG. 8 illustrates an exemplary geometric merge mode. In the geometric merge mode, the CU (800) can be partitioned into two partitions, and partitions 1-2 can be partitioned by a line or edge (810). Each of the two partitions can have any suitable shape, such as a triangle, a trapezoid, a pentagon, etc.

[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 side. The four merge candidate lists can include a merge candidate list (or a first merge candidate) for a regular merge mode, a merge candidate list (or a second merge candidate) for a geometric merge mode, a merge candidate list (or a third merge candidate) for a sub-block-based merge mode, and a merge candidate list (or a fourth merge candidate) for an IBC merge mode.

[0082] Compared with related techniques (such as certain techniques in HEVC), the first merge candidate list for the regular merge mode can be extended to include more kinds 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 extended, for example, from 5 to 6. The maximum number of merge MVP candidates in the first merge candidate list can be signaled in the picture parameter set (PPS) at the PPS level or in the picture header at the picture level.

[0083] Figure 9 shows a 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 a 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_6_minus_max_num_merge_cand_plus1) is equal to 0, it can be specified that the first picture level parameter (e.g., pic_6_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_6_minus_max_num_merge_cand_plus1) is greater than 0, it can be specified that the first picture level parameter (e.g., pic_6_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_6_minus_max_num_merge_cand_plus1) can be in the range of 0 to 6. If the first PPS level parameter (eg, pps_6_minus_max_num_merge_cand_plus1) is not present, then the first PPS level parameter (eg, pps_6_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 the 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_6_minus_max_num_merge_cand) can be inferred to be equal to the first PPS level parameter (e.g., pps_6_minus_max_num_merge_cand_plus1)-1.

[0088] The geometric merge mode can be enabled or disabled at the sequence level using the 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 such 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 image level.

[0091] Figure 12 shows an example syntax signaled in the PPS. The syntax includes a second PPS level parameter (e.g., pps_max_num_merge_cand_minus_max_num_geo_cand_plus1) indicating the maximum number of geometric merge mode merge candidates. Figure 13 shows an example syntax signaled in the picture header. The syntax includes a second picture level parameter (e.g., pic_max_num_merge_cand_minus_max_num_geo_cand) indicating 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] If the second PPS level parameter (e.g., pps_max_num_merge_cand_minus_max_num_geo_cand_plus1) is equal to 0, it may 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. If the second PPS level parameter (e.g., pps_max_num_merge_cand_minus_max_num_geo_cand_plus1) is greater than 0, it may 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) may 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, then 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 for a slice associated with the picture header, subtracted from the maximum number of merge MVP candidates (MaxNumMergeCand).

[0095] If the second picture level parameter is not present, then 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_ge_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 image 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 (i.e., signaled), the value of MaxNumGeoMergeCand can range from 2 to MaxNumMergeCand.

[0098] If the second image 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] Geometric Merge Mode If the maximum number of merge candidates (MaxNumGeoMergeCand) is 0, then geometric merge mode is not allowed for the slice associated with the image header.

[0100] The second PPS level parameters (e.g., pps_max_num_merge_cand_minus_max_num_ge_cand_plus1), the second image level parameters (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 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 image. On the other hand, if MaxNumGeoMergeCand changes frequently from image to image, image header signaling is effective.

[0101] 14 illustrates an example syntax signaled in the picture header, which includes a third picture level parameter (e.g., pic_5_minus_max_num_subblock_merge_cand) signaled in the picture header indicating 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_5_5_minus_max_num_subblock_merge_cand) may specify the maximum number of subblock-based merge MVP candidates supported in a slice, subtracted from a 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_5_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 illustrates an example syntax signaled in the picture header, which includes a fourth picture level parameter (e.g., pic_6_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_6_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_6_minus_max_num_ibc_merge_cand), e.g., 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 mentioned above, the first syntax element may indicate the maximum number of merged 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 merged MVP candidate list for the regular merge mode. The MVP candidate list may include MVP candidates for the regular merge mode. For example, 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.

[0111] The second syntax element may indicate a 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 a length of a 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 refer to 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 a maximum number of sub-block based merge MVP candidates at a corresponding coding level (e.g., a coding level higher than slice level or picture level), and thus the third syntax element may indicate a length of the sub-block based merge MVP candidate list for the sub-block based merging mode. The sub-block based merge MVP candidate list may include the sub-block based merge MVP candidates for the sub-block based merging mode. For example, the third syntax element may refer to a third picture level parameter that is 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 the 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 in 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 can be any suitable coding level, e.g., a level higher than a slice level. In an embodiment. The first coding level is higher than a PPS level. The maximum number of merge MVP candidates can be determined based on the first syntax element, e.g., based on Equation (5). Then, reconstruct coding blocks associated with the first coding level based at least on the maximum number of merge MVP candidates. In an embodiment, the first coding level is a sequence level, and the first syntax element is signaled in the SP. When the first coding level increases from a lower coding level (e.g., a PPS level) to a higher coding level (e.g., a 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 an embodiment, the first coding level is higher than a slice level or a picture level. In an embodiment, the first coding level is higher than a PPS level. The one or more syntax elements may include a first syntax element.

[0116] In one embodiment, the one or more syntax elements include a first syntax element, a second syntax element, a third syntax element, and a fourth syntax element, and are signaled in the SPS at a sequence level. In an embodiment, the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element are 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, are unchanged at the sequence level, and signaling certain syntax elements at the sequence level instead of at a lower coding level (e.g., PPS level, picture level, or 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 can be 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 illustrates 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 a 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), e.g., 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] The 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 (eg, 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] A third syntax element (eg, 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, 5_minus_max_num_subblock_merge_cand), eg, 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), e.g., 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, the syntax elements including the first syntax element, the second syntax element, the third syntax element, and the fourth syntax element are signaled in a PPS. In this way, 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 the first PPS to the 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 case of regular merge mode) is to be signaled, and the remaining syntax elements related to the lengths of the 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. Thus, an enable flag for a particular inter-coding tool may be used to control the signaling of the 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 a geometric merge mode. The maximum number of merge candidates is a maximum number of geometric merge mode merge candidates. The favorable / disfavorable factor is a second syntax element indicating a maximum number of geometric merge mode merge candidates. Referring to box (1712) of FIG. 17, the conditions are a geometric merge mode available in the second coding level and the maximum number of the merge MVP candidates being 3 or more. Based on the second syntax element, the maximum number of geometric merge mode merge candidates can be determined.

[0133] In an embodiment, the 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 syntax element is a third syntax element indicating a maximum number of sub-block based merge MVP candidates. Referring to box (1710) of FIG. 17, the condition is an affine mode that is enabled 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. The syntax element may be a fourth syntax element indicating the maximum number of IBC merge BVP candidates. Referring to box (1711) of 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), e.g., based on Equation (5). The value of MaxNumMergeCand can be specified in the range of 1 to 6.

[0137] 17, a second syntax element (e.g., max_num_merge_cand_minus_num_ge_cand) may be signaled if 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] The 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 true: 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, then a third syntax element (eg, five_minus_max_num_subblock_merge_cand) may 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) may specify the maximum number of subblock-based merge MVP candidates supported by the 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) may 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) may 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), e.g., using equation (8).

[0149] If the fourth syntax element (eg, six_minus_max_num_ibc_merge_cand) is not present, then 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 FIG. 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 the 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 way, a particular syntax element can be signaled at a first coding level (e.g., a higher coding level) instead of 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) can change at the first coding level and thus can 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 a sequence level, and the third syntax element changes within a sequence and does not change within a picture, and thus is signaled at a 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), e.g., a third syntax element indicating the length of a sub-block based merge MVP candidate list, may be signaled at a second coding level lower than the first coding level. In an embodiment, the first coding level is a sequence level and the second coding level is a PPS level, a picture level, or a 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. The other syntax element(s) indicating the length(s) of the other merge candidate list(s) are signaled at a level lower than the sequence level (e.g., at 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, e.g., 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, the first syntax element indicating the length of the merged MVP candidate list remains unchanged (e.g., cannot be updated, overridden, or modified) at coding levels lower than the first coding level. The second and fourth syntax elements conditionally signaled at the 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 the syntax element(s) indicating the length(s) of the other merge candidate list(s) excluding any of the merged MVP candidate list, the geometric merge mode merge candidate list, and the IBC merge candidate list may be updated, overridden, or modified at coding levels lower than the second coding level. In an embodiment, the third syntax element conditionally signaled at the second coding level is modified at a coding level lower than the second coding level. For example, the third syntax element conditionally signaled at the second coding level (e.g., 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, may be updated, overridden or modified at a coding level (eg, picture level) lower than the first coding level (sequence level).

[0159] FIG. 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. FIG. 19A-19B shows 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 FIG. 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 do not change at the sequence level, and the third syntax element (e.g., five_minus_max_num_subblock_merge_cand) can be changed from one picture to another.

[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 an aspect 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., sequence level), e.g., higher than a slice level or a 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., PPS level, picture level, slice level, etc.) lower than the first coding level (e.g., 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 with 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 changed at a coding level lower than the PPS level (e.g., picture level, 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 associated with the lengths of the various merge candidate lists.

[0165] In an embodiment, as shown by box (2010) in FIG. 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., 6_minus_max_ibc_merge_cand_present flag) is used to further indicate whether the fourth syntax element is present or not, as shown in FIG. 20. Thus, the presence of the fourth syntax element is conditionally determined based on the syntax element (e.g., 6_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., 6_minus_max_num_ibc_merge_cand_present flag) and the third sequence level flag (e.g., sps_ibc_enabled_flag). The above description can be appropriately adapted to signaling of other syntax elements, such as the second syntax element, the third syntax element, and / or similar.

[0166] 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 subblock-based merge MVP candidates (MaxNumSubblockMergeCand) may be determined based on Equation (5), as described above. The value of MaxNumMergeCand may be specified in the range of 1 to 6.

[0167] The 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) may 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 range from 2 to MaxNumMergeCand.

[0170] If max_num_merge_cand_minus_max_num_geo_cand is not present, and if 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) may 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 IBCs to merge BVP candidates into. 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) may 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) may be determined using equation (8).

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

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

[0179] FIG. 21 shows a flow chart 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, a maximum number of IBC merge BVP candidates, etc. In various embodiments, the process (2100) is performed by a processing circuit such as the processing circuit of the terminal device (210), (220), (230), and (240), a processing circuit performing the function of the video encoder (303), a processing circuit performing the function of the video decoder (310), a processing circuit performing the function of the video decoder (410), a processing circuit performing the function of the video encoder (503), etc. In some embodiments, the process (2100) is implemented in software instructions, and thus the processing circuit performs the process (2100) when the processing circuit executes the software instructions. The process starts at (S2101) and proceeds to (S2110).

[0180] At (S2110), a first syntax element signaled at a first coding level can be decoded from the 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 may be determined based on the first syntax element.

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

[0183] The method 2100 may be adapted as appropriate. Steps of the process 2100 may be modified and / or omitted. Additional step(s) may be added. Any suitable order of performance may 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, based on the second syntax element, the maximum number of geometric merge mode merge candidates may be determined, based on the third syntax element, the maximum number of sub-block based merge MVP candidates may be determined, and based on the fourth syntax element, the maximum number of IBC merge BVP candidates may be determined.

[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 embodiment, 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 can be 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 produce 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, etc.

[0189] 17 for computer system (2200) are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing the 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 be responsive to input by one or more human users, for example, via tactile input (e.g., keystrokes, swiping, 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 are not necessarily directly related to 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 touch screen (2210), a data glove (not shown), a joystick (2205), a microphone (2206), a scanner (2207), 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 haptic output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen (2210), data gloves (not shown), or joystick (2205), which may also be haptic feedback devices that do not act 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, OLED screens, each with or without haptic feedback capabilities, each with or without haptic feedback capabilities, some of which may allow two-dimensional visual output or three- or more-dimensional output via such means as stereoscopic output, such as virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0193] The computer system (2200) can also include human accessible storage devices and their accessible media, such as an optical media drive (2220) including a CD / DVD ROM / RW with media (2221) such as CD / DVD, a USB memory (2222), a removable head drive or solid state drive (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 communication networks. The networks may be, for example, wireless, wired, optical. The networks may further be local, wide area, metropolitan, vehicular and industrial, real-time, delay tolerant, etc. Examples of networks include Ethernet, WLAN, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., cable TV, satellite TV, and terrestrial broadcast TV, industrial and vehicular including CANBus. Certain networks require external network interface adapters connected to certain 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 may be unidirectional, receive only (e.g., broadcast television), unidirectional transmit only (e.g., a CAN bus to a particular CAN bus device), or bidirectional, for example to other computer systems using local or wide area digital networks. Specific protocols and protocol stacks may be used in each of these networks and network interfaces, as described above.

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

[0197] The cores (2240) may include one or more central processing devices (CPUs) (2241), graphics processing devices (GPUs) (2242), specialized programmable processing devices in the form of field programmable gate areas (FPGAs) (2243), hardware accelerators (2244) for specific tasks, etc. These devices may be connected via a system bus (2248), along with read only memory (ROM) (2245), random access memory (2246), internal mass storage devices such as internal non-user accessible hard drives, SSDs, etc. (2247). 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 be connected directly to the core's system bus (2248) or via a peripheral bus (2249). Peripheral bus architectures include PCI, USB, etc.

[0198] The CPU (2241), GPU (2242), FPGA (2243), and accelerator (2244) may combine to execute certain instructions that may constitute the computer code described above. The computer code may be stored in a ROM (2245) or a RAM (2246). Transient data may also be stored in the RAM (2246), while permanent data may be stored, for example, in an internal mass storage device (2247). Fast storage and retrieval in any of the memory devices may be enabled through the use of 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.

[0199] The computer-readable media 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 that is well known and available to those with skill in the computer software art.

[0200] As an example, and not by way of limitation, a computer system having the architecture (2200), and in particular 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 a specific storage device of the core (2240) that is 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 the particular needs. The software may cause the core (2240) and in particular the processor therein (including a CPU, GPU, FPGA, etc.) 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 Exploration 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 the 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 thus are within its concept and scope.

Claims

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 merged motion vector prediction candidates (merged MVP candidates), the first coding level being higher than a picture parameter set (PPS) level and being a sequence level, the first syntax element being signaled in a sequence parameter set (SPS); determining a maximum number of the merge MVP candidates based on the decoded first syntax element; reconstructing coding blocks associated with the first coding level based at least on the determined maximum number of merge MVP candidates; decoding, from the coded video bitstream, a fourth syntax element, a third syntax element, and a second syntax element signaled at the first coding level, where 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) merged block vector prediction (BVP) candidates (IBC merge BVP candidates); (i) determining a maximum number of the geometric merge mode merge candidates based on the second syntax element; (ii) determining a maximum number of the sub-block based merging MVP candidates based on the third syntax element; and (iii) determining a maximum number of the IBC merge BVP candidates based on the fourth syntax element; determining Including, determining, from the coded video bitstream, a syntax element signaled at a second coding level based on a condition being satisfied, the 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 merge mode (IBC merge mode); Including, 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 a maximum number of the geometric merge mode merge candidates; the condition is that the geometric merge mode is available at the second coding level, and the maximum number of merge MVP candidates is equal to or greater than three; The method further comprises: determining the maximum number of geometric merge mode merge candidates based on a second syntax element signaled in the second coding level; if there is no second syntax element signaled in the first coding level, and if a first sequence level flag is equal to 1 and the maximum number of merge MVP candidates is equal to 2, then the maximum number of geometric merge mode merge candidates is set to 2. method.

2. 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 syntax element is a third syntax element indicating a maximum number of the sub-block based merge MVP candidates; the condition being that an affine mode is available in the second coding level; The method further comprises: determining the maximum number of sub-block based merging MVP candidates based on a third syntax element signaled in the second coding level; The method of claim 1 , comprising:

3. 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 syntax element is a fourth syntax element indicating a maximum number of the IBC merge BVP candidates, the condition being that the IBC merge mode is available in the second coding level; The method further comprises: The method of claim 1 , further comprising determining the maximum number of IBC-merged BVP candidates based on a fourth syntax element signaled in the second coding level.

4. the second coding level is a sequence level; The method of claim 1.

5. The syntax element is changed at a coding level lower than the second coding level. The method of claim 2.

6. 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 of claim 5.

7. 1. An apparatus for video decoding, comprising: A processing circuit is provided, the processing circuit comprising: Implementing the method according to any one of claims 1 to 6 It is configured as follows: Device.

8. 1. A program including instructions that, when executed by a computer, cause the computer to:

7. Carrying out the method according to any one of claims 1 to 6, program.

Citation Information

Patent Citations

  • Method of Intra Picture Block Copy for Screen Content and Video Coding

    US20170280159A1

  • Method and apparatus for video coding

    US20190335200A1

  • Image encoding method, image encoding device, image decoding method, image decoding device, and image encoding / decoding device

    WO2013051209A1

  • An improved merge candidate list construction method for intra block copy

    WO2015180014A1