Method and apparatus for local illumination compensation model inheritance for video coding and decoding
By introducing Local Illumination Compensation (LIC) prediction technology into the video codec system, using scale and offset parameters to model local illumination changes, and controlling the application of LIC through flags and context variables, the problem of limited efficiency and quality in local illumination change processing in existing technologies is solved, thereby improving codec efficiency and quality.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- MEDIATEK INC
- Filing Date
- 2024-10-14
- Publication Date
- 2026-05-12
AI Technical Summary
Existing video encoding and decoding technologies cannot effectively utilize Local Illumination Compensation (LIC) tools when dealing with changes in local lighting, resulting in limitations in encoding and decoding efficiency and quality.
By introducing Local Illumination Compensation (LIC) prediction technology, local illumination variations are modeled using scaling and offset parameters, and the application of LIC is controlled on both the encoder and decoder sides using flags and context variables, thus optimizing the encoding and decoding process.
It improves the efficiency and quality of video encoding and decoding systems when handling changes in local lighting, reduces signaling overhead, and enhances encoding and decoding performance.
Smart Images

Figure CN122029809A_ABST
Abstract
Description
[0001] Cross-referencing This invention claims priority to U.S. Provisional Patent Application No. 63 / 590,481, filed October 16, 2023, and U.S. Provisional Patent Application No. 63 / 590,789, filed October 17, 2023. The full text of the above U.S. Provisional Patent Applications is incorporated herein by reference. [Technical Field] This invention relates to video encoding and decoding systems. More specifically, this invention relates to sending LIC flags to a video encoding and decoding system that includes LIC encoding and decoding tools. [Background Technology] Versatile Video Coding (VVC) is the latest international video coding standard developed by the Video Coding Experts Group (VCEG) of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) and the Joint Video Experts Team (JVET) of the Moving Picture Experts Group (MPEG) of the International Organization for Standardization / International Electrotechnical Commission (ISO / IEC). This standard was published as an ISO standard in February 2021: ISO / IEC 23090-3:2021, Information technology – Codec representation of immersive media – Part 3: Versatile Video Coding. VVC was developed based on its predecessor, High Efficiency Video Coding (HEVC). It improves encoding and decoding efficiency by adding more encoding and decoding tools, and can handle various types of video sources, including three-dimensional (3D) video signals.
[0004] Figure 1AAn exemplary adaptive inter-frame / intra-frame video coding system incorporating loop processing is illustrated. For intra-frame prediction, prediction data is derived from previously encoded / decoded picture video data in the current frame. For inter-frame prediction 112, motion estimation (ME) is performed at the encoder, and motion compensation (MC) is performed based on the results of ME to provide prediction data derived from other pictures and motion data. Switch 114 selects either intra-frame prediction 110 or inter-frame prediction 112 and provides the selected prediction data to adder 116 to form a prediction error, also known as a residual. The prediction error is then processed by transform (T) 118, followed by quantization (Q) 120. The residuals from the transform and quantization are then encoded by entropy encoder 122 to be included in the video bitstream corresponding to the compressed video data. The bitstream associated with the transform coefficients is then packaged with auxiliary information (such as motion and encoding / decoding modes associated with intra-frame and inter-frame prediction) and other information such as parameters associated with loop filters applied to the underlying image regions. Figure 1A As shown, auxiliary information related to intra-frame prediction 110, inter-frame prediction 112, and loop filter 130 is provided to entropy encoder 122. When inter-frame prediction mode is used, one or more reference images must also be reconstructed at the encoder. Therefore, the residuals from transform and quantization are processed by inverse quantization (IQ) 124 and inverse transformation (IT) 126 to recover the residuals. The residuals are then added back to the prediction data 136, reconstructing the video data at reconstruction (REC) 128. The reconstructed video data can be stored in reference image buffer 134 and used for prediction in other frames.
[0005] like Figure 1A As shown, the incoming video data undergoes a series of processes in the encoding system. The reconstructed video data from REC 128 may be subject to various degradations due to these processes. Therefore, before storing the reconstructed video data in the reference picture buffer 134, a loop filter 130 is typically applied to the reconstructed video data to improve video quality. For example, a deblocking filter (DF), sample adaptive offset (SAO), and adaptive loop filter (ALF) may be used. It may be necessary to incorporate loop filter information into the bitstream so that the decoder can correctly recover the required information. Therefore, loop filter information is also provided to the entropy encoder 122 for inclusion in the bitstream. Figure 1A In the process, the loop filter 130 is applied to the reconstructed video, and then the reconstructed samples are stored in the reference image buffer 134. Figure 1A The system described herein is intended to illustrate an exemplary architecture of a typical video encoder. It may correspond to a High Efficiency Video Coding (HEVC) system, VP8, VP9, H.264, or VVC.
[0006] like Figure 1B As shown, apart from transform 118 and quantization 120, the decoder can use the same or partially the same function blocks as the encoder, since the decoder only needs inverse quantization 124 and inverse transform 126. The decoder uses entropy decoder 140 instead of entropy encoder 122 to decode the video bitstream into quantized transform coefficients and the required encoding / decoding information (e.g., ILPF information, intra-frame prediction information, and inter-frame prediction information). Intra-frame prediction 150 at the decoder end does not require mode search. Instead, the decoder only needs to generate intra-frame predictions based on the intra-frame prediction information received from entropy decoder 140. Furthermore, for inter-frame prediction, the decoder only needs to perform motion compensation (MC 152) based on the inter-frame prediction information received from entropy decoder 140, without motion estimation.
[0007] Decoder-Side Intra Mode Derivation (DIMD) When DIMD is applied, two intra-frame modes are derived from reconstructed neighboring samples, and these two predictors are combined with a planar mode predictor, where weights are derived from gradients, as described in JVET-O0449. The division operation in weight derivation is performed using the same lookup table (LUT)-based integerization scheme used by CCLM. For example, division in direction calculation. The following LUT-based scheme is used for calculation: , , , , in .
[0008] The exported intra-frame modes are included in a master list of most probable intra-frame modes (MPMs), so DIMD processing is performed before the MPM list is built. The master exported intra-frame modes of a DIMD block are stored along with the block, as well as the MPM list for adjacent blocks.
[0009] DIMD chromaticity mode according to Figure 2 The adjacent reconstructed Y, Cb, and Cr samples in the second adjacent row and second column shown are used to derive the intra-frame prediction mode of the current block using the DIMD derivation method. Figure 2 In the diagram, regions 210, 220, and 230 correspond to the in-situ Y block, the current Cb block, and the current Cr block, respectively. The circles outside regions 210, 220, and 230 correspond to adjacent reconstructed samples. The gray circles indicate the sample positions where DIMD determines the gradient. Specifically, for each in-situ reconstructed luminance sample and the reconstructed Cb and Cr samples of the current chroma block, the horizontal and vertical gradients are calculated to construct HoG. Then, the intra-prediction mode with the largest histogram amplitude value is used to perform intra-frame chroma prediction on the current chroma block.
[0010] When the intra-prediction mode derived from the DIMD chroma mode is the same as the intra-prediction mode derived from the DM mode, the intra-prediction mode with the second largest histogram amplitude value is used as the DIMD chroma mode. A CU level flag is sent to indicate whether the proposed DIMD chroma mode is applied. The N derived DIMD modes with the best histogram amplitude are then mixed to form the final predictor for the current block.
[0011] Fusion of Template-Based Intra Mode Derivation (TIMD) For each intra-prediction mode in the MPM, the SATD between the predicted sample and the reconstructed sample of the template is calculated. Typically, the top-left adjacent reconstructed sample is used as the template. The two intra-prediction modes with the smallest SATD are selected as TIMD modes. After applying PDPC processing, these two TIMD modes are fused with weights, and this weighted intra-prediction is used to encode and decode the current CU. Position-dependent intra-prediction combination (PDPC) is included in the derivation of the TIMD modes.
[0012] The costs of the two selected modes are compared with a threshold. In the test, cost factor 2 is applied as follows: .
[0013] If this condition is true, fusion is applied; otherwise, only Mode 1 is used. The weights of the modes are calculated based on their SATD costs as follows: , .
[0014] The same lookup table (LUT)-based integerization scheme used in CCLM was employed for division operations.
[0015] Intra-frame prediction fusion This intra-frame prediction method derives the prediction sample as a weighted combination of multiple prediction values generated from different reference lines. In this process, multiple intra-frame prediction values are generated and then fused by a weighted average. The processing of the predictors used in the fusion process is described below: 1) For angular intra-prediction modes including TIMD and DIMD unidirectional modes, this method obtains intra-prediction by weighting the intra-prediction obtained from multiple reference lines, expressed as: , in, It is an intra-frame prediction performed from the default reference line, while This prediction is made from a line above the default reference line. The weights are set as follows: as well as .
[0016] 2) For TIMD modes with hybrid patterns, For the first mode as well as For the second mode .
[0017] 3) For the mixed DIMD mode, the number of predictors selected by weighted average is increased from 3 to 6.
[0018] When the intra-frame prediction mode has a non-integer slope (requiring reference sample interpolation) and the block size is greater than 16, the intra-frame prediction fusion method is applied to the luma block. This method is used in conjunction with MRL and is not applicable to ISP codec blocks. In one approach, the PDPC closest to the current block reference line is applied to the intra-frame prediction mode.
[0019] Multi-Model Language Model (MMLM) The CCLM included in VVC is extended by adding three multi-model LM (MMLM) modes (JVET-D0110). In each MMLM mode, reconstructed neighboring samples are divided into two classes using a threshold, which is the average of the neighboring samples in the luminance reconstruction. A linear model for each class is derived using the Least-Mean-Square (LMS) method. For CCLM modes, the LMS method is also used to derive the linear model. A slope adjustment is applied to the cross-component linear model (CCLM) and multi-model LM predictions. This adjustment is a sloping linear function that maps luminance values to chrominance values relative to a center point determined by the average luminance values of the reference samples.
[0020] Slope adjustment of CCLM CCLM uses a two-parameter model to map luminance values to chrominance values, such as... Figure 3A As shown. The slope parameter "a" and the deviation parameter "b" are defined and mapped as follows: The adjustment "u" to the slope parameter is sent to update the model to the following form, such as Figure 3B As shown: in , .
[0021] Through this selection, the image function revolves around the brightness value y. r The point is tilted or rotated. The average value of the reference brightness sample used in model creation is used as y. r This is so that meaningful modifications can be made to the model. Figure 3A and Figure 3B The process is illustrated.
[0022] Convolutional Cross-Component Model (CCCM) In this method, a convolutional cross-component model (CCCM) is applied to predict chroma samples from reconstructed luminance samples, similar in spirit to the current CCLM model. As with CCLM, when using chroma subsampling, the reconstructed luminance samples are downsampled to match a lower-resolution chroma grid. Similar to CCLM, top, left, or top and left reference samples are used as templates for model derivation.
[0023] In addition, similar to CCLM, a single-model or multi-model variant of CCCM can be selected. The multi-model variant uses two models: one derived for samples above the average luminance reference value, and the other for the remaining samples (following the spirit of CCLM design). For PUs with at least 128 available reference samples, the multi-model CCCM mode can be selected.
[0024] CCCM convolution filter The convolutional model has a 7-tap filter, consisting of a 5-tap plus shape spatial component, a nonlinear term, and a bias term. The input to the filter's 5-tap spatial component consists of a center (C) luminance sample, which is co-located with the chrominance sample to be predicted and its above / north (N), below / south (S), left / west (W), and right / east (E) neighbors, such as... Figure 4 As shown.
[0025] The non-linear term (denoted as P) is represented as a power of 2 of the center brightness sample C, and the range of sample values scaled to the content: .
[0026] For example, for 10 bits of content, the nonlinear term is calculated as follows: .
[0027] The offset term (denoted as B) represents the scalar offset between the input and output (similar to the offset term in CCLM), and is set to an intermediate chroma value (512 for 1-bit content).
[0028] The output of the filter is calculated as the filter coefficients c. i The convolution between the input and output values, and the range truncated to the effective chromaticity samples: .
[0029] Calculation of CCCM filter coefficients Filter coefficients c i It is calculated by minimizing the MSE between the predicted and reconstructed chromaticity samples in the reference region. Figure 5 The reference region is shown, consisting of 2 or 6 rows of chroma samples above and to the left of the PU. In single-model CCCM, the template cost determines whether to use 6 or 2 rows of adjacent samples to derive the CCCM model parameters. Similarly, for multi-model CCCM, two candidates use 6 rows of adjacent luma samples or luma samples co-located with the current chroma block to derive the average value that divides the samples into two groups. The cost is derived by applying candidate CCPs (2 or 6 rows) to the template and calculating the sum of absolute differences (SAD) between the CCP prediction samples and the reconstructed samples in the template.
[0030] The reference region extends to the right by one PU width and below the PU boundary by one PU height. The region is adjusted to include only available samples. The blue-shown expansion of the region requires "side samples" to support the conformal spatial filter and is filled in unavailable areas.
[0031] MSE minimization is performed by computing the autocorrelation matrix of the luma input and the cross-correlation vector between the luma input and the chromaticity output. The autocorrelation matrix is an LDL decomposition, and the final filter coefficients are computed using inverse substitution. This process roughly follows the computation of ALF filter coefficients in ECM; however, LDL decomposition is chosen instead of Cholesky decomposition to avoid the use of square root operations.
[0032] The autocorrelation matrix is calculated using reconstructed values from luma and chroma samples. These samples are full-range (e.g., between 0 and 1023 for 10-bit content), resulting in relatively large values in the autocorrelation matrix. This necessitates high-bit depth operations during model parameter computation. It is recommended to remove a fixed offset from the luma and chroma samples in each PU of each model. This reduces the magnitude of the values used in model creation and allows for a reduction in the precision required for fixed-point algorithms. Therefore, 16-bit decimal precision is recommended instead of the 22-bit precision of the original CCCM implementation.
[0033] For simplicity, the reference sample values outside the top left corner of the PU are used as offsets (offsetLuma, offsetCb, and offsetCr). The sample values used in model creation and final prediction (i.e., the luminance and chrominance in the reference area and the luminance in the current PU) are reduced by these fixed values, as follows: Chromaticity values are predicted using the following formulas, where offsetChroma is equal to offsetCr and offsetCb of the Cr and Cb components, respectively: .
[0034] To avoid any additional sample-level operations, the luminance offset is removed during luminance reference sample interpolation. This can be achieved, for example, by replacing the rounding term used in luminance reference sample interpolation with an updated offset that includes rounding terms and offsetLuma. The chromaticity offset can also be removed by directly subtracting it from the reference chromaticity sample. Alternatively, the effect of the chromaticity offset can be removed from the cross-component vectors, yielding the same result. To add the chromaticity offset back to the output of the convolutional prediction operation, the chromaticity offset is added to the bias term of the convolutional model.
[0035] CCCM model parameter calculations require division operations. Division operations are not always considered easy to implement. Division operations can be replaced by multiplication (with a scaling factor) and shift operations, where the scaling factor and the number of shifts are calculated based on the denominator, similar to the method used when calculating CCLM parameters.
[0036] CCCM sent The PU level flag, encoded and decoded by CABAC, is used to send the usage information for this mode. A new CABAC context is included to support this. Upon notification, CCCM is treated as a sub-mode of CCLM. That is, the CCCM flag is only sent if the intra-prediction mode is LM_CHROMA.
[0037] Gradient linear model For the YUV 4:2:0 color format, the gradient linear model (GLM) method predicts chromaticity samples from the gradient of luminance samples. Two modes are supported: two-parameter GLM mode and three-parameter GLM mode.
[0038] Compared to CCLM, two-parameter GLM does not use downsampled luminance values; instead, it uses luminance sample gradients to derive a linear model. Specifically, when two-parameter GLM is applied, the input processed by CCLM (i.e., the downsampled luminance sample L) is replaced by the luminance sample gradient G. Other parts of CCLM (such as parameter derivation and linear transformation of predicted samples) remain unchanged.
[0039] , In the three-parameter GLM, chromaticity samples can be predicted based on the gradient of luminance samples and downsampled luminance values with different parameters. The model parameters of the three-parameter GLM are derived from 6 rows and 6 columns of adjacent samples using the MSE minimization method based on LDL decomposition used in CCCM.
[0040] , For transmission, when CCLM mode is enabled in the current CU, a flag is sent to indicate whether GLM is enabled for both Cb and Cr components; if GLM is enabled, another flag is sent to indicate which of the two GLM modes is selected, and a syntax element is further sent to select one of the four gradient filters (e.g., Figure 6 Figures 610-640 are used for gradient calculation.
[0041] CCCM using non-downsampled brightness samples (NS-CCCM) The CCCM mode is used, employing a 3x2 filter and employing unsampled luminance samples. It consists of a 6-tap spatial term, four nonlinear terms, and a bias term. The 6-tap spatial term corresponds to the six neighboring luminance samples (L0, L1, ..., L5) surrounding the chrominance sample (C) to be predicted. The four nonlinear terms come from samples L0, L1, L2, and L3, as shown below. Figure 7 As shown.
[0042] Where α i β is the coefficient, and β is the offset. Similar to existing CCCM designs, up to 6 rows / columns of chroma samples above and to the left of the current CU are used to derive the filter coefficients. The filter coefficients are derived based on the same LDL decomposition method used in CCCM. In addition to the existing CCCM model, the proposed method is also used as an additional CCCM model. When CCCM is selected, a single flag is sent, and this flag is applied to both chroma components, to indicate whether the default CCCM model or the proposed CCCM model is applied. Furthermore, SPS sending is introduced to indicate whether CCCM using non-downsampled luminance samples is enabled.
[0043] Gradient and location Based Convolutional Cross-Component Model (GL-CCCM) This method uses a filter to map luminance values to chrominance values. The input to this filter consists of a spatial luminance sample, two gradient values, two location information values, a nonlinear term, and a bias term. The GL-CCCM method uses gradient and location information instead of the four spatial neighborhood samples used in the CCCM filter. The GL-CCCM filter used for prediction is: , Among them G y and G x These are the vertical and horizontal gradients, calculated as follows: Figure 8 As shown: , , Furthermore, Y and X are the spatial coordinates of the center brightness sample. The remaining parameters are the same as those in the CCCM tool. The reference area for parameter calculation is the same as that in the CCCM method.
[0044] This mode is used to send PU-level flags encoded and decoded by CABAC. During transmission, GL-CCCM is treated as a sub-mode of CCCM. That is, the GL-CCCM flag is only sent if the original CCCM flag is true.
[0045] Similar to CCCM, the GL-CCCM tool has six modes for calculating parameters: • Single model GL-CCCM from the top and left templates • Single-model GL-CCCM from the template above • Single-model GL-CCCM from the template on the left • Multi-model GL-CCCM from the top and left templates • Multi-model GL-CCCM from the template above • Multi-model GL-CCCM from the left template The encoder performs a SATD search on the six GL-CCCM patterns and existing CCCM patterns to find the best candidate for the full RD test.
[0046] CCCM with Multiple Downsampling Filters (MDF-CCCM) Multiple downsampling filters are applied to a set of reconstructed luminance samples in the CCCM. A linear combination of these downsampling reconstructed samples is multiplied by derived filter coefficients to form the final chromaticity predictor. The horizontal or vertical position of the center luminance sample is considered in the test model. The cross-component model is shown below as an additional CCCM mode for testing, along with the mode index transmitted in the bitstream: (1) Model 1: predChroma = c0 * H(C) + c1 * G1(C) + c2 * G2(C) + c3 * G3(C) + c4 * P(H(C)) + c5 * P(G1(C)) + c6 * P(G2(C)) + c7 * X + c8 * Y + c9 * B (2) Model 2: predChroma = c0 * H(C) + c1 * H(W) + c2 * H(E) + c3 * G1(C)+ c4 * G1(W) + c5 * G1(E) + c6 * P(H(C)) + c7 * P(H(W)) + c8 * P(H(E)) + c9 *X + c10 * B (3) Model 3: predChroma = c0 * H(C) + c1 * H(NE) + c2 * H(SW) + c3 * G3(C) + c4 * G3(NE) + c5 * G3(SW) + c6 * P(H(C)) + c7 * P(H(NE)) + c8 * P(H(SW)) + c9 * Y + c10 * B Among them, H(·)910, G1(·)920, G2(·)930, and G3(·)940 are as follows: Figure 9 The various downsampling filters shown are: C represents the current chroma sample position; N, S, W, E, NE, and SW are the positions around C; ci is the filter coefficient; P and B are the nonlinear and bias terms; and X and Y are the horizontal and vertical positions of the center luminance sample relative to the top-left corner of the block.
[0047] Local-Boosting Cross-Component Prediction (LB-CCP) The predicted samples of MM-CCLM / MM-CCCM can be filtered using neighboring samples. For example... Figure 10 As shown, a 3×3 low-pass filter is used to filter the predicted samples generated by MM-CCLM / MM-CCCM. For samples at the top / left boundary, the filtering window can involve adjacent reconstructed samples. For inner samples, the filtering window only involves predicted samples, which can be padded. Flags are sent to indicate whether filtering is applied to blocks encoded and decoded using MM-CCLM / MM-CCCM.
[0048] Cross-Component Prediction (CCP) merging (also known as non-local CCP mode) For chroma encoding / decoding, a flag is sent to indicate whether to use a CCP mode (including CCLM, CCCM, GLM, and their variants) or a non-CCP mode (regular chroma intra-prediction mode, chroma intra-prediction mode fusion). If a CCP mode is selected, another flag is sent to indicate how the CCP type and parameters are derived: either from the CCP merge list or dynamically (on-the-fly) sent / derived. The CCP merge candidate list consists of spatially adjacent, spatially non-adjacent, or history-based candidates. After including these candidates, a default model is also included to fill any remaining empty positions in the merge list. To remove redundant CCP models from the list, a pruning operation is applied. After the list is constructed, the CCP models in the list are reordered based on the SAD cost obtained using the adjacent templates of the current block. More details are described below.
[0049] Spatial adjacent and non-adjacent candidates The location and inclusion order of spatially adjacent and non-adjacent candidates are the same as those defined for predictive candidates in regular merges in ECM.
[0050] Candidates based on history Maintain a history-based table to include recently used CCP models, and reset the table at the beginning of each CTU row. If the current list is not full after including spatially adjacent and non-adjacent candidates, add CCP models from the history-based table to the list.
[0051] Default Candidate CCLM candidates with default scaling parameters are considered only if the list is not full after including spatially adjacent, spatially non-adjacent, or historically based candidates. If the current list has no candidates with a single-model CCLM mode, the default scaling parameters are {0, 1 / 8, -1 / 8, 2 / 8, -2 / 8, 3 / 8, -3 / 8, 4 / 8, -4 / 8, 5 / 8, -5 / 8, 6 / 8}. Otherwise, the default scaling parameters are {0, the scaling parameter of the first CCLM candidate + {1 / 8, -1 / 8, 2 / 8, -2 / 8, 3 / 8, -3 / 8, 4 / 8, -4 / 8, 5 / 8, -5 / 8, 6 / 8}}. The offset parameters are derived based on the preset scaling parameters, the average adjacent reconstructed luminance sample values, and the average adjacent reconstructed Cb / Cr sample values.
[0052] A flag is sent to indicate whether CCP merging mode is applied. If CCP merging mode is applied, an index is sent to indicate which candidate model is used for the current block. Furthermore, CCP merging mode is not allowed for the current chroma codec block when the current CU is encoded / decoded by an Intra Sub-Partition (ISP) with a single tree, or when the current chroma codec block size is less than or equal to 16.
[0053] Local Illumination Compensation (LIC) LIC is an inter-frame prediction technique used to model the local illumination variation between the current block and its predicted block as a function of the local illumination variation between the current block template and the reference block template. The parameters of this function can be represented by a scaling factor α and an offset β, which form a linear equation, α*p[x]+β, to compensate for the illumination variation, where p[x] is a reference sample at position x on the reference image pointed to by the MV. When surround motion compensation is enabled, the MV should be clipped, taking the surround offset into account. Since α and β can be derived based on the current block template and the reference block template, they require no signaling overhead, except that the LIC flag is sent in AMVP mode to indicate the use of LIC.
[0054] The local illumination compensation proposed in JVET-O0066 is used for unidirectional prediction of inter-frame CU, and the following modifications are made.
[0055] • Intra-frame adjacent samples are used in the derivation of LIC parameters; • For blocks with fewer than 32 luminance samples, LIC is disabled; • For non-subblock and affine modes, the LIC parameter derivation is performed based on the template block sample corresponding to the current CU, rather than based on the partial template block sample corresponding to the first top-left 16x16 cell. • Samples of the reference block template are generated using MC and block MV, without the need to round them to integer pixel precision.
[0056] Bidirectional prediction LIC This method extends the LIC model to bidirectional prediction of CUs. Specifically, it applies two different linear models to two prediction blocks and then combines them to generate bidirectional prediction samples for the current CU, i.e.: , as well as , , Where α0 and β0, and α1 and β1 represent the scaling factor and offset in L0 and L1, respectively; ω represents the weight of the weighted combination of L0 and L1 predictions (represented by the CU-level BCW index). The same derivation scheme for the LIC pattern is reused and applied iteratively to derive the L0 and L1 LIC parameters. Specifically, the method first derives the L0 parameters by minimizing the difference between the L0 template prediction T0 and the template T, and updates the samples in T by subtracting the corresponding samples in T0. Then, the L1 parameters are calculated to minimize the difference between the L1 template prediction T1 and the updated template. Finally, the L0 parameters are refined again in the same manner.
[0057] Following the current LIC design, a flag is sent to the AMVP bidirectional prediction CU to indicate the LIC mode, and the flag is inherited between related CUs. Furthermore, the LIC is disabled when Decoder-Side Motion Vector Refinement (DMVR) (including multi-channel DMVR, adaptive DMVR, and affine DMVR) and bidirectional optical flow (BDOF) are applied.
[0058] OBMC with LIC In this method, OBMC is enabled for inter-frame blocks encoded and decoded using LIC mode. To reduce complexity, OBMC is only applied to the top and left boundaries of the CU, while the boundaries of internal sub-blocks of a LIC CU are always disabled. Furthermore, when a neighboring block is encoded and decoded using LIC, its LIC parameters are applied to generate a corresponding predicted sample of the OBMC for the current block.
[0059] LIC marking based on TM cost determination proposed in JVET-AF0128 In JVET-AF0128 (EE2-3.2), a template cost-based approach is proposed to derive the LIC flag for merging candidates.
[0060] The LIC flag for merging candidates is determined by comparing the costs of two templates: the template cost based on SAD (denoted as C0) and the template cost based on average SAD removal (MRSAD) (denoted as C1). If C0 <= C1, the LIC flag is set to false; if C0 > C1, the LIC flag is set to true.
[0061] To support the inherited LIC flag, C0 is multiplied by α if the inherited LIC flag is false, and C1 is multiplied by α if the inherited LIC flag is true, where α < 1.
[0062] Bidirectional matching AMVP - merge mode and LIC handling A bidirectional predictor consists of an AMVP predictor in one direction and a merge predictor in the other. This mode is enabled in the codec block when the selected merge predictor and AMVP predictor satisfy the DMVR condition, where there is at least one reference image from the past and one reference image from the future relative to the current image, and the two reference images are equidistant from the current image. Bidirectional matching MV refinement is applied to the merge MV candidate and the AMVP MVP as starting points. Otherwise, if template matching is enabled, template matching MV refinement is applied to the merge predictor or the AMVP predictor with a higher template matching cost.
[0063] The AMVP portion of this pattern is sent in the form of a regular one-way AMVP, that is, the reference index and MVD are sent, and if template matching is used, it has the exported MVP index, or if template matching is disabled, the MVP index is sent.
[0064] For the AMVP direction LX, where X can be 0 or 1, the merging portion in the other direction (1-LX) is implicitly derived by minimizing the bidirectional matching cost between the AMVP predictor and the merging predictor (i.e., for a pair of AMVP and merging motion vectors). For each merging candidate in the merging candidate list that has the motion vector in the other direction (1-LX), the bidirectional matching cost is computed using the merging candidate MV and the AMVP MV. The merging candidate with the minimum cost is selected. Starting with the selected merging candidate MV and AMVP MV, bidirectional matching refinement is applied to the codec block.
[0065] The mode is indicated by a flag. If the mode is enabled, the AMVP direction LX is also indicated by a flag.
[0066] When the AMVP merge pattern is used for the current block and template matching is enabled, MVD is not sent. Additional AMVP merge MVP pairs are introduced. The merge candidate list is sorted in ascending order based on bidirectional matching cost. An index (0 or 1) is sent to indicate which merge candidate from the sorted merge candidate list to use. When there is only one candidate in the merge candidate list, AMVP MVPs and merge MVP pairs without bidirectional matching MV refinement are populated.
[0067] For AMVP-merge mode, the LIC flag used to indicate whether the current block has LIC enabled is inherited from the merge candidates of the AMVP-merge pair. This LIC flag is called the inherited LIC flag.
[0068] To improve the encoding and decoding performance of systems using LIC encoding and decoding tools, methods and apparatus for sending LIC flags are disclosed. [Summary of the Invention] This invention discloses a video encoding / decoding method and apparatus. According to the method, input data associated with the current block is received, wherein the input data includes pixel data to be encoded at the encoder end or data associated with the current block to be decoded at the decoder end. A first flag indicating whether to apply Local Illumination Compensation (LIC) processing to a candidate is determined. A second flag indicating whether the first flag is correct is determined. Based on the first and second flags, the current block is encoded or decoded using encoding / decoding information including LIC prediction, which is generated by applying LIC processing to a target candidate.
[0070] In one embodiment, when the second flag is true, LIC processing is applied if the first flag is true, and not applied if the first flag is false. In another embodiment, when the second flag is false, LIC processing is not applied if the first flag is true, and applied if the first flag is false.
[0071] In one embodiment, the second flag is encoded and decoded by one or more context code symbols (bins). In another embodiment, the second flag is encoded and decoded using one or more context variables. In yet another embodiment, the selection of the one or more context variables depends on whether LIC processing is enabled or disabled for one or more neighboring blocks.
[0072] According to another method, input data associated with the current block is received, wherein the input data includes pixel data to be encoded at the encoder side or data associated with the current block to be decoded at the decoder side, wherein the current block is encoded and decoded in a bidirectional matching Advanced Motion Vector Prediction (AMVP) merging mode. An explicit local illumination compensation (LIC) flag is sent at the encoder side or resolved at the decoder side. The current block is encoded or decoded using encoding / decoding information, wherein the encoding / decoding information includes LIC predictions generated by applying LIC processing to selected merging candidates and / or selected AMVP candidates associated with the bidirectional matching AMVP merging mode based on the explicit LIC flag.
[0073] In one embodiment, when the LIC flag inherited from the selected merge candidate is true, LIC processing is applied if the explicit LIC flag is set to true, and LIC processing is not applied if the explicit LIC flag is set to false. In another embodiment, when the LIC flag inherited from the selected merge candidate is false, LIC processing is applied if the explicit LIC flag is set to false, and LIC processing is not applied if the explicit LIC flag is set to true.
[0074] In one embodiment, the explicit LIC flag is encoded by one or more context codec bins. In another embodiment, the explicit LIC flag is encoded using one or more context variables. In yet another embodiment, the choice of the one or more context variables depends on whether LIC processing is enabled or disabled for one or more neighboring blocks. [Attached Image Description] Figure 1A An exemplary adaptive inter-frame / intra-frame video encoding and decoding system incorporating loop processing is shown.
[0076] Figure 1B Show Figure 1A The corresponding decoder for the encoder.
[0077] Figure 2 The adjacent reconstructed Y, Cb, and Cr samples used to derive the DIMD gradient are shown.
[0078] Figure 3A An example of a CCLM model is shown.
[0079] Figure 3B This example illustrates the effect of the slope adjustment parameter "u" on model updates.
[0080] Figure 4 An example of the spatial portion of a convolution filter is shown.
[0081] Figure 5 An example of a filled reference region is shown for deriving filter coefficients.
[0082] Figure 6 An example of a Sobel filter is shown, used to derive gradient information for isotopic luminance samples of a target chromaticity.
[0083] Figure 7 The diagram shows the 6-tap space terms corresponding to the 6 adjacent luminance samples (i.e., L0, L1, ..., L5) around the chromaticity sample (i.e., C) to be predicted for the CCCM mode.
[0084] Figure 8 The current chromaticity sample position C is shown, and N, S, W, E, NE, and SW are the downsampled luminance positions around C.
[0085] Figure 9 Multiple downsampling filters (MDFs) are shown for use across component modes: filters H(·), G1(·), G2(·), and G3(·).
[0086] Figure 10 An example of filtering MM-CCLM / MM-CCCM samples is shown.
[0087] Figure 11 An example of adjacent templates used to calculate model error is shown.
[0088] Figure 12 A flowchart illustrating an exemplary video codec system according to an embodiment of the present invention uses a second LIC flag to indicate whether a first LIC flag is used.
[0089] Figure 13 A flowchart illustrating an exemplary video codec system according to an embodiment of the present invention uses an explicit LIC flag to indicate whether LIC processing is applied to AMVP merged codec blocks.
Detailed Implementation Methods
[0091] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. However, those skilled in the art will recognize that the invention can be practiced without using one or more specific details, or using other methods, components, etc. In other instances, well-known structures or operations are not shown or described in detail to avoid obscuring aspects of the invention. Embodiments of the invention will be best understood by referring to the accompanying drawings, wherein like parts are designated by like numbers throughout. The following description is illustrative only and only illustrates embodiments of specific selected apparatus and methods consistent with the invention declared herein.
[0092] To improve the encoding and decoding performance of video encoding and decoding systems that include LIC encoding and decoding tools, transmission techniques related to LIC processing have been revealed.
[0093] LIC in merge mode In one embodiment, a second flag is sent to indicate whether the first exported LIC flag of the merge candidate is correct. The first exported LIC flag is derived based on template cost. If the template cost based on SAD is less than or equal to the template cost based on Average Removed SAD (MRSAD), the first exported LIC flag is set to false. If the template cost based on SAD is greater than the template cost based on Average Removed SAD (MRSAD), the first exported LIC flag is set to true.
[0094] For example, if the template cost based on SAD is less than or equal to the template cost based on mean-removed SAD (MRSAD), then the first exported LIC flag will be false, while the second sent flag will be true. In this case, the LIC will not be used for the current CU.
[0095] For example, if the template cost based on SAD is less than or equal to the template cost based on average removed SAD (MRSAD), then the first exported LIC flag will be false, and the second sent flag will also be false. In this case, the LIC will be used for the current CU.
[0096] For example, if the template cost based on SAD is greater than the template cost based on Average Removed SAD (MRSAD), then the first export LIC flag will be true, and the second send flag will be true. In this case, the LIC will be used for the current CU.
[0097] For example, if the template cost based on SAD is greater than the template cost based on Average Removed SAD (MRSAD), then the first export LIC flag will be true, and the second send flag will be false. In this case, the LIC will not be used for the current CU.
[0098] In one embodiment, the second flag is encoded and decoded by context code symbols.
[0099] In one embodiment, the second flag is encoded and decoded by multiple context variables. The choice of context variables depends on whether the LIC of adjacent blocks is enabled or disabled. For example, consider the top CU and the left CU.
[0100] In one embodiment, the second flag is encoded by multiple context variables. The choice of context variables depends on the current CU codec mode. For example, the context variables differ between affine mode CUs and non-affine mode CUs. As another example, the context variables differ between IBC mode CUs and non-IBC mode CUs.
[0101] In one embodiment, the second flag is sent only for certain merge modes. For other merge modes, the second flag does not need to be sent; it will always be set to true. For example, the regular merge mode and the MMVD merge mode require the second flag to be sent. As another example, only the non-skip merge mode requires the second flag to be sent.
[0102] In one embodiment, only the second flag is sent for certain merge modes. For some merge modes, the second flag does not need to be sent; it will always be set to true. For other merge modes (i.e., TM merge modes), implicit methods are used to indicate whether the second flag is on or off. For example, the TM cost is used to indicate whether the second flag is on or off. Furthermore, the on / off status of the second flags of adjacent blocks can be referenced to determine whether the second flag of the current block is on or off.
[0103] AMVP - Merged LIC In one embodiment, when the AMVP-merge mode is applied, the LIC flag is sent.
[0104] In one embodiment, when the AMVP-merge mode is applied, a second LIC flag is sent. The second LIC flag indicates whether a LIC is applied. Specifically, if a LIC is applied and the LIC flag from the corresponding merge candidate is true, the second LIC flag is set to true. Otherwise, if a LIC is applied and the LIC flag from the corresponding merge candidate is false, the second LIC flag is set to false.
[0105] In one embodiment, the second LIC flag is encoded and decoded by context codec symbols.
[0106] In one embodiment, the second LIC flag is encoded and decoded by multiple context variables. The choice of context variables depends on whether the LIC of adjacent blocks is enabled or disabled. For example, consider the top CU and the left CU.
[0107] In one embodiment, under AMVP-merge mode, it is not necessary to issue the LIC flag. The LIC will always be disabled.
[0108] In one embodiment, under the AMVP-merge mode, during the reordering of the merge candidate list, the BM costs associated with the candidates are calculated and compared. During the reordering, all merge candidates in the merge candidate list are treated as LIC-closed candidates.
[0109] In one embodiment, in AMVP-merge mode, the LIC parameters of the corresponding merge candidate can be used to guide the LIC parameter derivation of the current CU. The LIC parameters of the current CU are derived based on the template of the current block and the template of the reference block. For example, a regularization term is added to the LIC parameter derivation process of the current CU. This regularization term is designed based on the LIC parameters of the corresponding merge candidate and a lambda value. The lambda value is used to control the strength of the guidance.
[0110] In one embodiment, under AMVP-merge mode, the LIC parameters of the corresponding merge candidate can be used to guide the current CU. In this case, the LIC parameters of the current CU do not need to be derived again.
[0111] Inherited LIC information In one embodiment, all or part of the LIC information of the inherited LIC model can be stored together with the inherited LIC model parameters.
[0112] LIC information includes, but is not limited to, template region selection type (e.g., LIC_T, LIC_L, or LIC_LT), template region size, LIC model type (e.g., linear model ax + b, LIC with positional terms, or multi-tap LIC), multi-model flag, multi-model classification method, and multi-model threshold or model parameters.
[0113] In another embodiment, after decoding a block, the LIC information of the current block is exported and stored for later reconstruction of neighboring blocks using inherited neighbor model parameters. For example, even if the current block is encoded using a non-LIC prediction algorithm, the LIC model parameters of the current block are still derived using reconstruction samples from the current block and a reference region (e.g., identified by the current block size and motion vectors). Later, if another block is to be predicted using the inherited LIC model parameters of neighboring blocks, the LIC model parameters can be inherited from the stored LIC information of the current block. For another example, even if the current block is encoded using a LIC prediction algorithm, the LIC model parameters of the current block are re-derived using reconstruction samples from the current block and a reference region. For another example, the stored LIC model could be LM_LA (a single-model LM derived using top and left neighbor samples) or MMLM_LA (a multi-model LM derived using top and left neighbor samples). For another example, the re-derived LIC model parameters can be combined with the original LIC model to reconstruct the current block. To combine with the original LIC model, assume the original LIC model parameters are... And the re-derived LIC model parameters are The final LIC model can be , Here, α is a weighting factor that can be predefined or implicitly derived from the cost of adjacent templates.
[0114] In another embodiment, the model types of the "LIC model obtained using neighboring samples of the current block and the reference block" and the "LIC model obtained using reconstructed samples of the current block and the reference block" are different. For example, the model types of the "LIC model obtained using neighboring samples of the current block and the reference block" and the "LIC model obtained using neighboring samples of the current block and the reference block" are a single-model language model and a multi-model language model, or a multi-model language model and a single-model language model. As another example, the model types of the "LIC model derived using neighboring samples of the current block and the reference block" and the "LIC model derived using neighboring samples of the current block and the reference block" are a 2-parameter LM model (e.g., the model parameters consist of scaling parameters and offset parameters) and a convolutional LM model (e.g., CCCM, GL-CCCM, NS-CCCM, MDF-CCCM), or a convolutional LM model and a 2-parameter LM model.
[0115] Construct an inherited list of LIC candidates In one embodiment, the candidate list is constructed by adding candidates in a predetermined order until a maximum number of candidates is reached. The added candidates may include, but are not limited to, all of the candidates described above. For example, the candidate list may include spatially adjacent candidates, temporally adjacent candidates, historical candidates, non-adjacent candidates, and single-model candidates generated based on other inherited models. As another example, the candidate list may include the same candidates as in the previous example, but the candidates are added to the list in a different order.
[0116] Candidates in the list are reordered to reduce the syntax overhead when sending the selected candidate indices. The reordering rules can depend on the encoding / decoding information of adjacent blocks or model errors. For example, if the adjacent upper or left block is encoded / decoded by LIC and uses a target cross-component prediction mode, a candidate in the list with the target cross-component prediction mode can be moved to the head of the current list.
[0117] In another embodiment, the reordering rule is based on model error. A candidate model is applied to the neighboring templates of the current block, and then the error is compared with the reconstructed samples of the neighboring templates. For example, as... Figure 11 As shown, the size of the template 1120 adjacent to the current block 1110 is... The size of the adjacent template 1130 to the left of the current block 1110 is Suppose there are K models in the current candidate list, α k and β k These are the final scaling factor and offset parameters after inheriting candidate k. The model error of the above adjacent templates for candidate k is: , in, and These are the reference luminance sample of the previous encoded / decoded frame and the reconstructed luminance sample of the current frame, respectively, at position (i, j) in the template above, where 0 ≤ i <w a And 0≤j <h a .
[0118] Similarly, the model error between candidate k and its left-adjacent template is: , in and These are the reference luminance sample of the previous encoded / decoded frame and the reconstructed luminance sample of the current frame, respectively, at position (m, n) in the left template, where 0 ≤ m. <w b And 0≤n <h b .
[0119] In another embodiment, the model error of each candidate in the list can be further adjusted by a corresponding weighting factor. The weighting factor can be set based on characteristics of the candidates in the list, such as model type (e.g., CCCM, GL-CCCM, NS-CCCM, MDF-CCCM), single or multiple models, spatial / temporal / historical / default candidate type, or the inherited candidate position's spatial geometric distance or temporal POC distance to the current block. For example, suppose the model types of "LIC model derived using neighboring samples of the current block and the reference block" and "LIC model derived using reconstructed samples of the current block and the reference block" are X and Y, respectively, and X is not equal to Y. For instance, the weighting factor of a candidate in the list of model type X is different from the weighting factor of another candidate in the list of model type Y. In one embodiment, a candidate in the list of model type X has a larger weighting factor than another candidate in the list of model type Y. In another embodiment, a candidate in the list of model type X has a smaller weighting factor than another candidate in the list of model type Y.
[0120] Any of the methods proposed above can be applied independently or in combination. Furthermore, any of the methods proposed above can be implemented in the encoder and / or decoder. For example, any of the proposed methods can be implemented in the inter-frame prediction module of the encoder and / or decoder. Alternatively, any of the proposed methods can be implemented as a circuit coupled to the inter-frame prediction module of the encoder and / or decoder.
[0121] The aforementioned LIC transmission can be implemented on the encoder side or the decoder side. For example, any of the proposed methods can be implemented in the intra / inter-frame encoding / decoding module of the decoder (e.g., Figure 1B Intra-frame prediction 150 / MC 152 in the encoder or intra-frame / inter-frame codec module in the encoder (e.g. Figure 1A The intra-frame prediction 110 / inter-frame prediction 112 is implemented in the proposed LIC transmission. Any of the proposed LIC transmissions can also be implemented as circuitry coupled to the intra-frame / inter-frame coding module of the decoder or encoder. However, the decoder or encoder can also use additional processing units to implement the required cross-component prediction processing. While the intra-frame prediction / MC unit (e.g., Figure 1A Units 110 / 112 and Figure 1BUnits 150 / 152 in the diagram are shown as separate processing units, but they may correspond to executable software or firmware code stored on a medium (such as a hard disk or flash memory) for a central processing unit (CPU) or a programmable device (e.g., a digital signal processor (DSP) or a field programmable gate array (FPAG)).
[0122] Figure 12 A flowchart illustrating an exemplary video codec system according to an embodiment of the present invention uses a second LIC flag to indicate whether a first LIC flag is used. The steps shown in the flowchart can be implemented as program code executable on one or more processors (e.g., one or more CPUs) on the encoder or decoder side. The steps shown in the flowchart can also be implemented in hardware, such as one or more electronic devices or processors arranged to perform the steps in the flowchart. According to the method, in step 1210, input data associated with the current block is received, wherein the input data includes pixel data to be encoded on the encoder side or data associated with the current block to be decoded on the decoder side. In step 1220, a first flag indicating whether Local Illumination Compensation (LIC) processing is applied to a candidate is determined. In step 1230, a second flag indicating whether the first flag is correct is determined. In step 1240, based on the first and second flags, the current block is encoded or decoded using codec information including LIC prediction, wherein the LIC prediction is generated by applying LIC processing to a target candidate.
[0123] Figure 13 A flowchart illustrating an exemplary video codec system according to an embodiment of the present invention uses an explicit LIC flag to indicate whether LIC processing is applied to an AMVP merged codec block. According to the method, in step 1310, input data associated with the current block is received, wherein the input data includes pixel data to be encoded on the encoder side or data associated with the current block to be decoded on the decoder side, wherein the current block is encoded and decoded in a bidirectional matching Advanced Motion Vector Prediction (AMVP) merging mode. In step 1320, an explicit Local Illumination Compensation (LIC) flag is sent on the encoder side or parsed on the decoder side. In step 1330, the current block is encoded or decoded using codec information, wherein the codec information includes LIC predictions generated by applying LIC processing to selected merge candidates and / or selected AMVP candidates associated with the bidirectional matching AMVP merging mode based on the explicit LIC flag.
[0124] The flowchart shown is intended to illustrate examples of video encoding and decoding according to the present invention. Those skilled in the art can modify each step, rearrange the steps, split the steps, or combine the steps to practice the invention without departing from its spirit. In this disclosure, specific syntax and semantics are used to illustrate examples of embodiments of the invention. Those skilled in the art can practice the invention by substituting equivalent syntax and semantics without departing from its spirit.
[0125] The above description is intended to enable those skilled in the art to practice the invention in the context of specific applications and their requirements. Various modifications to the described embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments. Therefore, the invention is not intended to be limited to the specific embodiments shown and described, but rather to be given the broadest scope consistent with the principles and novel features disclosed herein. In the above detailed description, various specific details have been set forth to provide a thorough understanding of the invention. However, the invention can be practiced by those skilled in the art.
[0126] As described above, embodiments of the present invention can be implemented through various hardware, software code, or a combination of both. For example, embodiments of the present invention may be program code integrated into one or more circuits in a video compression chip, or integrated into video compression software to perform the processes described herein. Embodiments of the present invention may also be program code to be executed on a digital signal processor (DSP) to perform the processes described herein. The present invention may also relate to multiple functions performed by a computer processor, digital signal processor, microprocessor, or field-programmable gate array (FPGA). These processors can be configured to perform specific tasks according to the invention, defining the specific methods embodied in the invention by executing machine-readable software code or firmware code. The software code or firmware code can be developed in different programming languages and different formats or styles. The software code can also be compiled for different target platforms. However, different code formats, styles, and languages of the software code, as well as other means of configuring the code to perform tasks according to the invention, do not depart from the spirit and scope of the invention.
[0127] This invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The examples described are to be considered illustrative in all respects, not limiting. Therefore, the scope of the invention should be indicated by the appended claims rather than the foregoing description. All variations within the meaning and equivalence of the claims should be included within its scope.
Claims
1. A video encoding / decoding method, the method comprising: Receive input data associated with the current block, wherein the input data includes pixel data to be encoded at the encoder end or data associated with the current block to be decoded at the decoder end; Determine the first indicator to indicate whether to apply local lighting compensation processing to the candidate; Determine the second mark to indicate whether the first mark is correct; and Based on the first flag and the second flag, the current block is encoded or decoded using encoding and decoding information, wherein the encoding and decoding information includes a local illumination compensation prediction generated by applying the local illumination compensation processing to the target candidate.
2. The video encoding / decoding method of claim 1, wherein when the second flag is true, if the first flag is true, the local illumination compensation process is applied, and if the first flag is false, the local illumination compensation process is not applied.
3. The video encoding and decoding method as described in claim 1, wherein when the second flag is false, if the first flag is true, the local illumination compensation process is not applied; if the first flag is false, the local illumination compensation process is not applied.
4. The video encoding / decoding method as described in claim 1, wherein the second flag is encoded / decoded by one or more context encoding / decoding symbols.
5. The video encoding / decoding method as described in claim 4, wherein the second flag is encoded / decoded using one or more context variables.
6. The video encoding / decoding method of claim 5, wherein the selection of the one or more context variables depends on whether the local illumination compensation processing is enabled or disabled for one or more adjacent blocks.
7. A video encoding / decoding apparatus, the apparatus comprising one or more electronic devices or processors, for: Receive input data associated with the current block, where, The input data includes pixel data to be encoded at the encoder end or data associated with the current block to be decoded at the decoder end; Determine the first indicator to indicate whether to apply local lighting compensation processing to the candidate; Determine the second mark to indicate whether the first mark is correct; and Based on the first flag and the second flag, the current block is encoded or decoded using encoding and decoding information, wherein the encoding and decoding information includes a local illumination compensation prediction generated by applying the local illumination compensation processing to a target candidate.
8. A video encoding / decoding method, the method comprising: Receive input data associated with the current block, wherein the input data includes pixel data to be encoded on the encoder side or data associated with the current block to be decoded on the decoder side, wherein the current block is encoded and decoded in a bidirectional matching advanced motion vector prediction merging mode; The explicit local illumination compensation flag is sent on the encoder side or resolved on the decoder side; and The current block is encoded or decoded using encoding / decoding information, which includes local illumination compensation predictions generated by applying local illumination compensation processing to selected merging candidates and / or selected bidirectional matching advanced motion vector prediction candidates associated with the bidirectional matching advanced motion vector prediction merging mode, according to the explicit local illumination compensation flag.
9. The video encoding / decoding method of claim 8, wherein when the local illumination compensation flag inherited from the selected merge candidate is true, the local illumination compensation process is applied if the explicit local illumination compensation flag is set to true, and the local illumination compensation process is not applied if the explicit local illumination compensation flag is set to false.
10. The video encoding / decoding method of claim 8, wherein when the local illumination compensation flag inherited from the selected merge candidate is false, if the explicit local illumination compensation flag is set to false, the local illumination compensation process is applied; and if the explicit local illumination compensation flag is set to true, the local illumination compensation process is not applied.
11. The video encoding / decoding method of claim 8, wherein the explicit local illumination compensation flag is encoded / decoded by one or more context code symbols.
12. The video encoding / decoding method of claim 8, wherein the explicit local illumination compensation flag is encoded / decoded using one or more context variables.
13. The video encoding / decoding method as described in claim 12, wherein, The choice of one or more context variables depends on whether the local lighting compensation process is turned on or off for one or more adjacent blocks.
14. A video encoding / decoding apparatus, the apparatus comprising one or more electronic devices or processors, for: Receive input data associated with the current block, where, The input data includes pixel data to be encoded on the encoder side or data associated with the current block to be decoded on the decoder side, wherein the current block is encoded and decoded in a bidirectional matching advanced motion vector prediction merging mode; The explicit local illumination compensation flag is sent on the encoder side or resolved on the decoder side; and The current block is encoded or decoded using encoding / decoding information, which includes local illumination compensation predictions generated by applying local illumination compensation processing to selected merge candidates and / or selected bidirectional matching advanced motion vector prediction candidates according to the explicit local illumination compensation flag.