Cross-component convolutional model in in-loop filtering

Abstract

A method for implementing in-loop filtering using convolution cross-component filtering in a video coder is provided. A video coder receives data to be encoded or decoded as a current block of pixels of a current picture of a video. The video coder reconstructs the current block based on the received data. The video coder computes intermediate chroma values based on chroma samples of the reconstructed current block. The video coder applies a convolution cross-component (CCCM) filter to luma samples of the reconstructed current block to obtain cross-component prediction samples. The video coder blends the cross-component prediction samples with the intermediate chroma values to generate final chroma values, wherein the blending is according to a set of adaptive blending weight. The video coder provides the final chroma values as chroma samples of the reconstructed current block.

Description

CROSS-COMPONENT CONVOLUTIONAL MODEL IN IN-LOOP FILTERINGCROSS REFERENCE TO RELATED PATENT APPLICATION (S)

[0001] The present disclosure is part of a non-provisional application that claims the priority benefit of U.S. Provisional Patent Application No. 63 / 716,275, filed on 5 November 2024. Content of above-listed application is herein incorporated by reference.TECHNICAL FIELD

[0002] The present disclosure relates generally to video coding. In particular, the present disclosure relates to methods of coding video pictures using adaptive loop filters.BACKGROUND

[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.

[0004] High-Efficiency Video Coding (HEVC) is an international video coding standard developed by the Joint Collaborative Team on Video Coding (JCT-VC) . HEVC is based on the hybrid block-based motion-compensated DCT-like transform coding architecture. The basic unit for compression, termed coding unit (CU) , is a 2Nx2N square block of pixels, and each CU can be recursively split into four smaller CUs until the predefined minimum size is reached. Each CU contains one or multiple prediction units (PUs) .

[0005] Versatile video coding (VVC) is the latest international video coding standard developed by the Joint Video Expert Team (JVET) of ITU-T SG16 WP3 and ISO / IEC JTC1 / SC29 / WG11. The input video signal is predicted from the reconstructed signal, which is derived from the coded picture regions. The prediction residual signal is processed by a block transform. The transform coefficients are quantized and entropy coded together with other side information in the bitstream. The reconstructed signal is generated from the prediction signal and the reconstructed residual signal after inverse transform on the de-quantized transform coefficients. The reconstructed signal is further processed by in-loop filtering for removing coding artifacts. The decoded pictures are stored in the frame buffer for predicting the future pictures in the input video signal.

[0006] In VVC, a coded picture is partitioned into non-overlapped square block regions represented by the associated coding tree units (CTUs) . The leaf nodes of a coding tree correspond to the coding units (CUs) . A coded picture can be represented by a collection of slices, each comprising an integer number of CTUs. The individual CTUs in a slice are processed in raster-scan order. A bi-predictive (B) slice may be decoded using intra prediction or inter prediction with at most two motion vectors (MVs) and reference indices to predict the sample values of each block. A predictive (P) slice is decoded using intra prediction or inter prediction with at most one motion vector and reference index to predict the sample values of each block. An intra (I) slice is decoded using intra prediction only.

[0007] A CTU can be partitioned into one or multiple non-overlapped coding units (CUs) using the quadtree (QT) with nested multi-type-tree (MTT) structure to adapt to various local motion and texture characteristics. A CU can be further split into smaller CUs using one of the five split types: quad-tree partitioning, vertical binary tree partitioning, horizontal binary tree partitioning, vertical center-side triple-tree partitioning, horizontal center-side triple-tree partitioning.

[0008] Each CU contains one or more prediction units (PUs) . The prediction unit, together with the associated CU syntax, works as a basic unit for signaling the predictor information. The specified prediction process is employed to predict the values of the associated pixel samples inside the PU. Each CU may contain one or more transform units (TUs) for representing the prediction residual blocks.

[0009] For each inter-predicted CU, motion parameters consisting of motion vectors, reference picture indices and reference picture list usage index, and additional information are used for inter-predicted sample generation. The motion parameter can be signalled in an explicit or implicit manner. When a CU is coded with skip mode, the CU is associated with one PU and has no significant residual coefficients, no coded motion vector delta or reference picture index. A merge mode is specified whereby the motion parameters for the current CU are obtained from neighbouring CUs, including spatial and temporal candidates, and additional schedules introduced in VVC. The merge mode can be applied to any inter-predicted CU. The alternative to merge mode is the explicit transmission of motion parameters, where motion vector, corresponding reference picture index for each reference picture list and reference picture list usage flag and other needed information are signalled explicitly per each CU.SUMMARY

[0010] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits and advantages of the novel and non-obvious techniques described herein. Select and not all implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0011] Some embodiments of the disclosure provide a method for implementing in-loop filtering using convolution cross-component filtering in a video coder. A video coder receives data to be encoded or decoded as a current block of pixels of a current picture of a video. The video coder reconstructs the current block based on the received data. The video coder computes intermediate chroma values based on chroma samples of the reconstructed current block. The intermediate chroma values may include sample provided by adaptive offsets (SAO) and cross-component SAO. The video coder applies a convolution cross-component (CCCM) filter to luma samples of the reconstructed current block to obtain cross-component prediction samples. The video coder blends the cross-component prediction samples with the intermediate chroma values to generate final chroma values, wherein the blending is according to a set of adaptive blending weight. The video coder provides the final chroma values as chroma samples of the reconstructed current block.

[0012] In some embodiments, the cross-component filter uses filter coefficients that are inherited from spatial neighbors, from one or more reference blocks identified by at least one motion vector or block vector. In some embodiments, the cross-component filter uses filter coefficients that are derived using reference luma and chroma samples that are identified by motion vectors or block vectors.

[0013] In some embodiments, the cross-component filter is applicable to only samples in a partition of a coding tree unit (CTU) . The partition may be determined based on a split tree of coding units, prediction units, or transform units in the CTU. In some embodiments, information regarding the partition and the cross-component filter are provided by syntax elements in a bitstream coding the video. In some embodiments, the set of adaptive blending weight may be signaled in or parsed from the bitstream as well.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings are included to provide a further understanding of the present disclosure, and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation in order to clearly illustrate the concept of the present disclosure.

[0015] FIGS. 1A-1B illustrates two diamond filter shapes for Adaptive Loop Filters (ALF) .

[0016] FIG. 2 illustrates a system level diagram of in-loop filters.

[0017] FIG. 3 illustrates filtering in cross-component ALF (CC-ALF) .

[0018] FIG. 4 illustrates a 25-tap large filter used in CCALF process.

[0019] FIG. 5 illustrates a CCALF filter with 5 luma residual taps in a cross 3x3 shape.

[0020] FIGS. 6A-6B illustrate the two candidate filter shapes that are adaptively selected for ALF.

[0021] FIG. 7 illustrates the four types of filter taps for ALF online-trained filters.

[0022] FIG. 8 illustrates an additional fixed filter.

[0023] FIG. 9 conceptually illustrates the spatial components of a convolutional filter.

[0024] FIG. 10 illustrates a reference area used to derive the filter coefficients for CCCM.

[0025] FIGS. 11A-11B illustrate a decoder-side diagram of in-loop filters 1100 with CCCM filters that are derived using SAO / CC-SAO outputs.

[0026] FIG. 12 illustrates an example video encoder that may implement in-loop filtering.

[0027] FIG. 13 illustrates portions of the video encoder that implement ALF that is refined by CCCM.

[0028] FIG. 14 conceptually illustrates a process for encoding pixel blocks using CCCM-ALF.

[0029] FIG. 15 illustrates an example video decoder that may implement in-loop filtering.

[0030] FIG. 16 illustrates portions of the video decoder that implement ALF that is refined by CCCM.

[0031] FIG. 17 conceptually illustrates a process for decoding pixel blocks using CCCM-ALF.

[0032] FIG. 18 conceptually illustrates an electronic system with which some embodiments of the present disclosure are implemented.DETAILED DESCRIPTION

[0033] In the following detailed description, numerous specific details are set forth by way of examples in order to provide a thorough understanding of the relevant teachings. Any variations, derivatives and / or extensions based on teachings described herein are within the protective scope of the present disclosure. In some instances, well-known methods, procedures, components, and / or circuitry pertaining to one or more example implementations disclosed herein may be described at a relatively high level without detail, in order to avoid unnecessarily obscuring aspects of teachings of the present disclosure. I. Adaptive Loop Filter (ALF)

[0034] A. ALF Filtering

[0035] Adaptive Loop Filter (ALF) is an in-loop filtering technique used in video coding standards such as VVC. It is a block-based filter that minimizes the mean square error between original and reconstructed samples. The reconstructed samples are classified into multiple classes based on local activity and directionality. Then, the samples in each class are filtered with an FIR-filter for that class.

[0036] At decoder side, when ALF is enabled for a CTB, each sample R' (i, j) within the CU is filtered, resulting in sample value R' (i, j) as shown below:

[0037] where f (k, l) denotes the decoded filter coefficients, K (x, y) is the clipping function and c (k, l) denotes the decoded clipping parameters. The variable k and l vary between -L / 2 and L / 2, wherein L denotes the filter length. The clipping function K (x, y) = min (y, max (-y, x) ) which corresponds to the function Clip3 (-y, y, x) . The clipping operation introduces non-linearity to make ALF more efficient by reducing the impact of neighbor sample values that are too different with the current sample value.

[0038] FIGS. 1A-1B illustrate two diamond filter shapes for Adaptive Loop Filters (ALF) . Each position in a diamond correspond to a filter tap having a filter coefficient. FIG. 1A shows a 7×7 diamond shape having taps with filter coefficients C0-C12 that is applied for luma component. FIG. 1B shows a 5×5 diamond shape with filter coefficients C0-C6 that is applied for chroma components.

[0039] B. Filter Parameter Signaling

[0040] ALF filter parameters are signalled in Adaptation Parameter Set (APS) . In one APS, up to 25 sets of luma filter coefficients and clipping value indexes, and up to eight sets of chroma filter coefficients and clipping value indexes could be signalled. To reduce bits overhead, filter coefficients of different classification for luma component can be merged. In slice header, the indices of the APSs used for the current slice are signaled.

[0041] Clipping value indexes, which are decoded from the APS, allow determining clipping values using a table of clipping values for both luma and Chroma components. These clipping values are dependent of the internal bit-depth. More precisely, the clipping values are obtained by the following formula: ALFClip = {round (2B-α*n) for n ∈ [0…N-1] }

[0042] with B equal to the internal bit-depth, α is a pre-defined constant value equal to 2.35, and N equal to 4 which is the number of allowed clipping values in VVC. The ALFClip is then rounded to the nearest value with the format of power of 2.

[0043] In slice header, up to 7 APS indices can be signaled to specify the luma filter sets that are used for the current slice. The filtering process can be further controlled at CTB level. A flag is always signalled to indicate whether ALF is applied to a luma CTB. A luma CTB may choose a filter set among 16 fixed filter sets and the filter sets from APSs. A filter set index is signaled for a luma CTB to indicate which filter set is applied. The 16 fixed filter sets are pre-defined and hard-coded in both the encoder and the decoder.

[0044] For chroma components, an APS index may be signaled in slice header to indicate the chroma filter sets being used for the current slice. At CTB level, a filter index is signaled for each chroma CTB if there is more than one chroma filter set in the APS. The filter coefficients are quantized with norm equal to 128. In order to restrict the multiplication complexity, a bitstream conformance is applied so that the coefficient value of the non-central position shall be in the range of -27 to 27 -1, inclusive. The central position coefficient is not signalled in the bitstream and is considered as equal to 128.

[0045] C. Cross Component Adaptive Loop Filter (CC-ALF)

[0046] Cross Component ALF (CC-ALF or CCALF) may use luma sample values to refine each chroma component by applying an adaptive, linear filter to the luma channel and then using the output of this filtering operation for chroma refinement. FIG. 2 illustrates a system level diagram of in-loop filters 200, in which reconstructed or decoded pixel data 210 are filtered or processed by deblock filter (DBF) , sample adaptive offset (SAO) , and adaptive filter (ALF) . The reconstructed or decoded samples 210 may be generated from prediction signals and residual signals of the current block.

[0047] The figure shows placement of CC-ALF with respect to other loop filters. Specifically, the luma component of the SAO output is processed by a luma ALF process (ALF Y) and a pair of cross-component ALF processes (CC-ALF Cb and CC-ALF Cr) . The two cross-component ALF processes generate cross-component offset for Cb and Cb components to be added to the output of a chroma ALF process (ALF chroma) to generate ALF output for the chroma components. The luma and chroma components of the ALF output are then stored in a reconstructed or decoded picture buffer 290 to be used for predictive coding of subsequent pixel blocks.

[0048] FIG. 3 illustrates filtering in cross-component ALF (CC-ALF) , which is accomplished by applying a linear, diamond shaped filter 310 to the luma channel. One filter is used for each chroma channel, and the operation is expressed as

[0049] where (x, y) is chroma component i location being refined (xY, yY) is the luma location based on (x, y) , Si is filter support area in luma component, ci (x0, y0) represents the filter coefficients. As shown in FIG. 3, the luma filter support is the region collocated with the current chroma sample after accounting for the spatial scaling factor between the luma and chroma planes.

[0050] CC-ALF filter coefficients may be computed by minimizing the mean square error of each chroma channels with respect to the original chroma content. To achieve this, an algorithm may use a coefficient derivation process similar to the one used for chroma ALF. Specifically, a correlation matrix is derived, and the coefficients are computed using a Cholesky decomposition solver in an attempt to minimize a mean square error metric. In designing the filters, a maximum of 8 CC-ALF filters can be designed and transmitted per picture. The resulting filters are then indicated for each of the two chroma channels on a CTU basis.

[0051] CC-ALF filtering may use a 3x4 diamond shape with 8 filter taps, with 7 filter coefficients transmitted in the APS (may be referenced in the slice header) . Each of the transmitted coefficients has a 6-bit dynamic range and is restricted to power-of-2 values. The 8th filter coefficient is derived at the decoder such that the sum of the filter coefficients is equal to 0. CC-ALF filter selection may be controlled at CTU-level for each chroma component. Boundary padding for the horizontal virtual boundaries may the same memory access pattern as luma ALF.

[0052] As an additional feature, the reference encoder can be configured to enable some basic subjective tuning through the configuration file. When enabled, the VTM attenuates the application of CC-ALF in regions that are coded with high quantization parameter (QP) and are either near mid-grey or contain a large amount of luma high frequencies. Algorithmically, this is accomplished by disabling the application of CC-ALF in CTUs where any of the following conditions are true: (i) The slice QP value minus 1 is less than or equal to the base QP value (ii) The number of chroma samples for which the local contrast is greater than (1 << (bitDepth –2) ) –1 exceeds the CTU height, where the local contrast is the difference between the maximum and minimum luma sample values within the filter support region (iii) More than a quarter of chroma samples are in the range between (1 << (bitDepth –1) ) –16 and (1 << (bitDepth –1) ) + 16

[0053] This is for providing some assurance that CC-ALF does not amplify artifacts introduced earlier in the decoding path.

[0054] D. ALF Simplifications and Extensions

[0055] In some embodiments, ALF gradient subsampling and ALF virtual boundary processing are removed. Block size for classification is reduced from 4x4 to 2x2. Filter size for both luma and chroma, for which ALF coefficients are signalled, is increased to 9x9.

[0056] To filter a luma sample, three different classifiers (C0, C1 and C2) and three different sets of filters (F0, F1 and F2) may be used. Filter sets F0 and F1 contain fixed filters, with coefficients trained for classifiers C0 and C1. Filter coefficients for filter set F2 are explicitly signaled. Which filter from a set Fi is used for a given sample is decided by a class Ci assigned to this sample using classifier Ci.

[0057] Thus, to filter one luma sample, C0 and C1 classifiers are applied to the sample (i.e., applied to the 2x2 block that includes that sample) to determine its C0 and C1 classification, then two 13x13 diamond shape fixed filters F0 and F1 are applied (based on their respective C0 and C1 classifications) to derive two intermediate samples R0 (x, y) and R1 (x, y) . After that, F2 is applied to R0 (x, y) and R1 (x, y) and neighboring samples to derive a filtered sample as:

[0058] where f i, j is the clipped difference between a neighboring sample and current sample R (x, y) and gi is the clipped difference between Ri-20 (x, y) and the current sample. The filter coefficients ci, i = 0, …21, are signaled.

[0059] The CCALF process uses a linear filter to filter luma sample values and generate a residual correction for the chroma samples. FIG. 4 illustrates a 25-tap large filter used in CCALF process. For a given slice, the encoder can collect the statistics of the slice, analyze them and can signal up to 16 filters through APS.

[0060] In some embodiments, for CCALF, five luma residual taps in a cross 3x3 shape are added. The extended taps take the co-located and neighboring luma residual values as input. FIG. 5 illustrates a CCALF filter with 5 luma residual taps in a cross 3x3 shape. The 3x3 cross shape luma residual filter 505 is used in conjunction with a cross 9x9 CCALF filter 510.

[0061] In some embodiments, two candidate filter shapes can be adaptively selected by the luma filters in ALF. FIGS. 6A-6B illustrate the two candidate filter shapes that are adaptively selected for ALF. FIG. 6A shows a first candidate filter shape 610 is a diamond shape and FIG. 6B shows a second candidate filter shape 620 that is a cross shape. The number of coefficients of a luma filter is 22 for both the filter shapes. In some embodiments, these 22 taps are constituted with 20 spatial taps and 2 fixed filters 630 based taps in both shapes.

[0062] In each adaptation parameter set (APS) , a shape index for the derived luma filters is signaled to decoder. Each APS contains the luma filters that are associated with the filter shape index. For each CTB, an APS index is signaled to indicate which luma filter shape is used to filter the current CTB. When filtering a luma sample, the coefficients and clip indices are also rearranged according to the corresponding filter shape. In some embodiments, the diamond shaped luma ALF is replaced by the longer diamond shaped filter shown in FIG. 6B.

[0063] In some embodiments, the samples before deblocking filters are used as additional inputs for ALF. A final ALF sample is derived by weighting the regular ALF and the filter applied to the samples before the deblocking filter. Specifically, a filtered sample is derived as

[0064] where fi, j is the clipped difference between a neighboring sample and current sample R (x, y) , gi is the clipped difference between an intermediate sample and current sample R (x, y) and hi, j is the clipped difference between a neighboring sample before DBF and current sample R (x, y) . The filter coefficients ci, i=0, …24 are signalled. In this test, 3x3 diamond shape is applied to samples before deblocking filter. In an APS, a flag is signalled to indicate whether samples before DBF are used for ALF which is always set as true at encoder.

[0065] There are four types of filter taps for ALF online-trained filters: spatial taps, reconstruction-before-DBF based taps, residual based taps and fixed-filter-output based taps. FIG. 7 illustrates the four types of filter taps for ALF online-trained filters.

[0066] In some embodiments, the residual samples are used as additional inputs to the ALF. A filtered sample is derived as:

[0067] where ri is the clipped neighboring residual sample value and rFilteredi is the clipped residual sample filtered by the fixed-filter. For residual samples, the fixed filter reuses the offline fixed filter trained for reconstruction after SAO.

[0068] In some embodiments, additional fixed filter with a shape of diamond 7x7 is used. The filter parameters are stored at both encoder and decoder. There is no classification for the newly added fixed filter. FIG. 8 illustrates an additional fixed filter. The additional fixed filter includes spatial taps 810 (i.e., tap 0 ～19) , reconstruction-before-DBF-based taps 820 (i.e., taps 26, 27, 36) , residual-based taps 830 (i.e., 37 ～38) and fixed-filter-output-based taps 840 (i.e., tap 20 ～ 25, 34, 35) , as well as extended taps 850 (i.e., tap 28 ～ 33, 39) that are added into luma online-trained filters. The reconstruction before DBF is fed into the additional fixed filter to produce the filter outputs, then these filter outputs are used as input for newly extended taps. In some embodiments, this additional fixed filter is always enabled without any filter shape switching. II. Convolutional Cross-Component Intra Prediction Model (CCCM)

[0069] In some embodiments, convolutional cross-component model (CCCM) is applied to predict chroma samples from reconstructed luma samples. In CCCM, the reconstructed luma samples are down-sampled to match the lower resolution chroma grid when chroma sub-sampling is used. Top, left, or top and left reference samples neighboring the current block may be used as templates for model derivation according to CCCM.

[0070] In some embodiments, there is an option of using a single model or multi-model variant of CCCM. The multi-model variant uses two models, one model derived for samples above the average luma reference value and another model for the rest of the samples. Multi-model CCCM mode can be selected for PUs that have at least 128 reference samples available.

[0071] For some embodiment, the convolutional model has 7-tap filter having a 5-tap plus sign shape spatial component, a non-linear term and a bias term. The input to the spatial 5-tap component of the filter includes a center (C) luma sample (which is collocated with the chroma sample to be predicted) and the center luma sample’s above / north (N) , below / south (S) , left / west (W) and right / east (E) neighbors. FIG. 9 conceptually illustrates the spatial components of a convolutional filter. The nonlinear term (denoted as P) is represented as power of two of the center luma sample C and scaled to the sample value range of the content: P = (C*C + midVal) >> bitDepth

[0072] Thus, for 10-bit content the non-linear term P is calculated as: P = (C*C + 512) >> 10

[0073] The bias term (denoted as B) represents a scalar offset between the input and output (similarly to the offset term in CCLM) and is set to middle chroma value (512 for 10-bit content) . Output of the filter is calculated as a convolution between the filter coefficients ci and the input values and clipped to the range of valid chroma samples: predChromaVal = c0C + c1N + c2S + c3E + c4W + c5P + c6B The filter coefficients ci are calculated by minimising MSE between predicted and reconstructed chroma samples in the reference area. FIG. 10 illustrates a reference area used to derive the filter coefficients for CCCM. The reference area consists of 2 or 6 lines of chroma samples above and left of the PU. Whether to use 6 lines or 2 lines of neighbouring samples to derive the CCCM model parameters in the single model CCCM is determined by a template cost. Similarly, for the multi-model CCCM mode, the two candidates use 6 lines neighboring luma samples or luma samples collocated to the current chroma block to derive mean values which separate samples into two groups. The cost is derived by applying the candidate CCP (either 2 or 6 lines) on a template, calculating the sum of absolute difference (SAD) between CCP predicted samples and reconstructed samples in the template.

[0074] The reference area may extend one PU width to the right and one PU height below the PU boundaries. The area is adjusted to include only available samples. The extension area is needed to support the “side samples” of the plus shaped spatial filter and are padded when in unavailable areas.

[0075] The MSE minimization may be performed by calculating autocorrelation matrix for the luma input and a cross-correlation vector between the luma input and chroma output. Autocorrelation matrix is LDL decomposed and the final filter coefficients are calculated using back-substitution. The process follows roughly the calculation of the ALF filter coefficients, but LDL decomposition was chosen instead of Cholesky decomposition to avoid using square root operations.

[0076] The autocorrelation matrix is calculated using the reconstructed values of 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 requires high bit depth operation during the model parameters calculation. In some embodiments, fixed offsets are removed from luma and chroma samples in each PU for each model. This drives down the magnitudes of the values used in the model creation and allows reducing the precision needed for the fixed-point arithmetic. As a result, 16-bit decimal precision may be used instead of the 22-bit precision of the original CCCM implementation.

[0077] Reference sample values just outside of the top-left corner of the PU may be used as the offsets (offsetLuma, offsetCb and offsetCr) for simplicity. The sample values used in both model creation and final prediction (i.e., luma and chroma in the reference area, and luma in the current PU) are reduced by these fixed values, as follows: C'= C –offsetLuma N'= N –offsetLuma S'= S –offsetLuma E'= E –offsetLuma W'= W –offsetLuma P'= nonLinear (C') B = midValue = 1 << (bitDepth -1)

[0078] and the chroma value is predicted using the following equation, where offsetChroma is equal to offsetCr and offsetCb for Cr and Cb components, respectively: predChromaVal = c0C'+ c1N'+ c2S'+ c3E'+ c4W'+ c5P'+ c6B + offsetChroma

[0079] In order to avoid any additional sample level operations, the luma offset may be removed during the luma reference sample interpolation. This can be done, for example, by substituting the rounding term used in the luma reference sample interpolation with an updated offset including both the rounding term and the offsetLuma. The chroma offset can be removed by deducting the chroma offset directly from the reference chroma samples. As an alternative way, impact of the chroma offset can be removed from the cross-component vector giving identical result. In order to add the chroma offset back to the output of the convolutional prediction operation the chroma offset is added to the bias term of the convolutional model.

[0080] The process of CCCM model parameter calculation may require division operations. Division operations are not always considered implementation friendly. In some embodiments, the division operation are replaced with multiplication (with a scale factor) and shift operation, where scale factor and number of shifts are calculated based on denominator similar to the method used in calculation of CCLM parameters. III. Convolutional Cross-Component Model for ALF (ALF-CCCM)

[0081] Some embodiments of the disclosure provide methods of improving the quality of the reconstructed chroma samples. In some embodiments, one more additional stages are introduced to the existing in-loop filtering process. In some embodiments, a convolutional cross-component model (CCCM) is used to refine the chroma samples before ALF as an ALF pre-processing stage, where the chroma ALF takes the CCCM-refined chroma samples as inputs.

[0082] In some embodiments, each CTU is divided into non-overlapping blocks, and for each block the cross-component filter coefficients are derived using the SAO / CC-SAO outputs. The output samples of luma ALF are used as input to the ALF-CCCM filtering. The cross-component prediction samples generated by the cross-component filtering operation are blended with the SAO / CC-SAO chroma output samples to obtain the final ALF-CCCM output samples. In some embodiments, the blending weights are equal to 0.5 for both the SAO / CC-SAO chroma output samples and the cross-component prediction samples. The final ALF-CCCM output samples may be further blended with output of chroma ALF filtering or provided as input to chroma ALF filtering to produce final chroma samples of in-loop filtering.

[0083] FIGS. 11A-11B illustrate a decoder-side diagram of in-loop filters 1100 with CCCM filters that are derived using SAO / CC-SAO outputs. As illustrated, the CCCM filtering module 1110 uses the ALF luma output samples 1105 as its input to generate cross-component prediction samples 1115 by applying filter coefficients 1122 provided by CCCM filter derivation 1120, which may derive or inherit the coefficients. The cross-component prediction samples 1115 are then blended with SAO / CC-SAO chroma outputs 1125 to produce the final ALF-CCCM output samples 1130. The blending weights are illustrated as 0.5 for chroma inputs 1125 and 0.5 for filter outputs 1115. In some embodiments, the blending weight may be adaptive.

[0084] FIG. 11A illustrates an example in which the final ALF-CCCM output samples 1130 is provided to the ALF chroma processing 1140 to generate offsets for the final chroma output of the in-loop filtering 1100. FIG. 11B illustrates an example in which the final ALF-CCCM output samples 1130 are further blended with result of ALF chroma processing 1140 to generate offsets for the final chroma output of the in-loop filtering 1100.

[0085] The encoder may decide the best block size for each CTU using a rate-distortion optimization loop. There are eight possible blocks sizes 2x2, 3x3, 4x4, 8x8, 16x16, 32x32, 64x64, 128x128. For filter derivation the blocks are extended by one sample on each side. For example, with 2x2 blocks the filter is derived using 4x4 blocks. The block extension is clipped against CTU boundaries. For each CTU, the encoder’s rate-distortion optimization (RDO) decides the best cross-component model from eight possible ALF-CCCM models. The eight ALF-CCCM models (Models 0 through Model 7) are listed in Table 1, where the cardinal directions indicate co-located luma sample position in the chroma grid (C=center, N=north / up, S=south / down, W=west / left, E=east / right, P=non-linear term, B=bias term. )

[0086] Table 1: Eight cross-component models of ALF-CCCM

[0087] The nonlinear and bias terms are the same as in the 7-tap CCCM model. The CCCM solver is used for deriving the filter coefficients. The 6-tap downsampling filter (used in CCCM and CCLM) is used for mapping the co-located luma into the chroma grid.

[0088] For each CTU, the choice of the block size and the choice of the cross-component model (for ALF-CCCM) may be signaled using CABAC coded flags. For intra-coding, a CTU may inherit both the block size and the model type from the above or left CTU. In some embodiments, this choice is signaled using a single CABAC coded flag for each CTU when ALF-CCCM is present in the left and / or above CTU. If two CTU candidates available, another CABAC coded flag may be signaled to indicate the choice.

[0089] For inter-coding, a picture may inherit the block sizes and model types for all CTUs from a reference picture. The reference picture may be derived from the L0 and L1 lists. In some embodiments, only reference pictures with ALF-CCCM present in at least one CTU are considered. In some embodiments, the reference picture with the smallest POC distance to the current POC is selected. If activated, the picture level inheritance will skip the CTU-level signaling completely for the current picture. In some embodiments, this choice is signaled using a single CABAC coded flag if a reference picture with at least one CTU utilizing ALF-CCCM is present. For some embodiments, the existing operations of SAO, CC-SAO, ALF and CC-ALF are kept unchanged with the exception that ALF chroma operates on ALF-CCCM output.

[0090] In some embodiments, more flexible block partition methods and coefficient derivation methods may be used for ALF-CCCM. In some embodiments, as to the block size for ALF-CCCM, in addition to dividing / splitting each CTU into non-overlapping blocks, the split may follow the split of coding units, prediction units, and / or transform units in the corresponding CTU. For example, the video coder may use luma TU block and chroma TU block to derive cross-component filter coefficients. In some embodiments, when a separate split tree is available (luma split and / or chroma split may be available) , the video coder may use luma split or chroma split to split current CTU. In some embodiments, one CTU may have different split sizes.

[0091] In some embodiments, as to the cross-component model for ALF, the cross-component filter coefficients may be inherited from neighboring blocks, coding units, prediction units, and / or transform units. In some embodiments, the coefficients may be inherited from intra CCCM mode or inter CCCM mode. In some embodiments, the cross-component model may be inherited from coding units, prediction units, and / or transform units. In some embodiments, the model may be inherited from intra CCCM model or inter CCCM model. In some embodiments, the cross-component filter coefficients and model may be inherited from coding units, prediction units, and / or transform units. In some embodiments, one CTU may have different cross-component models.

[0092] In some embodiments, to derive the cross-component filter coefficients, the corresponding MV and / or BV of the block may be used to locate the reference luma and chroma blocks to derive coefficients. In some embodiments, the MV and / or BV of the coding units, prediction units, and / or transform units are used to locate the reference luma and chroma blocks to derive coefficients.

[0093] In some embodiments, the blending weight between the cross-component prediction samples and the SAO / CC-SAO chroma output samples may be signaled in the bitstream. In some embodiments, a picture, slice, or APS-level syntax shortcut may be signaled to indicate the split or cross-component model for all CTUs in a picture or slice.

[0094] The foregoing proposed methods can be implemented in encoders and / or decoders. For example, the proposed method can be implemented in an in-loop filtering module of an encoder, and / or an in-loop filtering module of a decoder. IV. Example Video Encoder

[0095] FIG. 12 illustrates an example video encoder 1200 that may implement in-loop filtering. As illustrated, the video encoder 1200 receives input video signal from a video source 1205 and encodes the signal into bitstream 1295. The video encoder 1200 has several components or modules for encoding the signal from the video source 1205, at least including some components selected from a transform module 1210, a quantization module 1211, an inverse quantization module 1214, an inverse transform module 1215, an intra-picture estimation module 1224, an intra-prediction module 1225, a motion compensation module 1230, a motion estimation module 1235, an in-loop filter 1245, a reconstructed picture buffer 1250, a MV buffer 1265, and a MV prediction module 1275, and an entropy encoder 1290. The motion compensation module 1230 and the motion estimation module 1235 are part of an inter-prediction module 1240. The intra-prediction module 1225 and the intra-prediction estimation module 1224 are part of a current picture prediction module 1220, which uses current picture reconstructed samples as reference samples for prediction of the current block.

[0096] In some embodiments, the modules 1210 –1290 are modules of software instructions being executed by one or more processing units (e.g., a processor) of a computing device or electronic apparatus. In some embodiments, the modules 1210 –1290 are modules of hardware circuits implemented by one or more integrated circuits (ICs) of an electronic apparatus. Though the modules 1210 –1290 are illustrated as being separate modules, some of the modules can be combined into a single module.

[0097] The video source 1205 provides a raw video signal that presents pixel data of each video frame without compression. A subtractor 1208 computes the difference between the raw video pixel data of the video source 1205 and the predicted pixel data 1213 from the motion compensation module 1230 or intra-prediction module 1225 as prediction residual 1209. The transform module 1210 converts the difference (or the residual pixel data or residual signal 1208) into transform coefficients (e.g., by performing Discrete Cosine Transform, or DCT) . The quantization module 1211 quantizes the transform coefficients into quantized data (or quantized coefficients) 1212, which is encoded into the bitstream 1295 by the entropy encoder 1290.

[0098] The inverse quantization module 1214 de-quantizes the quantized data (or quantized coefficients) 1212 to obtain transform coefficients 1218, and the inverse transform module 1215 performs inverse transform on the transform coefficients 1218 to produce reconstructed residual 1219. The reconstructed residual 1219 is added with the predicted pixel data 1213 to produce reconstructed pixel data 1217. In some embodiments, the reconstructed pixel data 1217 is temporarily stored in a line buffer 1227 (or intra prediction buffer) for intra-picture prediction and spatial MV prediction. The reconstructed pixels are filtered by the in-loop filter 1245 and stored in the reconstructed picture buffer 1250. In some embodiments, the reconstructed picture buffer 1250 is a storage external to the video encoder 1200. In some embodiments, the reconstructed picture buffer 1250 is a storage internal to the video encoder 1200.

[0099] The intra-picture estimation module 1224 performs intra-prediction based on the reconstructed pixel data 1217 to produce intra prediction data. The intra-prediction data is provided to the entropy encoder 1290 to be encoded into bitstream 1295. The intra-prediction data is also used by the intra-prediction module 1225 to produce the predicted pixel data 1213.

[0100] The motion estimation module 1235 performs inter-prediction by producing MVs to reference pixel data of previously decoded frames stored in the reconstructed picture buffer 1250. These MVs are provided to the motion compensation module 1230 to produce predicted pixel data.

[0101] Instead of encoding the complete actual MVs in the bitstream, the video encoder 1200 uses MV prediction to generate predicted MVs, and the difference between the MVs used for motion compensation and the predicted MVs is encoded as residual motion data and stored in the bitstream 1295.

[0102] The MV prediction module 1275 generates the predicted MVs based on reference MVs that were generated for encoding previously video frames, i.e., the motion compensation MVs that were used to perform motion compensation. The MV prediction module 1275 retrieves reference MVs from previous video frames from the MV buffer 1265. The video encoder 1200 stores the MVs generated for the current video frame in the MV buffer 1265 as reference MVs for generating predicted MVs.

[0103] The MV prediction module 1275 uses the reference MVs to create the predicted MVs. The predicted MVs can be computed by spatial MV prediction or temporal MV prediction. The difference between the predicted MVs and the motion compensation MVs (MC MVs) of the current frame (residual motion data) are encoded into the bitstream 1295 by the entropy encoder 1290.

[0104] The entropy encoder 1290 encodes various parameters and data into the bitstream 1295 by using entropy-coding techniques such as context-adaptive binary arithmetic coding (CABAC) or Huffman encoding. The entropy encoder 1290 encodes various header elements, flags, along with the quantized transform coefficients 1212, and the residual motion data as syntax elements into the bitstream 1295. The bitstream 1295 is in turn stored in a storage device or transmitted to a decoder over a communications medium such as a network.

[0105] The in-loop filter 1245 performs filtering or smoothing operations on the reconstructed pixel data 1217 to reduce the artifacts of coding, particularly at boundaries of pixel blocks. In some embodiments, the filtering or smoothing operations performed by the in-loop filter 1245 include deblock filter (DBF) , sample adaptive offset (SAO) , and / or adaptive loop filter (ALF) . In some embodiments, luma mapping chroma scaling (LMCS) is performed before the loop filters.

[0106] FIG. 13 illustrates portions of the video encoder 1200 that implement ALF that is refined by CCCM. Specifically, the figure illustrates the in-loop filters 1245 in greater detail. As illustrated, the reconstructed pixel data 1217 is processed by DBF module 1302 and the SAO module 1304 and then received by ALF module 1306.

[0107] The ALF module 1306 includes an ALF luma module 1310, an ALF chroma module 1320, and a CCCM-ALF module 1330. The ALF luma module 1310 receives luma (Y) samples from the SAO 1304 and provide ALF luma output 1315. The CCCM-ALF module 1330 receives the chroma (Cr / Cb) samples from the SAO 1304 and the ALF luma output 1315 to provide chroma CCCM refinement 1335. The chroma CCCM refinement 1335 is used by the ALF chroma module 1320 to generate the ALF chroma output 1325. The ALF chroma output 1325 and the ALF luma output 1315 are provided as the in-loop filter output 1340. The in-loop filter output 1340 is then stored to the reconstructed picture buffer 1250.

[0108] The CCCM-ALF module 1330 includes a cross-component filter 1331 and a blender 1332. An example of the CCCM-ALF module 1330 is described by reference to FIGS. 11A-11B. The CCCM filtering module 1110 is an example of the CCCM-ALF module 1330 and the in-loop filters 1100 is an example of the in-loop filters 1245. CCCM is described in Section II above. CCCM-ALF is described in Section III above.

[0109] The cross-component filter 1331 receives the ALF luma output 1315 and generates cross-component prediction samples 1335. The coefficients of the cross-component filter 1331 may be inherited from spatial neighbors or reference blocks (by MV or BV) , or derived based on reference samples in templates or reference blocks, stored in the line buffer 1227 and / or the reconstructed picture buffer 1250. The cross-component filter 1331 may select one of several (e.g., 8) filters to apply based on inputs from the RDO. The selected filter is applicable to the current block or a current partition that is determined by a split tree of the current block, or a transform unit, or a prediction unit. Such partition information may be provided by the entropy encoder 1290 and coded into the bitstream 1295.

[0110] The blender 1332 blends the cross-component prediction samples 1335 with the chroma (Cr / Cb) samples from the SAO 1304 according to adaptive blending weights that may be provided by the entropy encoder 1290 or the RDO and coded into the bitstream 1295 for the current block or current partition. The blending weight may be set to values that are different than 0.5 and 0.5 for the cross-component prediction samples 1335 and the chroma (Cr / Cb) samples from SAO.

[0111] FIG. 14 conceptually illustrates a process 1400 for encoding pixel blocks using CCCM-ALF. In some embodiments, one or more processing units (e.g., a processor) of a computing device implementing the encoder 1200 performs the process 1400 by executing instructions stored in a computer readable medium. In some embodiments, an electronic apparatus implementing the encoder 1200 performs the process 1400.

[0112] The encoder receives (at block 1410) data to be encoded as a current block of pixels in a current picture. The encoder reconstructs (at block 1420) the current block based on the received data. The encoder computes (at block 1430) intermediate chroma values based on chroma samples of the reconstructed current block. The intermediate chroma values may include sample provided by adaptive offsets (SAO) and cross-component SAO.

[0113] The encoder applies (at block 1440) a convolutional cross-component filter to luma samples of the reconstructed current block to obtain cross-component prediction samples. In some embodiments, the cross-component filter uses filter coefficients that are inherited from spatial neighbors, from one or more reference blocks identified by at least one motion vector or block vector. In some embodiments, the cross-component filter uses filter coefficients that are derived using reference luma and chroma samples that are identified by motion vectors or block vectors.

[0114] In some embodiments, the cross-component filter is applicable to only samples in a partition of a coding tree unit (CTU) . The partition may be determined based on a split tree of coding units, prediction units, or transform units in the CTU. In some embodiments, information regarding the partition and the cross-component filter are provided by syntax elements in a bitstream coding the video.

[0115] The encoder blends (at block 1450) the cross-component prediction samples with the intermediate chroma values to generate final chroma values according to a set of adaptive blending weight. In some embodiments, the set of adaptive blending weight is signaled in a bitstream.

[0116] The encoder provides (at block 1460) the final chroma values as chroma samples of the reconstructed current block. A subsequent block may be encoded by using the reconstructed current block. V. Example Video Decoder

[0117] In some embodiments, an encoder may signal (or generate) one or more syntax element in a bitstream, such that a decoder may parse said one or more syntax element from the bitstream.

[0118] FIG. 15 illustrates an example video decoder 1500 that may implement in-loop filtering. As illustrated, the video decoder 1500 is an image-decoding or video-decoding circuit that receives a bitstream 1595 and decodes the content of the bitstream into pixel data of video frames for display. The video decoder 1500 has several components or modules for decoding the bitstream 1595, including some components selected from an inverse quantization module 1514, an inverse transform module 1515, an intra-prediction module 1525, a motion compensation module 1530, an in-loop filter 1545, a decoded picture buffer 1550, a MV buffer 1565, a MV prediction module 1575, and a parser 1590. The motion compensation module 1530 is part of an inter-prediction module 1540. The intra-prediction module 1525 is part of a current picture prediction module 1520, which uses current picture reconstructed samples as reference samples for prediction of the current block.

[0119] In some embodiments, the modules 1514 –1590 are modules of software instructions being executed by one or more processing units (e.g., a processor) of a computing device. In some embodiments, the modules 1514 –1590 are modules of hardware circuits implemented by one or more ICs of an electronic apparatus. Though the modules 1514 –1590 are illustrated as being separate modules, some of the modules can be combined into a single module.

[0120] The parser 1590 (or entropy decoder) receives the bitstream 1595 and performs initial parsing according to the syntax defined by a video-coding or image-coding standard. The parsed syntax element includes various header elements, flags, as well as quantized data (or quantized coefficients) 1512. The parser 1590 parses out the various syntax elements by using entropy-coding techniques such as context-adaptive binary arithmetic coding (CABAC) or Huffman encoding.

[0121] The inverse quantization module 1514 de-quantizes the quantized data (or quantized coefficients) 1512 to obtain transform coefficients, and the inverse transform module 1515 performs inverse transform on the transform coefficients 1518 to produce reconstructed residual signal 1519. The reconstructed residual signal 1519 is added with predicted pixel data 1513 from the intra-prediction module 1525 or the motion compensation module 1530 to produce decoded pixel data 1517. The decoded pixels data are filtered by the in-loop filter 1545 and stored in the decoded picture buffer 1550. In some embodiments, the decoded picture buffer 1550 is a storage external to the video decoder 1500. In some embodiments, the decoded picture buffer 1550 is a storage internal to the video decoder 1500.

[0122] The intra-prediction module 1525 receives intra-prediction data from bitstream 1595 and according to which, produces the predicted pixel data 1513 from the decoded pixel data 1517 stored in the decoded picture buffer 1550. In some embodiments, the decoded pixel data 1517 is also stored in a line buffer 1527 (or intra prediction buffer) for intra-picture prediction and spatial MV prediction.

[0123] In some embodiments, the content of the decoded picture buffer 1550 is used for display. A display device 1505 either retrieves the content of the decoded picture buffer 1550 for display directly, or retrieves the content of the decoded picture buffer to a display buffer. In some embodiments, the display device receives pixel values from the decoded picture buffer 1550 through a pixel transport.

[0124] The motion compensation module 1530 produces predicted pixel data 1513 from the decoded pixel data 1517 stored in the decoded picture buffer 1550 according to motion compensation MVs (MC MVs) . These motion compensation MVs are decoded by adding the residual motion data received from the bitstream 1595 with predicted MVs received from the MV prediction module 1575.

[0125] The MV prediction module 1575 generates the predicted MVs based on reference MVs that were generated for decoding previous video frames, e.g., the motion compensation MVs that were used to perform motion compensation. The MV prediction module 1575 retrieves the reference MVs of previous video frames from the MV buffer 1565. The video decoder 1500 stores the motion compensation MVs generated for decoding the current video frame in the MV buffer 1565 as reference MVs for producing predicted MVs.

[0126] The in-loop filter 1545 performs filtering or smoothing operations on the decoded pixel data 1517 to reduce the artifacts of coding, particularly at boundaries of pixel blocks. In some embodiments, the filtering or smoothing operations performed by the in-loop filter 1545 include deblock filter (DBF) , sample adaptive offset (SAO) , and / or adaptive loop filter (ALF) . In some embodiments, luma mapping chroma scaling (LMCS) is performed before the loop filters.

[0127] FIG. 16 illustrates portions of the video decoder 1500 that implement ALF that is refined by CCCM cross-component filtering. Specifically, the figure illustrates the in-loop filters 1545 in greater detail. As illustrated, the reconstructed pixel data 1517 is processed by DBF module 1602 and the SAO module 1604 and then received by ALF module 1606.

[0128] The ALF module 1606 includes an ALF luma module 1610, an ALF chroma module 1620, and a CCCM-ALF module 1630. The ALF luma module 1610 receives luma (Y) samples from the SAO 1604 and provide ALF luma output 1615. The CCCM-ALF module 1630 receives the chroma (Cr / Cb) samples from the SAO 1604 and the ALF luma output 1615 to provide chroma CCCM refinement 1635. The chroma CCCM refinement 1635 is used by the ALF chroma module 1620 to generate the ALF chroma output 1625. The ALF chroma output 1625 and the ALF luma output 1615 are provided as the in-loop filter output 1640. The in-loop filter output 1640 is then stored to the decoded picture buffer 1550.

[0129] The CCCM-ALF module 1630 includes a cross-component filter 1631 and a blender 1632. An example of the CCCM-ALF module 1630 is described by reference to FIGS. 11A-11B. The CCCM filtering module 1110 is an example of the CCCM-ALF module 1630 and the in-loop filters 1100 is an example of the in-loop filters 1545. CCCM is described in Section II above. CCCM-ALF is described in Section III above.

[0130] The cross-component filter 1631 receives the ALF luma output 1615 and generates cross-component prediction samples 1635. The coefficients of the cross-component filter 1631 may be inherited from spatial neighbors or reference blocks (by MV or BV) , or derived based on reference samples in templates or reference blocks, stored in the line buffer 1527 and / or the decoded picture buffer 1550. The cross-component filter 1631 may select one of several (e.g., 8) filters to apply based on inputs from the RDO. The selected filter is applicable to the current block or a current partition that is determined by a split tree of the current block, or a transform unit, or a prediction unit. Such partition information may be provided by the entropy decoder 1590, which may parse the information from the bitstream 1595.

[0131] The blender 1632 blends the cross-component prediction samples 1635 with the chroma (Cr / Cb) samples from the SAO 1604 according to adaptive blending weights that may be provided by the entropy decoder 1590, which may parse the bitstream 1595 for information regarding the blending weight for the current block or partition. The blending weight may be set to values that are different than 0.5 and 0.5 for the cross-component prediction samples 1635 and the chroma (Cr / Cb) samples from SAO.

[0132] FIG. 17 conceptually illustrates a process 1700 for decoding pixel blocks using CCCM-ALF. In some embodiments, one or more processing units (e.g., a processor) of a computing device implementing the decoder 1500 performs the process 1700 by executing instructions stored in a computer readable medium. In some embodiments, an electronic apparatus implementing the decoder 1500 performs the process 1700.

[0133] The decoder receives (at block 1710) data to be decoded as a current block of pixels in a current picture. The decoder reconstructs (at block 1720) the current block based on the received data. The decoder computes (at block 1730) intermediate chroma values based on chroma samples of the reconstructed current block. The intermediate chroma values may include sample provided by adaptive offsets (SAO) and cross-component SAO.

[0134] The decoder applies (at block 1740) a convolutional cross-component filter to luma samples of the reconstructed current block to obtain cross-component prediction samples. In some embodiments, the cross-component filter uses filter coefficients that are inherited from spatial neighbors, from one or more reference blocks identified by at least one motion vector or block vector. In some embodiments, the cross-component filter uses filter coefficients that are derived using reference luma and chroma samples that are identified by motion vectors or block vectors.

[0135] In some embodiments, the cross-component filter is applicable to only samples in a partition of a coding tree unit (CTU) . The partition may be determined based on a split tree of coding units, prediction units, or transform units in the CTU. In some embodiments, information regarding the partition and the cross-component filter are provided by syntax elements in a bitstream coding the video.

[0136] The decoder blends (at block 1750) the cross-component prediction samples with the intermediate chroma values to generate final chroma values according to a set of adaptive blending weight. In some embodiments, the set of adaptive blending weight is signaled in a bitstream.

[0137] The decoder provides (at block 1760) the final chroma values as chroma samples of the reconstructed current block. The decoder may then output the reconstructed current block for display, transmission, or storage. The reconstructed current block may also be used as reference for subsequent blocks. VI. Example Electronic System

[0138] Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium) . When these instructions are executed by one or more computational or processing unit (s) (e.g., one or more processors, cores of processors, or other processing units) , they cause the processing unit (s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, random-access memory (RAM) chips, hard drives, erasable programmable read only memories (EPROMs) , electrically erasable programmable read-only memories (EEPROMs) , etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[0139] In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the present disclosure. In some embodiments, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.

[0140] FIG. 18 conceptually illustrates an electronic system 1800 with which some embodiments of the present disclosure are implemented. The electronic system 1800 may be a computer (e.g., a desktop computer, personal computer, tablet computer, etc. ) , phone, PDA, or any other sort of electronic device. Such an electronic system includes various types of computer readable media and interfaces for various other types of computer readable media. Electronic system 1800 includes a bus 1805, processing unit (s) 1810, a graphics-processing unit (GPU) 1815, a system memory 1820, a network 1825, a read-only memory 1830, a permanent storage device 1835, input devices 1840, and output devices 1845.

[0141] The bus 1805 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 1800. For instance, the bus 1805 communicatively connects the processing unit (s) 1810 with the GPU 1815, the read-only memory 1830, the system memory 1820, and the permanent storage device 1835.

[0142] From these various memory units, the processing unit (s) 1810 retrieves instructions to execute and data to process in order to execute the processes of the present disclosure. The processing unit (s) may be a single processor or a multi-core processor in different embodiments. Some instructions are passed to and executed by the GPU 1815. The GPU 1815 can offload various computations or complement the image processing provided by the processing unit (s) 1810.

[0143] The read-only-memory (ROM) 1830 stores static data and instructions that are used by the processing unit (s) 1810 and other modules of the electronic system. The permanent storage device 1835, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 1800 is off. Some embodiments of the present disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 1835.

[0144] Other embodiments use a removable storage device (such as a floppy disk, flash memory device, etc., and its corresponding disk drive) as the permanent storage device. Like the permanent storage device 1835, the system memory 1820 is a read-and-write memory device. However, unlike storage device 1835, the system memory 1820 is a volatile read-and-write memory, such a random access memory. The system memory 1820 stores some of the instructions and data that the processor uses at runtime. In some embodiments, processes in accordance with the present disclosure are stored in the system memory 1820, the permanent storage device 1835, and / or the read-only memory 1830. For example, the various memory units include instructions for processing multimedia clips in accordance with some embodiments. From these various memory units, the processing unit (s) 1810 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.

[0145] The bus 1805 also connects to the input and output devices 1840 and 1845. The input devices 1840 enable the user to communicate information and select commands to the electronic system. The input devices 1840 include alphanumeric keyboards and pointing devices (also called “cursor control devices” ) , cameras (e.g., webcams) , microphones or similar devices for receiving voice commands, etc. The output devices 1845 display images generated by the electronic system or otherwise output data. The output devices 1845 include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD) , as well as speakers or similar audio output devices. Some embodiments include devices such as a touchscreen that function as both input and output devices.

[0146] Finally, as shown in FIG. 18, bus 1805 also couples electronic system 1800 to a network 1825 through a network adapter (not shown) . In this manner, the computer can be a part of a network of computers (such as a local area network ( “LAN” ) , a wide area network ( “WAN” ) , or an Intranet, or a network of networks, such as the Internet. Any or all components of electronic system 1800 may be used in conjunction with the present disclosure.

[0147] Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media) . Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM) , recordable compact discs (CD-R) , rewritable compact discs (CD-RW) , read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM) , a variety of recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc. ) , flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc. ) , magnetic and / or solid state hard drives, read-only and recordable  discs, ultra-density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

[0148] While the above discussion primarily refers to microprocessor or multi-core processors that execute software, many of the above-described features and applications are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) . In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself. In addition, some embodiments execute software stored in programmable logic devices (PLDs) , ROM, or RAM devices.

[0149] As used in this specification and any claims of this application, the terms “computer” , “server” , “processor” , and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium, ” “computer readable media, ” and “machine readable medium” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

[0150] While the present disclosure has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the present disclosure can be embodied in other specific forms without departing from the spirit of the present disclosure. In addition, a number of the figures (including FIGS. 14, and 17) conceptually illustrate processes. The specific operations of these processes may not be performed in the exact order shown and described. The specific operations may not be performed in one continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process could be implemented using several sub-processes, or as part of a larger macro process. Thus, one of ordinary skill in the art would understand that the present disclosure is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims. Additional Notes

[0151] The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can also be viewed as being "operably connected" , or "operably coupled" , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable" , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0152] Further, with respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0153] Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an, " e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of "two recitations, " without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B. ”

[0154] From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1.A video coding method comprising:receiving data to be encoded or decoded as a current block of pixels of a current picture of a video;reconstructing the current block based on the received data;computing intermediate chroma values based on chroma samples of the reconstructed current block;applying a convolutional cross-component filter to luma samples of the reconstructed current block to obtain cross-component prediction samples;blending the cross-component prediction samples with the intermediate chroma values to generate final chroma values, wherein the blending is according to a set of adaptive blending weight; andproviding the final chroma values as chroma samples of the reconstructed current block.2.The video coding method of claim 1, wherein the intermediate chroma values comprise sample adaptive offsets (SAO) .3.The video coding method of claim 2, wherein the intermediate chroma values further comprises cross-component sample adaptive offset (CCSAO) .4.The video coding method of claim 1, wherein the set of adaptive blending weight is signaled in or parsed from a bitstream.5.The video coding method of claim 1, wherein the convolutional cross-component filter uses filter coefficients that are inherited.6.The video coding method of claim 5, wherein the filter coefficients are inherited from spatial neighbors.7.The video coding method of claim 5, wherein the filter coefficients are inherited from one or more reference blocks identified by at least one motion vector or block vector.8.The video coding method of claim 1, wherein the cross-component filter uses filter coefficients that are derived using reference luma and chroma samples that are identified by motion vectors or block vectors.9.The video coding method of claim 1, wherein the cross-component filter is applicable to only samples in a partition of a coding tree unit (CTU) .10.The video coding method of claim 9, wherein the partition is determined based on a split tree of coding units, prediction units, or transform units in the CTU.11.The video coding method of claim 9, wherein information regarding the partition and the cross-component filter are provided by syntax elements in a bitstream coding the video.12.An electronic apparatus comprising:a video coder circuit configured to perform operations comprising:receiving data to be encoded or decoded as a current block of pixels of a current picture of a video;reconstructing the current block based on the received data;computing intermediate chroma values based on chroma samples of the reconstructed current block;applying a convolutional cross-component filter to luma samples of the reconstructed current block to obtain cross-component prediction samples;blending the cross-component prediction samples with the intermediate chroma values to generate final chroma values, wherein the blending is according to a set of adaptive blending weight; andproviding the final chroma values as chroma samples of the reconstructed current block.13.A video decoding method comprising:receiving data to be decoded as a current block of pixels of a current picture of a video;reconstructing the current block based on the received data;computing intermediate chroma values based on chroma samples of the reconstructed current block;applying a convolutional cross-component filter to luma samples of the reconstructed current block to obtain cross-component prediction samples;blending the cross-component prediction samples with the intermediate chroma values to generate final chroma values, wherein the blending is according to a set of adaptive blending weight;providing the final chroma values as chroma samples of the reconstructed current block; andoutputting the reconstructed current block.14.A video encoding method comprising:receiving data to be encoded as a current block of pixels of a current picture of a video;reconstructing the current block based on the received data;computing intermediate chroma values based on chroma samples of the reconstructed current block;applying a convolutional cross-component filter to luma samples of the reconstructed current block to obtain cross-component prediction samples;blending the cross-component prediction samples with the intermediate chroma values to generate final chroma values, wherein the blending is according to a set of adaptive blending weight;providing the final chroma values as chroma samples of the reconstructed current block; andencoding a subsequent block by using the reconstructed current block.

Images