Method and apparatus of harmonizing weighted prediction with non-rectangular merge mode

Abstract

To provide a coding method and apparatus of harmonizing weighted prediction with a non-rectangular merge mode.SOLUTION: A coding method includes: obtaining a bitstream for a current picture; obtaining a value of a first indicator for the current picture according to the bitstream indicating a slice type; obtaining a value of a second indicator for the current picture according to the bitstream indicating whether a weighted prediction parameter is present in a picture header or slice header of the bitstream; parsing a value of the weighted prediction parameter for a current block of a current slice of the current picture from the bitstream, when the value of the first indicator is equal to a first preset value and the value of the second indicator is equal to a second preset value; and predicting the current block according to the value of the weighted prediction parameter.SELECTED DRAWING: Figure 15

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application claims priority to US62 / 960,134, filed January 12, 2020. The disclosures of the above-mentioned patent applications are incorporated herein by reference in their entireties.

[0002] TECHNICAL FIELD Embodiments of the present application relate generally to the field of video processing, and more particularly to non-rectangular partitioning modes when used in combination with weighted prediction for coding fade. [Background technology]

[0003] Video coding (video encoding and video decoding) is used in a wide range of digital video applications, such as broadcast digital TV, video transmission over the Internet and mobile networks, real-time interactive applications such as video chat, video conferencing, DVDs and Blu-ray® discs, video content collection and editing systems, and camcorders for security applications.

[0004] The amount of video data required to render even a relatively short video can be substantial, which can pose difficulties when the data is to be streamed or otherwise communicated across communication networks with limited bandwidth capacity. Thus, video data is generally compressed before being communicated across modern telecommunication networks. The size of the video can also be an issue when the video is stored on a storage device, since memory resources may be limited. Video compression devices often use software and / or hardware at the source to code the video data prior to transmission or storage, thereby reducing the amount of data required to represent a digital video image. The compressed data is then received at the destination by a video decompression device, which decodes the video data. With limited network resources and an ever-increasing demand for higher video quality, improved compression and decompression techniques are desirable that improve compression ratios with little sacrifice in picture quality.

[0005] In particular, for coding images exhibiting illumination changes, weighted prediction may be advantageously used for motion compensation in the context of inter prediction. Non-rectangular partitions as triangular partition / merge mode (TPM) and geometric motion / merge partition (GEO) may be employed to address various kinds of motion in a way that may be superior to inter prediction constrained to rectangular partitions. However, some harmonization is required for a codec that allows both weighted prediction and non-rectangular partitions. Summary of the Invention [Means for solving the problem]

[0006] An embodiment provides a method for coding a video sequence using weighted prediction parameters that are combined from fading weighting parameters and blending weighting parameters, the value of which is determined by a reference index value and a reference picture list, while the blending weighting parameters are determined by the position of a prediction sample within a prediction block.

[0007] These and other objects are achieved by the subject matter of the independent claims. Further implementations, which may be combined with one another, are evident from the dependent claims, the description and the drawings.

[0008] According to a first aspect, there is provided a method of coding, the method being performed by a decoding device, comprising: obtaining a bitstream for a current picture (e.g., of an encoded video sequence); obtaining a value of a first indicator for a current picture according to a bitstream (e.g., by parsing each syntax element provided in the bitstream), the first indicator indicating a slice type (of a slice of the current picture); obtaining a value of a second indicator for a current picture according to the bitstream (e.g., by parsing a respective syntax element provided in the bitstream), the second indicator indicating whether the weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream; parsing a value of a weighted prediction parameter for a current block from the bitstream when the value of the first indicator is equal to a first preset value (e.g., 1) and the value of the second indicator is equal to a second preset value (e.g., 2), where the current block is comprised in a current slice of a current picture, the first preset value is an integer value, and the second preset value is an integer value; and predicting the current block (generating a predicted block for the current block) according to values ​​of the weighted prediction parameters.

[0009] Therefore, based on the value of the second indicator valid for the entire current picture, it can be determined whether inter prediction will be performed for the current block of the current slice using weighted prediction with the value of the weighted prediction parameter parsed (only) for the specific slice type indicated by the value of the first indicator, and when the second indicator indicates that the weighted prediction parameter is present in the picture header. Signaling at a relatively high level, i.e., at the picture header level, allows a clear decision as to whether weighted prediction will be used for blocks (particularly, all blocks) of slices (particularly, all slices) of the current picture. If weighted prediction will be used, any non-rectangular partitions may not be allowed.

[0010] According to one implementation, the value of the first indicator is obtained according to (e.g., parsed from) a picture header provided in the bitstream. According to another implementation, the value of the second indicator is obtained according to (e.g., parsed from) a picture parameter set provided in the bitstream, and according to yet another implementation, the value of the weighted prediction parameter is parsed from a picture header provided in the bitstream. Thus, all of the relevant values ​​under consideration (or syntax elements having these values) can be obtained based on a relatively high level of signaling (i.e., in the picture header or picture parameter set). This provides efficient signaling related to the adoption of weighted inter prediction.

[0011] According to one implementation, the value of the first indicator being equal to the first preset value indicates that the slice type of at least one slice included in the current picture is an inter slice, for example, comprises a B slice or a P slice, or is a B slice or a P slice.

[0012] According to a second aspect, there is provided a method of coding, the method being performed by a decoding device, comprising: obtaining a bitstream for a current picture (e.g., of an encoded video sequence); obtaining a value of a first indicator for a current picture according to a bitstream (e.g., by parsing each syntax element provided in the bitstream), the first indicator indicating a slice type (of a slice of the current picture); obtaining a value of a second indicator for a current picture according to the bitstream (e.g., by parsing a respective syntax element provided in the bitstream), the second indicator indicating whether the weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream; Obtaining a value of a third indicator for the current picture according to the bitstream (e.g., by parsing a respective syntax element provided in the bitstream), where the third indicator indicates whether weighted prediction is applicable to an inter slice, and a slice type of the inter slice is a B slice or a P slice; parsing a value of a weighted prediction parameter for a current block from the bitstream when the value of the first indicator is equal to a first preset value (e.g., 1), the value of the second indicator is equal to a second preset value (e.g., 1), and the value of the third indicator indicates that weighted prediction is applicable to inter-slice, where the current block is comprised in a current slice of a current picture, the first preset value is an integer value, and the second preset value is an integer value; and predicting the current block (generating a predicted block for the current block) according to values ​​of the weighted prediction parameters.

[0013] According to alternative implementation forms (which may be combined with each other) of the method according to the second aspect, the value of the first indicator is obtained according to a picture header provided in the bitstream (e.g., parsed from the picture header), or the value of the second indicator is obtained according to a picture parameter set provided in the bitstream (e.g., parsed from the picture parameter set), or the value of the weighted prediction parameter is obtained according to a picture header provided in the bitstream, or the value of the third indicator is obtained according to a picture parameter set provided in the bitstream (e.g., parsed from the picture parameter set).

[0014] According to one implementation form of the method relating to the second aspect, a value of the first indicator equal to the first preset value indicates that the slice type of at least one slice included in the current picture is an inter slice, for example, comprises a B slice or a P slice, or is a B slice or a P slice.

[0015] According to one implementation form of the method according to the second aspect, a value of 1 of the third indicator indicates that weighted prediction is applicable to inter slices.

[0016] The method according to the second aspect and its implementations provides similar or the same advantages as the method according to the first aspect and its implementations.

[0017] Further provided is a decoder comprising processing circuitry for performing a method according to any one of the embodiments described above, and a computer program product comprising program code for performing a method according to any one of the embodiments described above, when executed on a computer or processor.

[0018] Further provided is a decoder comprising one or more processors and a non-transitory computer readable storage medium coupled to the processors and storing programming for execution by the processors, the programming, when executed by the processors, configuring the decoder to perform a method according to any one of the embodiments described above, and the non-transitory computer readable medium carrying program code, when executed by a computing device, causing the computing device to perform the method according to any one of the embodiments described above.

[0019] Furthermore, according to another aspect, there is provided a non-transitory storage medium comprising a bitstream coded according to the method of any one of the above described embodiments.

[0020] According to a further aspect, an encoded bitstream for a video signal is provided, the bitstream comprising a first indicator for the current picture indicating a slice type (of a slice of a current picture) and a second indicator for the current picture indicating whether weighted prediction parameters are present in a picture header or a slice header of the bitstream. The bitstream further comprises weighted prediction parameters for a current block, particularly when a value of the second indicator is equal to a second preset value (e.g., 2), the current block is comprised in a current slice of the current picture, and the second preset value is an integer value.

[0021] According to one implementation, the first indicator is provided in a picture header and / or the second indicator is provided in a picture parameter set and / or the weighted prediction parameters are provided in a picture header provided in the bitstream.

[0022] According to one implementation, the value of the first indicator being equal to the first preset value indicates that the slice type of at least one slice included in the current picture is an inter slice, for example, comprises a B slice or a P slice, or is a B slice or a P slice.

[0023] According to a further aspect, an encoded bitstream for a video signal is provided, the bitstream comprising a first indicator for the current picture indicating a slice type (of a slice of a current picture), a second indicator for the current picture indicating whether weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream, and a third indicator for the current picture indicating whether weighted prediction is applicable to an inter slice, the slice type of the inter slice being a B slice or a P slice. The bitstream further comprises the weighted prediction parameters, particularly when the value of the second indicator is equal to a second preset value (e.g., 1), the current block is comprised in a current slice of the current picture, and the second preset value is an integer value.

[0024] According to alternative implementations, the first indicator is provided in the picture header, and / or the second indicator is provided in a picture parameter set, and / or the weighted prediction parameters are provided in the picture header, and / or the third indicator is provided in a picture parameter set provided in the bitstream.

[0025] According to one implementation, a value of the first indicator equal to the first preset value indicates that the slice type of at least one slice included in the current picture is an inter slice, e.g., comprises or is a B slice or a P slice, and / or a value of the third indicator of 1 indicates that weighted prediction is applicable to inter slices.

[0026] According to yet another aspect, a non-transitory storage medium is provided that includes an encoded bitstream that is decoded (or to be decoded) by an image decoding device, the bitstream being generated by dividing a frame of a video or image signal into a plurality of blocks, and including a first indicator for the current picture indicating a slice type (of a slice of the current picture), and a second indicator for the current picture indicating whether weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream. The bitstream further includes weighted prediction parameters for a current block, particularly when the value of the second indicator is equal to a second preset value (e.g., 2), the current block is included in a current slice of the current picture, and the second preset value is an integer value.

[0027] According to one implementation, the first indicator is provided in a picture header and / or the second indicator is provided in a picture parameter set and / or the weighted prediction parameters are provided in a picture header provided in the bitstream.

[0028] According to one implementation, the value of the first indicator being equal to the first preset value indicates that the slice type of at least one slice included in the current picture is an inter slice, for example, comprises a B slice or a P slice, or is a B slice or a P slice.

[0029] Further, according to another aspect, a non-transitory storage medium is provided that includes an encoded bitstream that is decoded (or to be decoded) by an image decoding device, the bitstream being generated by dividing a frame of a video signal or an image signal into a plurality of blocks, and including a first indicator for the current picture indicating a slice type (of a slice of a current picture), a second indicator for the current picture indicating whether weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream, and a third indicator for the current picture indicating whether weighted prediction is applicable to an inter slice, the slice type of the inter slice being a B slice or a P slice. The bitstream further includes the weighted prediction parameters, particularly when the value of the second indicator is equal to a second preset value (e.g., 1), the current block is included in a current slice of the current picture, and the second preset value is an integer value.

[0030] According to alternative implementations, the first indicator is provided in the picture header, and / or the second indicator is provided in a picture parameter set, and / or the weighted prediction parameters are provided in the picture header, and / or the third indicator is provided in a picture parameter set provided in the bitstream.

[0031] According to one implementation, a value of the first indicator equal to the first preset value indicates that the slice type of at least one slice included in the current picture is an inter slice, e.g., comprises or is a B slice or a P slice, and / or a value of the third indicator of 1 indicates that weighted prediction is applicable to inter slices.

[0032] All of the above described methods may be implemented in the decoding devices described below, which may be configured to carry out the procedural steps of the respective methods with the same advantages as described above. The following devices are provided:

[0033] A decoding device (configured to decode an encoded video sequence), comprising: a bitstream acquisition unit configured to acquire a bitstream for a current picture; a) obtaining a value of a first indicator for a current picture according to a bitstream, the first indicator indicating a slice type; and b) obtaining a value of a second indicator for the current picture according to the bitstream, the second indicator indicating whether the weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream; An indicator value acquisition unit; a parsing unit configured to parse a value of a weighted prediction parameter for a current block from the bitstream when the value of the first indicator is equal to a first preset value (e.g., 1) and the value of the second indicator is equal to a second preset value (e.g., 1), where the current block is comprised in a current slice of a current picture, the first preset value is an integer value, and the second preset value is an integer value; a prediction unit configured to predict a current block according to values ​​of the weighted prediction parameters.

[0034] In this decoding device, the indicator value obtaining unit may be configured to obtain a value of the first indicator according to a picture header provided in the bitstream or a value of the second indicator according to a picture parameter set provided in the bitstream, or the parsing unit may be configured to parse a value of the weighted prediction parameter from a picture header provided in the bitstream.

[0035] The value of the first indicator being equal to the first preset value may indicate that the slice type of at least one slice included in the current picture is inter slice, for example, comprises a B slice or a P slice, or is a B slice or a P slice.

[0036] Further, a decoding device (configured to decode the encoded video sequence) is provided, the decoding device comprising: a bitstream acquisition unit configured to acquire a bitstream for a current picture; a) obtaining a value of a first indicator for a current picture according to a bitstream, the first indicator indicating a slice type; b) obtaining a value of a second indicator for a current picture according to the bitstream, the second indicator indicating whether the weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream; and c) obtaining a value of a third indicator for the current picture according to the bitstream, the third indicator indicating whether weighted prediction is applicable to an inter slice, and a slice type of the inter slice is a B slice or a P slice; An indicator value acquisition unit; a parsing unit configured to parse a value of a weighted prediction parameter for a current block from the bitstream when the value of the first indicator is equal to a first preset value (e.g., 1), the value of the second indicator is equal to a second preset value (e.g., 1), and the value of the third indicator indicates that weighted prediction is applicable to inter-slice, where the current block is comprised in a current slice of a current picture, the first preset value is an integer value, and the second preset value is an integer value; a prediction unit configured to predict a current block according to values ​​of the weighted prediction parameters.

[0037] In this decoding device, the indicator value obtaining unit may be configured to obtain a value of the first indicator according to a picture header provided in the bitstream, or a value of the second indicator according to a picture parameter set provided in the bitstream, or a value of the third indicator according to a picture parameter set provided in the bitstream, or the parsing unit may be configured to parse the weighted prediction parameters from a picture header provided in the bitstream.

[0038] Again, a value of the first indicator equal to the first preset value may indicate that the slice type of at least one slice included in the current picture is inter-slice, e.g., comprises or is a B slice or a P slice.

[0039] A value of 1 for the third indicator may indicate that weighted prediction is applicable to inter slices.

[0040] The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will become apparent from the description, drawings, and claims.

[0041] In the following, embodiments of the invention will be explained in more detail with reference to the accompanying figures and drawings. [Brief description of the drawings]

[0042] [Figure 1A] 1 is a block diagram illustrating an example of a video coding system configured to implement embodiments of the present invention. [Figure 1B] 2 is a block diagram illustrating another example of a video coding system configured to implement embodiments of the present invention. [Diagram 2] FIG. 1 is a block diagram illustrating an example of a video encoder configured to implement embodiments of the present invention. [Diagram 3] 2 is a block diagram illustrating an exemplary structure of a video decoder configured to implement embodiments of the present invention. [Figure 4] FIG. 1 is a block diagram showing an example of an encoding device or a decoding device. [Diagram 5] FIG. 13 is a block diagram showing another example of an encoding device or a decoding device. [Figure 6] 13 is a flow chart for weighted prediction encoder side decision making and parameter estimation. [Figure 7] FIG. 13 is a diagram illustrating an example of a triangular prediction mode. [Figure 8] FIG. 13 is a diagram illustrating an example of a geometric prediction mode. [Figure 9] FIG. 13 is a diagram illustrating another example of a geometric prediction mode. [Figure 10] 31 is a block diagram showing an exemplary structure of a content delivery system 3100 for implementing a content distribution service. [Figure 11] FIG. 2 is a block diagram illustrating the structure of an example of a terminal device. [Figure 12] FIG. 2 is a block diagram illustrating an example of an inter-prediction method according to the present application. [Figure 13] FIG. 2 is a block diagram illustrating an example of an apparatus for inter prediction according to the present application. [Figure 14] FIG. 2 is a block diagram illustrating another example of an apparatus for inter prediction according to the present application. [Figure 15] 4 is a flow chart illustrating a method of coding according to an embodiment. [Figure 16a] 4 is a flow chart illustrating a method of coding according to another embodiment; [Figure 16b] 4 is a flow chart illustrating a method of coding according to another embodiment; [Figure 17] FIG. 2 illustrates a decoding device according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] In the following, identical reference signs refer to identical or at least functionally equivalent features, unless expressly specified otherwise.

[0044] In the following description, reference is made to the accompanying figures, which form a part of this disclosure and which show, by way of example, certain aspects of embodiments of the invention or in which embodiments of the invention may be used. It is understood that embodiments of the invention may be used in other ways and may have structural or logical changes not shown in the figures. Therefore, the following detailed description should not be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.

[0045] For example, it is understood that disclosure regarding a described method may also apply to a corresponding device or system configured to perform the method, and vice versa. For example, when one or more particular method steps are described, the corresponding device may include one or more units (e.g., one unit performing one or more steps, or multiple units each performing one or more of the multiple steps), e.g., functional units, for performing the described one or more method steps, even if such one or more units are not explicitly described or shown in the figures. On the other hand, when, for example, a particular apparatus is described based on one or more units, e.g., functional units, the corresponding method may include one step (e.g., one step performing the function of one or more units, or multiple steps each performing one or more functions of multiple units) for performing the function of one or more units, even if such one or more steps are not explicitly described or shown in the figures. Furthermore, it is understood that features of various exemplary embodiments and / or aspects described herein may be combined with each other, unless specifically stated otherwise.

[0046] Video coding usually refers to the processing of a sequence of pictures to form a video or a video sequence. Instead of the term "picture", the terms "frame" or "image" may be used synonymously in the field of video coding. Video coding (or, in general, coding) comprises two parts: video encoding and video decoding. Video encoding is performed at the source side and usually comprises processing an original video picture (e.g., by compression) to reduce the amount of data required to represent the video picture (for more efficient storage and / or transmission). Video decoding is performed at the destination side and usually comprises the reverse processing compared to the encoder to reconstruct the video picture. The embodiments referring to "coding" of a video picture (or, in general, a picture) shall be understood to relate to "encoding" or "decoding" of the video picture or the respective video sequence. The combination of the encoding and decoding parts is also called a codec (coding and decoding).

[0047] In the case of lossless video coding, the original video picture can be reconstructed, i.e., the reconstructed video picture has the same quality as the original video picture (assuming there is no transmission loss or other data loss during storage or transmission). In the case of lossy video coding, further compression is performed, e.g., by quantization, to reduce the amount of data representing the video picture, and the video picture cannot always be completely reconstructed at the decoder, i.e., the quality of the reconstructed video picture is lower, i.e., worse, than the quality of the original video picture.

[0048] Some video coding standards belong to the group of "lossy hybrid video codecs" (i.e., they combine spatial and temporal prediction in the sample domain with 2D transform coding to apply quantization in the transform domain). Each picture of a video sequence is usually partitioned into a set of non-overlapping blocks, and coding is usually performed at the block level. In other words, in the encoder, a video is usually processed or coded at the block (video block) level, for example, by using spatial (intra-picture) and / or temporal (inter-picture) prediction to generate a predictive block, subtracting the predictive block from a current block (the block currently being / to be processed) to obtain a residual block, transforming the residual block, and quantizing the residual block in the transform domain to reduce (compress) the amount of data to be transmitted, while in the decoder, the reverse processing is applied to the coded or compressed block compared to the encoder in order to reconstruct the current block for representation. Furthermore, the encoder replicates the decoder processing loop so that both generate the same prediction (e.g., intra-prediction and inter-prediction) and / or reconstruction for processing or coding a subsequent block.

[0049] In the following, embodiments of a video coding system 10, a video encoder 20, and a video decoder 30 are described based on FIGS.

[0050] 1A is a schematic block diagram illustrating an example coding system 10, such as video coding system 10 (or short coding system 10), that may utilize techniques of the present application. A video encoder 20 (or short encoder 20) and a video decoder 30 (or short decoder 30) of video coding system 10 represent examples of devices that may be configured to perform techniques according to various examples described in the present application.

[0051] As shown in FIG. 1A, coding system 10 includes a source device 12 configured to provide encoded picture data 21 to a destination device 14 for decoding, for example, the encoded picture data 13.

[0052] The source device 12 comprises an encoder 20, and may additionally, i.e. optionally, comprise a picture source 16, a pre-processor (or pre-processing unit) 18, for example a picture pre-processor 18, and a communication interface or unit 22.

[0053] Picture source 16 may comprise or be any kind of picture capture device, e.g., a camera for capturing real-world pictures, and / or any kind of picture generation device, e.g., a computer graphics processor for generating computer-animated pictures, or any kind of other device for obtaining and / or providing real-world pictures, computer-generated pictures (e.g., screen content, virtual reality (VR) pictures), and / or any combination thereof (e.g., augmented reality (AR) pictures). Picture source may be any kind of memory or storage that stores any of the above-mentioned pictures.

[0054] In contrast to the pre-processor 18 and the processing performed by the pre-processing unit 18 , the pictures or picture data 17 are sometimes referred to as raw pictures or raw picture data 17 .

[0055] The pre-processor 18 is configured to receive (raw) picture data 17 and perform pre-processing on the picture data 17 to obtain a pre-processed picture 19 or pre-processed picture data 19. The pre-processing performed by the pre-processor 18 may comprise, for example, cropping, color format conversion (e.g., from RGB to YCbCr), color correction, or noise removal. It may be understood that the pre-processing unit 18 may be an optional component.

[0056] Video encoder 20 is configured to receive pre-processed picture data 19 and to provide encoded picture data 21 (further details are described below, eg, with reference to FIG. 2).

[0057] Communications interface 22 of source device 12 may be configured to receive encoded picture data 21 and transmit the encoded picture data 21 (or any further processed version thereof) via communications channel 13 to another device, e.g., destination device 14 or any other device, for storage or direct reconstruction.

[0058] The destination device 14 comprises a decoder 30 (e.g., a video decoder 30), and may additionally, i.e. optionally, comprise a communications interface or unit 28, a post-processor 32 (or a post-processing unit 32), and a display device 34.

[0059] The communications interface 28 of the destination device 14 is configured to receive the encoded picture data 21 (or any further processed version thereof), for example directly from the source device 12 or from any other source, for example a storage device, for example an encoded picture data storage device, and to provide the encoded picture data 21 to a decoder 30.

[0060] The communication interface 22 and the communication interface 28 may be configured to transmit or receive the encoded picture data 21 or the encoded data 13 via a direct communication link between the source device 12 and the destination device 14, e.g., a direct wired connection or a direct wireless connection, or via any type of network, e.g., a wired network or a wireless network or any combination thereof, or any type of private network and public network, or any type of combination thereof.

[0061] The communications interface 22 may be configured, for example, to package the encoded picture data 21 in a suitable format, e.g., in packets, and / or to process the encoded picture data using any type of transmission encoding or processing for transmission over a communications link or network.

[0062] Communications interface 28, which forms the counterpart of communications interface 22, may be configured, for example, to receive transmitted data and process the transmitted data using any type of corresponding transmission decoding or processing and / or depackaging to obtain encoded picture data 21.

[0063] Both communication interface 22 and communication interface 28 may be configured as unidirectional communication interfaces, as indicated by the arrow for communication channel 13 in FIG. 1A pointing from source device 12 to destination device 14, or as bidirectional communication interfaces, and may be configured to, for example, send and receive messages to set up a connection, for example, to acknowledge, respond and exchange any other information related to the communication link and / or data transmission, e.g., encoded picture data transmission.

[0064] The decoder 30 is configured to receive the encoded picture data 21 and provide decoded picture data 31 or decoded pictures 31 (further details are described below, for example based on Figure 3 or Figure 5).

[0065] The post-processor 32 of the destination device 14 is configured to post-process the decoded picture data 31 (also referred to as reconstructed picture data), e.g., the decoded picture 31, to obtain post-processed picture data 33, e.g., a post-processed picture 33. The post-processing performed by the post-processing unit 32 may comprise, e.g., color format conversion (e.g., from YCbCr to RGB), color correction, cropping or resampling, or any other processing, e.g., to prepare the decoded picture data 31 for, e.g., display, by a display device 34.

[0066] A display device 34 of destination device 14 is configured to receive the post-processed picture data 33, e.g., for displaying the picture to a user or viewer. Display device 34 may be or comprise any type of display for presenting the reconstructed picture, e.g., an integrated or external display or monitor. The display may comprise, e.g., a liquid crystal display (LCD), an organic light emitting diode (OLED) display, a plasma display, a projector, a micro-LED display, a liquid crystal on silicon (LCoS), a digital light processor (DLP), or any type of other display.

[0067] 1A illustrates source device 12 and destination device 14 as separate devices, an embodiment of the devices may also include both or both the functionality of source device 12 or corresponding functionality and destination device 14 or corresponding functionality. In such an embodiment, source device 12 or corresponding functionality and destination device 14 or corresponding functionality may be implemented using the same hardware and / or software or by separate hardware and / or software or any combination thereof.

[0068] As will be clear to a person skilled in the art based on the description, the presence and (exact) division of functions of different units or functions within source device 12 and / or destination device 14 as shown in FIG. 1A may vary depending on the actual device and application.

[0069] The encoder 20 (e.g., video encoder 20) or the decoder 30 (e.g., video decoder 30), or both the encoder 20 and the decoder 30, may be implemented via processing circuitry as shown in FIG. 1B, such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic, hardware, dedicated to video coding, or any combination thereof. The encoder 20 may be implemented via processing circuitry 46 to embody various modules as described with respect to the encoder 20 of FIG. 2 and / or any other encoder system or subsystem described herein. The decoder 30 may be implemented via processing circuitry 46 to embody various modules as described with respect to the decoder 30 of FIG. 3 and / or any other decoder system or subsystem described herein. The processing circuitry may be configured to perform various operations as described below. As shown in FIG. 5, if the techniques are implemented in part in software, the device may store instructions for the software in a suitable non-transitory computer-readable storage medium and execute the instructions in hardware using one or more processors to perform the techniques of this disclosure. Either video encoder 20 and video decoder 30 may be integrated into a single device as part of a combined encoder / decoder (codec), for example, as shown in FIG. 1B.

[0070] Source device 12 and destination device 14 may comprise any of a wide range of devices, including any type of handheld or fixed device, e.g., a notebook or laptop computer, a mobile phone, a smartphone, a tablet or tablet computer, a camera, a desktop computer, a set-top box, a television, a display device, a digital media player, a video game console, a video streaming device (such as a content service server or a content delivery server), a broadcast receiver device, a broadcast transmitter device, and the like, and may use no operating system or any type of operating system. In some cases, source device 12 and destination device 14 may be equipped for wireless communication. Thus, source device 12 and destination device 14 may be wireless communication devices.

[0071] In some cases, the video coding system 10 shown in FIG. 1A is only an example, and techniques of the present application may be applied to video coding settings (e.g., video encoding or video decoding) that do not necessarily include any data communication between encoding and decoding devices. In other examples, data may be retrieved from local memory, streamed over a network, etc. A video encoding device may encode and store data in memory, and / or a video decoding device may retrieve data from memory and decode data. In some examples, encoding and decoding are performed by devices that do not communicate with each other, but simply encode data into memory and / or retrieve data from memory and decode data.

[0072] For ease of explanation, embodiments of the present invention are described herein by reference to, for example, High-Efficiency Video Coding (HEVC) or to Versatile Video Coding (VVC), a next-generation video coding standard developed by the Joint Collaboration Team on Video Coding (JCT-VC) of the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Motion Picture Experts Group (MPEG). It will be appreciated by those skilled in the art that embodiments of the present invention are not limited to HEVC or VVC.

[0073] Encoder and encoding method FIG. 2 shows a schematic block diagram of an exemplary video encoder 20 configured to implement the techniques of the present application. In the example of FIG. 2, the video encoder 20 includes an input unit 201 (or an input interface 201), a residual calculation unit 204, a transform processing unit 206, a quantization unit 208, an inverse quantization unit 210 and an inverse transform processing unit 212, a reconstruction unit 214, a loop filter unit 220, a decoded picture buffer (DPB) 230, a mode selection unit 260, an entropy coding unit 270, and an output unit 272 (or an output interface 272). The mode selection unit 260 may include an inter prediction unit 244, an intra prediction unit 254, and a partition unit 262. The inter prediction unit 244 may include a motion estimation unit and a motion compensation unit (not shown). The video encoder 20 as shown in FIG. 2 may also be called a hybrid video encoder, i.e., a video encoder according to a hybrid video codec.

[0074] The residual calculation unit 204, the transform processing unit 206, the quantization unit 208, and the mode selection unit 260 may be referred to as forming a forward signal path of the encoder 20, while the inverse quantization unit 210, the inverse transform processing unit 212, the reconstruction unit 214, the buffer 216, the loop filter 220, the decoded picture buffer (DPB) 230, the inter prediction unit 244, and the intra prediction unit 254 may be referred to as forming a backward signal path of the video encoder 20, which corresponds to the signal path of the decoder (see video decoder 30 in FIG. 3). The inverse quantization unit 210, the inverse transform processing unit 212, the reconstruction unit 214, the loop filter 220, the decoded picture buffer (DPB) 230, the inter prediction unit 244, and the intra prediction unit 254 are also referred to as forming a “built-in decoder” of the video encoder 20.

[0075] Pictures and picture divisions (pictures and blocks) The encoder 20 may be configured to receive, for example via an input 201, a picture 17 (or picture data 17), for example a picture of a sequence of pictures forming a video or a video sequence. The received picture or picture data may also be a preprocessed picture 19 (or preprocessed picture data 19). For simplicity, the following description refers to picture 17. Picture 17 may also be called a current picture or a picture to be coded (particularly in video coding, to distinguish the current picture from other pictures, for example previously encoded and / or decoded pictures, of the same video sequence, i.e. the video sequence that also comprises the current picture).

[0076] A (digital) picture may be or be considered as a two-dimensional array or matrix of samples with intensity values. The samples in the array may also be called pixels (picture elements in short form) or pels. The number of samples in the horizontal and vertical directions (or axes) of the array or picture defines the size and / or resolution of the picture. For color representation, three color components are usually employed, i.e. a picture may be represented or contain three sample arrays. In an RBG format or color space, a picture comprises corresponding red, green, and blue sample arrays. However, in video coding, each pixel is usually represented in a luminance and chrominance format or color space, e.g. YCbCr, which comprises a luminance component denoted by Y (sometimes L is also used instead) and two chrominance components denoted by Cb and Cr. The luminance (or short luma) component Y represents luminance or gray level intensity (e.g., as in a grayscale picture), and the two chrominance (or short chroma) components Cb and Cr represent chromaticity or color information components. Thus, a picture in YCbCr format comprises a luminance sample array of luminance sample values ​​(Y) and two chrominance sample arrays of chrominance values ​​(Cb and Cr). A picture in RGB format may be converted or transformed into YCbCr format, or vice versa, a process also called color transformation or color conversion. If the picture is monochrome, the picture may comprise only a luminance sample array. Thus, a picture may be, for example, an array of luma samples in monochrome format, or an array of luma samples and two corresponding arrays of chroma samples in 4:2:0, 4:2:2, and 4:4:4 color formats.

[0077] An embodiment of video encoder 20 may comprise a picture partitioning unit (not shown in FIG. 2) configured to partition picture 17 into multiple (usually non-overlapping) picture blocks 203. These blocks may also be called root blocks, macroblocks (H.264 / AVC), or coding tree blocks (CTBs) or coding tree units (CTUs) (H.265 / HEVC and VVC). The picture partitioning unit may be configured to use the same block size for all pictures of a video sequence and a corresponding grid that defines the block sizes, or to vary the block size among pictures or subsets or groups of pictures, and to partition each picture into corresponding blocks.

[0078] In further embodiments, the video encoder may be configured to directly receive block 203 of picture 17, e.g., one, multiple, or all of the blocks that form picture 17. Picture block 203 may also be referred to as a current picture block or a picture block to be coded.

[0079] Like picture 17, picture block 203 may again be or be considered as a two-dimensional array or matrix of samples having intensity values ​​(sample values), but with smaller dimensions than picture 17. In other words, block 203 may comprise, for example, one sample array (e.g., a luma array in case of a monochrome picture 17, or a luma array or a chroma array in case of a color picture), or three sample arrays (e.g., a luma array and two chroma arrays in case of a color picture 17), or any other number and / or type of arrays depending on the color format applied. The number of samples in the horizontal and vertical directions (or axes) of block 203 defines the size of block 203. Thus, a block may be, for example, an M×N (M columns×N rows) array of samples, or an M×N array of transform coefficients.

[0080] An embodiment of video encoder 20 as shown in FIG. 2 may be configured to code picture 17 on a block-by-block basis, eg, encoding and prediction are performed on a block 203 basis.

[0081] An embodiment of video encoder 20 as shown in FIG. 2 may be further configured to partition and / or encode pictures by using slices (also referred to as video slices), where a picture may be partitioned into or encoded using one or more (usually non-overlapping) slices, each of which may comprise one or more blocks (e.g., CTUs).

[0082] An embodiment of video encoder 20 as shown in FIG. 2 may be further configured to partition and / or encode a picture by using tile groups (also referred to as video tile groups) and / or tiles (also referred to as video tiles), where a picture may be partitioned into or encoded using one or more (usually non-overlapping) tile groups, each of which may comprise, for example, one or more blocks (e.g., CTUs) or one or more tiles, and each tile may be, for example, rectangular in shape and comprise one or more blocks (e.g., CTUs), e.g., whole or fractional blocks.

[0083] Residual calculation The residual calculation unit 204 may be configured to calculate a residual block 205 (also referred to as residual 205) based on the picture block 203 and the prediction block 265 (further details about the prediction block 265 are provided later), for example, by subtracting sample values ​​of the prediction block 265 from sample values ​​of the picture block 203 on a sample-by-sample (pixel-by-pixel) basis to obtain the residual block 205 in the sample domain.

[0084] conversion The transform processing unit 206 may be configured to apply a transform, such as a discrete cosine transform (DCT) or a discrete sine transform (DST), to the sample values ​​of the residual block 205 to obtain transform coefficients 207 in the transform domain. The transform coefficients 207 may also be referred to as transform residual coefficients and may represent the residual block 205 in the transform domain.

[0085] The transform processing unit 206 may be configured to apply an integer approximation of a DCT / DST, such as the transform specified for H.265 / HEVC. Compared to an orthogonal DCT transform, such an integer approximation is typically scaled by some factors. In order to preserve the norm of the residual block processed by the forward transform and the inverse transform, an additional scaling factor is applied as part of the transform process. The scaling factor is typically chosen based on some constraints, such as the scaling factor being a power of two due to shift operations, the bit depth of the transform coefficients, a trade-off between accuracy and implementation cost, etc. For example, a particular scaling factor may be specified for, e.g., the inverse transform, e.g., by the inverse transform processing unit 212 (and the corresponding inverse transform, e.g., by the inverse transform processing unit 312 in the video decoder 30), and a corresponding scaling factor for the forward transform, e.g., by the transform processing unit 206 in the encoder 20, may be specified accordingly.

[0086] An embodiment of video encoder 20 (respectively, transform processing unit 206) may be configured to output transform parameters, e.g., one or more types of transform, e.g., directly or encoded or compressed via entropy coding unit 270, so that, for example, video decoder 30 may receive and use the transform parameters for decoding.

[0087] Quantization The quantization unit 208 may be configured to quantize the transform coefficients 207, for example by applying scalar quantization or vector quantization, to obtain quantized coefficients 209. The quantized coefficients 209 may also be referred to as quantized transform coefficients 209 or quantized residual coefficients 209.

[0088] The quantization process may reduce the bit depth associated with some or all of the transform coefficients 207. For example, an n-bit transform coefficient may be truncated to an m-bit transform coefficient during quantization, where n is greater than m. The degree of quantization may be modified by adjusting a quantization parameter (QP). For example, in the case of scalar quantization, various scalings may be applied to achieve finer or coarser quantization. A smaller quantization step size corresponds to a finer quantization, while a larger quantization step size corresponds to a coarser quantization. The applicable quantization step sizes may be indicated by a quantization parameter (QP). The quantization parameter may, for example, be an index into a predefined set of applicable quantization step sizes. For example, a small quantization parameter may correspond to fine quantization (small quantization step size) and a large quantization parameter may correspond to coarse quantization (large quantization step size), or vice versa. Quantization may include division by the quantization step size, and corresponding and / or inverse dequantization, e.g., by the inverse quantization unit 210, may include multiplication by the quantization step size. Some standards, e.g., HEVC, embodiments may be configured to use a quantization parameter to determine the quantization step size. In general, the quantization step size may be calculated based on the quantization parameter using a fixed-point approximation of an equation that includes a division. An additional scaling factor may be introduced for quantization and dequantization to restore the norm of the residual block, which may be modified due to the scaling used in the fixed-point approximation of the equation for the quantization step size and the quantization parameter. In one example implementation, the scaling of the inverse transform and dequantization may be combined. Alternatively, customized quantization tables may be used, e.g., signaled from the encoder to the decoder in the bitstream. Quantization is a lossy operation, and the loss increases with increasing quantization step size.

[0089] An embodiment of video encoder 20 (respectively, quantization unit 208) may be configured to output a quantization parameter (QP), e.g., encoded directly or via entropy encoding unit 270, such that video decoder 30, for example, may receive and apply the quantization parameter for decoding.

[0090] inverse quantization Inverse quantization unit 210 is configured to apply the inverse quantization of quantization unit 208 to the quantized coefficients to obtain dequantized coefficients 211, e.g., by applying the inverse of the quantization scheme applied by quantization unit 208, based on or using the same quantization step size as quantization unit 208. The dequantized coefficients 211, which may also be referred to as dequantized residual coefficients 211, may correspond to transform coefficients 207—although they are not typically identical to the transform coefficients due to losses due to quantization.

[0091] Inverse transformation The inverse transform processing unit 212 is configured to apply an inverse transform of the transform applied by the transform processing unit 206, for example, an inverse discrete cosine transform (DCT) or an inverse discrete sine transform (DST), or other inverse transform, to obtain a reconstructed residual block 213 in the sample domain (or corresponding dequantized coefficients 213). The reconstructed residual block 213 may also be referred to as a transform block 213.

[0092] Reconstruction The reconstruction unit 214 (e.g., adder or summer 214) is configured to add the transform block 213 (i.e., the reconstructed residual block 213) to the prediction block 265 to obtain a reconstructed block 215 in the sample domain, e.g., by adding sample values ​​of the reconstructed residual block 213 and sample values ​​of the prediction block 265 - sample by sample.

[0093] Filtering The loop filter unit 220 (or short "loop filter" 220) is configured to filter the reconstructed block 215 to obtain a filtered block 221, or in general, to filter the reconstructed samples to obtain filtered samples. The loop filter unit is configured, for example, to smooth pixel transitions or otherwise improve video quality. The loop filter unit 220 may comprise one or more loop filters, such as a deblocking filter, a Sample-Adaptive Offset (SAO) filter, or one or more other filters, for example, a bilateral filter, an Adaptive Loop Filter (ALF), a sharpening filter, a smoothing filter, or a collaborative filter, or any combination thereof. Although the loop filter unit 220 is illustrated in FIG. 2 as being an in-loop filter, in other configurations the loop filter unit 220 may be implemented as a post-loop filter. The filtered block 221 may also be referred to as a filtered reconstructed block 221.

[0094] Embodiments of video encoder 20 (respectively, loop filter unit 220) may be configured to output loop filter parameters (such as sample adaptive offset information), e.g., directly or encoded via entropy encoding unit 270, such that, for example, decoder 30 may receive and apply the same loop filter parameters or respective loop filters for decoding.

[0095] Decoded Picture Buffer The decoded picture buffer (DPB) 230 may be a memory that stores reference pictures or generally reference picture data for encoding video data by the video encoder 20. The DPB 230 may be formed by any of a variety of memory devices, such as dynamic random access memory (DRAM), including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. The decoded picture buffer (DPB) 230 may be configured to store one or more filtered blocks 221. The decoded picture buffer 230 may further be configured to store other previously filtered blocks, e.g., previously reconstructed and filtered blocks 221 of the same current picture or of a different picture, e.g., previously reconstructed pictures, and may provide, e.g., a previously reconstructed or decoded overall picture (and corresponding reference blocks and samples) and / or a partially reconstructed current picture (and corresponding reference blocks and samples) for inter prediction. For example, if the reconstructed block 215 has not been filtered by the loop filter unit 220 or is any other further processed version of a reconstructed block or sample, the decoded picture buffer (DPB) 230 may also be configured to store one or more unfiltered reconstructed blocks 215, or in general, unfiltered reconstructed samples.

[0096] Mode Selection (Segmentation and Prediction) The mode selection unit 260 comprises a partitioning unit 262, an inter prediction unit 244, and an intra prediction unit 254, and is configured to receive or obtain original picture data, e.g., original block 203 (current block 203 of current picture 17), as well as reconstructed picture data, e.g., filtered and / or unfiltered reconstructed samples or blocks, from, e.g., a decoded picture buffer 230 or other buffer (e.g., a line buffer, not shown) of the same (current) picture and / or from one or more previously decoded pictures. The reconstructed picture data is used as reference picture data for prediction, e.g., inter prediction or intra prediction, to obtain a prediction block 265 or a predictor 265.

[0097] The mode selection unit 260 may be configured to determine or select a partition for a current block prediction mode (not including a partition) and a prediction mode (e.g., intra or inter prediction mode) and generate a corresponding prediction block 265 used for calculation of the residual block 205 and for reconstruction of the reconstructed block 215.

[0098] An embodiment of the mode selection unit 260 may be configured to select a partition and prediction mode (e.g., from those supported by or available to the mode selection unit 260) that gives the best match, or in other words the smallest residual (smallest residual means better compression for transmission or storage), or the smallest signaling overhead (smallest signaling overhead means better compression for transmission or storage), or considers or balances both. The mode selection unit 260 may be configured to determine the partition and prediction mode based on Rate Distortion Optimization (RDO), i.e., to select the prediction mode that results in the smallest rate distortion. Terms such as "best," "minimum," "optimum," etc. in this context do not necessarily refer to an overall "best," "minimum," "optimum," etc., but may refer to the satisfaction of a termination or selection criterion, such as a value above or below a threshold or other constraint, potentially leading to a "suboptimal selection," but reducing computational effort and processing time.

[0099] In other words, the partitioning unit 262 may be configured to partition the block 203 into smaller block partitions or sub-blocks (which again form blocks) using, for example, a quad-tree partitioning (QT), binary partitioning (BT), or triple-tree partitioning (TT), or any combination thereof in an iterative manner, and to perform, for example, prediction on each of the block partitions or sub-blocks, wherein the mode selection comprises selection of a tree structure of the partitioned block 203, and a prediction mode is applied to each of the block partitions or sub-blocks.

[0100] Below, the partitioning (eg, by partition unit 260) and prediction processes (by inter prediction unit 244 and intra prediction unit 254) performed by the exemplary video encoder 20 are described in more detail.

[0101] classification The partitioning unit 262 may partition (i.e., split) the current block 203 into smaller partitions, e.g., smaller blocks of square or rectangular size. These smaller blocks (sometimes called sub-blocks) may be further partitioned into even smaller partitions. This is also called tree partitioning or hierarchical tree partitioning, e.g., a root block at root tree level 0 (hierarchical level 0, depth 0) may be partitioned recursively, e.g., into two or more blocks at the next lower tree level, e.g., nodes at tree level 1 (hierarchical level 1, depth 1), which may again be partitioned into two or more blocks at the next lower level, e.g., tree level 2 (hierarchical level 2, depth 2), etc., until the partitioning is terminated, e.g., because a termination criterion is met, e.g., a maximum tree depth or a minimum block size has been reached. Blocks that are not partitioned further are also called leaf blocks or leaf nodes of the tree. A tree that uses a partition into two partitions is called a Binary-Tree (BT), a tree that uses a partition into three partitions is called a Ternary-Tree (TT), and a tree that uses a partition into four partitions is called a Quad-Tree (QT).

[0102] As mentioned before, the term "block" as used herein may be a portion of a picture, specifically a square or rectangular portion. For example, referring to HEVC and VVC, a block may be or may correspond to a coding tree unit (CTU), a coding unit (CU), a prediction unit (PU), and a transform unit (TU), and / or a corresponding block, such as a coding tree block (CTB), a coding block (CB), a transform block (TB), or a prediction block (PB).

[0103] For example, a coding tree unit (CTU) may be or comprise a CTB of luma samples for a picture with three sample arrays, two corresponding CTBs of chroma samples, or a CTB of samples for a monochrome picture or a picture coded using three separate color planes, and a syntax structure used to code the samples. Correspondingly, a coding tree block (CTB) may be an N×N block of samples for some values ​​of N such that the division of the components into CTBs is partitioned. A coding unit (CU) may be or comprise a coding block of luma samples for a picture with three sample arrays, two corresponding coding blocks of chroma samples, or a coding block of samples for a monochrome picture or a picture coded using three separate color planes, and a syntax structure used to code the samples. Correspondingly, a coding block (CB) may be an M×N block of samples for some values ​​of M and N such that the division of the CTB into coding blocks is partitioned.

[0104] For example, in an embodiment related to HEVC, a coding tree unit (CTU) may be divided into CUs by using a quad-tree structure denoted as a coding tree. The decision of whether a picture area should be coded using (temporal) inter-picture prediction or (spatial) intra-picture prediction is made at the CU level. Each CU may be further divided into one, two, or four PUs according to a PU partition type. Inside one PU, the same prediction process is applied, and related information is transmitted to the decoder on a PU-by-PU basis. After obtaining residual blocks by applying a prediction process based on the PU partition type, the CU may be partitioned into transform units (TUs) according to another quad-tree structure similar to the coding tree for CUs.

[0105] For example, in an embodiment of the latest video coding standard currently under development, called Versatile Video Coding (VVC), a combined quad-tree and binary tree (QTBT) partition is used, for example, to partition the coding block. In the QTBT block structure, the CU can have either a square or a rectangular shape. For example, the coding tree unit (CTU) is first partitioned by a quad-tree structure. The quad-tree leaf node is further partitioned by a binary tree structure or a ternary tree (i.e., triple tree) structure. The partitioning tree leaf node is called a coding unit (CU), whose segmentation is used for prediction and transformation processes without further partitioning. This means that the CU, PU, ​​and TU have the same block size in the QTBT coding block structure. In parallel, multiple partitions, for example triple tree partitions, can be used with the QTBT block structure.

[0106] In one example, mode selection unit 260 of video encoder 20 may be configured to perform any combination of the partitioning techniques described herein.

[0107] As described above, video encoder 20 is configured to determine or select a best or optimal prediction mode from a (e.g., predetermined) set of prediction modes. The set of prediction modes may comprise, for example, intra-prediction modes and / or inter-prediction modes.

[0108] Intra prediction The set of intra prediction modes may, for example, comprise 35 different intra prediction modes, e.g., an omnidirectional mode such as DC (or average) mode and a planar mode, or a directional mode, as specified in HEVC, or may comprise 67 different intra prediction modes, e.g., an omnidirectional mode such as DC (or average) mode and a planar mode, or a directional mode, as specified for VVC.

[0109] The intra prediction unit 254 is configured to use reconstructed samples of neighboring blocks of the same current picture to generate an intra prediction block 265 according to an intra prediction mode of the set of intra prediction modes.

[0110] The intra prediction unit 254 (or generally, the mode selection unit 260) is further configured to output intra prediction parameters (or generally, information indicating the selected intra prediction mode for the block) to the entropy encoding unit 270 in the form of a syntax element 266 for inclusion in the encoded picture data 21, so that, for example, the video decoder 30 may receive and use the prediction parameters for decoding.

[0111] Inter Prediction The set of inter prediction modes (or possible inter prediction modes) depends on the available reference pictures (i.e., previous pictures that have been at least partially decoded and that are, for example, stored in DBP230) as well as other inter prediction parameters, such as whether the entire reference picture is used to search for the best matching reference block or only a portion of it, for example a search window area around the area of ​​the current block of the reference picture, is used, and / or whether, for example, pixel interpolation, for example half-pel / semi-pel and / or quarter-pel interpolation, is applied.

[0112] In addition to the above prediction modes, skip mode and / or direct mode may be applied.

[0113] The inter prediction unit 244 may include a motion estimation (ME) unit and a motion compensation (MC) unit (both not shown in FIG. 2). The motion estimation unit may be configured to receive or obtain the picture block 203 (current picture block 203 of current picture 17) and the decoded picture 231, or at least one or more previously reconstructed blocks, e.g., reconstructed blocks of one or more other / different previously decoded pictures 231, for motion estimation. For example, a video sequence may comprise the current picture and the previously decoded picture 231, i.e., in other words, the current picture and the previously decoded picture 231 may be part of or form a sequence of pictures forming a video sequence.

[0114] The encoder 20 may be configured to, for example, select a reference block from multiple reference blocks of the same or different pictures among multiple other pictures, and provide the reference picture (or reference picture index) and / or an offset (spatial offset) between the position (x, y coordinates) of the reference block and the position of the current block as an inter-prediction parameter to the motion estimation unit, which offset is also called a motion vector (MV).

[0115] The motion compensation unit is configured to obtain, e.g., receive, inter prediction parameters and perform inter prediction based on or using the inter prediction parameters to obtain inter prediction block 265. The motion compensation performed by the motion compensation unit may involve fetching or generating a prediction block based on a motion / block vector determined by motion estimation, possibly performing interpolation to sub-pixel accuracy. Interpolation filtering may generate additional pixel samples from known pixel samples, thus potentially increasing the number of candidate prediction blocks that can be used to code the picture block. Upon receiving a motion vector for the PU of the current picture block, the motion compensation unit may locate the prediction block to which the motion vector points in one of the reference picture lists.

[0116] The motion compensation unit may also generate syntax elements associated with the blocks and video slices for use by video decoder 30 in decoding picture blocks of the video slices. In addition to, or as an alternative to, slices and their respective syntax elements, tile groups and / or tiles and their respective syntax elements may be generated or used.

[0117] Entropy Coding The entropy encoding unit 270 is configured to apply, for example, an entropy encoding algorithm or scheme (e.g., a variable length coding (VLC) scheme, a context-adaptive VLC scheme (CAVLC), an arithmetic coding scheme, a binarization scheme, a context-adaptive binary arithmetic coding (CABAC), a syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or another entropy encoding method or technique), or bypass (no compression), to the quantized coefficients 209, the inter-prediction parameters, the intra-prediction parameters, the loop filter parameters, and / or other syntax elements to obtain encoded picture data 21, which may be output via an output unit 272, for example, in the form of an encoded bitstream 21, so that, for example, the video decoder 30 may receive and use the parameters for decoding. The encoded bitstream 21 may be transmitted to the video decoder 30 or may be stored in a memory for later transmission or retrieval by the video decoder 30.

[0118] Other structural variations of the video encoder 20 may be used to encode the video stream. For example, a non-transform-based encoder 20 may directly quantize the residual signal without using the transform processing unit 206 for some blocks or frames. In another implementation, the encoder 20 may have the quantization unit 208 and the inverse quantization unit 210 combined into a single unit.

[0119] Decoder and decoding method 3 shows an example of a video decoder 30 configured to implement the techniques of the present application. The video decoder 30 is configured to receive encoded picture data 21 (e.g., encoded bitstream 21), e.g., encoded by encoder 20, to obtain a decoded picture 331. The encoded picture data or bitstream comprises information for decoding the encoded picture data, e.g., data representing picture blocks of an encoded video slice (and / or tile group or tile), and associated syntax elements.

[0120] In the example of Figure 3, the decoder 30 includes an entropy decoding unit 304, an inverse quantization unit 310, an inverse transform processing unit 312, a reconstruction unit 314 (e.g., adder 314), a loop filter 320, a decoded picture buffer (DBP) 330, a mode application unit 360, an inter prediction unit 344, and an intra prediction unit 354. The inter prediction unit 344 may be or include a motion compensation unit. The video decoder 30 may, in some examples, perform a decoding path that is generally reciprocal to the encoding path described with respect to the video encoder 100 from Figure 2.

[0121] As described with respect to encoder 20, inverse quantization unit 210, inverse transform processing unit 212, reconstruction unit 214, loop filter 220, decoded picture buffer (DPB) 230, inter prediction unit 344, and intra prediction unit 354 are also referred to as forming a “built-in decoder” of video encoder 20. Thus, inverse quantization unit 310 may be identical in function to inverse quantization unit 110, inverse transform processing unit 312 may be identical in function to inverse transform processing unit 212, reconstruction unit 314 may be identical in function to reconstruction unit 214, loop filter 320 may be identical in function to loop filter 220, and decoded picture buffer 330 may be identical in function to decoded picture buffer 230. Thus, the descriptions provided for the respective units and functions of video encoder 20 apply correspondingly to the respective units and functions of video decoder 30.

[0122] Entropy Decoding The entropy decoding unit 304 is configured to parse the bitstream 21 (or generally, the coded picture data 21) and, e.g., perform entropy decoding on the coded picture data 21 to obtain, e.g., quantized coefficients 309 and / or decoded coding parameters (not shown in FIG. 3), e.g., any or all of inter prediction parameters (e.g., reference picture indexes and motion vectors), intra prediction parameters (e.g., intra prediction modes or indices), transform parameters, quantization parameters, loop filter parameters, and / or other syntax elements. The entropy decoding unit 304 may be configured to apply a decoding algorithm or scheme corresponding to an encoding scheme as described with respect to the entropy encoding unit 270 of the encoder 20. The entropy decoding unit 304 may be further configured to provide the inter prediction parameters, intra prediction parameters, and / or other syntax elements to the mode application unit 360 and other parameters to other units of the decoder 30. The video decoder 30 may receive syntax elements at a video slice level and / or a video block level. In addition to or as an alternative to slices and their respective syntax elements, tile groups and / or tiles and their respective syntax elements may be received and / or used.

[0123] inverse quantization Inverse quantization unit 310 may be configured to receive a quantization parameter (QP) (or generally, information related to inverse quantization) and quantized coefficients from encoded picture data 21 (e.g., by parsing and / or decoding, e.g., by entropy decoding unit 304), and apply inverse quantization to the decoded quantized coefficients 309 based on the quantization parameter to obtain dequantized coefficients 311, which may also be referred to as transform coefficients 311. The inverse quantization process may involve use of a quantization parameter determined by video encoder 20 for each video block in a video slice (or tile or tile group) to determine the degree of quantization, and similarly, the degree of inverse quantization to be applied.

[0124] Reverse transformation The inverse transform processing unit 312 may be configured to receive the dequantized coefficients 311, also referred to as transform coefficients 311, and apply a transform to the dequantized coefficients 311 to obtain a reconstructed residual block 213 in the sample domain. The reconstructed residual block 213 may also be referred to as a transform block 313. The transform may be an inverse transform, e.g., an inverse DCT transform, an inverse DST transform, an inverse integer transform, or a conceptually similar inverse transform process. The inverse transform processing unit 312 may further be configured to receive transform parameters or corresponding information from the encoded picture data 21 (e.g., by parsing and / or decoding, e.g., by the entropy decoding unit 304) to determine a transform to be applied to the dequantized coefficients 311.

[0125] Reconstruction The reconstruction unit 314 (e.g., an adder or summer 314) may be configured to add the reconstructed residual block 313 to the prediction block 365, for example, by adding sample values ​​of the reconstructed residual block 313 and sample values ​​of the prediction block 365, to obtain a reconstructed block 315 in the sample domain.

[0126] Filtering A loop filter unit 320 (either in the coding loop or after the coding loop) is configured to filter the reconstructed block 315 to obtain a filtered block 321, e.g., to smooth pixel transitions or otherwise improve video quality. The loop filter unit 320 may comprise one or more loop filters, such as a deblocking filter, a sample adaptive offset (SAO) filter, or one or more other filters, e.g., a bilateral filter, an adaptive loop filter (ALF), a sharpening filter, a smoothing filter, or a collaborative filter, or any combination thereof. Although the loop filter unit 320 is illustrated in FIG. 3 as being an in-loop filter, in other configurations, the loop filter unit 320 may be implemented as a post-loop filter.

[0127] Decoded Picture Buffer The decoded video blocks 321 of the picture are then stored in a decoded picture buffer 330, which stores the decoded picture 331 as a reference picture for subsequent motion compensation relative to other pictures and / or for output display, respectively.

[0128] The decoder 30 is arranged to output the decoded pictures 311, for example via an output 312, for presentation or viewing to a user.

[0129] prediction The inter prediction unit 344 may be identical to the inter prediction unit 244 (in particular, the motion compensation unit), and the intra prediction unit 354 may be identical in function to the inter prediction unit 254, performing the partitioning or partition decision and prediction based on the partition and / or prediction parameters or respective information received (e.g., by parsing and / or decoding by the entropy decoding unit 304) from the encoded picture data 21. The mode application unit 360 may be configured to perform prediction (intra prediction or inter prediction) for each block based on the (filtered or unfiltered) reconstructed picture, block, or respective sample to obtain a prediction block 365.

[0130] When a video slice is coded as an intra-coded (I) slice, the intra prediction unit 354 of the mode application unit 360 is configured to generate a prediction block 365 for a picture block of the current video slice based on the signaled intra prediction mode and data from a previously decoded block of the current picture. When a video picture is coded as an inter-coded (i.e., B or P) slice, the inter prediction unit 344 (e.g., a motion compensation unit) of the mode application unit 360 is configured to produce a prediction block 365 for a video block of the current video slice based on a motion vector and other syntax elements received from the entropy decoding unit 304. For inter prediction, the prediction block may be produced from one of the reference pictures in one of the reference picture lists. The video decoder 30 may construct the reference frame lists, i.e., List 0 and List 1, using a preset construction technique based on the reference pictures stored in the DPB 330. The same or similar may apply to or with embodiments that use tile groups (e.g., video tile groups) and / or tiles (e.g., video tiles) in addition to or as an alternative to slices (e.g., video slices), e.g., video may be coded using I, P, or B tile groups and / or tiles.

[0131] Mode application unit 360 is configured to determine prediction information for video blocks of the current video slice by parsing the motion vectors or related information and other syntax elements, and use the prediction information to produce a predictive block for the current video block being decoded. For example, mode application unit 360 uses some of the received syntax elements to determine the prediction mode (e.g., intra prediction or inter prediction) used to code the video blocks of the video slice, the inter prediction slice type (e.g., B slice, P slice, or GPB slice), configuration information for one or more of the reference picture lists for the slice, motion vectors for each inter coded video block of the slice, inter prediction status for each inter coded video block of the slice, and other information for decoding video blocks in the current video slice. The same or similar may apply to or with embodiments that use tile groups (e.g., video tile groups) and / or tiles (e.g., video tiles) in addition to or as an alternative to slices (e.g., video slices), e.g., video may be coded using I, P, or B tile groups and / or tiles.

[0132] An embodiment of the video decoder 30 as shown in FIG. 3 may be configured to partition and / or decode pictures by using slices (also referred to as video slices), where a picture may be partitioned into or decoded using one or more (usually non-overlapping) slices, each of which may comprise one or more blocks (e.g., CTUs).

[0133] An embodiment of video decoder 30 as shown in FIG. 3 may be configured to partition and / or decode a picture by using tile groups (also referred to as video tile groups) and / or tiles (also referred to as video tiles), where a picture may be partitioned into or decoded using one or more (usually non-overlapping) tile groups, each of which may comprise, for example, one or more blocks (e.g., CTUs) or one or more tiles, and each tile may be, for example, rectangular in shape and comprise one or more blocks (e.g., CTUs), e.g., whole or fractional blocks.

[0134] Other variations of the video decoder 30 may be used to decode the encoded picture data 21. For example, the decoder 30 may produce an output video stream without a loop filtering unit 320. For example, a non-transform-based decoder 30 may directly inverse quantize the residual signal without an inverse transform processing unit 312 for some blocks or frames. In another implementation, the video decoder 30 may have the inverse quantization unit 310 and the inverse transform processing unit 312 combined into a single unit.

[0135] It should be understood that in the encoder 20 and the decoder 30, the processing result of the current step may be further processed and then output to the next step. For example, after the interpolation filtering, the motion vector derivation, or the loop filtering, further operations such as clipping or shifting may be performed on the processing result of the interpolation filtering, the motion vector derivation, or the loop filtering.

[0136] It should be noted that further operations may be applied to the derived motion vector of the current block (including but not limited to control point motion vectors in affine mode, sub-block motion vectors in affine mode, planar mode, ATMVP mode, temporal motion vectors, etc.). For example, the value of the motion vector is constrained to a predefined range according to its representation bit. If the representation bit of the motion vector is bitDepth, the range is -2^(bitDepth-1) to 2^(bitDepth-1)-1, where "^" means exponentiation. For example, if bitDepth is set equal to 16, the range is -32768 to 32767, and if bitDepth is set equal to 18, the range is -131072 to 131071. For example, the value of the derived motion vector (e.g., MVs of four 4x4 sub-blocks in one 8x8 block) is constrained such that the maximum difference between the integer parts of the four 4x4 sub-block MVs is less than or equal to N pixels, such as less than or equal to 1 pixel. Here, we provide two methods for constraining motion vectors according to bitDepth.

[0137] Method 1: Remove the overflow MSB (Most Significant Bit) by a flowing operation. ux = ( mvx + 2 bitDepth ) % 2 bitDepth (1) mvx = ( ux >= 2 bitDepth-1 ) ? ( ux - 2 bitDepth ) : ux (2) uy = ( mvy + 2 bitDepth ) % 2 bitDepth (3) mvy = ( uy >= 2 bitDepth-1 ) ? ( uy - 2 bitDepth ) : uy (4) where mvx is the horizontal component of the motion vector of the image block or sub-block, mvy is the vertical component of the motion vector of the image block or sub-block, and ux and uy denote intermediate values.

[0138] For example, if the value of mvx is -32769, then after applying equation (1) and equation (2), the resulting value is 32767. In computer systems, decimal numbers are stored as two's complement. The two's complement of -32769 is 1, 0111, 1111, 1111, 1111 (17 bits), then the MSB is discarded, so the resulting two's complement is 0111, 1111, 1111, 1111, which is the same as the output by applying equation (1) and equation (2) (decimal number is 32767). ux = ( mvpx + mvdx +2 bitDepth ) % 2 bitDepth (5) mvx = ( ux >= 2 bitDepth-1 ) ? ( ux - 2 bitDepth ) : ux (6) uy = ( mvpy + mvdy +2 bitDepth ) % 2 bitDepth (7) mvy = ( uy >= 2 bitDepth-1 ) ? ( uy - 2 bitDepth ) : uy (8)

[0139] As shown in equations (5) to (8), the operation may be applied between the addition of mvp and mvd.

[0140] Method 2: Eliminate the overflow MSB by clipping the value. vx = Clip3(-2 bitDepth-1 , 2 bitDepth-1 -1, vx) vy = Clip3(-2 bitDepth-1 , 2 bitDepth-1 -1, vy) where vx is the horizontal component of the motion vector of the image block or sub-block, vy is the vertical component of the motion vector of the image block or sub-block, x, y, and z respectively correspond to the three input values ​​of the MV clipping process, and the definition of the function Clip3 is as follows:

number

[0141] 4 is a schematic diagram of a video coding device 400 according to one embodiment of the present disclosure. The video coding device 400 is suitable for implementing the disclosed embodiments as described herein. In one embodiment, the video coding device 400 may be a decoder, such as the video decoder 30 of FIG. 1A, or an encoder, such as the video encoder 20 of FIG. 1A.

[0142] Video coding device 400 comprises an ingress port 410 (or input port 410) and a receiver unit (Rx) 420 for receiving data, a processor, logic unit, or central processing unit (CPU) 430 for processing the data, a transmitter unit (Tx) 440 and an egress port 450 (or output port 450) for transmitting the data, and a memory 460 for storing data. Video coding device 400 may also comprise optical-to-electrical (OE) and electrical-to-optical (EO) components coupled to the ingress port 410, the receiver unit 420, the transmitter unit 440, and the egress port 450 for the egress or ingress of optical or electrical signals.

[0143] The processor 430 is implemented by hardware and software. The processor 430 may be implemented as one or more CPU chips, cores (e.g., multi-core processors), FPGAs, ASICs, and DSPs. The processor 430 is in communication with the ingress port 410, the receiver unit 420, the transmitter unit 440, the egress port 450, and the memory 460. The processor 430 comprises a coding module 470. The coding module 470 implements the disclosed embodiments described above. For example, the coding module 470 performs, processes, prepares, or provides various coding operations. Thus, the inclusion of the coding module 470 provides a significant improvement in the functionality of the video coding device 400 and provides transformation of the video coding device 400 into different states. Alternatively, the coding module 470 is implemented as instructions stored in the memory 460 and executed by the processor 430.

[0144] Memory 460 may comprise one or more disks, tape drives, and solid state drives, and may be used as an overflow data storage device for storing programs when such programs are selected for execution, and for storing instructions and data read during program execution. Memory 460 may be, for example, volatile and / or non-volatile, and may be read only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and / or static random access memory (SRAM).

[0145] FIG. 5 is a simplified block diagram of an apparatus 500 that may be used as either or both of source device 12 and destination device 14 from FIG. 1 according to an exemplary embodiment.

[0146] The processor 502 in the apparatus 500 may be a central processing unit. Alternatively, the processor 502 may be any other type of device or devices, now existing or later developed, capable of manipulating or processing information. Although the disclosed implementations may be practiced with a single processor, e.g., processor 502, as shown, advantages in speed and efficiency may be achieved using two or more processors.

[0147] The memory 504 in the apparatus 500 may be a read-only memory (ROM) device or a random access memory (RAM) device in one implementation. Any other suitable type of storage device may be used as the memory 504. The memory 504 may include code and data 506 that is accessed by the processor 502 using a bus 512. The memory 504 may further include an operating system 508 and application programs 510, which include at least one program that enables the processor 502 to perform the methods described herein. For example, the application programs 510 may include applications 1-N, which further include a video coding application that performs the methods described herein.

[0148] The apparatus 500 may also include one or more output devices, such as a display 518. The display 518, in one example, may be a touch-sensitive display that combines a display with a touch-sensitive element operable to sense touch input. The display 518 may be coupled to the processor 502 via the bus 512.

[0149] Although shown here as a single bus, bus 512 of device 500 may be comprised of multiple buses. Additionally, secondary storage 514 may be directly coupled to other components of device 500 or may be accessed over a network, and may comprise a single integrated unit, such as a memory card, or multiple units, such as multiple memory cards. Thus, device 500 may be implemented in a wide variety of configurations.

[0150] As described in the document JM Boyce "Weighted prediction in the H.264 / MPEG AVC video coding standard", IEEE International Symposium on Circuits and Systems, May 2004, Canada, pp. 789-792, weighted prediction (WP) is a useful tool, especially for coding fades. The weighted prediction (WP) tool is adopted in the main and extended profiles of the H.264 video coding standard to improve coding efficiency by applying a multiplicative weighting factor and an additive offset to the motion compensated prediction to form a weighted prediction. In the explicit mode, the weighting factor and offset may be coded in the slice header for each allowable reference picture index. In the implicit mode, the weighting factor is not coded, but is derived based on the relative picture order count (POC) distance of two reference pictures. Experimental results are provided that measure the coding efficiency improvement using WP. Bitrate reductions of up to 67% were achieved when coding fade-to-black sequences.

[0151] When applied to a single prediction such as in P pictures, WP is similar to leaky prediction previously proposed for error resiliency. Leaky prediction is a special case of WP with the scaling factor restricted to the range 0≦α≦1. H.264 WP allows negative scaling factors and scaling factors greater than 1. For efficient compression of covered and uncovered regions, the weighting factors are applied on a pixel-by-pixel basis using a coded label field. The main difference of the H.264 WP tool from previous proposals with weighted prediction for compression efficiency is the association of reference picture index with the weighting factor parameters, which allows efficient signaling of these parameters in a multiple reference picture environment. As written in the document R. Zhang and G. Cote "Accurate parameter estimation and efficient fade detection for weighted prediction in H.264 video compression", 15th IEEE International Conference on Image Processing, October 2008, San Diego, California, USA, pp. 2836-2839, the procedure of applying WP in a real-time coding system can be formalized as a sequence of steps shown in Fig. 6. First, some statistics 611 are generated through video analysis 610. The statistics 611 within a small window from some previous pictures to the current picture are then used to detect fades. Each picture is assigned a state value 631 indicating whether the picture is in a NORMAL state or a FADE state. Such a state value is saved for each picture. When coding a picture, if there is a FADE state in either the current picture or one of its reference pictures, WP is used for this current reference pair, and the statistics of the current picture and the corresponding reference picture are processed in step 650 to estimate the WP parameters.These parameters are then passed to the encoding engine 660. Otherwise, normal encoding occurs.

[0152] As described in the document A. Leontaris and A.M. Tourapis, "Weighted prediction methods for improved motion compensation", 16th IEEE International Conference on Image Processing (ICIP), November 2009, Cairo, Egypt, pp. 1029-1032, macroblocks in H.264 are divided into macroblock partitions. For each macroblock partition, a reference is selected from each of the available reference lists (often denoted as RefPicList in the specification), i.e., list 0 for P or B coded slices, or reference list 1 for B coded slices. The references used may be different for each partition. Using these references, a prediction block is selected per list, i.e., P for single list prediction and P for bi-prediction. O and P1 are generated using motion information, optionally with sub-pixel accuracy. The prediction block may be further processed depending on the availability of weighted prediction for the current slice. For P slices, the WP parameters are transmitted in the slice header. For B slices, there are two options: in explicit WP, the parameters are transmitted in the slice header, and in implicit WP, the parameters are derived based on the Picture Order Count (POC) number signaled in the slice header. In this document, we only focus on explicit WP and how this method can be used to improve motion compensation performance. Note that in HEVC and VVC, PB is used similarly to macroblock partitioning in AVC.

[0153] For a P slice or single-list explicit WP in a B slice, the prediction block is derived from a single reference. Let the sample value in prediction block P be denoted as p. If weighted prediction is not used, the final inter prediction sample is f=p. Otherwise, the prediction sample is

number

[0154] At a high level in VVC, weighted prediction is signaled in the sequence parameter set (SPS), picture parameter set (PPS), and slice header. In the SPS, the following syntax elements are used for that purpose: sps_weighted_pred_flag equal to 1 specifies that weighted prediction may be applied to P slices that reference an SPS, sps_weighted_pred_flag equal to 0 specifies that weighted prediction is not applied to P slices that reference an SPS. sps_weighted_bipred_flag equal to 1 specifies that explicit weighted prediction may be applied to B slices that reference an SPS. sps_weighted_bipred_flag equal to 0 specifies that explicit weighted prediction is not applied to B slices that reference an SPS.

[0155] In the PPS the following syntax elements are used for this purpose: - pps_weighted_pred_flag equal to 0 specifies that weighted prediction is not applied to P slices that reference the PPS. pps_weighted_pred_flag equal to 1 specifies that weighted prediction is applied to P slices that reference the PPS. When sps_weighted_pred_flag is equal to 0, the value of pps_weighted_pred_flag shall be equal to 0. - pps_weighted_bipred_flag equal to 0 specifies that no explicit weighted prediction is applied to B slices that reference a PPS. pps_weighted_bipred_flag equal to 1 specifies that explicit weighted prediction is applied to B slices that reference a PPS. When sps_weighted_bipred_flag is equal to 0, the value of pps_weighted_bipred_flag shall be equal to 0.

[0156] In the slice header, the weighted prediction parameters are signaled as pred_weight_table( ) structured as in Table 1 and containing the following elements:

[0157] luma_log2_weight_denom is the base 2 logarithm of the denominator for all luma weighting coefficients. Values ​​of luma_log2_weight_denom shall be in the range 0 to 7, inclusive.

[0158] delta_chroma_log2_weight_denom is the log base 2 delta of the denominators for all chroma weighting coefficients. When delta_chroma_log2_weight_denom is not present, it is inferred to be equal to 0.

[0159] The variable ChromaLog2WeightDenom is derived to be equal to luma_log2_weight_denom + delta_chroma_log2_weight_denom and its value shall be in the range 0 to 7, inclusive.

[0160] luma_weight_l0_flag[ i ] equal to 1 specifies that weighting factors for the luma component of list 0 prediction using RefPicList

[0000] [ i ] are present. luma_weight_l0_flag[ i ] equal to 0 specifies that these weighting factors are not present.

[0161] chroma_weight_l0_flag[ i ] equal to 1 specifies that weighting factors for chroma prediction values ​​for list 0 prediction using RefPicList

[0000] [ i ] are present. chroma_weight_l0_flag[ i ] equal to 0 specifies that these weighting factors are not present. When chroma_weight_l0_flag[ i ] is not present, it is inferred to be equal to 0.

[0162] delta_luma_weight_l0[ i ] is the delta weighting factor applied to the luma prediction value for list 0 prediction using RefPicList

[0000] [ i ].

[0163] The variable LumaWeightL0[ i ] is derived to be equal to ( 1 << luma_log2_weight_denom ) + delta_luma_weight_l0[ i ]. When luma_weight_l0_flag[ i ] is equal to 1, the value of delta_luma_weight_l0[ i ] shall be in the range -128 to 127, inclusive. When luma_weight_l0_flag[ i ] is equal to 0, LumaWeightL0[ i ] shall be equal to 2 luma_log2_weight_denom is assumed to be equal to

[0164] luma_offset_l0[ i ] is an additive offset applied to the luma prediction value for list 0 prediction using RefPicList

[0000] [ i ]. The value of luma_offset_l0[ i ] shall be in the range of -128 to 127, inclusive. When luma_weight_l0_flag[ i ] is equal to 0, luma_offset_l0[ i ] is inferred to be equal to 0.

[0165] delta_chroma_weight_l0[ i ][ j ] is the delta weighting factor applied to the chroma prediction value for list 0 prediction using RefPicList

[0000]

【 i ], where j equals 0 for Cb and j equals 1 for Cr.

[0166] The variable ChromaWeightL0[ i ][ j ] is derived to be equal to ( 1 << ChromaLog2WeightDenom ) + delta_chroma_weight_l0[ i ][ j ]. When chroma_weight_l0_flag[ i ] is equal to 1, the value of delta_chroma_weight_l0[ i ][ j ] shall be in the range -128 to 127, inclusive. When chroma_weight_l0_flag[ i ] is equal to 0, ChromaWeightL0[ i ][ j ] shall be 2 ChromaLog2WeightDenom is assumed to be equal to

[0167] delta_chroma_offset_l0[ i ][ j ] is the additive offset delta applied to the chroma prediction value for list 0 prediction using RefPicList

[0000]

【 i ], where j equals 0 for Cb and j equals 1 for Cr.

[0168] The variable ChromaOffsetL0[i][j] is derived as follows: ChromaOffsetL0[ i ][ j ] = Clip3( -128, 127, ( 128 + delta_chroma_offset_l0[ i ][ j ] - ( ( 128 * ChromaWeightL0[ i ][ j ] ) >> ChromaLog2WeightDenom ) ) )

[0169] The value of delta_chroma_offset_l0[ i ][ j ] shall be in the range of -4 * 128 to 4 * 127, inclusive. When chroma_weight_l0_flag[ i ] is equal to 0, ChromaOffsetL0[ i ][ j ] is inferred to be equal to 0.

[0170] luma_weight_l1_flag[ i ], chroma_weight_l1_flag[ i ], delta_luma_weight_l1[ i ], luma_offset_l1[ i ], delta_chroma_weight_l1[ i ][ j ], and delta_chroma_offset_l1[ i ][ j ] have the same semantics as luma_weight_l0_flag[ i ], chroma_weight_l0_flag[ i ], delta_luma_weight_l0[ i ], luma_offset_l0[ i ], delta_chroma_weight_l0[ i ][ j ], and delta_chroma_offset_l0[ i ][ j ], respectively, with l0, L0, List0, and List0 replaced by l1, L1, List1, and List1, respectively.

[0171] The variable sumWeightL0Flags is derived to be equal to the sum of luma_weight_l0_flag[ i ] + 2 * chroma_weight_l0_flag[ i ], for i = 0..NumRefIdxActive

[0000] - 1.

[0172] When slice_type is equal to B, the variable sumWeightL1Flags is derived to be equal to the sum of luma_weight_l1_flag[ i ] + 2 * chroma_weight_l1_flag[ i ], for i = 0..NumRefIdxActive

[0001] - 1.

[0173] It is a bitstream conformance requirement that sumWeightL0Flags must be less than or equal to 24 when slice_type is equal to P, and the sum of sumWeightL0Flags and sumWeightL1Flags must be less than or equal to 24 when slice_type is equal to B.

[0174] [Table 1A] [Table 1B]

[0175] In contribution JVET-O0244 (V. Seregin et al., "AHG17: On zero delta POC in reference picture structure", 15th JVET Meeting, Gothenburg, Sweden), it was pointed out that in the current VVC specification draft, reference pictures are signaled in the reference picture structure (RPS), where abs_delta_poc_st represents a delta POC value that can be equal to 0. The RPS can be signaled in the SPS and slice header. This functionality is needed to signal different weights for the same reference picture, potentially required if layered scalability is supported, where the same POC value is used across layers in an access unit. It is mentioned therein that it is not required to repeat reference pictures when weighted prediction is not enabled. In particular, the contribution proposes not to allow a zero delta POC value when weighted prediction is not enabled.

[0176] [Table 2A] [Table 2B] [Table 2C] [Table 2D] [Table 2E]

[0177] [Table 3]

[0178] The ref_pic_list_struct( listIdx, rplsIdx ) syntax structure can be present in the SPS or in the slice header. Depending on whether the syntax structure is included in the slice header or in the SPS, the following applies: - If present in the slice header, the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure specifies the reference picture list listIdx of the current picture (the picture that contains the slice). - Otherwise (present in the SPS), the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure specifies candidates for the reference picture list listIdx, and the term "current picture" in the semantics specified in the remainder of this section refers to each picture that (1) has one or more slices with ref_pic_list_idx[ listIdx ] equal to an index into the list of ref_pic_list_struct( listIdx, rplsIdx ) syntax structures contained in the SPS, and (2) is in a CVS that references the SPS.

[0179] num_ref_entries[listIdx][rplsIdx] specifies the number of entries in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. The value of num_ref_entries[listIdx][rplsIdx] shall be in the range 0 to sps_max_dec_pic_buffering_minus1 + 14, inclusive.

[0180] ltrp_in_slice_header_flag[listIdx][rplsIdx] equal to 0 specifies that the POC LSB of the LTRP entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is present in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. ltrp_in_slice_header_flag[listIdx][rplsIdx] equal to 1 specifies that the POC LSB of the LTRP entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is not present in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure.

[0181] inter_layer_ref_pic_flag[listIdx][rplsIdx][i] equal to 1 specifies that the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is an ILRP entry. inter_layer_ref_pic_flag[listIdx][rplsIdx][i] equal to 0 specifies that the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is not an ILRP entry. When not present, the value of inter_layer_ref_pic_flag[listIdx][rplsIdx][i] is inferred to be equal to 0.

[0182] st_ref_pic_flag[listIdx][rplsIdx][i] equal to 1 specifies that the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is a STRP entry. st_ref_pic_flag[listIdx][rplsIdx][i] equal to 0 specifies that the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is an LTRP entry. When inter_layer_ref_pic_flag[listIdx][rplsIdx][i] is equal to 0 and st_ref_pic_flag[listIdx][rplsIdx][i] is not present, the value of st_ref_pic_flag[listIdx][rplsIdx][i] is inferred to be equal to 1.

[0183] The variables NumLtrpEntries[ listIdx ][ rplsIdx ] are derived as follows: for( i = 0, NumLtrpEntries[ listIdx ][ rplsIdx ] = 0; i < num_ref_entries[ listIdx ][ rplsIdx ]; i++ ) if(!inter_layer_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] && !st_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] ) NumLtrpEntries[ listIdx ][ rplsIdx ]++

[0184] abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] specifies the value of the variable AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] as follows: if( sps_weighted_pred_flag || sps_weighted_bipred_flag ) AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] = abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] else AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] = abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] + 1

[0185] The value of abs_delta_poc_st[listIdx][rplsIdx][i] shall be in the range 0 to 215 - 1, inclusive.

[0186] strp_entry_sign_flag[listIdx][rplsIdx][i] equal to 1 specifies that the i-th entry in the syntax structure ref_pic_list_struct(listIdx,rplsIdx) has a value greater than or equal to 0. strp_entry_sign_flag[listIdx][rplsIdx][i] equal to 0 specifies that the i-th entry in the syntax structure ref_pic_list_struct(listIdx,rplsIdx) has a value less than 0. When not present, the value of strp_entry_sign_flag[listIdx][rplsIdx][i] is inferred to be equal to 1.

[0187] The list DeltaPocValSt[ listIdx ][ rplsIdx ] is derived as follows: for( i = 0; i < num_ref_entries[ listIdx ][ rplsIdx ]; i++ ) if( !inter_layer_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] && st_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] ) DeltaPocValSt[ listIdx ][ rplsIdx ][ i ] = ( strp_entry_sign_flag[ listIdx ][ rplsIdx ][ i ] ) ? AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] : 0 - AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ]

[0188] rpls_poc_lsb_lt[listIdx][rplsIdx][i] specifies the value of the picture order count modulo MaxPicOrderCntLsb of the picture referenced by the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. The length of the rpls_poc_lsb_lt[listIdx][rplsIdx][i] syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits.

[0189] ilrp_idc[listIdx][rplsIdx][i] specifies the index into the list of directly dependent layers of the ILRP of the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure into the list of directly dependent layers. The value of ilrp_idc[listIdx][rplsIdx][i] shall be in the range of 0 to GeneralLayerIdx[nuh_layer_id] - 1, inclusive.

[0190] In Table 2, the weighted prediction parameters are signaled after the reference picture list signaling. In Table 4, these syntax elements are reordered to constrain the binarization of the delta POC syntax element based on the value of the weighted prediction flag.

[0191] [Table 4A] [Table 4B]

[0192] Then, the value of the delta POC (variable AbsDeltaPocSt) is conditionally restored at the decoder side as follows:

[0193] abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] specifies the value of the variable AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] as follows: if( sps_weighted_pred_flag || sps_weighted_bipred_flag ) AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] = abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] else AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] = abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] + 1

[0194] Triangular partitioning mode (TPM) and geometric motion partitioning (GEO), also called triangular merge mode and geometric merge mode, respectively, are partitioning techniques that allow non-horizontal and non-vertical boundaries between prediction partitions, where prediction unit PU1 and prediction unit PU2 are combined in regions using a weighted averaging procedure of subsets of their samples related to different color components. While TMP only allows boundaries between prediction partitions along rectangular block diagonals, the boundaries with GEO may be placed at any position. Within the region where the weighted averaging procedure is applied, the integers in the squares represent the weights W applied to the luma component of prediction unit PU1. PU1 In one example, the weights W applied to the luma component of prediction unit PU2 are PU2 is calculated as follows: W PU2 = 8 - W PU1

[0195] The weights applied to the chroma components of the corresponding prediction units may differ from the weights applied to the luma components of the corresponding prediction units.

[0196] Details about the syntax for the TPM are presented in Table 5, where four syntax elements are used to signal information about the TPM.

[0197] MergeTriangleFlag is a flag that identifies whether a TPM is selected or not ("0" means that a TPM is not selected, otherwise a TPM is selected).

[0198] merge_triangle_split_dir is the split direction flag for the TPM ("0" means split direction from top-left corner to bottom-right corner, else the split direction is from top-right corner to bottom-left corner).

[0199] merge_triangle_idx0 and merge_triangle_idx1 are the indices of merge candidates 0 and 1 used for the TPM.

[0200] [Table 5A] [Table 5B]

[0201] In more detail, TPM is described in the following proposal: R.L. Liao and C.S. Lim, "CE10.3.1.b: Triangular prediction unit mode", contribution JVET-L0124 to the 12th JVET meeting, Macau, China, October 2018. GEO is described in the following document: S. Esenlik, H. Gao, A. Filippov, V. Rufitskiy, A.M. Kotra, B. Wang, E. Alshina, M. Blaser, and J. Sauer, "Non-CE4: Geometrical partitioning for inter blocks", contribution JVET-O0489 to the 15th JVET meeting, Gothenburg, Sweden, July 2019.

[0202] The disclosed method for harmonizing the TPM and / or GEO with the WP is to disable the TPM and / or GEO when the WP is applied. A first embodiment is shown in Table 6 and may be performed by checking whether the value of the weightedPredFlag variable for a coding unit is equal to 0.

[0203] The variable weightedPredFlag is derived as follows: - if slice_type is equal to P, weightedPredFlag is set equal to pps_weighted_pred_flag. - Otherwise (slice_type is equal to B), weightedPredFlag is set equal to pps_weighted_bipred_flag.

[0204] The slice-level weighted prediction process may be switched at the picture level and slice level using the pps_weighted_pred_flag and sps_weighted_pred_flag syntax elements, respectively.

[0205] As disclosed above, the variable weightedPredFlag indicates whether slice-level weighted prediction should be used when obtaining inter-predicted samples for a slice.

[0206] [Table 6A] [Table 6B]

[0207] ciip_flag[x0][y0] specifies whether combined inter-picture merging and intra-picture prediction is applied for the current coding unit. The array indexes x0, y0 specify the location (x0, y0) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture.

[0208] When ciip_flag[x0][y0] is not present, it is inferred as follows: - ciip_flag[ x0 ][ y0 ] is inferred to be equal to 1 if all of the following conditions are true: - sps_ciip_enabled_flag is equal to 1. - general_merge_flag[ x0 ][ y0 ] is equal to 1. - merge_subblock_flag[ x0 ][ y0 ] is equal to 0. - regular_merge_flag[ x0 ][ y0 ] is equal to 0. - cbWidth is less than 128. - cbHeight is less than 128. - cbWidth * cbHeight is 64 or greater. - Otherwise, ciip_flag[ x0 ][ y0 ] is inferred to be equal to 0.

[0209] When ciip_flag[x0][y0] is equal to 1, the variable IntraPredModeY[x][y], with x = x0..x0 + cbWidth - 1 and y = y0..y0 + cbHeight - 1, is set equal to INTRA_PLANAR.

[0210] When decoding a B slice, the variable MergeTriangleFlag[x0][y0], which specifies whether triangle shape-based motion compensation is used to generate the prediction samples of the current coding unit, is derived as follows: - MergeTriangleFlag[ x0 ][ y0 ] is set equal to 1 if all of the following conditions are true: - sps_triangle_enabled_flag is equal to 1. - slice_type equals B. - general_merge_flag[ x0 ][ y0 ] is equal to 1. - MaxNumTriangleMergeCand is greater than or equal to 2. - cbWidth * cbHeight is 64 or greater. - regular_merge_flag[ x0 ][ y0 ] is equal to 0. - merge_subblock_flag[ x0 ][ y0 ] is equal to 0. - ciip_flag[ x0 ][ y0 ] is equal to 0. - weightedPredFlag is equal to 0. - Otherwise, MergeTriangleFlag[ x0 ][ y0 ] is set equal to 0.

[0211] A second embodiment is presented in Table 7. If weightedPredFlag is equal to 1, then the syntax element max_num_merge_cand_minus_max_num_triangle_cand is not present and is inferred with a value such that MaxNumTriangleMergeCand is less than 2.

[0212] [Table 7A] [Table 7B] [Table 7C] [Table 7D] [Table 7E]

[0213] In particular, the following semantics may be used for the second embodiment:

[0214] max_num_merge_cand_minus_max_num_triangle_cand specifies the maximum number of triangle merge mode candidates supported in a slice, subtracted from MaxNumMergeCand.

[0215] When max_num_merge_cand_minus_max_num_triangle_cand is not present and sps_triangle_enabled_flag is equal to 1, slice_type is equal to B, weightedPredFlag is equal to 0 and MaxNumMergeCand is 2 or greater, max_num_merge_cand_minus_max_num_triangle_cand is inferred to be equal to pps_max_num_merge_cand_minus_max_num_triangle_cand_minus1 + 1.

[0216] When max_num_merge_cand_minus_max_num_triangle_cand is not present and sps_triangle_enabled_flag is equal to 1, slice_type is equal to B, weightedPredFlag is equal to 1 and MaxNumMergeCand is 2 or greater, max_num_merge_cand_minus_max_num_triangle_cand is inferred to be equal to MaxNumMergeCand or MaxNumMergeCand-1.

[0217] The maximum number of triangle merge mode candidates, MaxNumTriangleMergeCand, is derived as follows: MaxNumTriangleMergeCand = MaxNumMergeCand - max_num_merge_cand_minus_max_num_triangle_cand

[0218] When max_num_merge_cand_minus_max_num_triangle_cand is present, the value of MaxNumTriangleMergeCand shall be in the range 2 to MaxNumMergeCand, inclusive.

[0219] When max_num_merge_cand_minus_max_num_triangle_cand is not present and (sps_triangle_enabled_flag is equal to 0 or MaxNumMergeCand is less than 2), MaxNumTriangleMergeCand is set equal to 0.

[0220] When MaxNumTriangleMergeCand is equal to 0, no triangle merge mode is allowed for the current slice.

[0221] The disclosed mechanism is applicable not only to TPM and GEO, but also to other non-rectangular prediction and partitioning modes, such as intra-inter prediction combined with triangular partitioning.

[0222] Since TPM and GEO are applied only in B slices, the variable weightedPredFlag in the above embodiment can be directly replaced by the variable pps_weighted_bipred_flag.

[0223] A third embodiment is shown in Table 6 and may be performed by checking whether the value of the weightedPredFlag variable is equal to 0 for a coding unit.

[0224] The variable weightedPredFlag is derived as follows: - weightedPredFlag is set to 0 if all of the following conditions are true: luma_weight_l0_flag[i] is equal to 0 for i from 0 to NumRefIdxActive

[0000] . luma_weight_l1_flag[i] is equal to 0 for i from 0 to NumRefIdxActive

[0001] . chroma_weight_l0_flag[i] is equal to 0 for i from 0 to NumRefIdxActive

[0000] . chroma_weight_l0_flag[i] is equal to 0 for i from 0 to NumRefIdxActive

[0001] . - Otherwise, weightedPredFlag is set to 1.

[0225] The derivation process of weightedPredFlag means that if all weighted flags for luma and chroma components and for all reference indexes of the current slice are 0, weighted prediction is disabled in the current slice; otherwise, weighted prediction may be used for the current slice.

[0226] As disclosed above, the variable weightedPredFlag indicates whether slice-level weighted prediction should be used when obtaining inter-predicted samples for a slice.

[0227] A fourth embodiment is shown in Table 6, where weightedPredFlag is replaced by slice_weighted_pred_flag signaled in the slice header as shown in Table 8.

[0228] As disclosed above, the syntax slice_weighted_pred_flag indicates whether slice-level weighted prediction should be used when obtaining inter-predicted samples of a slice.

[0229] [Table 8A] [Table 8B] [Table 8C] [Table 8D] [Table 8E]

[0230] In particular, the following semantics may be used for the fourth embodiment:

[0231] slice_weighted_pred_flag equal to 0 specifies that weighted prediction is not applied to the current slice. slice_weighted_pred_flag equal to 1 specifies that weighted prediction is applied to the current slice. When not present, the value of slice_weighted_pred_flag is inferred to be 0.

[0232] A fifth embodiment is to disable TPM at the block level with a conformance constraint: In the case of a TPM coded block, the weighting factors for the luma and chroma components of the reference picture for the inter predictors P0 710 and P1 720 (as shown in FIG. 7) should not be present.

[0233] More specifically, refIdxA and predListFlagA specify the reference index and the reference picture list of inter predictor P0, and refIdxB and predListFlagB specify the reference index and the reference picture list of inter predictor P1.

[0234] The variables lumaWeightedFlag and chromaWeightedFlag are derived as follows: lumaWeightedFlagA = predListFlagA ? luma_weight_l1_flag[ refIdxA ] : luma_weight_l0_flag[ refIdxA ] lumaWeightedFlagB = predListFlagB ? luma_weight_l1_flag[ refIdxB ] : luma_weight_l0_flag[ refIdxB ] chromaWeightedFlagA = predListFlagA ? chroma_weight_l1_flag[ refIdxA ] : chroma_weight_l0_flag[ refIdxA ] chromaWeightedFlagB = predListFlagB ? chroma_weight_l1_flag[ refIdxB ] : chroma_weight_l0_flag[ refIdxB ] lumaWeightedFlag = lumaWeightedFlagA || lumaWeightedFlagB chromaWeightedFlag = chromaWeightedFlagA || chromaWeightedFlagB.

[0235] It is a bitstream conformance requirement that lumaWeightedFlag and chromaWeightedFlag should be equal to 0.

[0236] A sixth embodiment is to disable the blending weighted sample prediction process for TPM coded blocks when explicit weighted prediction is used.

[0237] 7 and 8 show the basic concepts behind the given invention for TPM and GEO, respectively. Note that the embodiments for TPM may also be implemented for GEO mode.

[0238] In the case of TPM coded blocks, if there are weighting factors for the luma or chroma components of the reference picture for the inter predictor P0 710 or P1 720, a weighting process with WP parameters (WP parameters 730{w0, O0} and WP parameters 740{w1, O1} for P0 and P1, respectively) is used to generate the inter predictor block, otherwise a weighting process with blending weighting parameters is used to generate the inter predictor for block 750. As shown in FIG. 9, the inter predictor 901 requires two predictive blocks P0 911 and P1 912 with overlapping area 921, where non-zero weights are applied to both blocks 911 and 912 to partially blend the predictors P0 911 and P1 912. The blocks neighboring block 901 are shown in FIG. 9 as 931, 932, 933, 934, 935, and 936. 8 shows the difference between the TPM merge mode and the GEO merge mode. In the case of the GEO merge mode, the overlapped area between the predictors 851 and 852 may not only be located along the diagonal of the inter-prediction block 850. The predictors P0 851 and P1 852 may be received by copying the blocks 810 and 820 from other pictures with or without applying the weights and offsets {w0, O0} 830 and {w1, O1} 840 to the blocks 810 and 820, respectively.

[0239] More specifically, refIdxA and predListFlagA specify the reference index and the reference picture list of inter predictor P0, and refIdxB and predListFlagB specify the reference index and the reference picture list of inter predictor P1.

[0240] The variables lumaWeightedFlag and chromaWeightedFlag are derived as follows: lumaWeightedFlagA = predListFlagA ? luma_weight_l1_flag[ refIdxA ] : luma_weight_l0_flag[ refIdxA ] lumaWeightedFlagB = predListFlagB ? luma_weight_l1_flag[ refIdxB ] : luma_weight_l0_flag[ refIdxB ] chromaWeightedFlagA = predListFlagA ? chroma_weight_l1_flag[ refIdxA ] : chroma_weight_l0_flag[ refIdxA ] chromaWeightedFlagB = predListFlagB ? chroma_weight_l1_flag[ refIdxB ] : chroma_weight_l0_flag[ refIdxB ] lumaWeightedFlag = lumaWeightedFlagA || lumaWeightedFlagB chromaWeightedFlag = chromaWeightedFlagA || chromaWeightedFlagB

[0241] Then, if lumaWeightedFlag is true, the explicit weighting process is called, and if lumaWeightedFlag is false, the blending weighting process is called. Similarly, the chroma components are determined by chromaWeightedFlag.

[0242] For an alternative embodiment, the weighting flags for all components are considered together: if one of lumaWeightedFlag or chromaWeightedFlag is true, the explicit weighting process is invoked, if both lumaWeightedFlag and chromaWeightedFlag are false, the blending weighting process is invoked.

[0243] The explicit weighting process for rectangular blocks predicted using a bi-prediction mechanism is performed as described below.

[0244] The inputs to this process are: - two variables nCbW and nCbH that specify the width and height of the current coding block, - two (nCbW) x (nCbH) arrays predSamplesA and predSamplesB, - prediction list flags predListFlagA and predListFlagB, - reference indices refIdxA and refIdxB, - a variable cIdx that specifies the color component index, - Sample bit depth bitDepth.

[0245] The output of this process is a (nCbW) x (nCbH) array of predicted sample values, pbSamples.

[0246] The variable shift1 is set equal to Max(2, 14 - bitDepth).

[0247] The variables log2Wd, o0, o1, w0, and w1 are derived as follows: - If cIdx is equal to 0 for a luma sample, the following applies: log2Wd = luma_log2_weight_denom + shift1 w0 = predListFlagA ? LumaWeightL1[ refIdxA ] : LumaWeightL0[ refIdxA ] w1 = predListFlagB ? LumaWeightL1[ refIdxB ] : LumaWeightL0[ refIdxB ] o0 = ( predListFlagA ? luma_offset_l1[ refIdxA ] : luma_offset_l0[ refIdxA ] ) << ( BitDepth Y - 8 ) o1 = ( predListFlagB ? luma_offset_l1[ refIdxB ] : luma_offset_l0[ refIdxB ] ) << ( BitDepth Y - 8 ) - Otherwise (cIdx is not equal to 0 for any chroma sample), the following applies: log2Wd = ChromaLog2WeightDenom + shift1 w0 = predListFlagA ? ChromaWeightL1[ refIdxA ][ cIdx - 1 ] : ChromaWeightL0[ refIdxA ][ cIdx - 1 ] w1 = predListFlagA ? ChromaWeightL1[ refIdxB ][ cIdx - 1 ] : ChromaWeightL0[ refIdxB ][ cIdx - 1 ] o0 = ( predListFlagA ? ChromaOffsetL1[ refIdxA ][ cIdx - 1 ] : ChromaOffsetL0[ refIdxA ][ cIdx - 1 ] ) << ( BitDepth C - 8 ) o1 = ( predListFlagB ? ChromaOffsetL1[ refIdxB ][ cIdx - 1 ] : ChromaOffsetL0[ refIdxB ][ cIdx - 1 ] ) << ( BitDepth C - 8 )

[0248] The predicted samples pbSamples[ x ][ y ], with x = 0..nCbW - 1 and y = 0..nCbH - 1, are derived as follows: pbSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) - 1, ( predSamplesA[ x ][ y ] * w0 + predSamplesB[ x ][ y ] * w1 + ( ( o0 + o1 + 1 ) << log2Wd ) ) >> ( log2Wd + 1 ) )

[0249] The slice-level weighted prediction parameters may be represented as a set of variables assigned to each element of the reference picture list, the index of the element being further denoted as "i". These parameters may comprise: - LumaWeightL0[i] - luma_offset_l0[ i ] is an additive offset applied to the luma prediction value for list 0 prediction using RefPicList

[0000] [ i ]. The value of luma_offset_l0[ i ] shall be in the range of -128 to 127, inclusive. When luma_weight_l0_flag[ i ] is equal to 0, luma_offset_l0[ i ] is inferred to be equal to 0.

[0250] The variable LumaWeightL0[ i ] is derived to be equal to ( 1 << luma_log2_weight_denom ) + delta_luma_weight_l0[ i ]. When luma_weight_l0_flag[ i ] is equal to 1, the value of delta_luma_weight_l0[ i ] shall be in the range -128 to 127, inclusive. When luma_weight_l0_flag[ i ] is equal to 0, LumaWeightL0[ i ] shall be equal to 2 luma_log2_weight_denom is assumed to be equal to

[0251] The blending weighting process for rectangular blocks predicted using a bi-prediction mechanism, namely the following process, is performed as described below.

[0252] The inputs to this process are: - two variables nCbW and nCbH that specify the width and height of the current coding block, - two (nCbW) x (nCbH) arrays predSamplesLA and predSamplesLB, - variable triangleDir that specifies the division direction, - A variable cIdx that specifies the color component index.

[0253] The output of this process is a (nCbW) x (nCbH) array of predicted sample values, pbSamples.

[0254] The variable nCbR is derived as follows: nCbR = ( nCbW > nCbH ) ? ( nCbW / nCbH ) : ( nCbH / nCbW )

[0255] The variable bitDepth is derived as follows: - If cIdx is equal to 0, then bitDepth is Y is set equal to - Otherwise, bitDepth is BitDepth C is set equal to

[0256] The variables shift1 and offset1 are derived as follows: - The variable shift1 is set equal to Max(5, 17 - bitDepth). - The variable offset1 is set equal to 1 << ( shift1 - 1 ).

[0257] Depending on the values ​​of triangleDir, wS, and cIdx, the predicted samples pbSamples[ x ][ y ], with x = 0..nCbW - 1 and y = 0..nCbH - 1, are derived as follows: - The variable wIdx is derived as follows: - if cIdx is equal to 0 and triangleDir is equal to 0, the following applies: wIdx = ( nCbW > nCbH ) ? ( Clip3( 0, 8, ( x / nCbR - y ) + 4 ) ) : ( Clip3( 0, 8, ( x - y / nCbR ) + 4 ) ) - Otherwise, if cIdx is equal to 0 and triangleDir is equal to 1, then the following applies: wIdx = ( nCbW > nCbH ) ? ( Clip3( 0, 8, ( nCbH - 1 - x / nCbR - y ) + 4 ) ) ( Clip3( 0, 8, ( nCbW - 1 - x - y / nCbR ) + 4 ) ) Otherwise, if cIdx is greater than 0 and triangleDir is equal to 0, then the following applies: wIdx = ( nCbW > nCbH ) ? ( Clip3( 0, 4, ( x / nCbR - y ) + 2 ) ) : ( Clip3( 0, 4, ( x - y / nCbR ) + 2 ) ) Otherwise (cIdx is greater than 0 and triangleDir is equal to 1), the following applies: wIdx = ( nCbW > nCbH ) ? ( Clip3( 0, 4, ( nCbH - 1 - x / nCbR - y ) + 2 ) ) ( Clip3( 0, 4, ( nCbW - 1 - x - y / nCbR ) + 2 ) ) The variable wValue, which specifies the weight of the predicted sample, is derived using wIdx and cIdx as follows: wValue = ( cIdx = = 0 ) ? Clip3( 0, 8, wIdx ) : Clip3( 0, 8, wIdx * 2 ) The predicted sample values ​​are derived as follows: pbSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) - 1, ( predSamplesLA[ x ][ y ] * wValue + predSamplesLB[ x ][ y ] * ( 8 - wValue ) + offset1 ) >> shift1 )

[0258] For the geometric mode, the blending weighting process for rectangular blocks predicted using a bi-prediction mechanism, namely the following process, is performed as described below.

[0259] The inputs to this process are: - two variables nCbW and nCbH that specify the width and height of the current coding block, - two (nCbW) x (nCbH) arrays predSamplesLA and predSamplesLB, - a variable angleIdx that specifies the angle index of the geometric division, - a variable distanceIdx specifying the distance idx of the geometric division, - A variable cIdx that specifies the color component index.

[0260] The output of this process is a (nCbW) x (nCbH) array of predicted sample values, pbSamples, and the variable partIdx.

[0261] The variable bitDepth is derived as follows: - If cIdx is equal to 0, then bitDepth is Y is set equal to - Otherwise, bitDepth is BitDepth C is set equal to

[0262] The variables shift1 and offset1 are derived as follows: - The variable shift1 is set equal to Max(5, 17 - bitDepth). - The variable offset1 is set equal to 1 << ( shift1 - 1 ).

[0263] Weight array for luma, sampleWeight, with x = 0..nCbW - 1 and y = 0..nCbH - 1 L sampleWeight for [x][y] and chroma C [x][y] is derived as follows:

[0264] The values ​​of the following variables are set: - hwRatio is set to nCbH / nCbW. - displacementX is set to angleIdx. - displacementY is set to (displacementX + 8)%32. - partIdx is set to angleIdx >= 13 && angleIdx <= 27 ? 1 : 0. - rho is set to the following value using a look-up table, denoted as Dis, specified in Tables 8 to 12: rho = (Dis[displacementX]<< 8) + (Dis[displacementY] << 8) The variable shiftHor is set equal to 0 if one of the following conditions is true: angleIdx %16 is equal to 8. angleIdx %16 is not equal to 0 and hwRatio is greater than or equal to 1. Otherwise, shiftHor is set equal to 1. If shiftHor is equal to 0, offsetX and offsetY are derived as follows: offsetX = ( 256 - nCbW ) >> 1 offsetY = ( 256 - nCbH ) >> 1 + angleIdx < 16 ? (distanceIdx * nCbH) >> 3 : -((distanceIdx * nCbH) >> 3) Otherwise, if shiftHor is equal to 1, then offsetX and offsetY are derived as follows: offsetX = ( 256 - nCbW ) >> 1 + angleIdx < 16 ? (distanceIdx * nCbW) >> 3 : -((distanceIdx * nCbW) >> 3) offsetY = (256 - nCbH ) >> 1 The variables weightIdx and weightIdxAbs are calculated using lookup table Table 9 with x=0..nCbW - 1 and y=0..nCbH - 1 as follows: weightIdx = (((x + offsetX)<<1) + 1)*Dis[displacementX] + (((y + offsetY )<<1) + 1))*Dis[displacementY] - rho weightIdxAbs = Clip3(0, 26, abs(weightIdx)) sampleWeight with x = 0..nCbW - 1 and y = 0..nCbH - 1 L The values ​​of [x][y] are set according to Table 10 shown as GeoFilter. sampleWeight L [ x ][ y ] = weightIdx <= 0 ? GeoFilter[weightIdxAbs] : 8 - GeoFilter[weightIdxAbs] Value sampleWeight with x = 0..nCbW - 1 and y = 0..nCbH - 1 C [ x ][ y ] are set as follows: sampleWeight C[ x ][ y ] = sampleWeight L [ (x<< (SubWidthC - 1) ) ][ (y<< (SubHeightC - 1) ) ] Note - SampleWeight L The values ​​of [ x ][ y ] are also sampleWeight L It can be derived from [ x -shiftX][ y-shiftY ]. If angleIdx is greater than 4 and less than 12, or angleIdx is greater than 20 and less than 24, then shiftX is the tangent of the split angle and shiftY is 1, otherwise shiftX is 1 and shiftY is the cotangent of the split angle. If the tangent value is infinity, then shiftX is 1 or shiftY is 0, if the cotangent value is infinity, then shiftX is 0 or shiftY is 1.

[0265] The predicted sample values ​​are derived as follows with cIdx equal or not equal to 0 and X denoted as L or C: pbSamples[ x ][ y ] = partIdx ? Clip3( 0, ( 1 << bitDepth ) - 1, ( predSamplesLA[ x ][ y ] * ( 8 - sampleWeight X [ x ][ y ]) + predSamplesLB[ x ][ y ] * sampleWeight X [ x ][ y ] + offset1 ) >> shift1 ) : Clip3( 0, ( 1 << bitDepth ) - 1, ( predSamplesLA[ x ][ y ] * sampleWeight X [ x ][ y ] + predSamplesLB[ x ][ y ] * ( 8 - sampleWeight X [ x ][ y ]) + offset1 ) >> shift1 )

[0266] [Table 9]

[0267] [Table 10]

[0268] The VVC specification draft 7 (document JVET-P2001-vE, B. Bross, J. Chen, S. Liu, Y.-K. Wang, "Versatile Video Coding (Draft 7)", output document JVET-P2001 of the 16th JVET meeting, Geneva, Switzerland (this document is contained in the file JVET-P2001-v14: http: / / phenix.it-sudparis.eu / jvet / doc_end_user / documents / 16_Geneva / wg11 / JVET-P2001-v14.zip) states that each slice header (SH) associated with a picture header (PH) To reduce the signaling overhead caused by assigning the same or similar values ​​to the same syntax elements in the SH header, the concept of PH was introduced by moving some of the syntax elements of the SH to the PH. As presented in Table 11, the syntax elements for controlling the maximum number of merge candidates for the TPM merge mode are signaled in the PH, while the weighted prediction parameters are still in the SH as shown in Tables 12 and 14. The semantics of the syntax elements used in Tables 12 and 13 are described below.

[0269] [Table 11]

[0270] Picture Header RBSP Semantics The PH contains information that is common to all slices of the coded picture associated with the PH.

[0271] non_reference_picture_flag equal to 1 specifies that the picture associated with PH is not used as a reference picture at all. non_reference_picture_flag equal to 0 specifies that the picture associated with PH may or may not be used as a reference picture.

[0272] gdr_pic_flag equal to 1 specifies that the picture associated with the PH is a gradual decoding refresh (GDR) picture. gdr_pic_flag equal to 0 specifies that the picture associated with the PH is not a GDR picture.

[0273] The no_output_of_prior_pics_flag affects the output of previously decoded pictures in the decoded picture buffer (DPB) after decoding of a Coded Layer Video Sequence Start (CLVSS) picture that is not the first picture in the bitstream.

[0274] recovery_poc_cnt specifies the recovery point of the decoded picture in output order. If the current picture is a GDR picture associated with the PH, and there is a picture picA following the current GDR picture in decoding order in the coded layer video sequence (CLVS) with a PicOrderCntVal equal to the value of PicOrderCntVal+recovery_poc_cnt of the current GDR picture, then the picture picA is called a recovery point picture. Otherwise, the first picture in output order with a PicOrderCntVal greater than the value of PicOrderCntVal+recovery_poc_cnt of the current picture is called a recovery point picture. A recovery point picture shall not precede the current GDR picture in decoding order. The value of recovery_poc_cnt shall be in the range 0 to MaxPicOrderCntLsb - 1, inclusive. NOTE 1 - When gdr_enabled_flag is equal to 1 and the PicOrderCntVal of the current picture is greater than or equal to the RpPicOrderCntVal of the associated GDR picture, the current and subsequent decoded pictures in output order are exact matches of the corresponding pictures produced by starting the decoding process from the previous Intra Random Access Point (IRAP) picture, if any, that precedes the associated GDR picture in decoding order.

[0275] ph_pic_parameter_set_id specifies the value of pps_pic_parameter_set_id for the PPS in use. The value of ph_pic_parameter_set_id shall be in the range 0 to 63, inclusive.

[0276] It is a bitstream conformance requirement that the value of TemporalId of a PH must be greater than or equal to the value of TemporalId of the picture parameter set (PPS) with pps_pic_parameter_set_id equal to ph_pic_parameter_set_id.

[0277] sps_poc_msb_flag equal to 1 specifies that the ph_poc_msb_cycle_present_flag syntax element is present in the PH that references the Sequence Parameter Set (SPS). sps_poc_msb_flag equal to 0 specifies that the ph_poc_msb_cycle_present_flag syntax element is not present in the PH that references the SPS.

[0278] ph_poc_msb_present_flag equal to 1 specifies that the syntax element poc_msb_val is present in PH. ph_poc_msb_present_flag equal to 0 specifies that the syntax element poc_msb_val is not present in PH. The value of ph_poc_msb_present_flag shall be equal to 0 when vps_independent_layer_flag[ GeneralLayerIdx[ nuh_layer_id ] ] is equal to 0 and there is a picture in the current access unit (AU) in the current layer's reference layer.

[0279] poc_msb_val specifies the Picture Order Count (POC) Most Significant Bit (MSB) value of the current picture. The length of the syntax element poc_msb_val is poc_msb_len_minus1 + 1 bits.

[0280] sps_triangle_enabled_flag specifies whether triangle shape-based motion compensation may be used for inter prediction. sps_triangle_enabled_flag equal to 0 specifies that triangle shape-based motion compensation is not used in the coded layer video sequence (CLVS) and that the syntax must be constrained such that merge_triangle_split_dir, merge_triangle_idx0, and merge_triangle_idx1 are not present in the coding unit syntax of the CLVS. sps_triangle_enabled_flag equal to 1 specifies that triangle shape-based motion compensation may be used in the CLVS.

[0281] pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 equal to 0 specifies that pic_max_num_merge_cand_minus_max_num_triangle_cand is present in the PH of the slice that references the Picture Parameter Set (PPS). pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 greater than 0 specifies that pic_max_num_merge_cand_minus_max_num_triangle_cand is not present in the PH that references the PPS. The value of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 shall be in the range 0 to MaxNumMergeCand - 1.

[0282] pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 equal to 0 specifies that pic_max_num_merge_cand_minus_max_num_triangle_cand is present in the PH of the slice that references the PPS. pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 greater than 0 specifies that pic_max_num_merge_cand_minus_max_num_triangle_cand is not present in the PH that references the PPS. The value of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 shall be in the range 0 to MaxNumMergeCand - 1.

[0283] pic_six_minus_max_num_merge_cand specifies the maximum number of merging motion vector prediction (MVP) candidates supported in the slice associated with PH, subtracted from 6. The maximum number of merging MVP candidates, MaxNumMergeCand, is derived as follows: MaxNumMergeCand = 6 - picsix_minus_max_num_merge_cand

[0284] The value of MaxNumMergeCand shall be in the range 1 to 6, inclusive. When not present, the value of pic_six_minus_max_num_merge_cand is inferred to be equal to pps_six_minus_max_num_merge_cand_plus1 - 1.

[0285] [Table 12A] [Table 12B]

[0286] Generic slice header semantics When present, the value of the slice header syntax element slice_pic_order_cnt_lsb shall be the same in all slice headers of a coded picture.

[0287] The variable CuQpDeltaVal, which specifies the difference between the luma quantization parameter and its prediction for a coding unit that includes cu_qp_delta_abs, is set equal to 0. Cb , Qp' Cr , and Qp' CbCr The variable CuQpOffset, which specifies the value that should be used when determining each value of the quantization parameter. Cb , CuQpOffset Cr , and CuQpOffset CbCr are all set equal to 0.

[0288] slice_pic_order_cnt_lsb specifies the picture order count modulo MaxPicOrderCntLsb for the current picture. The length of the slice_pic_order_cnt_lsb syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits. The value of slice_pic_order_cnt_lsb shall be in the range 0 to MaxPicOrderCntLsb - 1, inclusive.

[0289] When the current picture is a GDR picture, the variable RpPicOrderCntVal is derived as follows: RpPicOrderCntVal = PicOrderCntVal + recovery_poc_cnt

[0290] slice_subpic_id specifies the subpicture identifier of the subpicture that contains the slice. If slice_subpic_id is present, the value of the variable SubPicIdx is derived such that SubpicIdList[ SubPicIdx ] is equal to slice_subpic_id. Otherwise (slice_subpic_id is not present), the variable SubPicIdx is derived to be equal to 0. The length of slice_subpic_id in bits is derived as follows: - If sps_subpic_id_signalling_present_flag is equal to 1, the length of slice_subpic_id is equal to sps_subpic_id_len_minus1 + 1. - Otherwise, if ph_subpic_id_signalling_present_flag is equal to 1, the length of slice_subpic_id is equal to ph_subpic_id_len_minus1 + 1. - Otherwise, if pps_subpic_id_signalling_present_flag is equal to 1, the length of slice_subpic_id is equal to pps_subpic_id_len_minus1 + 1. - Otherwise, the length of slice_subpic_id is equal to Ceil( Log2 ( sps_num_subpics_minus1 + 1 ) ).

[0291] slice_address specifies the slice address of the slice. When not present, the value of slice_address is inferred to be equal to 0.

[0292] If rect_slice_flag is equal to 0, the following applies: - A slice address is a raster scan tile index. - slice_address is Ceil( Log2 ( NumTilesInPic ) ) bits long. - The value of slice_address shall be in the range 0 to NumTilesInPic - 1, inclusive.

[0293] Otherwise (rect_slice_flag is equal to 1), the following applies: - The slice address is the slice index of the slice within the SubPicIdx-th subpicture. - slice_address is Ceil( Log2( NumSlicesInSubpic[ SubPicIdx ] ) ) bits long. - The value of slice_address shall be in the range 0 to NumSlicesInSubpic[SubPicIdx] - 1, inclusive.

[0294] It is a requirement of bitstream conformance that the following constraints apply: - If rect_slice_flag is equal to 0 or subpics_present_flag is equal to 0, the value of slice_address must not be equal to the value of slice_address of any other coded slice Network Abstraction Layer (NAL) unit of the same coded picture. - Otherwise, the slice_subpic_id and slice_address value pair must not be equal to the slice_subpic_id and slice_address value pair of any other coded slice NAL unit of the same coded picture. - When rect_slice_flag is equal to 0, the slices of a picture shall be in ascending order of their slice_address values. - The shape of a slice of a picture shall be such that each coding tree unit (CTU), when decoded, must have its entire left and top boundaries consisting of either a picture boundary or the boundaries of a previously decoded CTU.

[0295] num_tiles_in_slice_minus1+1, when present, specifies the number of tiles in the slice. The value of num_tiles_in_slice_minus1 shall be in the range 0 to NumTilesInPic - 1, inclusive.

[0296] The variable NumCtuInCurrSlice, which specifies the number of CTUs in the current slice, and the list CtbAddrInCurrSlice[ i ], for i ranging from 0 to NumCtuInCurrSlice - 1 inclusive, which specifies the picture raster scan address of the i-th coding tree block (CTB) in the slice, are derived as follows: if( rect_slice_flag ) { picLevelSliceIdx = SliceSubpicToPicIdx[ SubPicIdx ][ slice_address ] NumCtuInCurrSlice = NumCtuInSlice[ picLevelSliceIdx ] for( i = 0; i < NumCtuInCurrSlice; i++ ) CtbAddrInCurrSlice[ i ] = CtbAddrInSlice[ picLevelSliceIdx ][ i ] } else { NumCtuInCurrSlice = 0 for( tileIdx = slice_address; tileIdx <= slice_address + num_tiles_in_slice_minus1[ i ]; tileIdx++ ) { tileX = tileIdx % NumTileColumns tileY = tileIdx / NumTileColumns for( ctbY = tileRowBd[ tileY ]; ctbY < tileRowBd[ tileY + 1 ]; ctbY++ ) { for( ctbX = tileColBd[ tileX ]; ctbX < tileColBd[ tileX + 1 ]; ctbX++ ) { CtbAddrInCurrSlice[ NumCtuInCurrSlice ] = ctbY * PicWidthInCtb + ctbX NumCtuInCurrSlice++ } } } }

[0297] The variables SubPicLeftBoundaryPos, SubPicTopBoundaryPos, SubPicRightBoundaryPos, and SubPicBotBoundaryPos are derived as follows: if( subpic_treated_as_pic_flag[ SubPicIdx ] ) { SubPicLeftBoundaryPos = subpic_ctu_top_left_x[ SubPicIdx ] * CtbSizeY SubPicRightBoundaryPos = Min( pic_width_max_in_luma_samples - 1, ( subpic_ctu_top_left_x[ SubPicIdx ] + subpic_width_minus1[ SubPicIdx ] + 1 ) * CtbSizeY - 1) SubPicTopBoundaryPos = subpic_ctu_top_left_y[ SubPicIdx ] *CtbSizeY SubPicBotBoundaryPos = Min( pic_height_max_in_luma_samples - 1, ( subpic_ctu_top_left_y[ SubPicIdx ] + subpic_height_minus1[ SubPicIdx ] + 1 ) * CtbSizeY - 1) }

[0298] slice_type specifies the coding type of the slice according to Table 13.

[0299] [Table 13]

[0300] slice_rpl_sps_flag[ i ] equal to 1 specifies that reference picture list i of the current slice is derived based on one of the ref_pic_list_struct( listIdx, rplsIdx ) syntax structures with listIdx equal to i in the SPS. slice_rpl_sps_flag[ i ] equal to 0 specifies that reference picture list i of the current slice is derived based on the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure with listIdx equal to i that is included directly in the slice header of the current picture.

[0301] When slice_rpl_sps_flag[ i ] is not present, the following applies: - If pic_rpl_present_flag is equal to 1, the value of slice_rpl_sps_flag[ i ] is inferred to be equal to pic_rpl_sps_flag[ i ]. - Otherwise, if num_ref_pic_lists_in_sps[ i ] is equal to 0, the value of ref_pic_list_sps_flag[ i ] is inferred to be equal to 0. - Otherwise, if num_ref_pic_lists_in_sps[i] is greater than 0 and rpl1_idx_present_flag is equal to 0, the value of slice_rpl_sps_flag

[0001] is inferred to be equal to slice_rpl_sps_flag

[0000] .

[0302] slice_rpl_idx[ i ] specifies an index into the list of ref_pic_list_struct( listIdx, rplsIdx ) syntax structures with listIdx equal to i contained in the SPS of ref_pic_list_struct( listIdx, rplsIdx ) syntax structures with listIdx equal to i that are used for the derivation of reference picture list i of the current picture. The syntax element slice_rpl_idx[ i ] is represented by Ceil( Log2( num_ref_pic_lists_in_sps[ i ] ) ) bits. When not present, the value of slice_rpl_idx[ i ] is inferred to be equal to 0. The value of slice_rpl_idx[ i ] shall be in the range 0 to num_ref_pic_lists_in_sps[ i ] - 1, inclusive. When slice_rpl_sps_flag[ i ] is equal to 1 and num_ref_pic_lists_in_sps[ i ] is equal to 1, the value of slice_rpl_idx[ i ] is inferred to be equal to 0. When slice_rpl_sps_flag[ i ] is equal to 1 and rpl1_idx_present_flag is equal to 0, the value of slice_rpl_idx

[0001] is inferred to be equal to slice_rpl_idx

[0000] .

[0303] The variable RplsIdx[ i ] is derived as follows: if( pic_rpl_present_flag ) RplsIdx[ i ] = PicRplsIdx[ i ] else RplsIdx[ i ] = slice_rpl_sps_flag[ i ] ? slice_rpl_idx[ i ] : num_ref_pic_lists_in_sps[ i ]

[0304] slice_poc_lsb_lt[ i ][ j ] specifies the value of the picture order count modulo MaxPicOrderCntLsb of the j-th LTRP entry in the i-th reference picture list. The length of the slice_poc_lsb_lt[ i ][ j ] syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits.

[0305] The variables PocLsbLt[i][j] are derived as follows: if( pic_rpl_present_flag ) PocLsbLt[ i ][ j ] = PicPocLsbLt[ i ][ j ] (142) else PocLsbLt[ i ][ j ] = ltrp_in_slice_header_flag[ i ][ RplsIdx[ i ] ] ? slice_poc_lsb_lt[ i ][ j ] : rpls_poc_lsb_lt[ listIdx ][ RplsIdx[ i ] ][ j ] (143)

[0306] slice_delta_poc_msb_present_flag[i][j] equal to 1 specifies that slice_delta_poc_msb_cycle_lt[i][j] is present. slice_delta_poc_msb_present_flag[i][j] equal to 0 specifies that slice_delta_poc_msb_cycle_lt[i][j] is not present.

[0307] Let prevTid0Pic be the previous picture in decoding order that has the same nuh_layer_id as the current picture, has TemporalId equal to 0, and is not a Random Access Skipped Leading (RASL) picture or a Random Access Decodable Leading (RADL) picture. Let setOfPrevPocVals be the set consisting of: - PicOrderCntVal of prevTid0Pic, - the PicOrderCntVal of each picture referenced by an entry in RefPicList

[0000] or RefPicList

[0001] of prevTid0Pic and having the same nuh_layer_id as the current picture, - The PicOrderCntVal of each picture that follows prevTid0Pic in decoding order, has the same nuh_layer_id as the current picture, and precedes the current picture in decoding order.

[0308] When pic_rpl_present_flag is equal to 0 and there are two or more values ​​in setOfPrevPocVals for which PocLsbLt[i][j] modulo MaxPicOrderCntLsb is equal to it, the value of slice_delta_poc_msb_present_flag[i][j] shall be equal to 1.

[0309] slice_delta_poc_msb_cycle_lt[ i ][ j ] specifies the value of the variable FullPocLt[ i ][ j ] as follows: if( pic_rpl_present_flag ) FullPocLt[ i ][ j ] = PicFullPocLt[ i ][ j ] else { if( j == 0 ) DeltaPocMsbCycleLt[ i ][ j ] = delta_poc_msb_cycle_lt[ i ][ j ] else DeltaPocMsbCycleLt[ i ][ j ] = delta_poc_msb_cycle_lt[ i ][ j ] + DeltaPocMsbCycleLt[ i ][ j - 1 ] FullPocLt[ i ][ j ] = PicOrderCntVal - DeltaPocMsbCycleLt[ i ][ j ] * MaxPicOrderCntLsb - ( PicOrderCntVal & ( MaxPicOrderCntLsb - 1 ) ) + PocLsbLt[ i ][ j ] }

[0310] The value of slice_delta_poc_msb_cycle_lt[ i ][ j ] is between 0 and 2, inclusive. (32 - log2_max_pic_order_cnt_lsb_minus4 - 4 ) When not present, the value of slice_delta_poc_msb_cycle_lt[ i ][ j ] is inferred to be equal to 0.

[0311] num_ref_idx_active_override_flag equal to 1 specifies that the syntax element num_ref_idx_active_minus1

[0000] is present for P slices and B slices, and that the syntax element num_ref_idx_active_minus1

[0001] is present for B slices. num_ref_idx_active_override_flag equal to 0 specifies that the syntax elements num_ref_idx_active_minus1

[0000] and num_ref_idx_active_minus1

[0001] are not present. When not present, the value of num_ref_idx_active_override_flag is inferred to be equal to 1.

[0312] The num_ref_idx_active_minus1[ i ] is used to derive the variable NumRefIdxActive[ i ] as specified by Equation 145. The value of num_ref_idx_active_minus1[ i ] shall be in the range 0 to 14, inclusive.

[0313] For i equal to 0 or 1, when the current slice is a B slice, num_ref_idx_active_override_flag is equal to 1, and num_ref_idx_active_minus1[ i ] is not present, num_ref_idx_active_minus1[ i ] is inferred to be equal to 0.

[0314] When the current slice is a P slice, num_ref_idx_active_override_flag is equal to 1, and num_ref_idx_active_minus1

[0000] is not present, num_ref_idx_active_minus1

[0000] is inferred to be equal to 0.

[0315] The variable NumRefIdxActive[ i ] is derived as follows: for( i = 0 ; i < 2 ; i++ ) { if( slice_type = = B || ( slice_type = = P && i = = 0 ) ) { if( num_ref_idx_active_override_flag ) NumRefIdxActive[ i ] = num_ref_idx_active_minus1[ i ] + 1 (145) else { if( num_ref_entries[ i ][ RplsIdx[ i ] ] >= num_ref_idx_preset_active_minus1[ i ] + 1 ) NumRefIdxActive[ i ] = num_ref_idx_preset_active_minus1[ i ] + 1 else NumRefIdxActive[ i ] = num_ref_entries[ i ][ RplsIdx[ i ] ] } } else / * slice_type = = I || ( slice_type = = P && i = = 1 ) * / NumRefIdxActive[ i ] = 0 }

[0316] A value of −1 for NumRefIdxActive[ i ] specifies the maximum reference index for reference picture list i that may be used to decode a slice. When the value of NumRefIdxActive[ i ] is equal to 0, no reference index for reference picture list i may be used to decode a slice.

[0317] When the current slice is a P slice, the value of NumRefIdxActive

[0000] shall be greater than 0.

[0318] When the current slice is a B slice, both NumRefIdxActive

[0000] and NumRefIdxActive

[0001] shall be greater than 0.

[0319] [Table 14A] [Table 14B]

[0320] Weighted Prediction Parameter Semantics luma_log2_weight_denom is the base 2 logarithm of the denominator for all luma weighting coefficients. Values ​​of luma_log2_weight_denom shall be in the range 0 to 7, inclusive.

[0321] delta_chroma_log2_weight_denom is the log base 2 delta of the denominators for all chroma weighting coefficients. When delta_chroma_log2_weight_denom is not present, it is inferred to be equal to 0.

[0322] The variable ChromaLog2WeightDenom is derived to be equal to luma_log2_weight_denom + delta_chroma_log2_weight_denom and its value shall be in the range 0 to 7, inclusive.

[0323] luma_weight_l0_flag[ i ] equal to 1 specifies that weighting factors for the luma component of list 0 prediction using RefPicList

[0000] [ i ] are present. luma_weight_l0_flag[ i ] equal to 0 specifies that these weighting factors are not present.

[0324] chroma_weight_l0_flag[ i ] equal to 1 specifies that weighting factors for chroma prediction values ​​for list 0 prediction using RefPicList

[0000] [ i ] are present. chroma_weight_l0_flag[ i ] equal to 0 specifies that these weighting factors are not present. When chroma_weight_l0_flag[ i ] is not present, it is inferred to be equal to 0.

[0325] delta_luma_weight_l0[ i ] is the delta weighting factor applied to the luma prediction value for list 0 prediction using RefPicList

[0000] [ i ].

[0326] The variable LumaWeightL0[ i ] is derived to be equal to ( 1 << luma_log2_weight_denom ) + delta_luma_weight_l0[ i ]. When luma_weight_l0_flag[ i ] is equal to 1, the value of delta_luma_weight_l0[ i ] shall be in the range -128 to 127, inclusive. When luma_weight_l0_flag[ i ] is equal to 0, LumaWeightL0[ i ] is inferred to be equal to 2luma_log2_weight_denom.

[0327] luma_offset_l0[ i ] is an additive offset applied to the luma prediction value for list 0 prediction using RefPicList

[0000] [ i ]. The value of luma_offset_l0[ i ] shall be in the range of -128 to 127, inclusive. When luma_weight_l0_flag[ i ] is equal to 0, luma_offset_l0[ i ] is inferred to be equal to 0.

[0328] delta_chroma_weight_l0[ i ][ j ] is the delta weighting factor applied to the chroma prediction value for list 0 prediction using RefPicList

[0000]

【 i ], where j equals 0 for Cb and j equals 1 for Cr.

[0329] The variable ChromaWeightL0[ i ][ j ] is derived to be equal to ( 1 << ChromaLog2WeightDenom ) + delta_chroma_weight_l0[ i ][ j ]. When chroma_weight_l0_flag[ i ] is equal to 1, the value of delta_chroma_weight_l0[ i ][ j ] shall be in the range -128 to 127, inclusive. When chroma_weight_l0_flag[ i ] is equal to 0, ChromaWeightL0[ i ][ j ] shall be 2 ChromaLog2WeightDenomis assumed to be equal to

[0330] delta_chroma_offset_l0[ i ][ j ] is the additive offset delta applied to the chroma prediction value for list 0 prediction using RefPicList

[0000]

【 i ], where j equals 0 for Cb and j equals 1 for Cr.

[0331] The variable ChromaOffsetL0[i][j] is derived as follows: ChromaOffsetL0[ i ][ j ] = Clip3( -128, 127, (128 + delta_chroma_offset_l0[ i ][ j ] - ( (128 * ChromaWeightL0[ i ][ j ] ) >> ChromaLog2WeightDenom ) ) )

[0332] The value of delta_chroma_offset_l0[ i ][ j ] shall be in the range of -4 * 128 to 4 * 127, inclusive. When chroma_weight_l0_flag[ i ] is equal to 0, ChromaOffsetL0[ i ][ j ] is inferred to be equal to 0.

[0333] luma_weight_l1_flag[ i ], chroma_weight_l1_flag[ i ], delta_luma_weight_l1[ i ], luma_offset_l1[ i ], delta_chroma_weight_l1[ i ][ j ], and delta_chroma_offset_l1[ i ][ j ] have the same semantics as luma_weight_l0_flag[ i ], chroma_weight_l0_flag[ i ], delta_luma_weight_l0[ i ], luma_offset_l0[ i ], delta_chroma_weight_l0[ i ][ j ], and delta_chroma_offset_l0[ i ][ j ], respectively, with l0, L0, List0, and List0 replaced by l1, L1, List1, and List1, respectively.

[0334] The variable sumWeightL0Flags is derived to be equal to the sum of luma_weight_l0_flag[ i ] + 2 * chroma_weight_l0_flag[ i ], for i = 0..NumRefIdxActive

[0000] - 1.

[0335] When slice_type is equal to B, the variable sumWeightL1Flags is derived to be equal to the sum of luma_weight_l1_flag[ i ] + 2 * chroma_weight_l1_flag[ i ], for i = 0..NumRefIdxActive

[0001] - 1.

[0336] It is a bitstream conformance requirement that when slice_type is equal to P, sumWeightL0Flags must be less than or equal to 24, and when slice_type is equal to B, the sum of sumWeightL0Flags and sumWeightL1Flags must be less than or equal to 24.

[0337] Reference Picture List Structure Semantics The ref_pic_list_struct( listIdx, rplsIdx ) syntax structure can be present in the SPS or in the slice header. Depending on whether the syntax structure is included in the slice header or in the SPS, the following applies: - If present in the slice header, the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure specifies the reference picture list listIdx of the current picture (the picture that contains the slice). - Otherwise (present in the SPS), the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure specifies candidates for the reference picture list listIdx, and the term "current picture" in the semantics specified in the remainder of this section refers to each picture that 1) has one or more slices with ref_pic_list_idx[ listIdx ] equal to an index into the list of ref_pic_list_struct( listIdx, rplsIdx ) syntax structures contained in the SPS, and 2) is a Coded Video Sequence (CVS) that references the SPS.

[0338] num_ref_entries[listIdx][rplsIdx] specifies the number of entries in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. The value of num_ref_entries[listIdx][rplsIdx] shall be in the range of 0 to MaxDecPicBuffMinus1 + 14, inclusive.

[0339] ltrp_in_slice_header_flag[listIdx][rplsIdx] equal to 0 specifies that the POC LSB of the LTRP entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is present in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. ltrp_in_slice_header_flag[listIdx][rplsIdx] equal to 1 specifies that the POC LSB of the Long Term Reference Picture (LTRP) entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is not present in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure.

[0340] inter_layer_ref_pic_flag[listIdx][rplsIdx][i] equal to 1 specifies that the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is an inter-layer reference picture (ILRP) entry. inter_layer_ref_pic_flag[listIdx][rplsIdx][i] equal to 0 specifies that the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is not an ILRP entry. When not present, the value of inter_layer_ref_pic_flag[listIdx][rplsIdx][i] is inferred to be equal to 0.

[0341] st_ref_pic_flag[listIdx][rplsIdx][i] equal to 1 specifies that the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is a STRP entry. st_ref_pic_flag[listIdx][rplsIdx][i] equal to 0 specifies that the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is an LTRP entry. When inter_layer_ref_pic_flag[listIdx][rplsIdx][i] is equal to 0 and st_ref_pic_flag[listIdx][rplsIdx][i] is not present, the value of st_ref_pic_flag[listIdx][rplsIdx][i] is inferred to be equal to 1.

[0342] The variables NumLtrpEntries[ listIdx ][ rplsIdx ] are derived as follows: for( i = 0, NumLtrpEntries[ listIdx ][ rplsIdx ] = 0; i < num_ref_entries[ listIdx ][ rplsIdx ]; i++ ) if( !inter_layer_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] && !st_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] ) (151) NumLtrpEntries[ listIdx ][ rplsIdx ]++

[0343] abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] specifies the value of the variable AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] as follows: if( sps_weighted_pred_flag || sps_weighted_bipred_flag ) AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] = abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] else AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] = abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] + 1

[0344] The value of abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] is between 0 and 2, inclusive. 15 It is assumed to be in the range -1.

[0345] strp_entry_sign_flag[listIdx][rplsIdx][i] equal to 1 specifies that the i-th entry in the syntax structure ref_pic_list_struct(listIdx,rplsIdx) has a value greater than or equal to 0. strp_entry_sign_flag[listIdx][rplsIdx][i] equal to 0 specifies that the i-th entry in the syntax structure ref_pic_list_struct(listIdx,rplsIdx) has a value less than 0. When not present, the value of strp_entry_sign_flag[listIdx][rplsIdx][i] is inferred to be equal to 1.

[0346] The list DeltaPocValSt[ listIdx ][ rplsIdx ] is derived as follows: for( i = 0; i < num_ref_entries[ listIdx ][ rplsIdx ]; i++ ) if( !inter_layer_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] && st_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] ) DeltaPocValSt[ listIdx ][ rplsIdx ][ i ] = ( strp_entry_sign_flag[ listIdx ][ rplsIdx ][ i ] ) ? AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ] : 0 - AbsDeltaPocSt[ listIdx ][ rplsIdx ][ i ]

[0347] rpls_poc_lsb_lt[listIdx][rplsIdx][i] specifies the value of the picture order count modulo MaxPicOrderCntLsb of the picture referenced by the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. The length of the rpls_poc_lsb_lt[listIdx][rplsIdx][i] syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits.

[0348] ilrp_idx[listIdx][rplsIdx][i] specifies the index into the list of direct reference layers of the ILRP of the i-th entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. The value of ilrp_idx[listIdx][rplsIdx][i] shall be in the range of 0 to NumDirectRefLayers[GeneralLayerIdx[nuh_layer_id]] - 1, inclusive.

[0349] Therefore, different mechanisms may be used to allow control of the GEO / TPM merge mode conditional on whether WP is applied to a reference picture, namely: - moving the WP parameters listed in Table 14 from SH to PH; - moving GEO / TPM parameters back from PH to SH, from changing the semantics of MaxNumTriangleMergeCand by setting it equal to 0 or 1 for such slices, i.e. when reference pictures with WP may be used (e.g. when at least one of the flags lumaWeightedFlag or lumaWeightedFlag is equal to true); Reference blocks P0 and P1 are taken.

[0350] For the TPM merge mode, exemplary reference blocks P0 and P1 are indicated by 710 and 720, respectively, in Figure 7. For the GEO merge mode, exemplary reference blocks P0 and P1 are indicated by 810 and 820, respectively, in Figure 8.

[0351] In one embodiment, when the WP parameters and enablement of non-rectangular modes (eg, GEO and TPM) are signaled in the picture header, the following syntax may be used, as shown in the table below.

[0352] [Table 15A] [Table 15B]

[0353] When all values ​​of luma_weight_l0_flag[ i ], chroma_weight_l0_flag[ i ], luma_weight_l1_flag[ j ], and chroma_weight_l1_flag[ j ] are set to 0 (the value of i = 0..NumRefIdxActive

[0000] , the value of j = 0..NumRefIdxActive

[0001] ), the variable WPDisabled is set equal to 1, otherwise the value of WPDisabled is set equal to 0.

[0354] When the variable WPDisabled is set equal to 0, the value of pic_max_num_merge_cand_minus_max_num_triangle_cand is set equal to MaxNumMergeCand.

[0355] In a second embodiment, the signaling of WP parameters and the enablement of non-rectangular modes (eg, GEO and TPM) is performed in the slice header. An example syntax is given in the table below.

[0356] [Table 16A] [Table 16B] [Table 16C] [Table 16D] [Table 16E]

[0357] When all of the values ​​of luma_weight_l0_flag[ i ], chroma_weight_l0_flag[ i ], luma_weight_l1_flag[ j ], and chroma_weight_l1_flag[ j ] are set to 0, the value of i = 0..NumRefIdxActive

[0000] , and the value of j = 0..NumRefIdxActive

[0001] , the variable WPDisabled is set equal to 1, otherwise the value of WPDisabled is set equal to 0.

[0358] When the variable WPDisabled is set equal to 0, the value of max_num_merge_cand_minus_max_num_triangle_cand is set equal to MaxNumMergeCand.

[0359] In the embodiments disclosed above, the weighted prediction parameters may be signaled either in the picture header or in the slice header.

[0360] In a third embodiment, the decision of whether TPM or GEO is enabled is performed with consideration of the reference picture lists that a block may use for non-rectangular weighted prediction. When the merge list for a block contains elements from only one reference picture list k, the value of the variable WPDisabled[k] determines whether this merge mode is enabled or not.

[0361] In a fourth embodiment, the merge list for non-rectangular inter prediction modes is constructed in such a way that it contains only elements for which weighted prediction is not enabled.

[0362] The following portion of the specification illustrates the fourth embodiment.

[0363] The inputs to this process are: - the luma location ( xCb, yCb ) of the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples, - The variable cbHeight that specifies the height of the current coding block in luma samples.

[0364] The output of this process, where X is either 0 or 1, is: - the availability flags availableFlagA0, availableFlagA1, availableFlagB0, availableFlagB1, and availableFlagB2 of the adjacent coding units, - the reference indices refIdxLXA0, refIdxLXA1, refIdxLXB0, refIdxLXB1, and refIdxLXB2 of the neighboring coding units; - prediction list usage flags predFlagLXA0, predFlagLXA1, predFlagLXB0, predFlagLXB1, and predFlagLXB2 of adjacent coding units; - motion vectors mvLXA0, mvLXA1, mvLXB0, mvLXB1, and mvLXB2 at 1 / 16 fractional sample accuracy of adjacent coding units; - Half-sample interpolation filter indices hpelIfIdxA0, hpelIfIdxA1, hpelIfIdxB0, hpelIfIdxB1, and hpelIfIdxB2, - The bi-prediction weight indices bcwIdxA0, bcwIdxA1, bcwIdxB0, bcwIdxB1, and bcwIdxB2.

[0365] For the derivation of availableFlagB1, refIdxLXB1, predFlagLXB1, mvLXB1, hpelIfIdxB1, and bcwIdxB1, the following applies: - The inner luma location (xNbB1, yNbB1) of the neighboring luma coding block is set equal to (xCb + cbWidth - 1, yCb - 1). - The neighboring block availability derivation process as specified in Section 6.4.4 is called with as input the current luma location (xCurr, yCurr) set equal to (xCb, yCb), the neighboring luma locations (xNbB1, yNbB1), checkPredModeY set equal to TRUE, and cIdx set equal to 0, and the output is assigned to the block availability flag availableB1. The variables availableFlagB1, refIdxLXB1, predFlagLXB1, mvLXB1, hpelIfIdxB1, and bcwIdxB1 are derived as follows: - if availableB1 is equal to FALSE, availableFlagB1 is set equal to 0, X is 0 or 1, both components of mvLXB1 are set equal to 0, refIdxLXB1 is set equal to -1, predFlagLXB1 is set equal to 0, hpelIfIdxB1 is set equal to 0, and bcwIdxB1 is set equal to 0. - Otherwise, availableFlagB1 is set equal to 1 and the following allocation is made: mvLXB1= MvLX[ xNbB1][ yNbB1] (501) refIdxLXB1= RefIdxLX[ xNbB1][ yNbB1] (502) predFlagLXB1= PredFlagLX[ xNbB1][ yNbB1] (503) hpelIfIdxB1= HpelIfIdx[ xNbB1][ yNbB1] (504) bcwIdxB1= BcwIdx[ xNbB1][ yNbB1] (505)

[0366] For the derivation of availableFlagA1, refIdxLXA1, predFlagLXA1, mvLXA1, hpelIfIdxA1, and bcwIdxA1, the following applies: - The luma location (xNbA1, yNbA1) inside the neighboring luma coding block is set equal to (xCb - 1, yCb + cbHeight - 1). - The neighboring block availability derivation process as specified in Section 6.4.4 is called with as input the current luma location (xCurr, yCurr) set equal to (xCb, yCb), the neighboring luma locations (xNbA1, yNbA1), checkPredModeY set equal to TRUE, and cIdx set equal to 0, and the output is assigned to the block availability flag availableA1. The variables availableFlagA1, refIdxLXA1, predFlagLXA1, mvLXA1, hpelIfIdxA1, and bcwIdxA1 are derived as follows: If one or more of the following conditions are true, then availableFlagA1 is set equal to 0, X is 0 or 1, both components of mvLXA1 are set equal to 0, refIdxLXA1 is set equal to -1, predFlagLXA1 is set equal to 0, hpelIfIdxA1 is set equal to 0, and bcwIdxA1 is set equal to 0: - availableA1 equals FALSE. - availableB1 is equal to TRUE and luma locations (xNbA1, yNbA1) and (xNbB1, yNbB1) have the same motion vector and the same reference index. - WPDisabledX[ RefIdxLX[ xNbA1][ yNbA1] ] is set to 0 and the merge mode is non-rectangular (for example, the triangle flag is set equal to 1 for the block within the current luma location ( xCurr, yCurr )). - WPDisabledX[ RefIdxLX[ xNbB1][ yNbB1] ] is set to 0 and the merge mode is non-rectangular (for example, the triangle flag is set equal to 1 for the block within the current luma location ( xCurr, yCurr )). - Otherwise, availableFlagA1 is set equal to 1 and the following allocation is made: mvLXA1= MvLX[ xNbA1][ yNbA1] (506) refIdxLXA1= RefIdxLX[ xNbA1][ yNbA1] (507) predFlagLXA1= PredFlagLX[ xNbA1][ yNbA1] (508) hpelIfIdxA1= HpelIfIdx[ xNbA1][ yNbA1] (509) bcwIdxA1= BcwIdx[ xNbA1][ yNbA1] (510)

[0367] For the derivation of availableFlagB0, refIdxLXB0, predFlagLXB0, mvLXB0, hpelIfIdxB0, and bcwIdxB0, the following applies: - The inner luma location (xNbB0, yNbB0) of the neighboring luma coding block is set equal to (xCb + cbWidth, yCb - 1). - The neighboring block availability derivation process as specified in Section 6.4.4 is called with as input the current luma location (xCurr, yCurr) set equal to (xCb, yCb), the neighboring luma location (xNbB0, yNbB0), checkPredModeY set equal to TRUE, and cIdx set equal to 0, and the output is assigned to the block availability flag availableB0. The variables availableFlagB0, refIdxLXB0, predFlagLXB0, mvLXB0, hpelIfIdxB0, and bcwIdxB0 are derived as follows: If one or more of the following conditions are true, then availableFlagB0 is set equal to 0, X is 0 or 1, both components of mvLXB0 are set equal to 0, refIdxLXB0 is set equal to -1, predFlagLXB0 is set equal to 0, hpelIfIdxB0 is set equal to 0, and bcwIdxB0 is set equal to 0: - availableB0 equals FALSE. - availableB1 is equal to TRUE and luma locations (xNbB1, yNbB1) and (xNbB0, yNbB0) have the same motion vector and the same reference index. - WPDisabledX[ RefIdxLX[ xNbB0][ yNbB0] ] is set to 0 and the merge mode is non-rectangular (for example, the triangle flag is set equal to 1 for the block within the current luma location ( xCurr, yCurr )). - WPDisabledX[ RefIdxLX[ xNbB1][ yNbB1] ] is set to 0 and the merge mode is non-rectangular (for example, the triangle flag is set equal to 1 for the block within the current luma location ( xCurr, yCurr )). - - Otherwise, availableFlagB0 is set equal to 1 and the following allocation is made: mvLXB0= MvLX[ xNbB0][ yNbB0] (511) refIdxLXB0= RefIdxLX[ xNbB0][ yNbB0] (512) predFlagLXB0= PredFlagLX[ xNbB0][ yNbB0] (513) hpelIfIdxB0= HpelIfIdx[ xNbB0][ yNbB0] (514) bcwIdxB0= BcwIdx[ xNbB0][ yNbB0] (515)

[0368] For the derivation of availableFlagA0, refIdxLXA0, predFlagLXA0, mvLXA0, hpelIfIdxA0, and bcwIdxA0, the following applies: - The inner luma location (xNbA0, yNbA0) of the neighboring luma coding block is set equal to (xCb - 1, yCb + cbWidth). - The neighboring block availability derivation process as specified in Section 6.4.4 is called with as input the current luma location (xCurr, yCurr) set equal to (xCb, yCb), the neighboring luma location (xNbA0, yNbA0), checkPredModeY set equal to TRUE, and cIdx set equal to 0, and the output is assigned to the block availability flag availableA0. The variables availableFlagA0, refIdxLXA0, predFlagLXA0, mvLXA0, hpelIfIdxA0, and bcwIdxA0 are derived as follows: If one or more of the following conditions are true, then availableFlagA0 is set equal to 0, X is 0 or 1, both components of mvLXA0 are set equal to 0, refIdxLXA0 is set equal to -1, predFlagLXA0 is set equal to 0, hpelIfIdxA0 is set equal to 0, and bcwIdxA0 is set equal to 0: - availableA0 equals FALSE. - availableA1 is equal to TRUE and luma locations (xNbA1, yNbA1) and (xNbA0, yNbA0) have the same motion vector and the same reference index. - WPDisabledX[ RefIdxLX[ xNbA0][ yNbA0] ] is set to 0 and the merge mode is non-rectangular (for example, the triangle flag is set equal to 1 for the block within the current luma location ( xCurr, yCurr )). - WPDisabledX[ RefIdxLX[ xNbA1][ yNbA1] ] is set to 0 and the merge mode is non-rectangular (for example, the triangle flag is set equal to 1 for the block within the current luma location ( xCurr, yCurr )). - Otherwise, availableFlagA0 is set equal to 1 and the following allocation is made: mvLXA0= MvLX[ xNbA0][ yNbA0] (516) refIdxLXA0= RefIdxLX[ xNbA0][ yNbA0] (517) predFlagLXA0= PredFlagLX[ xNbA0][ yNbA0] (518) hpelIfIdxA0= HpelIfIdx[ xNbA0][ yNbA0] (519) bcwIdxA0= BcwIdx[ xNbA0][ yNbA0] (520)

[0369] For the derivation of availableFlagB2, refIdxLXB2, predFlagLXB2, mvLXB2, hpelIfIdxB2, and bcwIdxB2, the following applies: - The inner luma location (xNbB2, yNbB2) of the neighboring luma coding block is set equal to (xCb - 1, yCb - 1). - The neighboring block availability derivation process as specified in Section 6.4.4 is called with as input the current luma location (xCurr, yCurr) set equal to (xCb, yCb), the neighboring luma location (xNbB2, yNbB2), checkPredModeY set equal to TRUE, and cIdx set equal to 0, and the output is assigned to the block availability flag availableB2. The variables availableFlagB2, refIdxLXB2, predFlagLXB2, mvLXB2, hpelIfIdxB2, and bcwIdxB2 are derived as follows: If one or more of the following conditions are true, then availableFlagB2 is set equal to 0, X is 0 or 1, both components of mvLXB2 are set equal to 0, refIdxLXB2 is set equal to -1, predFlagLXB2 is set equal to 0, hpelIfIdxB2 is set equal to 0, and bcwIdxB2 is set equal to 0: - availableB2 equals FALSE. - availableA1 is equal to TRUE and luma locations (xNbA1, yNbA1) and (xNbB2, yNbB2) have the same motion vector and the same reference index. - availableB1 is equal to TRUE and luma locations (xNbB1, yNbB1) and (xNbB2, yNbB2) have the same motion vector and the same reference index. - availableFlagA0+availableFlagA1+availableFlagB0+availableFlagB1 is equal to 4. - WPDisabledX[ RefIdxLX[ xNbB1][ yNbB1] ] is set to 0 and the merge mode is non-rectangular (for example, the triangle flag is set equal to 1 for the block within the current luma location ( xCurr, yCurr )). - WPDisabledX[ RefIdxLX[ xNbB2][ yNbB2] ] is set to 0 and the merge mode is non-rectangular (for example, the triangle flag is set equal to 1 for the block within the current luma location ( xCurr, yCurr )). - - Otherwise, availableFlagB2 is set equal to 1 and the following allocation is made: mvLXB2= MvLX[ xNbB2][ yNbB2] (521) refIdxLXB2= RefIdxLX[ xNbB2][ yNbB2] (522) predFlagLXB2= PredFlagLX[ xNbB2][ yNbB2] (523) hpelIfIdxB2= HpelIfIdx[ xNbB2][ yNbB2] (524) bcwIdxB2= BcwIdx[ xNbB2][ yNbB2] (525)

[0370] In the above disclosed embodiment, the following variable definitions are used:

[0371] When all of the values ​​of luma_weight_l0_flag[ i ] and chroma_weight_l0_flag[ i ] are set to the value 0, i = 0..NumRefIdxActive[ 0], the variable WPDisabled0[i] is set equal to 1. Otherwise, the value of WPDisabled0[i] is set equal to 0.

[0372] When all of the values ​​of luma_weight_l1_flag[ i ] and chroma_weight_l1_flag[ i ] are set to the value 0, i = 0..NumRefIdxActive[ 1], the variable WPDisabled1[i] is set equal to 1. Otherwise, the value of WPDisabled1[1] is set equal to 0.

[0373] In another embodiment, the variable SliceMaxNumTriangleMergeCand is defined in the slice header according to one of the following: - SliceMaxNumTriangleMergeCand = (lumaWeightedFlag || chromaWeightedFlag) ? 0 : MaxNumTriangleMergeCand - SliceMaxNumTriangleMergeCand = (lumaWeightedFlag || chromaWeightedFlag) ? 1 : MaxNumTriangleMergeCand - SliceMaxNumTriangleMergeCand = slice_weighted_pred_flag ? 0 : MaxNumTriangleMergeCand or - SliceMaxNumTriangleMergeCand = slice_weighted_pred_flag ? 1 : MaxNumTriangleMergeCand

[0374] Various embodiments use different cases described above.

[0375] The value of this variable is further used during parsing of merge information at the block level. An example syntax is given in the table below.

[0376] [Table 17A] [Table 17B]

[0377] For the case where the non-rectangular inter prediction mode is a GEO mode, the following embodiment is further described.

[0378] Therefore, different mechanisms may be used to allow control of the GEO / TPM merge mode conditional on whether WP is applied to a reference picture, namely: - moving the WP parameters listed in Table 14 from SH to PH; - Moving the GEO parameters back from PH to SH, from modifying the semantics of MaxNumGeoMergeCand by setting it equal to 0 or 1 for such slices, i.e. when reference pictures with WP may be used (e.g. when at least one of the flags lumaWeightedFlag or lumaWeightedFlag is equal to true); Reference blocks P0 and P1 are taken.

[0379] For the GEO merge mode, exemplary reference blocks P0 and P1 are indicated by 810 and 820, respectively, in FIG.

[0380] In one embodiment, when the WP parameters and enablement of non-rectangular modes (eg, GEO and TPM) are signaled in the picture header, the following syntax may be used, as shown in the table below.

[0381] [Table 18A] [Table 18B]

[0382] When all of the values ​​of luma_weight_l0_flag[ i ], chroma_weight_l0_flag[ i ], luma_weight_l1_flag[ j ], and chroma_weight_l1_flag[ j ] are set to 0, the value of i = 0..NumRefIdxActive

[0000] , and the value of j = 0..NumRefIdxActive

[0001] , the variable WPDisabled is set equal to 1, otherwise the value of WPDisabled is set equal to 0.

[0383] When the variable WPDisabled is set equal to 0, the value of pic_max_num_merge_cand_minus_max_num_geo_cand is set equal to MaxNumMergeCand.

[0384] In another embodiment, pic_max_num_merge_cand_minus_max_num_geo_cand is set equal to MaxNumMergeCand - 1.

[0385] In a second embodiment, the signaling of WP parameters and the enablement of non-rectangular modes (eg, GEO and TPM) is performed in the slice header. An example syntax is given in the table below.

[0386] [Table 19A] [Table 19B] [Table 19C] [Table 19D]

[0387] When all of the values ​​of luma_weight_l0_flag[ i ], chroma_weight_l0_flag[ i ], luma_weight_l1_flag[ j ], and chroma_weight_l1_flag[ j ] are set to 0, the value of i = 0..NumRefIdxActive

[0000] , and the value of j = 0..NumRefIdxActive

[0001] , the variable WPDisabled is set equal to 1, otherwise the value of WPDisabled is set equal to 0.

[0388] When the variable WPDisabled is set equal to 0, the value of max_num_merge_cand_minus_max_num_geo_cand is set equal to MaxNumMergeCand.

[0389] In another embodiment, when the variable WPDisabled is set equal to 0, the value of max_num_merge_cand_minus_max_num_geo_cand is set equal to MaxNumMergeCand - 1.

[0390] In the embodiments disclosed above, the weighted prediction parameters may be signaled either in the picture header or in the slice header.

[0391] In another embodiment, the variable SliceMaxNumGeoMergeCand is defined in the slice header according to one of the following: - SliceMaxNumGeoMergeCand = (lumaWeightedFlag || chromaWeightedFlag) ? 0 : MaxNumGeoMergeCand - SliceMaxNumGeoMergeCand = (lumaWeightedFlag || chromaWeightedFlag) ? 1 : MaxNumGeoMergeCand - SliceMaxNumGeoMergeCand = slice_weighted_pred_flag ? 0 : MaxNumGeoMergeCand or - SliceMaxNumGeoMergeCand = slice_weighted_pred_flag ? 1 : MaxNumGeoMergeCand

[0392] Various embodiments use different cases described above.

[0393] The value of this variable is further used during parsing of merge information at the block level. An example syntax is given in the table below.

[0394] 7.3.9.7 Merge Data Syntax

[0395] [Table 20A] [Table 20B]

[0396] The relevant picture header semantics are as follows:

[0397] pic_max_num_merge_cand_minus_max_num_geo_cand specifies the maximum number of geo merge mode candidates supported in the slice associated with the picture header, subtracted from MaxNumMergeCand.

[0398] When pic_max_num_merge_cand_minus_max_num_geo_cand is not present, and sps_geo_enabled_flag is equal to 1, and MaxNumMergeCand is 2 or greater, pic_max_num_merge_cand_minus_max_num_geo_cand is inferred to be equal to pps_max_num_merge_cand_minus_max_num_geo_cand_plus1 - 1.

[0399] The maximum number of geo merge mode candidates, MaxNumGeoMergeCand, is derived as follows: MaxNumGeoMergeCand = MaxNumMergeCand - pic_max_num_merge_cand_minus_max_num_geo_cand (87)

[0400] When pic_max_num_merge_cand_minus_max_num_geo_cand is present, the value of MaxNumGeoMergeCand shall be in the range 2 to MaxNumMergeCand, inclusive.

[0401] When pic_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), MaxNumGeoMergeCand is set equal to 0.

[0402] When MaxNumGeoMergeCand is equal to 0, geo merge mode is not allowed for slices associated with PH.

[0403] In the following embodiments, several signaling-related aspects are considered, namely, these aspects are as follows: - A syntax element related to the number of candidates for merge mode() is signaled in the sequence parameter set (SPS), allowing a specific implementation to derive the number of non-rectangular mode merge candidates (MaxNumGeoMergeCand) at the SPS level. When a picture comprises exactly one slice, the PH can be signaled in the SH. - Specify a PH / SH parameter override mechanism, involving: · A PPS flag specifying whether the syntax element of the associated coding tool is present in either PH or SH (but not both). In particular, reference picture lists and weighted prediction tables may use this mechanism. - Prediction weight tables, i.e. the fifth type of data, which can be signaled either in the PH or SH (like ALF, deblocking, RPL and SAO). When weighted prediction is enabled for a picture, all slices of the picture will be required to have the same reference picture list. - If only some slice types are used in the picture associated with the PH, inter- and intra-related syntax elements are conditionally signaled. In detail, two flags pic_inter_slice_present_flag and pic_intra_slice_present_flag are introduced.

[0404] In the first embodiment, a syntax element related to the number of candidates for merge mode() is signaled in a sequence parameter set (SPS), which enables a specific implementation to derive the number of non-rectangular mode merge candidates (MaxNumGeoMergeCand) at the SPS level. This aspect can be implemented by an encoding process or a decoding process based on the following syntax:

[0405] 7.3.2.3 Sequence parameter set RBSP syntax

[0406] [Table 21A] [Table 21B]

[0407] The syntax described above has the following semantics:

[0408] sps_six_minus_max_num_merge_cand_plus1 equal to 0 specifies that pic_six_minus_max_num_merge_cand is present in the PH that references the PPS. sps_six_minus_max_num_merge_cand_plus1 greater than 0 specifies that pic_six_minus_max_num_merge_cand is not present in the PH that references the PPS. The value of sps_six_minus_max_num_merge_cand_plus1 shall be in the range 0 to 6, inclusive.

[0409] sps_max_num_merge_cand_minus_max_num_geo_cand_plus1 equal to 0 specifies that pic_max_num_merge_cand_minus_max_num_geo_cand is present in the PH of the slice that references the PPS. sps_max_num_merge_cand_minus_max_num_geo_cand_plus1 greater than 0 specifies that pic_max_num_merge_cand_minus_max_num_geo_cand is not present in the PH that references the PPS. The value of sps_max_num_merge_cand_minus_max_num_geo_cand_plus1 shall be in the range 0 to MaxNumMergeCand - 1.

[0410] The semantics of the corresponding elements in PH are as follows:

[0411] pic_six_minus_max_num_merge_cand specifies the maximum number of merging motion vector prediction (MVP) candidates supported in the slice associated with PH, subtracted from 6. The maximum number of merging MVP candidates, MaxNumMergeCand, is derived as follows: MaxNumMergeCand = 6 - pic_six_minus_max_num_merge_cand (85)

[0412] The value of MaxNumMergeCand shall be in the range 1 to 6, inclusive. When not present, the value of pic_six_minus_max_num_merge_cand is inferred to be equal to sps_six_minus_max_num_merge_cand_plus1 - 1.

[0413] pic_max_num_merge_cand_minus_max_num_geo_cand specifies the maximum number of geo merge mode candidates supported in the slice associated with the picture header, subtracted from MaxNumMergeCand.

[0414] When sps_max_num_merge_cand_minus_max_num_geo_cand is not present, and sps_geo_enabled_flag is equal to 1, and MaxNumMergeCand is 2 or greater, pic_max_num_merge_cand_minus_max_num_geo_cand is inferred to be equal to sps_max_num_merge_cand_minus_max_num_geo_cand_plus1 - 1.

[0415] The maximum number of geo merge mode candidates, MaxNumGeoMergeCand, is derived as follows: MaxNumGeoMergeCand = MaxNumMergeCand - pic_max_num_merge_cand_minus_max_num_geo_cand (87)

[0416] When pic_max_num_merge_cand_minus_max_num_geo_cand is present, the value of MaxNumGeoMergeCand shall be in the range 2 to MaxNumMergeCand, inclusive.

[0417] When pic_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), MaxNumGeoMergeCand is set equal to 0.

[0418] When MaxNumGeoMergeCand is equal to 0, geo merge mode is not allowed for slices associated with PH.

[0419] The alternative syntax and semantics for this embodiment are as follows:

[0420] [Table 22]

[0421] sps_six_minus_max_num_merge_cand specifies the maximum number of merging motion vector prediction (MVP) candidates supported in the slice associated with PH, subtracted from 6. The maximum number of merging MVP candidates, MaxNumMergeCand, is derived as follows: MaxNumMergeCand = 6 - sps_six_minus_max_num_merge_cand (85)

[0422] The value of MaxNumMergeCand shall be in the range 1 to 6, inclusive.

[0423] sps_max_num_merge_cand_minus_max_num_geo_cand specifies the maximum number of geo merge mode candidates supported in the slice associated with the picture header, subtracted from MaxNumMergeCand.

[0424] The maximum number of geo merge mode candidates, MaxNumGeoMergeCand, is derived as follows: MaxNumGeoMergeCand = MaxNumMergeCand - sps_max_num_merge_cand_minus_max_num_geo_cand (87)

[0425] When sps_max_num_merge_cand_minus_max_num_geo_cand is present, the value of MaxNumGeoMergeCand shall be in the range 2 to MaxNumMergeCand, inclusive.

[0426] When sps_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), MaxNumGeoMergeCand is set equal to 0.

[0427] When MaxNumGeoMergeCand is equal to 0, geo merge mode is not allowed.

[0428] For the embodiment described above, and for both alternative syntax definitions, a check is performed as to whether weighted prediction is enabled. This check affects the derivation of the MaxNumGeoMergeCand variable, and the value of MaxNumGeoMergeCand is set to 0 in one of the following cases: - For values ​​i = 0..NumRefIdxActive

[0000] and j = 0..NumRefIdxActive

[0001] , when all values ​​of luma_weight_l0_flag[ i ], chroma_weight_l0_flag[ i ], luma_weight_l1_flag[ j ], and chroma_weight_l1_flag[ j ] are either set to 0 or are not present. - When a flag in the SPS or PPS indicates the presence of bidirectional weighted prediction (pps_weighted_bipred_flag). - When the presence of bidirectional weighted prediction is indicated in either the picture header (PH) or the slice header (SH).

[0429] An SPS-level flag indicating the presence of weighted prediction parameters may be signaled as follows:

[0430] [Table 23]

[0431] The syntax element "sps_wp_enabled_flag" determines whether weighted prediction can be enabled at the lower levels (PPS, PH, or SH). An example implementation is given below.

[0432] [Table 24]

[0433] In the above table, pps_weighted_pred_flag and pps_weighted_bipred_flag are flags in the bitstream that indicate whether weighted prediction is enabled for uni-predictive and bi-predictive blocks.

[0434] In one embodiment, when a weighted prediction flag, such as, for example, pic_weighted_pred_flag and pic_weighted_bipred_flag, is specified in the picture header, the following dependency on sps_wp_enabled_flag may be specified in the bitstream syntax:

[0435] [Table 25]

[0436] In one embodiment, if a weighted prediction flag, such as, for example, weighted_pred_flag and weighted_bipred_flag, is specified in the slice header, the following dependency on sps_wp_enabled_flag may be specified in the bitstream syntax:

[0437] [Table 26]

[0438] In embodiment 2, the reference picture list may be indicated either in the PPS or in either the PH or SH (but not both). As known from the state of the art, the signaling of the reference picture list depends on syntax elements (e.g., pps_weighted_pred_flag and pps_weighted_bipred_flag) that indicate the presence of weighted prediction. Thus, depending on whether the reference picture list is indicated in the PPS, PH, or SH, the weighted prediction parameters are signaled before the reference picture list in the PPS, PH, or SH accordingly.

[0439] The following syntax can be specified for this embodiment:

[0440] Picture Parameter Set Syntax

[0441] [Table 27]

[0442] rpl_present_in_ph_flag equal to 1 specifies that reference picture list signaling is not present in the slice header that references the PPS, but may be present in the PH that references the PPS. rpl_present_in_ph_flag equal to 0 specifies that reference picture list signaling is not present in the PH that references the PPS, but may be present in the slice header that references the PPS.

[0443] sao_present_in_ph_flag equal to 1 specifies that syntax elements for enabling SAO usage are not present in the slice header that references the PPS, but may be present in the PH that references the PPS. sao_present_in_ph_flag equal to 0 specifies that syntax elements for enabling SAO usage are not present in the PH that references the PPS, but may be present in the slice header that references the PPS.

[0444] alf_present_in_ph_flag equal to 1 specifies that syntax elements for enabling ALF usage are not present in the slice header that references the PPS, but may be present in the PH that references the PPS. alf_present_in_ph_flag equal to 0 specifies that syntax elements for enabling ALF usage are not present in the PH that references the PPS, but may be present in the slice header that references the PPS.

[0445] weighted_pred_table_present_in_ph_flag equal to 1 specifies that a weighted prediction table is not present in the slice header that references the PPS, but may be present in the PH that references the PPS. weighted_pred_table_present_in_ph_flag equal to 0 specifies that a weighted prediction table is not present in the PH that references the PPS, but may be present in the slice header that references the PPS. When not present, the value of weighted_pred_table_present_in_ph_flag is inferred to be equal to 0.

[0446] A deblocking_filter_override_enabled_flag equal to 1 specifies that a deblocking filter override may be present in the PH that references the PPS or in the slice header. A deblocking_filter_override_enabled_flag equal to 0 specifies that the deblocking filter override is not present in either the PH that references the PPS or in the slice header. When not present, the value of deblocking_filter_override_enabled_flag is inferred to be equal to 0.

[0447] deblocking_filter_override_present_in_ph_flag equal to 1 specifies that a deblocking filter override is not present in the slice header that references the PPS, but may be present in the PH that references the PPS. deblocking_filter_override_present_in_ph_flag equal to 0 specifies that a deblocking filter override is not present in the PH that references the PPS, but may be present in the slice header that references the PPS.

[0448] [Table 28A] [Table 28B]

[0449] [Table 29A] [Table 29B] [Table 29C]

[0450] An alternative syntax for the picture header is as follows:

[0451] [Table 30A] [Table 30B]

[0452] In embodiment 3, the signaling of picture header and slice header elements may be combined in a single process.

[0453] This embodiment introduces a flag ("picture_header_in_slice_header_flag") that indicates whether the picture and slice headers are combined. The syntax for the bitstream according to this embodiment is as follows:

[0454] Picture Header RBSP Syntax

[0455] [Table 31]

[0456] Picture Header Structure Syntax

[0457] [Table 32]

[0458] Generic slice header syntax

[0459] [Table 33]

[0460] The semantics for picture_header_in_slice_header_flag and the associated bitstream constraints are as follows:

[0461] picture_header_in_slice_header_flag equal to 1 specifies that the picture header syntax structure is present in the slice header. picture_header_in_slice_header_flag equal to 0 specifies that the picture header syntax structure is not present in the slice header.

[0462] It is a bitstream conformance requirement that the value of picture_header_in_slice_header_flag be the same among all slices of a CLVS.

[0463] When picture_header_in_slice_header_flag is equal to 1, it is a bitstream conformance requirement that no NAL units with a NAL unit type equal to PH_NUT are present in the CLVS.

[0464] When picture_header_in_slice_header_flag is equal to 0, it is a bitstream conformance requirement that a NAL unit with a NAL unit type equal to PH_NUT is present in the PU preceding the first VCL NAL unit of the PU.

[0465] The combination of embodiment 2 and embodiment 3 is important as both embodiments relate to the subject of PH and SH signaling.

[0466] Combinations of aspects of these embodiments are as follows:

[0467] When picture_header_in_slice_header_flag is equal to 0 (embodiment 4), a flag that specifies whether the syntax element of the associated coding tool is present in either PH or SH (but not both).

[0468] Otherwise (when picture_header_in_slice_header_flag is equal to 1), these flags are inferred to be 0, indicating tool parameter signaling at the slice level.

[0469] The alternative combinations are as follows:

[0470] When picture_header_in_slice_header_flag is equal to 0 (embodiment 4), a flag that specifies whether the syntax element of the associated coding tool is present in either PH or SH (but not both).

[0471] Otherwise (when picture_header_in_slice_header_flag is equal to 1), these flags are inferred to be 0, indicating tool parameter signaling at the picture header level.

[0472] This combination has the following syntax:

[0473] Picture Parameter Set Syntax

[0474] [Table 34]

[0475] In embodiment 4, checking whether weighted prediction is enabled is performed by indicating the number of entries in the reference picture list that are referenced using weighted prediction.

[0476] The syntax and semantics in this embodiment are defined as follows:

[0477] [Table 35A] [Table 35B]

[0478] num_l0_weighted_ref_pics specifies the number of reference pictures in weighted reference picture list 0. The value of num_l0_weighted_ref_pics shall range from 0 to MaxDecPicBuffMinus1 + 14, inclusive.

[0479] When present, it is a bitstream conformance requirement that the value of num_l0_weighted_ref_pics must not be less than the number of active reference pictures for L0 of any slice in the picture associated with the picture header.

[0480] num_l1_weighted_ref_pics specifies the number of reference pictures in weighted reference picture list 1. The value of num_l1_weighted_ref_pics shall range from 0 to MaxDecPicBuffMinus1 + 14, inclusive.

[0481] When present, it is a bitstream conformance requirement that the value of num_l1_weighted_ref_pics must not be less than the number of active reference pictures for L1 of any slice in the picture associated with the picture header.

[0482] When either num_l0_weighted_ref_pics or num_l1_weighted_ref_pics is non-zero, MaxNumGeoMergeCand is set to 0. The following syntax is an example of how this dependency can be exploited.

[0483] [Table 36]

[0484] The semantics of pic_max_num_merge_cand_minus_max_num_geo_cand in this embodiment is the same as in the previous embodiment.

[0485] In embodiment 5, if only some slice types are used in the picture associated with the PH, the inter- and intra-related syntax elements are conditionally signaled.

[0486] The syntax for this embodiment is given below.

[0487] [Table 37A] [Table 37B] [Table 37C] [Table 37D]

[0488] 7.3.7.1 Generic slice header syntax

[0489] [Table 38]

[0490] 7.4.3.6 Picture Header RBSP Semantics A pic_inter_slice_present_flag equal to 1 specifies that one or more slices with slice_type equal to 0 (B) or 1 (P) may be present in the picture associated with the PH. A pic_inter_slice_present_flag equal to 0 specifies that slices with slice_type equal to 0 (B) or 1 (P) may not be present in the picture associated with the PH.

[0491] pic_intra_slice_present_flag equal to 1 specifies that one or more slices with slice_type equal to 2(I) may be present in the picture associated with PH. pic_intra_slice_present_flag equal to 0 specifies that slices with slice_type equal to 2(I) may not be present in the picture associated with PH. When not present, the value of pic_intra_slice_only_flag is inferred to be equal to 1.

[0492] NOTE - The values ​​of both pic_inter_slice_present_flag and pic_intra_slice_present_flag are set equal to 1 in a picture header associated with a picture that contains one or more sub-pictures containing intra-coded slices that may be merged with one or more sub-pictures containing inter-coded slices.

[0493] 7.4.8.1 Generic slice header semantics slice_type specifies the coding type of the slice according to Table 7-5.

[0494] Table 7-5 - Name associations to slice_type

[0495] [Table 39]

[0496] When nal_unit_type is a value of nal_unit_type in the range IDR_W_RADL to CRA_NUT, inclusive, and the current picture is the first picture in an access unit, slice_type shall be equal to 2.

[0497] When not present, the value of slice_type is inferred to be equal to 2.

[0498] When pic_intra_slice_present_flag is equal to 0, the value of slice_type shall be in the range from 0 to 1, inclusive.

[0499] The fourth embodiment can be combined with the signaling of pred_weight_table() in the picture header, which is disclosed in the previous embodiment.

[0500] An example syntax is as follows:

[0501] [Table 40]

[0502] When indicating the presence of pred_weight_table( ) in the picture header, the following syntax combination with embodiment 3 may be used.

[0503] [Table 41]

[0504] An alternative embodiment may use the following syntax:

[0505] [Table 42]

[0506] An alternative embodiment may use the following syntax:

[0507] [Table 43]

[0508] In the above syntax, pic_inter_bipred_slice_present_flag indicates the presence of all slice types that refer to the picture header, namely I slices, B slices, and P slices.

[0509] When pic_inter_bipred_slice_present_flag is 0, the picture comprises only slices of either I or B type.

[0510] In this case, the non-rectangular mode is disabled.

[0511] Embodiment 5 is a combination of the features disclosed above. An exemplary syntax is described as follows:

[0512] [Table 44A] [Table 44B]

[0513] The sixth embodiment allows the encoder to select a non-rectangular (eg, GEO) mode that references pictures that do not have weighted prediction coefficients.

[0514] In this embodiment, the semantics are defined as follows:

[0515] 7.4.10.7 Merge Data Semantics When decoding a B slice, the variable MergeGeoFlag[x0][y0], which specifies whether geo-shape-based motion compensation is used to generate the prediction samples of the current coding unit, is derived as follows: - MergeGeoFlag[ x0 ][ y0 ] is set equal to 1 if all of the following conditions are true: - sps_geo_enabled_flag is equal to 1. - slice_type equals B. - general_merge_flag[ x0 ][ y0 ] is equal to 1. - MaxNumGeoMergeCand is greater than or equal to 2. - cbWidth is 8 or greater. - cbHeight is greater than or equal to 8. - cbWidth is smaller than 8*cbHeight. - cbHeight is less than 8*cbWidth. - regular_merge_flag[ x0 ][ y0 ] is equal to 0. - merge_subblock_flag[ x0 ][ y0 ] is equal to 0. - ciip_flag[ x0 ][ y0 ] is equal to 0. - Otherwise, MergeGeoFlag[ x0 ][ y0 ] is set equal to 0.

[0516] It is a bitstream conformance requirement that if one of the CU's luma or chroma explicit weighted flags is true, then MergeGeoFlag[x0][y0] must be equal to 0.

[0517] The seventh embodiment can be described as part of the VVC specification as follows:

[0518] 8.5.7 Decoding process for geo interblocks 8.5.7.1 Overview This process is invoked when decoding a coding unit with MergeGeoFlag[xCb][yCb] equal to 1.

[0519] The inputs to this process are: - a luma location (xCb, yCb) that specifies the top-left sample of the current coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples, - a variable cbHeight that specifies the height of the current coding block in luma samples, - luma motion vectors mvA and mvB with 1 / 16 fractional sample accuracy, - Chroma motion vectors mvCA and mvCB, - reference indices refIdxA and refIdxB, - Prediction list flags predListFlagA and predListFlagB.

[0520] A (cbWidth) x (cbHeight) array of predicted luma sample values ​​is stored in predSamplesLA. L and predSamplesLB L Let predSamplesLA be a (cbWidth / SubWidthC) × (cbHeight / SubHeightC) array of predicted chroma sample values. Cb , predSamplesLB Cb ,predSamplesLA Cr , and predSamplesLB Cr Let us assume that.

[0521] predSamples L , predSamples Cb , and predSamples Cr is derived by the following ordered steps: 1. For N, each of A and B, the following applies: 2. The partition angle and distance for merge geo mode, i.e., the variables angleIdx and distanceIdx, are set according to the value of merge_geo_partition_idx[xCb][yCb] as specified in Table 36. 3. The variable explicitWeightedFlag is derived as follows: lumaWeightedFlagA = predListFlagA ? luma_weight_l1_flag[ refIdxA ] : luma_weight_l0_flag[ refIdxA ] lumaWeightedFlagB = predListFlagB ? luma_weight_l1_flag[ refIdxB ] : luma_weight_l0_flag[ refIdxB ] chromaWeightedFlagA = predListFlagA ? chroma_weight_l1_flag[ refIdxA ] : chroma_weight_l0_flag[ refIdxA ] chromaWeightedFlagB = predListFlagB ? chroma_weight_l1_flag[ refIdxB ] : chroma_weight_l0_flag[ refIdxB ] weightedFlag = lumaWeightedFlagA || lumaWeightedFlagB || chromaWeightedFlagA || chromaWeightedFlagB 4.x L = 0..cbWidth - 1 and y L Prediction samples inside the current luma coding block, with predSamples = 0..cbHeight - 1 L [ x L ][ y L] is a set of the coding block width nCbW set equal to cbWidth, the coding block height nCbH set equal to cbHeight, and the sample array predSamplesLA L and predSamplesLB L , and the variables angleIdx, distanceIdx, and cIdx equal to 0, and are derived by invoking the weighted sample prediction process for geo merge mode specified in Section 8.5.7.2 if weightedFlag is equal to 0, or the explicit weighted sample prediction process in Section 8.5.6.6.3 if weightedFlag is equal to 1. 5.x C = 0..cbWidth / SubWidthC - 1 and y C Prediction samples predSamples inside the current chroma component Cb coding block, with = 0..cbHeight / SubHeightC - 1 Cb [ x C ][ y C ] is the coding block width nCbW set equal to cbWidth / SubWidthC, the coding block height nCbH set equal to cbHeight / SubHeightC, and the sample array predSamplesLA Cb and predSamplesLB Cb , and the variables angleIdx, distanceIdx, and cIdx equal to 1, and are derived by invoking the weighted sample prediction process for geo merge mode specified in Section 8.5.7.2 if weightedFlag is equal to 0, or the explicit weighted sample prediction process in Section 8.5.6.6.3 if weightedFlag is equal to 1. 6.x C = 0..cbWidth / SubWidthC - 1 and y CPredicted samples inside the current chroma component Cr coding block, with = 0..cbHeight / SubHeightC - 1. Cr [ x C ][ y C ] is the coding block width nCbW set equal to cbWidth / SubWidthC, the coding block height nCbH set equal to cbHeight / SubHeightC, and the sample array predSamplesLA Cr and predSamplesLB Cr , and the variables angleIdx, distanceIdx, and cIdx equal to 2, are used as inputs to invoke the weighted sample prediction process for geo merge mode specified in Section 8.5.7.2 if weightedFlag is equal to 0, or the explicit weighted sample prediction process in Section 8.5.6.6.3 if weightedFlag is equal to 1. 7. The motion vector storage process for merge geo mode specified in section 8.5.7.3 is called with the luma coding block location (xCb, yCb), luma coding block width cbWidth, luma coding block height cbHeight, partition direction angleIdx and distanceIdx, luma motion vectors mvA and mvB, reference indices refIdxA and refIdxB, and prediction list flags predListFlagA and predListFlagB as input.

[0522] [Table 45]

[0523] 8.5.6.6.3 Explicit Weighted Sample Prediction Process The inputs to this process are: - two variables nCbW and nCbH that specify the width and height of the current coding block, - two (nCbW) x (nCbH) arrays predSamplesL0 and predSamplesL1, - prediction list usage flags predFlagL0 and predFlagL1, - reference indices refIdxL0 and refIdxL1, - a variable cIdx that specifies the color component index, - Sample bit depth bitDepth.

[0524] The output of this process is a (nCbW) x (nCbH) array of predicted sample values, pbSamples.

[0525] The variable shift1 is set equal to Max(2, 14 - bitDepth).

[0526] The variables log2Wd, o0, o1, w0, and w1 are derived as follows: - If cIdx is equal to 0 for a luma sample, the following applies: log2Wd = luma_log2_weight_denom + shift1 (1010) w0 = LumaWeightL0[ refIdxL0 ] (1011) w1 = LumaWeightL1[ refIdxL1 ] (1012) o0 = luma_offset_l0[ refIdxL0 ] << ( bitDepth - 8 ) (1013) o1 = luma_offset_l1[ refIdxL1 ] << ( bitDepth - 8 ) (1014) - Otherwise (cIdx is not equal to 0 for any chroma sample), the following applies: log2Wd = ChromaLog2WeightDenom + shift1 (1015) w0 = ChromaWeightL0[ refIdxL0 ][ cIdx - 1 ] (1016) w1 = ChromaWeightL1[ refIdxL1 ][ cIdx - 1 ] (1017) o0 = ChromaOffsetL0[ refIdxL0 ][ cIdx - 1 ] << ( bitDepth - 8 ) (1018) o1 = ChromaOffsetL1[ refIdxL1 ][ cIdx - 1 ] << ( bitDepth - 8 ) (1019)

[0527] The predicted samples pbSamples[ x ][ y ], with x = 0..nCbW - 1 and y = 0..nCbH - 1, are derived as follows: If predFlagL0 is equal to 1 and predFlagL1 is equal to 0, the predicted sample values ​​are derived as follows: if( log2Wd >= 1 ) pbSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) - 1, ( ( predSamplesL0[ x ][ y ] * w0 + 2 log2Wd - 1 ) >> log2Wd ) + o0 ) (1020) else pbSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) - 1, predSamplesL0[ x ][ y ] * w0 + o0 ) - otherwise, if predFlagL0 is equal to 0 and predFlagL1 is equal to 1, the predicted sample values ​​are derived as follows: if( log2Wd >= 1 ) pbSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) - 1, ( ( predSamplesL1[ x ][ y ] * w1 + 2 log2Wd - 1 ) >> log2Wd ) + o1 ) (1021) else pbSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) - 1, predSamplesL1[ x ][ y ] * w1 + o1 ) Otherwise (predFlagL0 is equal to 1 and predFlagL1 is equal to 1), the predicted sample values ​​are derived as follows: pbSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) - 1, ( predSamplesL0[ x ][ y ] * w0 + predSamplesL1[ x ][ y ] * w1 + ( ( o0 + o1 + 1 ) << log2Wd ) ) >> ( log2Wd + 1 ) ) (1022)

[0528] Embodiment 8 discloses a syntax for the merge data parameter that comprises a check for a variable that indicates the presence of a non-rectangular merge mode (eg, GEO mode). An example syntax is given below:

[0529] [Table 46A] [Table 46B]

[0530] The variable MaxNumGeoMergeCand is derived according to any of the previous embodiments.

[0531] Embodiment 9 uses an alternative variable SliceMaxNumGeoMergeCand that is derived from the MaxNumGeoMergeCand variable. The value of MaxNumGeoMergeCand is obtained at a higher signaling level (i.e., PH, PPS, or SPS).

[0532] In this embodiment, SliceMaxNumGeoMergeCand is derived based on the value of MaxNumGeoMergeCand and additional checks performed on the slice.

[0533] - For example, SliceMaxNumGeoMergeCand = (num_l0_weighted_ref_pics>0 || num_l1_weighted_ref_pics>0) ? 0 : MaxNumGeoMergeCand.

[0534] Embodiment 10 is a variation of embodiment 9, which uses the following formula to determine the MaxNumGeoMergeCand value:

[0535] SliceMaxNumGeoMergeCand = (!pic_inter_slice_present_flag) ? 0 : MaxNumGeoMergeCand

[0536] The eleventh embodiment is a combination with the fourth embodiment.

[0537] The following syntax table is specified:

[0538] [Table 47]

[0539] The variable MaxNumGeoMergeCand is derived as follows:

[0540] SliceMaxNumGeoMergeCand = (!pic_inter_bipred_slice_present_flag) ? 0 : MaxNumGeoMergeCand

[0541] In accordance with the above description, the following embodiments are provided in detail herein.

[0542] FIG. 15 is a flow chart illustrating a coding method according to one embodiment.

[0543] The method shown in FIG. 15 comprises a step of obtaining (1510) a bitstream for a current picture (e.g., of an encoded video sequence). A value of a first indicator for the current picture is obtained (1520) according to the bitstream (e.g., by parsing a respective syntax element provided in the bitstream). The first indicator indicates a slice type (of a slice of the current picture). Furthermore, the method comprises a step of obtaining (1530) a value of a second indicator for the current picture according to the bitstream (e.g., by parsing a respective syntax element provided in the bitstream), the second indicator indicating whether the weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream.

[0544] Then, when the value of the first indicator is equal to a first preset value (for example, 1) and the value of the second indicator is equal to a second preset value (for example, 2) indicating whether the weighted prediction parameter is present in the picture header of the bitstream or in the slice header of the bitstream, the value of the weighted prediction parameter is parsed (1540) for the current block from the bitstream, and the current block is comprised in the current slice of the current picture. The first preset value is an integer value, and the second preset value is an integer value. Then, the current block is predicted (1550) according to the value of the parsed weighted prediction parameter (a predicted block is generated for the current block).

[0545] A coding method according to another embodiment is shown in Figures 16a and 16b.

[0546] The method comprises obtaining (1610) a bitstream for a current picture (e.g., of an encoded video sequence). Several indicator values ​​are obtained. Thus, the method includes obtaining (1620) a value of a first indicator for the current picture according to the bitstream (e.g., by parsing a respective syntax element provided in the bitstream), where the first indicator indicates a slice type (of a slice of the current picture); and obtaining (1630) a value of a second indicator for the current picture according to the bitstream (e.g., by parsing a respective syntax element provided in the bitstream), where the second indicator indicates a slice type (of a slice of the current picture). The method includes obtaining a value of a second indicator indicating whether the parameter is present in a picture header of the bitstream or in a slice header of the bitstream (1630), and obtaining a value of a third indicator for the current picture according to the bitstream (e.g., by parsing each syntax element provided in the bitstream) (1640), wherein the third indicator indicates whether weighted prediction is applicable to the inter slice, and the slice type of the inter slice is a B slice or a P slice (1640).

[0547] Then, when a) the value of the first indicator is equal to a first preset value (e.g., 1), b) the value of the second indicator is equal to a second preset value (e.g., 1), and c) the value of the third indicator indicates that weighted prediction is applicable to inter-slice, a value of the weighted prediction parameter is parsed from the bitstream for the current block, the current block being comprised in the current slice of the current picture, the first preset value being an integer value, and the second preset value being an integer value. The current block is predicted according to the parsed value of the weighted prediction parameter (1660) (a predicted block is generated for the current block).

[0548] The above described method may be embedded in a decoding device as described below.

[0549] A decoding device 1700 is provided as shown in Figure 17. The decoding device 1700 includes a bitstream obtaining unit 1710, an indicator value obtaining unit 1720, a parsing unit 1730, and a prediction unit 1740.

[0550] The bitstream obtaining unit 1710 is configured to obtain a bitstream for the current picture.

[0551] According to one embodiment, the indicator value obtaining unit 1720 is: a) obtaining a value of a first indicator for a current picture according to a bitstream, the first indicator indicating a slice type; b) obtaining a value of a second indicator for the current picture according to the bitstream, the second indicator indicating whether the weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream; The present invention is configured to:

[0552] In this case, the parsing unit 1730 is configured to parse a value of the weighted prediction parameter for a current block from the bitstream when the value of the first indicator is equal to a first preset value (e.g., 1) and the value of the second indicator is equal to a second preset value (e.g., 1), the current block is comprised in a current slice of the current picture, the first preset value is an integer value, the second preset value is an integer value, and the prediction unit is configured to predict the current block according to the value of the weighted prediction parameter.

[0553] According to another embodiment, the indicator value obtaining unit 1720 is: a) obtaining a value of a first indicator for a current picture according to a bitstream, the first indicator indicating a slice type; b) obtaining a value of a second indicator for a current picture according to the bitstream, the second indicator indicating whether the weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream; c) obtaining a value of a third indicator for the current picture according to the bitstream, the third indicator indicating whether weighted prediction is applicable to an inter slice, and a slice type of the inter slice is a B slice or a P slice; The present invention is configured to:

[0554] In this case, the parsing unit 1730 is configured to parse a value of the weighted prediction parameter for a current block from the bitstream when the value of the first indicator is equal to a first preset value (e.g., 1), the value of the second indicator is equal to a second preset value (e.g., 1), and the value of the third indicator indicates that weighted prediction is applicable to inter slices, the current block is comprised in a current slice of the current picture, the first preset value is an integer value, the second preset value is an integer value, and the prediction unit 1740 is configured to predict the current block according to the value of the weighted prediction parameter.

[0555] The decoding device 1700 shown in Figure 17 may be or may be provided by the decoder 30 shown in Figures 1A, 1B, and 3, and the video decoder 3206 shown in Figure 11. The decoding device 1700 shown in Figure 17 may be provided by the video coding device 400 shown in Figure 4, the apparatus 500 shown in Figure 5, the terminal device 3106 shown in Figure 10, the apparatus 1300 shown in Figure 13, and the apparatus 1400 shown in Figure 14.

[0556] The following is a description of application examples of the encoding method and the decoding method as shown in the above embodiments and the system using them.

[0557] 10 is a block diagram showing a content supply system 3100 for realizing a content distribution service. The content supply system 3100 includes a capture device 3102, a terminal device 3106, and optionally includes a display 3126. The capture device 3102 communicates with the terminal device 3106 via a communication link 3104. The communication link may include the communication channel 13 described above. The communication link 3104 includes, but is not limited to, WIFI, Ethernet, cable, wireless (3G / 4G / 5G), USB, or any kind of combination thereof.

[0558] The capture device 3102 may generate data and encode the data by the encoding method as shown in the above embodiment. Alternatively, the capture device 3102 may deliver the data to a streaming server (not shown), which encodes the data and transmits the encoded data to the terminal device 3106. The capture device 3102 includes, but is not limited to, a camera, a smartphone or pad, a computer or laptop, a video conferencing system, a PDA, a vehicle-mounted device, or any combination thereof. For example, the capture device 3102 may include a source device 12 as described above. When the data includes video, a video encoder 20 included in the capture device 3102 may actually perform the video encoding process. When the data includes audio (i.e., voice), an audio encoder included in the capture device 3102 may actually perform the audio encoding process. For some practical scenarios, the capture device 3102 delivers the encoded video and audio data by multiplexing them together. For other practical scenarios, for example in a video conferencing system, the encoded audio data and the encoded video data are not multiplexed, and the capture device 3102 delivers the encoded audio data and the encoded video data to the terminal device 3106 separately.

[0559] In the content supply system 3100, the terminal device 310 receives and plays the encoded data. The terminal device 3106 may be a device having data receiving and restoring capabilities, such as a smartphone or pad 3108, a computer or laptop 3110, a network video recorder (NVR) / digital video recorder (DVR) 3112, a TV 3114, a set-top box (STB) 3116, a video conferencing system 3118, a video surveillance system 3120, a personal digital assistant (PDA) 3122, a vehicle mounted device 3124, or any combination thereof, capable of decoding the above-mentioned encoded data. For example, the terminal device 3106 may include the destination device 14 as described above. When the encoded data includes video, the video decoder 30 included in the terminal device is prioritized to perform video decoding. When the encoded data includes audio, the audio decoder included in the terminal device is prioritized to perform audio decoding processing.

[0560] In case of a terminal device having a display, for example, a smartphone or pad 3108, a computer or laptop 3110, a network video recorder (NVR) / digital video recorder (DVR) 3112, a TV 3114, a personal digital assistant (PDA) 3122, or a vehicle-mounted device 3124, the terminal device can provide the decoded data to its display. In case of a terminal device not equipped with a display, for example, an STB 3116, a video conferencing system 3118, or a video surveillance system 3120, an external display 3126 is contacted thereto to receive and display the decoded data.

[0561] When each device in the system performs encoding or decoding, a picture encoding device or a picture decoding device may be used as shown in the above embodiments.

[0562] 11 is a diagram showing the structure of an example of a terminal device 3106. After the terminal device 3106 receives a stream from the capture device 3102, a protocol progression unit 3202 analyzes the transmission protocol of the stream. The protocol includes, but is not limited to, Real Time Streaming Protocol (RTSP), Hypertext Transfer Protocol (HTTP), HTTP Live Streaming Protocol (HLS), MPEG-DASH, Real Time Transport Protocol (RTP), Real Time Messaging Protocol (RTMP), or any kind of combination thereof.

[0563] After the protocol proceeding unit 3202 processes the stream, a stream file is generated. The file is output to the demultiplexing unit 3204. The demultiplexing unit 3204 can separate the multiplexed data into encoded audio data and encoded video data. As described above, for some practical scenarios, for example, in a video conference system, the encoded audio data and the encoded video data are not multiplexed. In this situation, the encoded data is sent to the video decoder 3206 and the audio decoder 3208 without passing through the demultiplexing unit 3204.

[0564] Through the demultiplexing process, a video elementary stream (ES), an audio ES, and optionally a subtitle are generated. The video decoder 3206, including the video decoder 30 as described in the above embodiment, decodes the video ES by the decoding method as shown in the above embodiment to generate a video frame, and supplies this data to the synchronization unit 3212. The audio decoder 3208 decodes the audio ES to generate an audio frame, and supplies this data to the synchronization unit 3212. Alternatively, the video frame may be stored in a buffer (not shown in FIG. 11) before supplying it to the synchronization unit 3212. Similarly, the audio frame may be stored in a buffer (not shown in FIG. 11) before supplying it to the synchronization unit 3212.

[0565] The synchronization unit 3212 synchronizes video and audio frames and provides the video / audio to a video / audio display 3214. For example, the synchronization unit 3212 synchronizes the presentation of video and audio information, which may be coded in the syntax using timestamps related to the presentation of the coded audio and visual data, as well as timestamps related to the delivery of the data stream itself.

[0566] If subtitles are included in the stream, a subtitle decoder 3210 decodes the subtitles, synchronizes them with the video and audio frames, and provides the video / audio / subtitles to a video / audio / subtitle display 3216 .

[0567] The present invention is not limited to the above-mentioned system, and either the picture encoding device or the picture decoding device in the above-mentioned embodiments may be incorporated into other systems, for example, an automobile system.

[0568] Mathematical Operators The mathematical operators used in this application are similar to those used in the C programming language. However, the results of integer division and arithmetic shift operations are more precisely defined, and additional operations such as exponentiation and real value division are defined. Numbering and counting conventions generally start at 0, e.g., "first" is equivalent to number 0, "second" is equivalent to number 1, etc.

[0569] Arithmetic Operators The following arithmetic operators are defined as follows: + Add. - Subtraction (as a two-argument operator) or negation (as a unary prefix operator). * Multiplication, including matrix multiplication. x yPower. Specifies x to the power of y. In other contexts, such notation is used to make a superscript that is not intended to be interpreted as a power. / Integer division with truncation of the result towards 0. For example, 7 / 4 and -7 / -4 round down to 1, and -7 / 4 and 7 / -4 round down to -1. ÷ Used to indicate division in mathematical expressions, without truncation or rounding.

number

number

[0570] Logical Operators The following logical operators are defined as follows: x && yThe Boolean logic "connection" of x and y. x || yThe Boolean logic "disjunction" of x and y. ! "Not" in Boolean logic. x ? y : zIf x is TRUE (i.e. not equal to 0), finds the value of y; otherwise, finds the value of z.

[0571] Relational Operators The following relational operators are defined as follows: > Greater than. >= Greater than or equal to. < Less than. <= Less than or equal. == Equal to. != Not equal.

[0572] When a relational operator is applied to a syntax element or variable that has been assigned the value "na" (not applicable), the value "na" is treated as a distinct value for that syntax element or variable. The value "na" is not considered equal to any other value.

[0573] Bitwise Operators The following bitwise operators are defined as follows: & Bitwise "and". When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on a binary argument that contains fewer bits than another argument, the shorter argument is extended by appending its additional significant bits equal to 0. Bitwise "or". When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on a binary argument that contains fewer bits than another argument, the shorter argument is extended by appending its further significant bits equal to 0. ^ Bitwise "exclusive or". When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on a binary argument that contains fewer bits than another argument, the shorter argument is extended by appending further significant bits equal to 0. x >> yArithmetic right shift of the two's complement integer representation of x by y binary places. This function is defined only for nonnegative integer values ​​of y. The bits shifted into the most significant bits (MSBs) as a result of a right shift have value equal to the MSB of x before the shift operation. x << yArithmetic left shift of the two's complement integer representation of x by y binary places. This function is defined only for nonnegative integer values ​​of y. Bits shifted into the least significant bits (LSBs) as a result of the left shift have value equal to 0.

[0574] Assignment Operator The following arithmetic operators are defined as follows: = Assignment operator. ++ Increment, i.e., x++ is equivalent to x = x + 1, and when used in an array index, evaluates to the value of the variable before the increment operation. -- Decrement, i.e., x-- is equivalent to x = x - 1, and when used in an array index, evaluates to the value of the variable before the decrement operation. += Increment by the specified amount, i.e., x += 3 is equivalent to x = x + 3 and x += (-3) is equivalent to x = x + (-3). -= Decrement by the specified amount, i.e., x -= 3 is equivalent to x = x - 3 and x -= (-3) is equivalent to x = x - (-3).

[0575] Range Notation The following notation is used to specify a range of values: x=y..zx takes integer values ​​from y to z (inclusive), where x, y, and z are integers and z is greater than y.

[0576] Mathematical Functions The following mathematical functions are defined:

number

[0577] Asin(x) The trigonometric arcsine function, operated on an argument x in the range -1.0 to 1.0, inclusive, and with an output value in the range -π÷2 to π÷2, inclusive, in radians. Atan(x) The trigonometric arctangent function, operated on the argument x, with output values ​​in the range -π÷2 to π÷2 (inclusive), in radians.

number

number

number

number

number

number

[0578] Precedence order When the order of precedence in an expression is not explicitly indicated by the use of parentheses, the following rules apply: - An operation with a higher precedence is evaluated before any operation with a lower precedence. - Operations of equal rank are evaluated consecutively from left to right.

[0579] The following table specifies the ranking of operations from highest to lowest, with a higher position in the table indicating a higher ranking.

[0580] For operators that are also used in the C programming language, the precedence order used herein is the same as that used in the C programming language.

[0581] [Table 48]

[0582] Text description of logical operations A statement of logical operations that may be mathematically written in the text in the form: if(condition 0) Statement 0 else if(condition 1) Statement 1 ... else / * informative mentions in remaining conditions * / Statement n can be explained as follows. ...as follows / ...the following applies - if condition 0, then statement 0 - Otherwise, if condition 1, then statement 1 - ... - in other cases (informative mention in the remaining conditions), statement n.

[0583] Each "If... otherwise then..." statement in the text is begun with "... as follows" or "... the following applies" followed immediately by "If...". The final condition in an "If... otherwise then..." is always "Otherwise...". Interleaved "If... otherwise then..." statements can be identified by aligning the "... as follows" or "... the following applies" with the ending "Otherwise...".

[0584] A statement of logical operations that may be mathematically written in the text in the form: if(condition0a && condition0b) Statement 0 else if(condition 1a || condition 1b) Statement 1 ... else Statement n can be explained as follows. ...as follows / ...the following applies - Statement 0 if all of the following conditions are true: - Condition 0a - Condition 0b - Otherwise, if one or more of the following conditions are true, statement 1: - Condition 1a - Condition 1b - ... - else statement n

[0585] A statement of logical operations that may be mathematically written in the text in the form: if(condition 0) Statement 0 if(condition1) Statement 1 can be explained as follows. If condition 0, then statement 0 If condition 1, then statement 1.

[0586] For example, embodiments of the encoder 20 and the decoder 30, and functions described herein with reference to the encoder 20 and the decoder 30, may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on a computer-readable medium or transmitted over a communication medium as one or more instructions or codes and executed by a hardware-based processing unit. The computer-readable medium may include a computer-readable storage medium, which corresponds to a tangible medium, such as a data storage medium, or a communication medium, which includes any medium that facilitates the transfer of a computer program from one place to another, for example, according to a communication protocol. In this manner, the computer-readable medium may generally correspond to (1) a tangible computer-readable storage medium that is non-transitory, or (2) a communication medium, such as a signal or carrier wave. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0587] By way of example, and without limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Also, any connection is properly referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but instead cover non-transitory tangible storage media. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically and discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer readable media.

[0588] The instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, the term "processor" as used herein may refer to any of the above structures or any other structure suitable for implementing the techniques described herein. In addition, in some aspects, the functionality described herein may be provided in dedicated hardware and / or software modules configured for encoding and decoding, or may be incorporated into a combined codec. Also, the techniques may be implemented entirely within one or more circuits or logic elements.

[0589] The techniques of the present disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). Various components, modules, or units are described in this disclosure to highlight functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, the various units may be combined in a codec hardware unit, or may be provided by a collection of interoperable hardware units, including one or more processors as described above, along with suitable software and / or firmware.

[0590] Further embodiments of the present invention are provided below. Please note that the numbering used in the following sections does not necessarily follow the numbering used in the previous sections.

[0591] Embodiment 1: A method of inter-prediction of a block of a picture, in which signaling of weighted prediction parameters and enabling of non-rectangular inter-prediction is performed for a group of predictive blocks, the method comprising: obtaining inter-prediction mode parameters for the block, the obtaining comprising checking whether non-rectangular inter-prediction mode is enabled for the group of blocks comprising the predictive blocks; and obtaining weighted prediction parameters associated with the block and inter-prediction mode parameters for the block with respect to a reference picture indicated for the block and weighted prediction parameters specified for the group of blocks.

[0592] Embodiment 2: The method of embodiment 1, wherein enabling non-rectangular inter prediction is performed by indicating a maximum number of triangle merge candidates (MaxNumTriangleMergeCand) greater than one.

[0593] Embodiment 3: In the method of embodiment 1 or 2, when the weighted prediction parameters specify enabled weighted prediction for at least one reference index, non-rectangular inter prediction is inferred to be disabled.

[0594] Embodiment 4: The method of any of embodiments 1-3, wherein the group of blocks is a picture, and both the weighted prediction parameters and the enabling of the inter-prediction non-rectangular mode parameter are indicated in the picture header.

[0595] Embodiment 5: The method of any of embodiments 1-4, wherein the group of blocks is a slice, and both the weighted prediction parameters and the enabling of the inter-prediction non-rectangular mode parameter are indicated in a slice header.

[0596] Embodiment 6: The method of any of embodiments 1 to 5, wherein the inter prediction mode parameters comprise a reference index used to determine a reference picture and motion vector information used to determine a position of a reference block within the reference picture.

[0597] Embodiment 7: The method of any of embodiments 1-6, wherein the non-rectangular merging mode is a triangulation mode.

[0598] Embodiment 8: The method of any of embodiments 1-7, wherein the non-rectangular merge mode is a GEO mode.

[0599] Embodiment 9: The method of any of embodiments 1-8, wherein the weighted prediction is a slice-level luminance compensation mechanism (such as global weighted prediction).

[0600] Embodiment 10: The method of any of embodiments 1-9, wherein the weighted prediction is a block-level luminance compensation mechanism, such as local illumination compensation (LIC).

[0601] Embodiment 11: The method of any of embodiments 1-10, wherein the weighted prediction parameters comprise a set of flags indicating whether weighted prediction is applied to luma and chroma components of the prediction block, and linear model parameters \alpha and \betta that specify a linear transformation of values ​​of the prediction block.

[0602] In a first aspect of the present application, as shown in FIG. 12, an inter prediction method 1200 is disclosed, including: S1201: determining whether a non-rectangular inter prediction mode is allowed for a group of blocks; S1202: obtaining one or more inter prediction mode parameters and weighted prediction parameters for the group of blocks; and S1203: obtaining a prediction value of a current block based on the one or more inter prediction mode parameters and weighted prediction parameters, wherein one of the inter prediction mode parameters indicates reference picture information for the current block, and the group of blocks comprises the current block.

[0603] In one possible implementation, the reference picture information comprises whether weighted prediction is enabled for the reference picture index, and if weighted prediction is enabled, the non-rectangular inter prediction mode is disabled.

[0604] In one possible implementation, if weighted prediction is disabled, non-rectangular inter prediction mode is enabled.

[0605] In one possible implementation, determining that the non-rectangular inter prediction mode is allowed includes indicating that a maximum number of triangle merge candidates (MaxNumTriangleMergeCand) is greater than one.

[0606] In one possible implementation, the group of blocks comprises a picture, and the weighted prediction parameters and the indication information for determining that non-rectangular inter prediction modes are allowed are in the picture header of the picture.

[0607] In one possible implementation, the group of blocks comprises a slice, and the weighted prediction parameters and the indication information for determining that non-rectangular inter prediction modes are allowed are in the slice header of the slice.

[0608] In one possible implementation, the non-rectangular inter prediction mode is a triangular partition mode.

[0609] In one possible implementation, the non-rectangular inter prediction mode is a geometric (GEO) partitioning mode.

[0610] In one possible implementation, the weighted prediction parameters are used for slice-level luminance compensation.

[0611] In one possible implementation, the weighted prediction parameters are used for block-level luminance compensation.

[0612] In one possible implementation, the weighted prediction parameters include a flag indicating whether weighted prediction is applied to the luma and / or chroma components of the prediction block, as well as linear model parameters that specify a linear transformation of the values ​​of the prediction block.

[0613] In a second aspect of the present application, as shown in FIG. 13, an apparatus 1300 for inter prediction comprises a non-transitory memory 1301 having processor-executable instructions stored thereon, and a processor 1302 coupled to the memory 1301, configured to execute the processor-executable instructions to facilitate any one of the possible implementation forms in the first aspect of the present application.

[0614] In a third aspect of the present application, a bitstream for inter prediction comprises display information for determining whether a non-rectangular inter prediction mode is allowed for a group of blocks, as well as one or more inter prediction mode parameters and weighted prediction parameters for the group of blocks, a prediction value of a current block is obtained based on the one or more inter prediction mode parameters and weighted prediction parameters, one of the inter prediction mode parameters indicating reference picture information for the current block, and the group of blocks comprises the current block.

[0615] In one possible implementation, the reference picture information comprises whether weighted prediction is enabled for the reference picture index, and if weighted prediction is enabled, the non-rectangular inter prediction mode is disabled.

[0616] In one possible implementation, if weighted prediction is disabled, non-rectangular inter prediction mode is enabled.

[0617] In one possible implementation, the indication information includes that the maximum number of triangle merge candidates (MaxNumTriangleMergeCand) is greater than one.

[0618] In one possible implementation, the group of blocks comprises a picture, and the weighted prediction parameters and the display information are in the picture header of the picture.

[0619] In one possible implementation, a group of blocks comprises a slice, and the weighted prediction parameters and the display information are in the slice header of the slice.

[0620] In one possible implementation, the non-rectangular inter prediction mode is a triangular partition mode.

[0621] In one possible implementation, the non-rectangular inter prediction mode is a geometric (GEO) partitioning mode.

[0622] In one possible implementation, the weighted prediction parameters are used for slice-level luminance compensation.

[0623] In one possible implementation, the weighted prediction parameters are used for block-level luminance compensation.

[0624] In one possible implementation, the weighted prediction parameters include a flag indicating whether weighted prediction is applied to the luma and / or chroma components of the prediction block, as well as linear model parameters that specify a linear transformation of the values ​​of the prediction block.

[0625] In a fourth aspect of the present application, as shown in FIG. 14, an inter prediction device 1400 is disclosed, comprising: a determination module 1401 configured to determine whether a non-rectangular inter prediction mode is allowed for a group of blocks; an acquisition module 1402 configured to acquire one or more inter prediction mode parameters and weighted prediction parameters for the group of blocks; and a prediction module 1403 configured to acquire a prediction value of a current block based on the one or more inter prediction mode parameters and weighted prediction parameters, wherein one of the inter prediction mode parameters indicates reference picture information for the current block, and the group of blocks comprises the current block.

[0626] In one possible implementation, the reference picture information comprises whether weighted prediction is enabled for the reference picture index, and if weighted prediction is enabled, the non-rectangular inter prediction mode is disabled.

[0627] In one possible implementation, if weighted prediction is disabled, non-rectangular inter prediction mode is enabled.

[0628] In one possible implementation, the determining module 1401 is specifically configured to indicate that the maximum number of triangle merge candidates (MaxNumTriangleMergeCand) is greater than one.

[0629] In one possible implementation, the group of blocks comprises a picture, and the weighted prediction parameters and the indication information for determining that non-rectangular inter prediction modes are allowed are in the picture header of the picture.

[0630] In one possible implementation, the group of blocks comprises a slice, and the weighted prediction parameters and the indication information for determining that non-rectangular inter prediction modes are allowed are in the slice header of the slice.

[0631] In one possible implementation, the non-rectangular inter prediction mode is a triangular partition mode.

[0632] In one possible implementation, the non-rectangular inter prediction mode is a geometric (GEO) partitioning mode.

[0633] In one possible implementation, the weighted prediction parameters are used for slice-level luminance compensation.

[0634] In one possible implementation, the weighted prediction parameters are used for block-level luminance compensation.

[0635] In one possible implementation, the weighted prediction parameters include a flag indicating whether weighted prediction is applied to the luma and / or chroma components of the prediction block, as well as linear model parameters that specify a linear transformation of the values ​​of the prediction block.

[0636] Furthermore, the following embodiments / aspects, which may be arbitrarily combined with each other as deemed suitable for practical applications, are provided herein, which are newly listed and described as follows:

[0637] In a first aspect of the present application, an inter prediction method includes determining whether a non-rectangular inter prediction mode is allowed for a group of blocks, obtaining one or more inter prediction mode parameters and weighted prediction parameters for the group of blocks, and obtaining a prediction value of a current block based on the one or more inter prediction mode parameters and weighted prediction parameters, wherein one of the inter prediction mode parameters indicates reference picture information for the current block, and the group of blocks comprises the current block.

[0638] In one possible implementation, the reference picture information comprises whether weighted prediction is enabled for the reference picture index, and if weighted prediction is enabled, the non-rectangular inter prediction mode is disabled.

[0639] In one possible implementation, if weighted prediction is disabled, non-rectangular inter prediction mode is enabled.

[0640] In one possible implementation, determining that the non-rectangular inter prediction mode is allowed includes indicating that a maximum number of triangle merge candidates (MaxNumTriangleMergeCand) is greater than one.

[0641] In one possible implementation, the group of blocks comprises a picture, and the weighted prediction parameters and the indication information for determining that non-rectangular inter prediction modes are allowed are in the picture header of the picture.

[0642] In one possible implementation, the group of blocks comprises a slice, and the weighted prediction parameters and the indication information for determining that non-rectangular inter prediction modes are allowed are in the slice header of the slice.

[0643] In one possible implementation, the non-rectangular inter prediction mode is a triangular partition mode.

[0644] In one possible implementation, the non-rectangular inter prediction mode is a geometric (GEO) partitioning mode.

[0645] In one possible implementation, a syntax element related to the number of candidates for a merge mode (display information for determining non-rectangular inter prediction) is signaled in a sequence parameter set (SPS), where a picture header may be signaled in a slice header when the picture comprises exactly one slice.

[0646] In one possible implementation, when a picture comprises exactly one slice, the picture header is signaled within the slice header.

[0647] In one possible implementation, the picture parameter set comprises a flag, the value of which specifies whether the weighted prediction parameters are present in the picture header or in the slice header.

[0648] In one possible implementation, a flag in the picture header indicates whether a non-intra type slice is present and whether inter prediction mode parameters are signaled for this slice.

[0649] In one possible implementation, the weighted prediction parameters are used for slice-level luminance compensation.

[0650] In one possible implementation, the weighted prediction parameters are used for block-level luminance compensation.

[0651] In one possible implementation, the weighted prediction parameters include a flag indicating whether weighted prediction is applied to the luma and / or chroma components of the prediction block, as well as linear model parameters that specify a linear transformation of the values ​​of the prediction block.

[0652] In a second aspect of the present application, an apparatus for inter prediction comprises a non-transitory memory having processor-executable instructions stored thereon, and a processor coupled to the memory configured to execute the processor-executable instructions to facilitate any one of the possible implementation forms in the first aspect of the present application.

[0653] In a third aspect of the present application, a bitstream for inter prediction comprises display information for determining whether a non-rectangular inter prediction mode is allowed for a group of blocks, as well as one or more inter prediction mode parameters and weighted prediction parameters for the group of blocks, a prediction value of a current block is obtained based on the one or more inter prediction mode parameters and weighted prediction parameters, one of the inter prediction mode parameters indicating reference picture information for the current block, and the group of blocks comprises the current block.

[0654] In one possible implementation, the reference picture information comprises whether weighted prediction is enabled for the reference picture index, and if weighted prediction is enabled, the non-rectangular inter prediction mode is disabled.

[0655] In one possible implementation, if weighted prediction is disabled, non-rectangular inter prediction mode is enabled.

[0656] In one possible implementation, the indication information includes that the maximum number of triangle merge candidates (MaxNumTriangleMergeCand) is greater than one.

[0657] In one possible implementation, the group of blocks comprises a picture, and the weighted prediction parameters and the display information are in the picture header of the picture.

[0658] In one possible implementation, a group of blocks comprises a slice, and the weighted prediction parameters and the display information are in the slice header of the slice.

[0659] In one possible implementation, the non-rectangular inter prediction mode is a triangular partition mode.

[0660] In one possible implementation, the non-rectangular inter prediction mode is a geometric (GEO) partitioning mode.

[0661] In one possible implementation, the weighted prediction parameters are used for slice-level luminance compensation.

[0662] In one possible implementation, the weighted prediction parameters are used for block-level luminance compensation.

[0663] In one possible implementation, the weighted prediction parameters include a flag indicating whether weighted prediction is applied to the luma and / or chroma components of the prediction block, as well as linear model parameters that specify a linear transformation of the values ​​of the prediction block.

[0664] In a fourth aspect of the present application, an inter prediction device comprises a determination module configured to determine whether a non-rectangular inter prediction mode is allowed for a group of blocks; an acquisition module configured to acquire one or more inter prediction mode parameters and weighted prediction parameters for the group of blocks; and a prediction module configured to acquire a prediction value of a current block based on the one or more inter prediction mode parameters and weighted prediction parameters, wherein one of the inter prediction mode parameters indicates reference picture information for the current block, and the group of blocks comprises the current block.

[0665] In one possible implementation, the reference picture information comprises whether weighted prediction is enabled for the reference picture index, and if weighted prediction is enabled, the non-rectangular inter prediction mode is disabled.

[0666] In one possible implementation, if weighted prediction is disabled, non-rectangular inter prediction mode is enabled.

[0667] In one possible implementation, the decision module is specifically configured to indicate that the maximum number of triangle merge candidates (MaxNumTriangleMergeCand) is greater than one.

[0668] In one possible implementation, the group of blocks comprises a picture, and the weighted prediction parameters and the indication information for determining that non-rectangular inter prediction modes are allowed are in the picture header of the picture.

[0669] In one possible implementation, the group of blocks comprises a slice, and the weighted prediction parameters and the indication information for determining that non-rectangular inter prediction modes are allowed are in the slice header of the slice.

[0670] In one possible implementation, the non-rectangular inter prediction mode is a triangular partition mode.

[0671] In one possible implementation, the non-rectangular inter prediction mode is a geometric (GEO) partitioning mode.

[0672] In one possible implementation, the weighted prediction parameters are used for slice-level luminance compensation.

[0673] In one possible implementation, the weighted prediction parameters are used for block-level luminance compensation.

[0674] In one possible implementation, the weighted prediction parameters include a flag indicating whether weighted prediction is applied to the luma and / or chroma components of the prediction block, as well as linear model parameters that specify a linear transformation of the values ​​of the prediction block.

[0675] Additionally, the following embodiments are provided herein:

[0676] 1. A method for encoding a video sequence, comprising: determining whether a weighted prediction parameter may be present in a picture header or a slice header to obtain a determination result; and signaling by a flag in a picture parameter set that the weighted prediction parameters may be present in the picture header or in the slice header depending on the determination result.

[0677] 2. The method of embodiment 1, wherein a flag in a picture parameter set is A flag equal to 1 specifies that weighted prediction parameters are not present in slice headers that reference the picture parameter set, but may be present in picture headers that reference the PPS, and a flag equal to 0 in the picture parameter set specifies that weighted prediction parameters are not present in picture headers that reference the picture parameter set, but may be present in slice headers that reference the picture parameter set.

[0678] 3. The method of embodiment 1 or 2, further comprising signaling the weighted prediction parameters in a picture header.

[0679] 4. The method of any of the preceding embodiments, further comprising signaling weighted prediction parameters in a picture header only when another flag in the picture header specifies that inter slice is enabled.

[0680] 5. A method for decoding an encoded video sequence, parsing a picture parameter set of a bitstream of the encoded video sequence to obtain a value of a flag provided in the picture parameter set, and determining based on the obtained value of the flag that weighted prediction parameters may be present in a picture header of the encoded video sequence or in a slice header of the encoded video sequence.

[0681] 6. The method of embodiment 5, wherein a flag in a picture parameter set is A flag equal to 1 specifies that weighted prediction parameters are not present in slice headers that reference the picture parameter set, but may be present in picture headers that reference the PPS, and a flag equal to 0 in the picture parameter set specifies that weighted prediction parameters are not present in picture headers that reference the picture parameter set, but may be present in slice headers that reference the picture parameter set.

[0682] 7. The method of embodiment 5 or 6, further comprising parsing picture headers of a bitstream of the video sequence to obtain weighted prediction parameters from the parsed picture headers.

[0683] 8. A method according to any one of embodiments 5 to 7, comprising parsing a picture header of a bitstream of a video sequence, and obtaining a weighted prediction parameter from the parsed picture header only if the picture header comprises another flag, the other flag specifying that inter-slice is enabled.

[0684] 9. A method for inter prediction of a current block of a group of blocks of a video sequence, comprising the steps of any one of embodiments 1 to 8, Obtaining one or more inter prediction mode parameters and weighted prediction parameters for a group of blocks; and obtaining a prediction value for the current block based on one or more inter-prediction mode parameters and weighted prediction parameters, where one of the inter-prediction mode parameters indicates reference picture information for the current block.

[0685] 10. A method of embodiment 9, wherein the reference picture information comprises information about whether weighted prediction is enabled for the reference picture index, and when weighted prediction is enabled, at least one non-rectangular inter prediction mode is disabled.

[0686] 11. In the method of embodiment 9 or 10, when weighted prediction is disabled, a non-rectangular inter prediction mode is enabled.

[0687] 12. The method of any one of embodiments 9 to 11, wherein the group of blocks comprises a picture, and the information for determining whether a non-rectangular inter prediction mode is allowed is in a picture header of the picture.

[0688] 13. A method according to any one of embodiments 9 to 11, wherein the group of blocks comprises a slice, and the information for determining whether a non-rectangular inter prediction mode is allowed is in a slice header of the slice.

[0689] 14. The method of any one of embodiments 9 to 13, wherein the non-rectangular inter prediction mode is a triangular partition mode.

[0690] 15. The method of any one of embodiments 9 to 13, wherein the non-rectangular inter prediction mode is a geometric partition mode.

[0691] 16. In the method of any one of embodiments 1 to 15, when a picture comprises exactly one slice, the picture header is signaled in the slice header.

[0692] 17. The method of any one of embodiments 1-16, wherein the weighted prediction parameters are used for slice-level luminance compensation.

[0693] 18. The method of any one of embodiments 1-16, wherein the weighted prediction parameters are used for block-level luminance compensation.

[0694] 19. The method of any one of embodiments 1 to 18, wherein the weighted prediction parameters are: a flag indicating whether weighted prediction is applied to the luma and / or chroma components of the predicted block; and It comprises linear model parameters that specify a linear transformation of the values ​​of the prediction block.

[0695] 20. A non-transitory memory having processor-executable instructions stored thereon; and a processor coupled to the memory configured to execute the processor-executable instructions to facilitate any one of embodiments 1-19. Apparatus for inter prediction. [Explanation of symbols]

[0696] 10. Video Coding System 12 Source Device 13 Communication Channels 14 Destination Device 16 Picture Source 17 Picture, Picture Data, Raw Picture, Raw Picture Data 18 Preprocessor, preprocessing unit 19 Preprocessed Picture, Preprocessed Picture Data 20 Video Encoder 21 Encoded Picture Data 22 Communication interface, communication unit 28 Communication interface, communication unit 30 Video Decoder, Short Decoder, Decoder 31 Decoded Picture, Decoded Picture Data 32 Post-processor, post-processing unit 33 Post-Processed Picture, Post-Processed Picture Data 34 Display Devices 46 Processing circuit configuration 201 Input unit, input interface 203 Picture Block 204 Residual Calculation Unit 205 Residual Blocks, Residual 206 Conversion Processing Unit 207 Conversion Factors 208 Quantization Units 209 Quantized Coefficients, Quantized Transform Coefficients, Quantized Residual Coefficients 210 Inverse Quantization Unit 211 Dequantized coefficients, inverse quantized residual coefficients 212 Inverse Transformation Processing Unit 213 Reconstructed residual block, corresponding dequantized coefficients, transform block 214 Reconstruction Unit 215 Reconstructed Blocks 216 Buffers 220 Loop Filter Unit 221 Filtered Block, Filtered Reconstructed Block 230 Decoded Picture Buffer 231 Decoded Pictures 244 Inter Prediction Units 254 intra prediction units 260 Mode Selection Unit 262 Division Unit 265 prediction block, predictor 266 Syntax Elements 270 Entropy Coding Unit 272 Output section, output interface 304 Entropy Decoding Unit 309 Quantized Coefficients 310 Inverse Quantization Unit 311 transform coefficients, dequantized coefficients 312 Inverse Transformation Processing Unit 313 Reconstructed residual block, transform block 314 Reconstruction Unit, Adder 315 Reconstructed Blocks 320 Loop Filter Unit 321 Filtered Block, Decoded Video Block of a Picture 330 Decoded Picture Buffer (DPB) 331 Decoded Pictures 344 Inter Prediction Units 354 intra prediction units 360 mode application unit 365 predicted blocks 400 Video Coding Device 410 inlet port, input port 420 Receiver Unit 430 Processors, Logic Units, Central Processing Units 440 Transmitter Unit 450 Exit port, output port 460 Memory 470 Coding Module 500 devices 502 processor 504 Memory 506 Code and Data 508 Operating Systems 510 Application Program 512 Bus 514 Secondary Storage 518 Display 610 Video Analysis 611 Statistics 631 Status Value 660 Encoding Engine 710, 720 Inter-predictor 730, 740 WP parameters 750 blocks Blocks 810 and 820 830, 840 Weights and Offsets 850 Inter Prediction Blocks 851, 852 Predictors 901 Inter-predictor, Block 911, 912 Prediction block, predictor, block 921 overlapping areas 931, 932, 933, 934, 935, 936 blocks 1300 equipment 1301 Non-transient memory 1302 Processor 1400 Inter Prediction Device 1401 Decision Module 1402 Acquisition Module 1403 Prediction Module 1700 Decryption Device 1710 Bitstream Acquisition Unit 1720 Indicator Value Acquisition Unit 1730 Syntax Analysis Unit 1740 prediction units 3100 Contents Supply System 3102 Capture Device 3104 Communication Links 3106 Terminal Device 3108 Smartphone / Pad 3110 Computer / Laptop 3112 Network Video Recorder / Digital Video Recorder 3114 TV 3116 Set-top box 3118 Video Conference System 3120 Video Surveillance System 3122 Portable information terminals 3124 Vehicle-mounted devices 3126 Display 3202 Protocol Progression Unit 3204 Demultiplexing Unit 3206 Video Decoder 3208 Audio Decoder 3210 Subtitle Decoder 3212 Synchronous Unit 3214 Video / Audio Display 3216 Video / Audio / Subtitle Display

Claims

1. 1. A method of coding implemented by a decoding device, comprising: obtaining a bitstream for a current picture; obtaining a value of a first indicator for the current picture according to the bitstream, the first indicator indicating a slice type; obtaining a value of a second indicator for the current picture according to the bitstream, the second indicator indicating whether weighted prediction parameters are present in a picture header or a slice header; parsing a value of the weighted prediction parameter for a current block from the bitstream when the value of the first indicator is equal to a first preset value and the value of the second indicator is equal to a second preset value, the current block being comprised in a current slice of the current picture, the first preset value being an integer value and the second preset value being an integer value; predicting the current block according to the values ​​of the weighted prediction parameters; A method comprising:

2. 2. The method of claim 1, wherein the value of the first indicator is obtained according to a picture header provided in the bitstream, or the value of the second indicator is obtained according to a picture parameter set provided in the bitstream, or the value of the weighted prediction parameter is parsed from a picture header provided in the bitstream.

3. The method of claim 1 or 2, wherein the first preset value is 1 and the second preset value is 1.

4. A method according to any one of claims 1 to 3, wherein the value of the first indicator being equal to the first preset value indicates that the slice type of at least one slice included in the current picture is inter slice.

5. The method of claim 4 , wherein the inter slice comprises a B slice or a P slice.

6. 1. A method of coding implemented by a decoding device, comprising: obtaining a bitstream for a current picture; obtaining a value of a first indicator for the current picture according to the bitstream, the first indicator indicating a slice type; obtaining a value of a second indicator for the current picture according to the bitstream, the second indicator indicating whether weighted prediction parameters are present in a picture header or a slice header; obtaining a value of a third indicator for the current picture according to the bitstream, the third indicator indicating whether weighted prediction is applicable to an inter slice, and the slice type of the inter slice is a B slice or a P slice; parsing values ​​of the weighted prediction parameters for a current block from the bitstream when the value of the first indicator is equal to a first preset value, the value of the second indicator is equal to a second preset value, and the value of the third indicator indicates that weighted prediction is applicable to the inter slice, where the current block is comprised in a current slice of the current picture, the first preset value is an integer value, and the second preset value is an integer value; predicting the current block according to the values ​​of the weighted prediction parameters; A method comprising:

7. 7. The method of claim 6, wherein the value of the first indicator is obtained according to a picture header provided in the bitstream, or the value of the second indicator is obtained according to a picture parameter set provided in the bitstream, or the value of the weighted prediction parameter is obtained according to a picture header provided in the bitstream, or the value of the third indicator is obtained according to a picture parameter set provided in the bitstream.

8. The method according to claim 6 or 7, wherein the first preset value is 1 and the second preset value is 1.

9. A method according to any one of claims 6 to 8, wherein the value of the first indicator equal to the first preset value indicates that the slice type of at least one slice included in the current picture is inter slice.

10. 10. The method of claim 6, wherein the value of the third indicator being 1 indicates that weighted prediction is applicable to the inter slice.

11. A decoder (30) comprising processing circuitry for carrying out the method of any one of claims 1 to 10.

12. A computer program product comprising a program code for performing the method according to any one of claims 1 to 10, when the computer program product is executed on a computer or processor.

13. A decoder (30), one or more processors; and a non-transitory computer readable storage medium coupled to said processor and storing programming for execution by said processor, said programming, when executed by said processor, configuring said decoder to perform the method of any one of claims 1 to 10. Decoder(30).

14. A non-transitory computer readable medium carrying program code which, when executed by a computing device, causes the computing device to perform the method of any one of claims 1 to 10.

15. A decoding device (1700), a bitstream acquisition unit (1710) configured to acquire a bitstream for a current picture; obtaining a value of a first indicator for the current picture according to the bitstream, the first indicator indicating a slice type; and and obtaining a value of a second indicator for the current picture according to the bitstream, the second indicator indicating whether weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream. An indicator value acquisition unit (1720); a parsing unit (1730) configured to parse a value of the weighted prediction parameter for a current block from the bitstream when the value of the first indicator is equal to a first preset value and the value of the second indicator is equal to a second preset value, where the current block is comprised in a current slice of the current picture, the first preset value is an integer value, and the second preset value is an integer value; a prediction unit (1740) configured to predict the current block according to the value of the weighted prediction parameter; A decoding device (1700) comprising:

16. the indicator value obtaining unit (1720) is configured to obtain the value of the first indicator according to a picture header comprised in the bitstream or the value of the second indicator according to a picture parameter set comprised in the bitstream, or the parsing unit (1730) is configured to parse the values ​​of the weighted prediction parameters from picture headers provided in the bitstream.

16. The decoding device (1700) of claim 15.

17. 17. The decoding device (1700) of claim 15 or 16, wherein the first preset value is 1 and the second preset value is 1.

18. A decoding device (1700) according to any one of claims 15 to 17, wherein the value of the first indicator being equal to the first preset value indicates that the slice type of at least one slice included in the current picture is inter slice.

19. 20. The decoding device (1700) of claim 18, wherein the inter slice comprises a B slice or a P slice.

20. A decoding device (1700), a bitstream acquisition unit (1710) configured to acquire a bitstream for a current picture; obtaining a value of a first indicator for the current picture according to the bitstream, the first indicator indicating a slice type; obtaining a value of a second indicator for the current picture according to the bitstream, the second indicator indicating whether weighted prediction parameters are present in a picture header of the bitstream or in a slice header of the bitstream; and and obtaining a value of a third indicator for the current picture according to the bitstream, the third indicator indicating whether weighted prediction is applicable to an inter slice, and the slice type of the inter slice is a B slice or a P slice. An indicator value acquisition unit (1720); a parsing unit (1730) configured to parse values ​​of the weighted prediction parameters for a current block from the bitstream when the value of the first indicator is equal to a first preset value, the value of the second indicator is equal to a second preset value, and the value of the third indicator indicates that weighted prediction is applicable to the inter slice, where the current block is comprised in a current slice of the current picture, the first preset value is an integer value, and the second preset value is an integer value; a prediction unit (1740) configured to predict the current block according to the value of the weighted prediction parameter; A decoding device (1700) comprising:

21. the indicator value obtaining unit (1720) is configured to obtain the value of the first indicator according to a picture header comprised in the bitstream, or the value of the second indicator according to a picture parameter set comprised in the bitstream, or the value of the third indicator according to a picture parameter set comprised in the bitstream, or the parsing unit (1730) is configured to parse the weighted prediction parameters from a picture header provided in the bitstream.

21. The decoding device (1700) of claim 20.

22. 22. The decoding device (1700) of claim 20 or 21, wherein the first preset value is 1 and the second preset value is 1.

23. A decoding device (1700) according to any one of claims 20 to 22, wherein the value of the first indicator equal to the first preset value indicates that the slice type of at least one slice included in the current picture is inter slice.

24. 24. A decoding device (1700) according to any one of claims 20 to 23, wherein the value of the third indicator being 1 indicates that weighted prediction is applicable to the inter slice.

Images