Video encoding and decoding method and related device

Abstract

A method and apparatus for video encoding and decoding are disclosed. According to the method, a current block is received at an encoder, or compressed data including the current block is received at a decoder, wherein the current block is partitioned into two geometric prediction units. Motion information for the two geometric prediction units is determined. Weight information for the two geometric prediction units is determined. A motion storage type variable is determined based on the weight information, wherein the motion information associated with the current block is stored according to a value of the motion storage type variable. Based on the weight information, a geometric predictor for the current block is generated by blending two geometric predictors, wherein the two geometric predictors are derived for the two geometric prediction units using the motion information associated with the current block.

Description

[0001] Cross-references

[0002] This application claims priority to U.S. Provisional Patent Application Serial Nos. 62 / 940,964, filed on November 27, 2019, which are hereby incorporated by reference in their entirety. Technical Field

[0003] The present invention relates to using Geometric Merge mode (GEO) for prediction in video codecs. In particular, the present invention discloses techniques to integrate the derivation of weights and motion indices in GEO. Background Art

[0004] High Efficiency Video Coding (HEVC) is a next-generation international video codec standard developed by the Joint Collaborative Team on Video Coding (JCT-VC). HEVC is based on a hybrid block-based motion compensation codec architecture similar to the DCT transform. The basic unit of compensation (called a codec unit, CU) is a 2Nx2N square block. Each CU can be recursively split into four smaller CUs until a predetermined minimum size is reached. Each CU contains one or more prediction units (PUs).

[0005] To achieve optimal coding efficiency in the hybrid coding architecture of HEVC, two prediction modes (i.e., intra prediction and inter prediction) are provided for each PU. For the intra prediction mode, spatially adjacent reconstructed pixels can be used to generate directional predictions.

[0006] Following the development of the HEVC standard, another upcoming codec standard, Versatile Video Coding (VVC), is being developed by the Joint Video Exploration Team (JVET) within the International Telecommunication Union - Telecommunication Standardization Sector, Study Group 16, Working Group 3 (ITU-T SG16 WP3) and the International Organization for Standardization / International Electrotechnical Commission, Technical Committee 1, Subcommittee 29, Working Group 11 (ISO / IEC JTC1 / SC29 WG11). Various new codecs, along with existing ones, have been evaluated for use with VVC. Among these codecs, the Geometric Merge mode (GEO) has been proposed for use with VVC. A brief review of GEO is included below.

[0007] Geometry Merge Mode (GEO)

[0008] The geometric merge mode was proposed in document JVET-P0068 (“CE4: CE4-1.1, CE4-1.2 and CE4-1.14: Geometric Merge Mode (GEO)” by H. Gao et al.; in International Telecommunication Union - Telecommunication Standardization Sector, Study Group 16, Working Group 3 (ITU-T SG16 WP3) and International Organization for Standardization / International Electrotechnical Commission Technical Committee 1, Subcommittee 29, Working Group 11 (ISO / IEC JTC1 / SC29 WG11), 16th Meeting: Geneva, CH; October 1-11, 2019; document P0068), which uses the same predictor blending concept as TPM and extends the blending mask to up to 140 different modes with 32 angles and 5 distance offsets.

[0009] 140 modes were defined in CE4-1.1 of P0068. To further reduce complexity, 108 modes and 80 GEO modes were tested in CE4-1.2. In CE4-1.14, a TPM-like simplified motion storage was tested.

[0010] Figure 1A The partition shape (111-112) used for TPM in VTM-6.0 is shown and Figure 1B Additional shapes (113-119) proposed for non-rectangular inter blocks are shown.

[0011] Similar to TPM, the proposed GEO partitioning for inter-frames is allowed for unidirectionally predicted blocks no smaller than 8x8, allowing for the same memory bandwidth usage as bidirectionally predicted blocks at the decoder. Motion vector prediction is performed individually for each GEO partition. Similarly, blending between two predictions is applied at inner boundaries.

[0012] like Figure 2 As shown, the split boundaries in the geometric merge mode are described by angle φ_i and distance offset ρ_i. Angle φ_i represents a quantized angle between 0 and 360 degrees, and distance offset ρ_i represents a quantized offset of the maximum distance ρ_max. Furthermore, split directions that overlap with binary tree and TPM splits are excluded.

[0013] Decoding routine for GEO inter-frame blocks

[0014] The text of the decoding procedure for GEO inter-frame blocks (i.e., wedge inter-frame blocks) is proposed in an annex to JVET-P0884 ("Simplified GEO without multiplication and minimum blending mask storage" by H. Gao et al., a reconciliation of JVET-P0107, JVET-P0264, and JVET-P0304); in the International Telecommunication Union - Telecommunication Standardization Sector, Study Group 16, Working Group 3 (ITU-T SG16 WP3) and in the International Organization for Standardization / International Electrotechnical Commission, Technical Committee 1, Subcommittee 29, Working Group 11 (ISO / IEC JTC1 / SC29). (WG11), 16th Meeting: Geneva, CH; October 1–11, 2019; document JVET-P0884). As disclosed in an appendix to JVET-P0884, the text of the JVET-O2001 amendment for decoding GEO inter blocks is provided below to provide a baseline for the derivation of conventional weight indices and motion indices. Section, clause, table, and figure numbers remain the same as in the amended JVET-O2001.

[0015] 8.5.7 Decoding Procedure for Wedge-Shaped Inter-Frame Blocks

[0016] 8.5.7.1 General

[0017] This procedure is invoked when decoding a codec unit with wedge_merge_mode[xCb][yCb] equal to 1.

[0018] The input to this program is:

[0019] A luma position (xCb, yCb) to specify the top left sample of the current codec block relative to the top left luma sample of the current picture,

[0020] A variable cbWidth specifies the width of the current codec block in luma samples.

[0021] A variable cbHeight specifies the height of the current codec block in luma samples.

[0022] Luma motion vectors mvA and mvB with 1 / 16 fractional-sample accuracy,

[0023] Chroma motion vectors mvCA and mvCB,

[0024] Reference indexes refIdxA and refIdxB,

[0025] Prediction list flags predListFlagA and predListFlagB.

[0026] The output of this program is:

[0027] a (cbWidth)x(cbHeight) array of luma prediction samples, predSamplesL,

[0028] a (cbWidth / SubWidthC) x (cbHeight / SubHeightC) array of chroma prediction samples for component Cb, predSamplesCb,

[0029] A (cbWidth / SubWidthC) x (cbHeight / SubHeightC) array of chroma prediction samples for component Cr, predSamplesCr.

[0030] Assume that predSamplesLAL and predSamplesLBL are (cbWidth)x(cbHeight) arrays of predicted luma sample values, and predSamplesLACb, predSamplesLBCb, predSamplesLACr, and predSamplesLBCr are (cbWidth / SubWidthC)x(cbHeight / SubHeightC) arrays of predicted chroma sample values.

[0031] predSamplesL, predSamplesCb, and predSamplesCr are derived through the following sequential steps:

[0032] 1. For N, for each A and B, apply the following:

[0033] – A reference picture consisting of an ordered two-dimensional array of luma samples refPicLNL and two ordered two-dimensional arrays of chroma samples refPicLNCb and refPicLNCr is derived by referring to the procedure specified in clause 8.5.6.2, with X set equal to predListFlagN

[0034] And refIdxX is set equal to refIdxN as input.

[0035] – The array predSamplesLNL is derived by referencing the fractional sample interpolation procedure specified in clause 8.5.6.3 with the luma position (xCb, yCb), with the luma codec block width sbWidth set equal to cbWidth, the luma codec block height sbHeight set equal to cbHeight, the motion vector offset mvOffset set equal to (0,0), the motion vector mvLX set equal to mvN and the reference array refPicLXL set equal to refPicLNL, the variable bdofFlag set equal to FALSE, and the variable cIdx set equal to 0 as input.

[0036] – The array predSamplesLNCb is derived from the luma position (xCb, yCb) by referencing the fractional sample interpolation procedure specified in clause 8.5.6.3, with the codec block width sbWidth set equal to cbWidth / SubWidthC, the codec block height sbHeight set equal to cbHeight / SubHeightC, the motion vector offset mvOffset set equal to (0,0), the motion vector mvLX set equal to mvCN, and the reference array refPicLXCb set equal to refPicLNCb, the variable bdofFlag set equal to FALSE, and the variable cIdx

[0037] Set equal to 1 as input.

[0038] – The array predSamplesLNCr is derived by referencing the fractional sample interpolation procedure specified in clause 8.5.6.3 with the luma position (xCb, yCb), with the codec block width sbWidth set equal to cbWidth / SubWidthC, the codec block height sbHeight set equal to cbHeight / SubHeightC, the motion vector offset mvOffset set equal to (0,0), the motion vector mvLX set equal to mvCN, and the reference array refPicLXCr set equal to refPicLNCr, the variable bdofFlag set equal to FALSE, and the variable cIdx set equal to 2 as input.

[0039] 2. Set the wedge partitioning angle and distance (angleIdx and distanceIdex) for the wedge merge mode according to the wedge_partition_idx[xCb][yCb] values ​​specified in Tables 8-10.

[0040] 3. The prediction samples within the current luma codec block (predSamplesL[xL][yL] with xL = 0..cbWidth-1 and yL = 0..cbHeight–1) are derived by reference to the weighted sample prediction procedure for wedge merging mode specified in clause 8.5.7.2, with the codec block width nCbW set equal to cbWidth, the codec block height nCbH set equal to cbHeight, the sample arrays predSamplesLAL and predSamplesLBL, and the variables angleIdx and distanceIdx, and cIdx equal to 0 as input.

[0041] 4. The prediction samples within the current chroma component Cb codec block (predSamplesCb[xC][yC] with xC = 0..cbWidth / SubWidthC-1 and yC = 0..cbHeight / SubHeightC–1) are derived by reference to the weighted sample prediction procedure for wedge merging mode specified in clause 8.5.7.2, with the codec block width nCbW set equal to cbWidth / SubWidthC, the codec block height nCbH set equal to cbHeight / SubHeightC, the sample arrays predSamplesLACb and predSamplesLBCb, and the variables angleIdx and distanceIdx, and cIdx equal to 1 as input.

[0042] 5. The prediction samples within the current chroma component Cr codec block (predSamplesCr[xC][θyC] with xC = 0..cbWidth / SubWidthC-1 and yC = 0..cbHeight / SubHeightC-1) are derived by reference to the weighted sample prediction procedure for wedge merging mode specified in clause 8.5.7.2, with the codec block width nCbW set equal to cbWidth / SubWidthC, the codec block height nCbH set equal to cbHeight / SubHeightC, the sample arrays predSamplesLACr and predSamplesLBCr, and the variables angleIdx and distanceIdx, and cIdx equal to 2 as input.

[0043] 6. The motion vector storage procedure for wedge merge mode specified in clause 8.5.7.3 is referenced, with the luma codec block position (xCb, yCb), luma codec block width cbWidth, luma codec block height cbHeight, segmentation directions angleIdx and distanceIdx, luma motion vectors mvA and mvB, reference indices refIdxA and refIdxB, and prediction list flags predListFlagA and predListFlagB as input.

[0044] Table θ8-10 – Specification of angleIdx and distanceIdx values ​​based on wedge_partition_idx values

[0045] wedge_partition_idx 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 angleIdx 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 distanceIdx 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 wedge_partition_idx 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 angleIdx 4 5 5 5 5 6 6 6 7 7 7 7 8 8 8 8 9 9 distanceIdx 3 0 1 2 3 1 2 3 0 1 2 3 0 1 2 3 0 1 wedge_partition_idx 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 angleIdx 9 9 10 10 10 10 11 11 11 11 12 12 12 13 13 13 14 14 distanceIdx 2 3 0 1 2 3 0 1 2 3 1 2 3 1 2 3 1 2 wedge_partition_idx 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 angleIdx 14 15 15 15 16 16 16 17 17 17 18 18 18 19 19 19 20 20 distanceIdx 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 wedge_partition_idx 72 73 74 75 76 77 78 79 80 81 angleIdx 20 21 21 21 22 22 22 23 23 23 distanceIdx 3 1 2 3 1 2 3 1 2 3

[0046] 8.5.7.2 Weighted Sample Prediction Procedure for Wedge Merging Mode

[0047] The input to this program is:

[0048] The two variables nCbW and nCbH are used to indicate the width and height of the current codec block.

[0049] Two (nCbW)x(nCbH) arrays predSamplesLA and predSamplesLB,

[0050] A variable angleIdx specifies the angle index of the wedge segmentation.

[0051] A variable distanceIdx specifies the distance index of the wedge segmentation.

[0052] A variable cIdx specifies the color component index.

[0053] The output of this procedure is a (nCbW)x(nCbH) array pbSamples of predicted sample values.

[0054] The variable bitDepth is derived as follows:

[0055] If cIdx is equal to 0, bitDepth is set equal to BitDepthY.

[0056] If cIdx is equal to 0, nW and nH are set equal to nCbW a and nCbH respectively. Otherwise (cIdx is not equal to 0), nW and nH are set equal to nCbW x SubWidthC and nCbH x SubHeightC respectively.

[0057] If cIdx is equal to 0, both subW and subH are set to 1, otherwise (cIdx is not equal to 0) subW and subH are set equal to SubWidthC and SubHeightC respectively.

[0058] Otherwise, bitDepth is set equal to BitDepthC.

[0059] The variables shift1 and offset1 are derived as follows:

[0060] The variable shift1 is set equal to Max(5,17-bitDepth).

[0061] The variable offset1 is set equal to 1<<(shift1-1).

[0062] The following variables are set to the following values:

[0063] hwRatio is set to nH / nW

[0064] displacementX is set to angleIdx

[0065] displacementY is set to (displacementX+6)%24

[0066] If angleIdx>=10&&angleIdx<=20, PART1 and PART2 are set equal to A and B respectively; otherwise, PART1 and PART2 are set equal to B and A respectively.

[0067] Use the lookup table labeled Dis (specified in Tables 8-12) to set rho to the following values:

[0068] rho=(Dis[displacementX]<<8)+(Dis[displacementY]<<8)

[0069] The variable shiftHor is set equal to 0 if one of the following conditions is true:

[0070] angleIdx%12 is equal to 6

[0071] angleIdx%12 is not equal to 0 and hwRatio≥1

[0072] Otherwise, shiftHor is set equal to 1.

[0073] If shiftHor is equal to 0, offsetX and offsetY are derived as follows:

[0074] offsetX=(256-nW)>>1

[0075] offsetY=(256-nH)>>1+angleIdx<12? (distanceIdx*nH)>>3:-((distanceIdx*nH)>>3)

[0076] Otherwise, if shiftHor is equal to 1, offsetX and offsetY are derived as follows:

[0077] offsetX=(256-nW)>>1+angleIdx<12? (distanceIdx*nW)>>3:-((distanceIdx*nW)>>3)

[0078] offsetY=(256-nH)>>1

[0079] The predicted sample values ​​pbSamples[x][y] (where x = 0..nCbW-1 and y = 0..nCbH-1) are set according to the following sequential steps:

[0080] The variables weightIdx and weightIdxAbs are calculated using the lookup tables 8-12 as follows:

[0081] weightIdx=(((x*subW+offsetX)<<1)+1)*Dis[displacementX]

[0082] +(((y*subH+offsetY)<<1)+1))*Dis[displacementY]-rho.

[0083] weightIdxAbs=Clip3(0,26,abs(weightIdx)).

[0084] The value of sampleWeight is derived from Table 8-13 as follows:

[0085] sampleWeight=weightIdx<=0? WedgeFilter[weightIdxAbs]:8-WedgeFilter[weightIdxAbs]

[0086] Note – The sampleWeightL[x][y] values ​​can also be obtained from

[0087] SampleWeightL[x-shiftX][y-shiftY] is derived. If angleIdx is greater than 4 and less than 12, or angleIdx is greater than 20 and less than 24, shiftX is the tangent of the split angle and shiftY is 1. Otherwise, shiftX is 1 of the split angle and shiftY is the cotangent of the split angle. If the tangent (or cotangent, respectively) is infinite, shiftX is 1 (or 0, respectively) or shiftY is 0 (or 1, respectively).

[0088] The predicted sample values ​​pbSamples[x][y] are derived as follows:

[0089] pbSamples[θx][y]=Clip3(0,(1< <bitDepth)-1,

[0090] (predSamplesLPART1[θx][y]*(8–

[0091] sampleWeight)+predSamplesLPART2[x][y]*sampleWeight

[0092] +offset1)>>shift1)

[0093] Table 8-12 – Comparison table Dis for derivation of wedgemetric segmentation distance

[0094]

[0095]

[0096] Table 8-13 – Comparison of filter weights used for wedge segmentation filter weight derivation

[0097] WedgeFilter

[0098]

[0099] 8.5.7.3 Motion Vector Storage Procedure for Wedge Merging Mode

[0100] This procedure is invoked when decoding a codec unit with MergeWedgeFlag[xCb][yCb] equal to 1.

[0101] The input to this program is:

[0102] A luma position (xCb, yCb) to specify the top left sample of the current codec block relative to the top left luma sample of the current picture,

[0103] A variable cbWidth specifies the width of the current codec block in luma samples.

[0104] A variable cbHeight specifies the height of the current codec block in luma samples.

[0105] Luma motion vectors mvA and mvB with 1 / 16 fractional-sample accuracy,

[0106] Reference indexes refIdxA and refIdxB,

[0107] Prediction list flags predListFlagA and predListFlagB.

[0108] The variables numSbX and numSbY, which indicate the number of 4x4 blocks in the current codec block in the horizontal and vertical directions, are set equal to numSbX=cbWidth>>2 and numSbY=cbHeight>>2.

[0109] The following variables are set to the following values:

[0110] displacementX is set to angleIdx, displacementY is set to (displacementX+6)%24

[0111] hwRatio is set equal to nCbH / nCbW

[0112] The variable shiftHor is set equal to 0 if one of the following conditions is true:

[0113] angleIdx%12 is equal to 8

[0114] angleIdx%12 is not equal to 0 and hwRatio≥1

[0115] Otherwise, shiftHor is set equal to 1.

[0116] partIdx is set to angleIdx>=10&&angleIdx<=20?1:0.

[0117] If shiftHor is equal to 0, offsetX and offsetY are derived as follows:

[0118] offsetX=(64–numSbX)>>1

[0119] offsetY=(64-numSbY)>>1+angleIdx<12? (distanceIdx*

[0120] nCbH)>>5:

[0121] -((distanceIdx*nCbH)>>5)

[0122] Otherwise, if shiftHor is equal to 1, offsetX and offsetY are derived as follows:

[0123] offsetX=(64–numSbX)>>1+angleIdx<12? (distanceIdx*

[0124] nCbW)>>5:

[0125] -((distanceIdx*nCbW)>>5)

[0126] offsetY=(64–numSbY)>>1

[0127] The value of the variable rho is derived according to the following equation and the Dis comparison table specified in Tables 8-12:

[0128] rho=(Dis[displacementX]<<8)+(Dis[displacementY]<<8).

[0129] Use the lookup table labeled Dis (specified in Tables 8-11 and 8-12) to set motionOffset to the following values:

[0130] motionOffset=3*Dis[displacementX]+3*Dis[displacementY].

[0131] For each 4x4 subblock at subblock index (xSbIdx, ySbIdx),

[0132] For xSbIdx=0..numSbX-1 and ySbIdx=0..numSbY-1, the following applies:

[0133] Use the lookup table in Table 8-12 to calculate the variable motionIdx as follows:

[0134] motionIdx=(((xSbIdx+offsetX)<<3)+1)*Dis[displacementX]

[0135] +(((xSbIdx+offsetY<<3)+1))*Dis[displacementY]–rho+motionOffset

[0136] The variable sType is derived as follows:

[0137] sType=abs(motionIdx)<32? 2: motionIdx<=0? partIdx: 1-partIdx Depending on the value of sType, the following specifications are made:

[0138] If sType is equal to 0, the following applies:

[0139] predFlagL0 = ( predListFlagA = = 0 )? 1 : 0 (8-853)

[0140] predFlagL1 = ( predListFlagA = = 0 )? 0 : 1 (8-854)

[0141] refIdxL0 = ( predListFlagA = = 0 )? refIdxA : -1 (8-855)

[0142] refIdxL1 = ( predListFlagA = = 0 )? -1 : refIdxA (8-856)

[0143] mvL0[ 0 ] = ( predListFlagA = 0 ) ? mvA[0] : 0 (8-857)

[0144] mvL0[1]=(predListFlagA==0)? mvA[ 1 ] : 0 (8-858)

[0145] mvL1[ 0 ] = ( predListFlagA = 0 ) ? 0 : mvA[ 0 ] (8-859)

[0146] mvL1[1]=(predListFlagA==0)? 0 : mvA[ 1 ] (8-860)

[0147] Otherwise, if sType is equal to 1 or (sType is equal to 2 and predListFlagA+

[0148] predListFlagB is not equal to 1), application follows:

[0149] predFlagL0 = ( predListFlagB = = 0 ) ? 1 : 0 (8-861)

[0150] predFlagL1 = ( predListFlagB = = 0 ) ? 0 : 1 (8-862)

[0151] refIdxL0 = ( predListFlagB = = 0 ) ? refIdxB : -1 (8-863)

[0152] refIdxL1 = ( predListFlagB = = 0 ) ? -1 : refIdxB (8-864)

[0153] mvL0[ 0 ] = ( predListFlagB = = 0 ) ? mvB[0 ] : 0 (8-865)

[0154] mvL0[ 1 ] = ( predListFlagB = = 0 ) ? mvB[1 ] : 0 (8-866)

[0155] mvL1[ 0 ] = ( predListFlagB = = 0 ) ? 0 : mvB[ 0 ] (8-867)

[0156] mvL1[ 1 ] = ( predListFlagB = = 0 ) ? 0 : mvB[ 1 ] (8-868)

[0157] Otherwise(sType is equal to 2 and predListFlagA+predListFlagB is equal to 1), application follows:

[0158] predFlagL0=1

[0159] (8-869)

[0160] predFlagL1=1

[0161] (8-870)

[0162] refIdxL0 = ( predListFlagA = = 0 ) ? refIdxA : refIdxB (8-871)

[0163] refIdxL1 = (predListFlagA == 0)? refIdxB : refIdxA (8-872)

[0164] mvL0[0]=(predListFlagA == 0)? mvA[0] : mvB[0]

[0165] (8-873)

[0166] mvL0[1]=(predListFlagA == 0)? mvA[1] : mvB[1]

[0167] (8-874)

[0168] mvL1[0]=(predListFlagA == 0)? mvB[0] : mvA[0]

[0169] (8-875)

[0170] mvL1[1]=(predListFlagA == 0)? mvB[1] : mvA[1]

[0171] (8-876)

[0172] The following specifications are made for x = 0..3 and y = 0..3:

[0173] MvL0[(xSbIdx << 2) + x][(ySbIdx << 2) + y] = mvL0 (8-877)

[0174] MvL-1[(xSbIdx << 2) + x][(ySbIdx << 2) + y] = mvL1 (8-878)<**********<**********RefIdxL0[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=refIdxL0(8-879)

[0176] RedIdxL1[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=refIdxL1(8-880)

[0177] PredFlagL0[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=predFlagL0

[0178] (8-881)

[0179] PredFlagL1[(xSbIdx<<2)+x][(ySbIdx<<2)+y]=predFlagL1

[0180] (8-882)

[0181] In the following disclosure, the grammatical design disclosed above will be used as a reference to illustrate the present invention. Summary of the Invention

[0182] A method and apparatus for video encoding and decoding are disclosed. According to the method, a current block is received at an encoder, or compressed data including the current block is received at a decoder, wherein the current block is partitioned into two geometric prediction units. Motion information for the two geometric prediction units is determined. Weight information for the two geometric prediction units is determined. A motion storage type variable is determined based on the weight information, wherein the motion information associated with the current block is stored according to a value of the motion storage type variable. Based on the weight information, a geometric predictor for the current block is generated by mixing two geometric predictors, wherein the two geometric predictors are derived for the two geometric prediction units using the motion information associated with the current block.

[0183] In one embodiment, the motion memory type variable is determined based on a luma weight index, wherein the luma weight index indicates a target weight factor set used for blending the two geometry predictors. For example, the motion memory type variable may be determined based on the target weight factor set at a sub-sample position of a sub-block grid. In another embodiment, the motion memory type variable is determined based on the target weight factor set at any sub-sample position of a 4x4 grid.

[0184] In one embodiment, the motion memory type variable is determined based on luma sample weights. For example, the motion memory type variable may be determined based on the luma sample weights at a sub-sampling position of a sub-block grid. In another embodiment, the motion memory type variable may be determined based on the luma sample weights at any sub-sampling position of a 4x4 grid. BRIEF DESCRIPTION OF THE DRAWINGS

[0185] Figure 1A The figure shows the partitioning shape used in the triangular prediction mode (TPM) disclosed in VTM-6.0.

[0186] Figure 1B Draws additional shapes for non-rectangular inter blocks under discussion.

[0187] Figure 2The segmentation boundary of the geometric merge mode described by the angle φ_i and the distance offset ρ_i is shown.

[0188] Figure 3 An example of traditional derivation of sampleWeight and sType for GEO is shown.

[0189] Figure 4 An example of unified weight and sType derivation is shown according to an embodiment of the present invention.

[0190] Figure 5 An example of unified weight and sType derivation with 4x4 sub-block based subsampling is shown.

[0191] Figure 6 A flowchart of an exemplary prediction for video coding is shown according to an embodiment of the present invention, where sType is derived using motion information.

[0192] Figure 7 A flowchart of an exemplary prediction for video decoding is shown according to an embodiment of the present invention, where sType is derived using motion information. DETAILED DESCRIPTION

[0193] The following description is the best contemplated mode of implementing the present invention. The purpose of this description is to illustrate the general principles of the present invention and should not be viewed in a limiting sense. The scope of the present invention is determined by reference to the appended claims.

[0194] To improve coding efficiency, this invention proposes to integrate the weight index and motion index derivation in the geometric merge mode for skip, merge, direct, inter mode, and / or IBC mode.

[0195] Figure 3 An example of the conventional derivation of GEO's sampleWeight 316 and sType 324 is shown. However, there are many other ways to implement the conventional derivation of GEO's sampleWeight 316 and sType 324. For other variations, the derivation of weightIdxAbs 314 and sampleWeight 316 can be done with Figure 3However, the main concepts may be the same. In other words, weightIdx 312 is calculated from a geometric pixel-based formula, and weightIdxAbs 314 is derived from the clipped value of weightIdx 312. Then, sampleWeigh t 316 is obtained from a table lookup based on a filter mapping table. On the other hand, sType 324 is defined as an internal variable to determine the mode of sub-block based motion storage. sType 324 equal to 0 indicates that MV0 (i.e., the motion vector associated with partition 0) is stored, 1 indicates that MV1 (i.e., the motion vector associated with partition 1) is stored, and 2 indicates that the derived MV is stored.

[0196] To simplify the derivation process, according to one embodiment of the present invention, a unified derivation is disclosed, wherein sType 324 is derived from the luminance weightIdx 312 samples (e.g. Figure 4 Variation 1 (Var 1) is shown. According to this embodiment, sType 324 is derived according to the following equation:

[0197] sType=abs(weightIdx)<32?2:weightIdx<=0? partIdx:1-partIdx.

[0198] As shown in the above equation, if abs(weightIdx) is less than 32, sType 324 is equal to 2. Otherwise (i.e., abs(weightIdx)>=32), if weightIdx 312 is less than or equal to 0, sType 324 is equal to partIdx; and otherwise (i.e., weightIdx>0), sType 324 is equal to (1-partIdx). According to the GEO decoding procedure in the appendix to JVET-P0884, partIdx is a variable corresponding to a partition index.

[0199] In another embodiment, sType 324 is derived from luma sampleWeight 316 samples (e.g. Figure 4 Variation 2 is shown. According to this embodiment, sType 324 is derived according to the following equation:

[0200] sType=sampleWeight==8?0:sampleWeight==0?1:2.

[0201] As shown in the above equation, if sampleWeight 316 equals 8, sType 324 equals 0. Otherwise (i.e., sampleWeight ≠ 8), if sampleWeight 316 equals 0, sType 324 equals 1; and otherwise (i.e., sampleWeight ≠ 0), sType 324 equals 2.

[0202] In the above embodiment, sType 324 is derived from subsampling the luminance weightIdx according to Var 1. Although weightIdx is compared with a value 32, other conditions can also be used. For example, weightIdx can be compared with other values. In another embodiment, sType 324 is derived from the following:

[0203] sType = abs(weightIdx) < N? 2 : weightIdx <= 0? partIdx : 1 - partIdx,

[0204] where N is a fixed positive integer.

[0205] In yet another embodiment, if (weightIdx < -P), sType = partIdx; otherwise if (weightIx >= -P && weightIdx < Q), sTyp = 2; otherwise sType = (1 - partIdx), where P and Q are fixed positive integers.

[0206] In the above embodiment, for sType 324 derived from subsampling the luminance sampleWeight 316: when sampleWeight 316 is between the minimum sampleWeight value and the maximum sampleWeight value, sType324 is set to 2, indicating that the derived motion will be stored. When sampleWeight 316 equals the minimum sampleWeight value or the maximum sampleWeight value, sType 324 is set to 0 or 1, indicating that unidirectional - predicted motion will be stored.

[0207] In the above embodiment, as Figure 5 shown, the subsampling is based on 4x4. In the above embodiment, the subsampling position can be any position in a 4x4 grid as Figure 5 shown. For example, the subsampling at the position (1,1) in a 4x4 grid is shown in Figure 5 configuration 510, or the subsampling at the position (2,2) in a 4x4 grid is shown in Figure 5In the configuration 520, a gray pixel (512 or 522) indicates the subsampling position.

[0208] The method proposed above can be implemented in an encoder and / or a decoder. For example, the method can be implemented in an inter-frame prediction module and / or an intra-block copy (IBCC) prediction module of an encoder, and / or an inter-frame prediction module (and / or an intra-block copy (IBCC) prediction module) of a decoder.

[0209] Figure 6 A flowchart is provided for an exemplary prediction method for video encoding according to an embodiment of the present invention, in which sType is derived using motion information. The steps shown in the flowchart (and other subsequent flowcharts in this disclosure) can be implemented as executable code in one or more processors (e.g., one or more CPUs) on the encoder and / or decoder side. The steps shown in the flowchart can be implemented in hardware (e.g., one or more electronic devices or processors) arranged to perform the flowchart steps. According to this method, in step 610, a current block comprising a luma block and one or more chroma blocks is received, wherein the current block is divided into two geometry prediction units. In step 620, motion information for the two geometry prediction units is determined. In step 630, weight information for the two geometry prediction units is determined. In step 640, a motion storage type variable is determined based on the weight information, wherein the motion information associated with the current block is stored according to a value of the motion storage type variable. In step 650 , a geometry predictor for the current block is generated by blending two geometry predictors according to the weight information, wherein the two geometry predictors are derived using the motion information associated with the current block for the two geometry prediction units.

[0210] Figure 7 A flowchart illustrating an exemplary prediction method for video decoding according to an embodiment of the present invention, wherein sType is derived using motion information, is provided. According to this method, in step S710, compressed data including a current block is received, wherein the current block is partitioned into two geometry prediction units. In step 720, motion information for the two geometry prediction units is determined. In step 730, weight information for the two geometry prediction units is determined. In step 740, a motion storage type variable is determined based on the weight information, wherein the motion information associated with the current block is stored according to a value of the motion storage type variable. In step 750, a geometry predictor for the current block is generated by blending two geometry predictors based on the weight information, wherein the two geometry predictors for the two geometry prediction units are derived using the motion information associated with the current block.

[0211] The flowchart shown is used to illustrate an example of video encoding and decoding according to the present invention. Without departing from the spirit of the present invention, those skilled in the art can modify each step, reorganize the steps, separate a step, or combine the steps to implement the present invention. In this disclosure, specific syntax and semantics have been used to illustrate examples of implementing embodiments of the present invention. Without departing from the spirit of the present invention, those skilled in the art can implement the present invention by replacing the syntax and semantics with equivalent syntax and semantics.

[0212] The above description enables one skilled in the art to implement the present invention within the context of a specific application and its requirements. Various variations of the described embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be applied to other embodiments. Therefore, the present invention is not limited to the specific embodiments shown and described, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. In the above detailed description, various specific details are provided to provide a thorough understanding of the present invention. Nevertheless, it will be understood by one skilled in the art that the present invention can be practiced.

[0213] The embodiments of the present invention described above can be implemented in various hardware, software code, or a combination of both. For example, an embodiment of the present invention can be implemented as circuitry integrated within a video compression chip or as program code integrated into video compression software to perform the processing described herein. An embodiment of the present invention can also be implemented as program code executed on a digital signal processor (DSP) to perform the processing described herein. The present invention can also include functions executed by a computer processor, digital signal processor, microprocessor, or field programmable gate array (FPGA). According to the present invention, these processors can be configured to perform specific tasks by executing machine-readable software code or firmware code that defines the specific methods implemented by the present invention. The software code or firmware code can be developed in different programming languages ​​and in different formats or styles. The software code can also be compiled for different target platforms. However, different code formats, software code styles and languages, and other forms of configuration code to perform the tasks of the present invention do not depart from the spirit and scope of the present invention.

[0214] Without departing from the spirit or essential characteristics of the present invention, the present invention may be implemented in other specific forms. The examples described are considered to be illustrative and not restrictive in all aspects only. Therefore, the scope of the present invention is indicated by the appended claims rather than the preceding description. All changes within the meaning and scope of equivalents belonging to the claims are intended to be included within their scope.

[0215] It will be appreciated from the foregoing that various embodiments of the present invention have been described herein for illustrative purposes, and that various modifications may be made without departing from the scope and spirit of the invention. Therefore, the various embodiments described herein are not intended to be limiting, the true scope and spirit of which are to be determined by the scope of the subsequent patent claims.

Claims

1. A video encoding method, the method comprising: receiving a current block, wherein the current block is divided into two geometric prediction units; determining motion information for the two geometric prediction units; determining weight information for the two geometric prediction units; determining a motion storage type variable based on the weight information, wherein the motion information associated with the current block is stored according to a value of the motion storage type variable; and According to the weight information, a geometric predictor for the current block is generated by mixing two geometric predictors, The two geometric predictors are derived using the motion information associated with the current block for the two geometric prediction units.

2. The video encoding method according to claim 1, wherein: The motion memory type variable is determined based on a luma weight index, wherein the luma weight index indicates a target set of weight factors used for blending the two geometry predictors.

3. The video encoding method according to claim 2, wherein: The motion memory type variable is determined based on the sub-sampling position of the target weight factor set in the sub-block grid.

4. The video encoding method according to claim 2, wherein: The motion memory type variable is determined based on the target weight factor set at any sampling position in a 4x4 grid.

5. The video encoding method according to claim 1, wherein: The motion memory type variable is determined based on the luma sample weights.

6. The video encoding method according to claim 5, wherein: The motion memory type variable is determined based on the sub-sampling position of the luma sample weights in the sub-block grid.

7. The video encoding method according to claim 5, wherein: The motion memory type variable is determined based on the luma sample weight at any sampling position in a 4x4 grid.

8. A video encoding apparatus comprising one or more electronic circuits or processors arranged to: receiving a current block, wherein the current block is divided into two geometric prediction units; determining motion information for the two geometric prediction units; determining weight information for the two geometric prediction units; determining a motion storage type variable based on the weight information, wherein the motion information associated with the current block is stored according to a value of the motion storage type variable; and According to the weight information, a geometric predictor for the current block is generated by mixing two geometric predictors, The two geometric predictors are derived using the motion information associated with the current block for the two geometric prediction units.

9. A video decoding method, the method comprising: receiving compressed data including a current block, wherein the current block is divided into two geometric prediction units; determining motion information for the two geometric prediction units; determining weight information for the two geometric prediction units; determining a motion storage type variable based on the weight information, wherein the motion information associated with the current block is stored according to a value of the motion storage type variable; and According to the weight information, a geometric predictor for the current block is generated by mixing two geometric predictors, The two geometric predictors are derived using the motion information associated with the current block for the two geometric prediction units.

10. The video decoding method according to claim 9, wherein: The motion memory type variable is determined based on a luma weight index, wherein the luma weight index indicates a target set of weight factors used for blending the two geometry predictors.

11. The video decoding method according to claim 10, wherein: The motion memory type variable is determined based on the sub-sampling position of the target weight factor set in the sub-block grid.

12. The video decoding method according to claim 10, wherein: The motion memory type variable is determined based on the sub-sampling position of the target weight factor set on a 4x4 grid.

13. The video decoding method according to claim 10, wherein: The motion memory type variable is determined based on the luma sample weights.

14. The video decoding method according to claim 13, wherein: The motion memory type variable is determined based on the sub-sampling position of the luma sample weights in the sub-block grid.

15. The video decoding method according to claim 13, wherein: The motion memory type variable is determined based on the subsampling position of the luma sample weights in the 4x4 grid.

16. A video decoding apparatus comprising one or more electronic circuits or processors arranged to: receiving compressed data including a current block, wherein the current block is divided into two geometric prediction units; determining motion information for the two geometric prediction units; determining weight information for the two geometric prediction units; determining a motion storage type variable based on the weight information, wherein the motion information associated with the current block is stored according to a value of the motion storage type variable; and According to the weight information, a geometric predictor for the current block is generated by mixing two geometric predictors, The two geometric predictors are derived using the motion information associated with the current block for the two geometric prediction units.

Images