CN114009018A - System and method for reducing reconstruction errors in video coding based on cross-component correlation - Google Patents

Abstract

The invention discloses a method for filtering reconstructed video data. The method comprises the following steps: inputting a reconstructed brightness component sample value; deriving filtered sample values by using cross component filter coefficients and the reconstructed luma component sample values prior to an adaptive loop filtering process; deriving a refinement value for a chrominance component by using the filtered sample value; and deriving a refined chroma sample value by using a sum of the sample value of the chroma component and a refined value for the chroma component.

Description

System and method for reducing reconstruction error in video coding based on cross-component correlation

technical field

The present disclosure relates to video coding, and more particularly to techniques for reducing reconstruction error.

Background technique

Digital video capabilities can be incorporated into a variety of devices, including digital televisions, laptop or desktop computers, tablet computers, digital recording devices, digital media players, video game devices, cellular phones (including so-called smart phones), medical imaging devices Wait. Digital video may be encoded according to video encoding standards. A video coding standard defines the format of a compliant bitstream that encapsulates encoded video data. A compliant bitstream is a data structure that can be received and decoded by a video decoding device to generate reconstructed video data. Video coding standards may incorporate video compression techniques. Examples of video coding standards include ISO/IEC MPEG-4 Visual and ITU-T H.264 (also known as ISO/IEC MPEG-4 AVC) and High Efficiency Video Coding (HEVC). HEVC is described in ITU-T Rec. H.265, High Efficiency Video Coding (HEVC), December 2016, incorporated herein by reference, and referred to herein as ITU-T H.265. Extensions and improvements to ITU-TH.265 are currently under consideration to develop next-generation video coding standards. For example, the ITU-T Video Coding Experts Group (VCEG) and the ISO/IEC Moving Picture Experts Group (MPEG) (collectively known as the Joint Video Study Group (JVET)) are working to standardize video coding techniques with compression capabilities significantly exceeding the current HEVC standard . Joint Exploratory Model 7 (JEM7), Algorithmic Description of Joint Exploratory Testing Model 7 (JEM 7), ISO/IEC JTC1/SC29/WG11 Document: JVET-G1001 (July 2017, Italy, both incorporated by reference) Ling) describes the coding characteristics studied by JVET under a joint test model, which is a potential enhanced video coding technique beyond the capabilities of ITU-T H.265. It should be noted that the encoding features of JEM 7 are implemented in the JEM reference software. As used herein, the term JEM may collectively refer to the algorithms included in JEM 7 as well as specific implementations of the JEM reference software. In addition, in response to "Joint Call for Proposals on VideoCompression with Capabilities beyond HEVC" jointly published by VCEG and MPEG, at ISO/IEC JTC1 April 16-20, 2018 in San Diego, CA At the 10th meeting of /SC29/WG11, various groups proposed various descriptions of video coding tools. Based on various descriptions of video coding tools, the final initial draft text of the video coding specification was presented at the "Versatile Video Coding (Draft 1)" is described in document JVET-J1001-v2, which is incorporated herein by reference and referred to as JVET-J1001. The current development of JVET and MPEG's next-generation video coding standard is known as the Versatile Video Coding (VVC) project. "Versatile Video Coding (Draft 5)" (document JVET-N1001-v8, ISO/IEC JTC1/SC29/WG11 14th meeting, Geneva, Switzerland, 19-27 March 2019, incorporated by reference incorporated herein and referred to as JVET-N1001) represents a new version of the draft text corresponding to the Video Coding Specification of the VVC Project. "Versatile Video Coding (Draft 6)" at ISO/IEC JTC1/SC29/WG11 15th meeting, Gothenburg, Sweden, 3-12 July 2019 (document JVET-O2001-vE, incorporated by reference incorporated herein and referred to as JVET-O2001) represents the current version of the draft text corresponding to the Video Coding Specification of the VVC Project.

Video compression techniques can reduce the data requirements for storing and transmitting video data. Video compression techniques can reduce data requirements by exploiting the redundancy inherent in video sequences. Video compression techniques may subdivide a video sequence into successively smaller portions (ie, a group of pictures within a video sequence, pictures within a group of pictures, regions within a picture, subregions within a region, etc.). Differences between a unit of video data to be encoded and a reference unit of video data may be generated using intra-frame prediction coding techniques (eg, spatial prediction techniques within a picture) and inter-frame prediction techniques (ie, inter-picture techniques (temporal)) value. This difference can be referred to as residual data. Residual data may be encoded as quantized transform coefficients. Syntax elements may relate to residual data and reference coding units (eg, intra-prediction mode index and motion information). Residual data and syntax elements may be entropy encoded. The entropy coded residual data and syntax elements may be included in the data structures forming the compatible bitstream.

SUMMARY OF THE INVENTION

In one example, a method of filtering reconstructed video data is provided, the method comprising: inputting reconstructed luma component sample values; reconstructing luma by using cross component filter coefficients and reconstructing luma prior to an adaptive loop filtering process component sample values to derive filtered sample values; use the filtered sample values to derive refinement values for the chroma components; and derive refinement values by using the sum of the sample values for the chroma components and the refinement values for the chroma components Chroma sample value.

In one example, a decoder for decoding encoded data is provided, the decoder comprising: a processor, and a memory associated with the processor; wherein the processor is configured to perform the steps of: inputting reconstructed luminance component sample values; deriving filtered sample values by using cross component filter coefficients and reconstructing luma component sample values prior to the adaptive loop filtering process; deriving refinement values for the chroma components by using the filtered sample values; and The refined chroma sample values are derived by using the sum of the sample values for the chroma components and the refinement values for the chroma components.

In one example, there is provided an encoder for encoding video data, the encoder comprising: a processor, and a memory associated with the processor; wherein the processor is configured to perform the steps of: inputting reconstructed luminance component sample values; deriving filtered sample values by using cross component filter coefficients and reconstructing luma component sample values prior to the adaptive loop filtering process; deriving refinement values for the chroma components by using the filtered sample values; and The refined chroma sample values are derived by using the sum of the sample values for the chroma components and the refinement values for the chroma components.

Description of drawings

[ FIG. 1] FIG. 1 is a conceptual diagram illustrating an example of a group of pictures encoded according to quadtree multitree partitioning according to one or more techniques of the present disclosure.

[FIG. 2A] FIG. 2A is a conceptual diagram illustrating an example of encoding a block of video data according to one or more techniques of this disclosure.

[FIG. 2B] FIG. 2B is a conceptual diagram illustrating an example of encoding a block of video data according to one or more techniques of this disclosure.

[ Fig. 3] Fig. 3 is a conceptual diagram illustrating an example of a video component sampling format that can be used in accordance with one or more techniques of this disclosure.

[FIG. 4A] FIG. 4A is a conceptual diagram illustrating an example of a location type of a video component sampling format that can be used in accordance with one or more techniques of this disclosure.

[FIG. 4B] FIG. 4B is a conceptual diagram illustrating an example of a location type of a video component sampling format that can be used in accordance with one or more techniques of this disclosure.

[FIG. 4C] FIG. 4C is a conceptual diagram illustrating an example of a location type of a video component sampling format that can be used in accordance with one or more techniques of this disclosure.

[FIG. 4D] FIG. 4D is a conceptual diagram illustrating an example of a location type of a video component sampling format that can be used in accordance with one or more techniques of this disclosure.

[FIG. 4E] FIG. 4E is a conceptual diagram illustrating an example of location types of video component sampling formats that can be used in accordance with one or more techniques of this disclosure.

[FIG. 4F] FIG. 4F is a conceptual diagram illustrating an example of a location type of a video component sampling format that can be used in accordance with one or more techniques of this disclosure.

[ Fig. 5] Fig. 5 is a block diagram illustrating an example of a system that may be configured to encode and decode video data according to one or more techniques of the present disclosure.

[ Fig. 6] Fig. 6 is a block diagram illustrating an example of a video encoder that may be configured to encode video data according to one or more techniques of the present disclosure.

[ Fig. 7] Fig. 7 is a block diagram illustrating an example of a cross-component filter unit that may be configured to encode video data in accordance with one or more techniques of this disclosure.

[ Fig. 8] Fig. 8 is a conceptual diagram illustrating an example of reconstruction errors for multiple components of video data according to one or more techniques of the present disclosure.

[ FIG. 9A] FIG. 9A is a conceptual diagram illustrating an example of support samples that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 9B] FIG. 9B is a conceptual diagram illustrating an example of support samples that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 9C] FIG. 9C is a conceptual diagram illustrating an example of support samples that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 9D] FIG. 9D is a conceptual diagram illustrating an example of support samples that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 9E] FIG. 9E is a conceptual diagram illustrating an example of support samples that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 9F] FIG. 9F is a conceptual diagram illustrating an example of support samples that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[ Fig. 10] Fig. 10 is a conceptual diagram illustrating an example of reducing reconstruction errors using cross-component filtering according to one or more techniques of the present disclosure.

[FIG. 11A] FIG. 11A is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 11B] FIG. 11B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 11C] FIG. 11C is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 11D] FIG. 11D is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 12A] FIG. 12A is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 12B] FIG. 12B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 13A] FIG. 13A is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 13B] FIG. 13B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 13C] FIG. 13C is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[ FIG. 14A] FIG. 14A is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[ Fig. 14B] Fig. 14B is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 14C] FIG. 14C is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 14D] FIG. 14D is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 14E] FIG. 14E is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 14F] FIG. 14F is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 15A] FIG. 15A is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 15B] FIG. 15B is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 15C] FIG. 15C is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 15D] FIG. 15D is a conceptual diagram illustrating an example of filter coefficient positions that may be used for cross-component filtering in accordance with one or more techniques of this disclosure.

[FIG. 16A] FIG. 16A is a conceptual diagram illustrating an example of a virtual line buffer that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 16A] FIG. 16A is a conceptual diagram illustrating an example of a virtual line buffer that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[ Fig. 16B] Fig. 16B is a conceptual diagram illustrating an example of a virtual line buffer that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 16C] FIG. 16C is a conceptual diagram illustrating an example of a virtual line buffer that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[FIG. 16D] FIG. 16D is a conceptual diagram illustrating an example of a virtual line buffer that may be used for cross-component filtering in accordance with one or more techniques of the present disclosure.

[ FIG. 17] FIG. 17 is a block diagram illustrating an example of a video decoder that may be configured to decode video data according to one or more techniques of this disclosure.

[FIG. 18] FIG. 18 is a block diagram illustrating an example of a cross-component filter unit that may be configured to encode video data in accordance with one or more techniques of this disclosure.

[FIG. 19A] FIG. 19A is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 19B] FIG. 19B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

[FIG. 19C] FIG. 19C is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error according to one or more techniques of the present disclosure.

Detailed ways

In general, this disclosure describes various techniques for encoding video data. Specifically, this disclosure describes techniques for reducing reconstruction error. It should be noted that although the techniques of this disclosure are described with respect to ITU-T H.264, ITU-T H.265, JEM, JVET-N1001, and JVET-O2001, the techniques of this disclosure are generally applicable to video encoding. For example, in addition to those included in ITU-T H.265, JEM, JVET-N1001, and JVET-O2001, the coding techniques described herein may be incorporated into video coding systems (including video coding systems based on future video coding standards) , including video block structures, intra prediction techniques, inter prediction techniques, transform techniques, filtering techniques, and/or other entropy coding techniques. Accordingly, references to ITU-T H.264, ITU-T H.265, JEM, JVET-N1001, and JVET-O2001 are for descriptive purposes and should not be construed as limiting the scope of the techniques described herein. Furthermore, it should be noted that the documents incorporated herein by reference are for descriptive purposes and should not be construed to limit or create ambiguity with respect to the terms used herein. For example, where a term is provided in one incorporated reference with a definition that differs from that in another incorporated reference and/or as used herein, the term shall be taken broadly to include each Each specific definition in the alternative is to be interpreted in a correspondingly defined manner and/or in a manner including each specific definition.

In one example, a method includes receiving reconstructed sample data for a current component of video data, receiving reconstructed sample data for one or more additional components of the video data, based on one or more differences with the video data Deriving a cross-component filter based on the data associated with the additional components and applying the filter to the current current value for the video data based on the derived cross-component filter and reconstructed sample data for the one or more additional components of the video data The reconstructed sample data for the components.

In one example, an apparatus includes one or more processors configured to: receive reconstructed sample data for a current component of video data, receive reconstructed sample data for one or more additional components of video data constructing sample data, deriving a cross-component filter based on data associated with one or more additional components of the video data, and reconstructing samples based on the derived cross-component filter and for the one or more additional components of the video data The data applies a filter to the reconstructed sample data for the current component of the video data.

In one example, a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed, cause one or more processors of a device to: receive reconstruction for a current component of video data sample data, receiving reconstructed sample data for one or more additional components of the video data, deriving a cross-component filter based on data associated with the one or more additional components of the video data, and filtering based on the derived cross-component The filter and the reconstructed sample data for one or more additional components of the video data apply a filter to the reconstructed sample data for the current component of the video data.

In one example, an apparatus includes: means for receiving reconstructed sample data for one or more additional components of video data for deriving based on data associated with the one or more additional components of video data Means for a cross-component filter, and for applying the filter to reconstruction for a current component of the video data based on the derived cross-component filter and reconstructed sample data for one or more additional components of the video data A device for constructing sample data.

The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects and advantages will be apparent from the description and drawings, and from the claims.

Video content includes a video sequence consisting of a series of frames (or pictures). A series of frames may also be referred to as a group of pictures (GOP). Each video frame or picture can be divided into one or more regions. Regions may be defined according to basic units (eg, video blocks) and sets of rules that define regions. For example, a rule for defining a region may be that the region must be an integer number of video blocks arranged in a rectangle. Additionally, video blocks in a region may be ordered according to a scan mode (eg, raster scan). As used herein, the term "video block" may refer generally to a region of a picture, or may refer more specifically to the largest array of sample values, sub-partitions thereof, and/or corresponding structures that may be predictively encoded. Furthermore, the term "current video block" may refer to a region of a picture that is being encoded or decoded. A video block may be defined as an array of sample values. It should be noted that, in some cases, pixel values may be described as sample values including corresponding components of video data, which may also be referred to as color components (eg, luma (Y) and chrominance (Cb and Cr) components or red, green and blue components). It should be noted that in some cases the terms "pixel value" and "sample value" are used interchangeably. Also, in some cases, a pixel or sample may be referred to as a pel. A video sampling format (which may also be referred to as a chroma format) may define the number of chroma samples included in a video block relative to the number of luma samples included in the video block. For example, for the 4:2:0 sampling format, the sampling rate of the luma component is twice the sampling rate of the chroma components in both the horizontal and vertical directions.

A video encoder may perform predictive encoding on a video block and its sub-partitions. A video block and its sub-partitions may be referred to as nodes. ITU-T H.264 specifies a macroblock comprising 16x16 luma samples. That is, in ITU-T H.264, pictures are segmented into macroblocks. ITU-T H.265 specifies a similar coding tree unit (CTU) structure (which may be referred to as the largest coding unit (LCU)). In ITU-T H.265, pictures are segmented into CTUs. In ITU-T H.265, for pictures, the CTU size can be set to include 16x16, 32x32, or 64x64 luma samples. In ITU-T H.265, a CTU consists of a corresponding coding tree block (CTB) for each component of video data (eg, luma (Y) and chroma (Cb and Cr)). It should be noted that a video with one luma component and two corresponding chroma components can be described as having two channels, a luma channel and a chroma channel. In addition, in ITU-T H.265, the CTU may be divided according to a quad-tree (QT) partition structure, which enables the CTB of the CTU to be divided into coding blocks (CBs). That is, in ITU-T H.265, CTUs can be divided into quad-leaf nodes. According to ITU-T H.265, a luma CB along with two corresponding chroma CBs and associated syntax elements is called a coding unit (CU). In ITU-TH.265, the minimum allowable size of a CB may be signaled. In ITU-T H.265, the minimum allowed minimum size of a luma CB is 8x8 luma samples. In ITU-T H.265, the decision to encode a picture region using intra prediction or inter prediction is made at the CU level.

In ITU-T H.265, a CU is associated with a prediction unit (PU) structure that has its root at the CU. In ITU-TH.265, the PU structure allows for segmentation of luma CB and chroma CB to generate corresponding reference samples. That is, in ITU-T H.265, luma CB and chroma CB may be partitioned into corresponding luma prediction blocks and chroma prediction blocks (PB), where PB includes blocks to which the same predicted sample values are applied. In ITU-T H.265, CBs can be divided into 1, 2 or 4 PBs. ITU-T H.265 supports PB sizes from 64x64 samples down to 4x4 samples. In ITU-T H.265, square PBs are supported for intra prediction, where a CB can form a PB or a CB can be divided into four square PBs. In ITU-T H.265, in addition to square PBs, rectangular PBs are also supported for inter prediction, where CBs can be halved vertically or horizontally to form PBs. Also, it should be noted that in ITU-T H.265, for inter prediction, four asymmetric PB partitions are supported, where the CB is at the height (top or bottom) or width (left or right) of the CB A quarter is divided into two PBs. Intra-prediction data (eg, intra-prediction mode syntax elements) or inter-prediction data (eg, motion data syntax elements) corresponding to the PB are used to generate reference and/or prediction sample values for the PB.

JEM specifies a CTU with a maximum size of 256x256 luma samples. JEM specifies a quadtree plus binary tree (QTBT) block structure. In JEM, the QTBT structure allows for the further division of quad-leaf nodes by a binary tree (BT) structure. That is, in JEM, the binary tree structure allows the recursive division of quad-leaf nodes vertically or horizontally. In JVET-N1001 and JVET-O2001, CTUs are partitioned according to a quadtree plus multi-type tree (QTMT or QT+MTT) structure. QTMT in JVET-N1001 and JVET-O2001 is similar to QTBT in JEM. However, in JVET-N1001 and JVET-O2001, in addition to indicating binary partitioning, multi-type trees can also indicate so-called ternary (or ternary tree (TT)) partitioning. Ternary segmentation divides a block into three blocks vertically or horizontally. In the case of vertical TT division, the block is divided at a quarter of its width from the left edge and at a quarter of its width from the right edge, and in the case of a horizontal TT division, the block is divided from the top edge Split at a quarter of its height and from the bottom edge at a quarter of its height. Referring again to FIG. 1, FIG. 1 shows an example in which the CTU is divided into quad-leaf nodes and the quad-leaf nodes are further divided according to BT splits or TT splits. That is, in Figure 1, the dashed lines indicate additional binary and ternary partitions in the quadtree.

As described above, each video frame or picture may be divided into one or more regions. For example, according to ITU-T H.265, each video frame or picture may be divided to include one or more slices, and further divided to include one or more tiles, where each slice includes a sequence of CTUs (eg, in raster scan order), and where a tile is a sequence of CTUs corresponding to rectangular regions of the picture. It should be noted that, in ITU-T H.265, a slice is one or the other of all subsequent dependent slice segments (if any) starting from an independent slice segment and including all subsequent dependent slice segments (if any) preceding the next independent slice segment (if any). A sequence of multiple slice fragments. Slice fragments (eg slices) are CTU sequences. Thus, in some cases, the terms "slice" and "slice segment" are used interchangeably to refer to a sequence of CTUs arranged in a raster scan order. Furthermore, it should be noted that in ITU-T H.265, a tile may be composed of CTUs contained in more than one slice, and a slice may be composed of CTUs contained in more than one tile. However, ITU-T H.265 specifies that one or both of the following conditions should be met: (1) all CTUs in a slice belong to the same tile; and (2) all CTUs in a tile belong to the same slice.

Regarding JVET-N1001 and JVET-O2001, a slice needs to consist of an integer number of bricks, not just an integer number of CTUs. In JVET-N1001 and JVET-O2001, a brick is a rectangular CTU row area within a specific tile in a picture. Furthermore, in JVET-N1001 and JVET-O2001, a tile can be divided into multiple bricks, each consisting of one or more CTU rows within the tile. Tiles that are not divided into bricks are also called bricks. However, bricks that are a proper subset of tiles are not called tiles. Accordingly, in some video coding techniques, a slice comprising a set of CTUs that do not form rectangular regions of a picture may or may not be supported. Also, it should be noted that in some cases a slice may need to consist of an integer number of full tiles, and in this case the slice is called a tile group. The techniques described herein may be applied to bricks, slices, tiles, and/or groups of tiles. FIG. 1 is a conceptual diagram illustrating an example of a picture group including slices. In the example shown in Figure 1, Pic ₃ is shown to include two slices (ie, slice ₀ and slice ₁ ). In the example shown in FIG. 1 , slice ₀ includes one brick, brick ₀ , and slice ₁ includes two bricks, brick ₁ and brick ₂ . It should be noted that, in some cases, slice ₀ and slice ₁ may satisfy the requirements of a tile and/or tile group and be classified as a tile and/or tile group.

For intra-prediction encoding, an intra-prediction mode may specify the location of reference samples within a picture. In ITU-TH.265, the defined possible intra prediction modes include planar (ie, surface fitting) prediction mode, DC (ie flat ensemble average) prediction mode, and 33 angle prediction modes (predMode: 2 -34). In JEM, the defined possible intra prediction modes include planar prediction mode, DC prediction mode, and 65 angle prediction modes. It should be noted that the planar prediction mode and the DC prediction mode may be referred to as a non-directional prediction mode, and the angular prediction mode may be referred to as a directional prediction mode. It should be noted that regardless of the number of defined possible prediction modes, the techniques described herein may be generally applicable.

For inter-predictive coding, a reference picture is determined, and a motion vector (MV) identifies the samples in the reference picture used to generate predictions for the current video block. For example, a current video block may be predicted using reference sample values located in one or more previously encoded pictures, and a motion vector used to indicate the position of the reference block relative to the current video block. A motion vector may describe, for example, the horizontal displacement component of the motion vector (ie, MV _x ), the vertical displacement component of the motion vector (ie, MV _y ), and the resolution of the motion vector (eg, quarter-pixel precision, half-pixel precision , one-pixel precision, two-pixel precision, four-pixel precision). Previously decoded pictures (which may include pictures output before or after the current picture) may be organized into one or more reference picture lists and identified using reference picture index values. Also, in inter predictive coding, uni-prediction refers to generating predictions using sample values from a single reference picture, and bi-prediction refers to generating predictions using corresponding sample values from two reference pictures. That is, in uni-prediction, a single reference picture and corresponding motion vector are used to generate predictions for the current video block, while in bi-prediction, the first reference picture and corresponding first motion vector and the second reference picture and The corresponding second motion vector is used to generate a prediction for the current video block. In bi-prediction, corresponding sample values are combined (eg, added, rounded and clipped, or averaged according to weights) to generate a prediction. Pictures and their regions may be classified based on which types of prediction modes are available for encoding their video blocks. That is, for regions with B type (eg, B slices), bi-prediction, uni-prediction, and intra-prediction modes may be utilized, and for regions with P-type (eg, P slices), uni-prediction and intra-frame prediction may be utilized Prediction mode, for regions with type I (eg, I slice), only intra prediction mode can be utilized. As described above, reference pictures are identified by reference indices. For example, for P slices, there may be a single reference picture list RefPicList0, and for B slices, in addition to RefPicList0, there may be a second independent reference picture list RefPicList1. It should be noted that for uni-prediction in a B slice, one of RefPicListO or RefPicListl may be used to generate the prediction. Furthermore, it should be noted that during the decoding process, when decoding a picture is started, a reference picture list is generated from previously decoded pictures stored in a decoded picture buffer (DPB).

In addition, the coding standard may support various motion vector prediction modes. Motion vector prediction enables the value of the motion vector for the current video block to be derived based on another motion vector. For example, a set of candidate blocks with associated motion information may be derived from spatial and temporal neighbors of the current video block. Furthermore, the generated (or default) motion information can be used for motion vector prediction. Examples of motion vector prediction include Advanced Motion Vector Prediction (AMVP), Temporal Motion Vector Prediction (TMVP), so-called "merge" modes, and "skip" and "direct" motion inference. Furthermore, other examples of motion vector prediction include Advanced Temporal Motion Vector Prediction (ATMVP) and Spatial-Temporal Motion Vector Prediction (STMVP). For motion vector prediction, both the video encoder and the video decoder perform the same process to derive a set of candidates. Therefore, for the current video block, the same set of candidates is generated during encoding and decoding.

As described above, for inter-predictive encoding, reference samples in previously encoded pictures are used to encode video blocks in the current picture. A previously encoded picture that can be used as a reference when encoding the current picture is called a reference picture. It should be noted that the decoding order does not necessarily correspond to the picture output order, ie the temporal order of pictures in the video sequence. In ITU-T H.265, when a picture is decoded, it is stored to a decoded picture buffer (DPB) (which may be referred to as a frame buffer, reference buffer, reference picture buffer, etc.). In ITU-T H.265, pictures stored to the DPB are removed from the DPB when output, and are no longer needed for encoding subsequent pictures. In ITU-TH.265, the determination of whether the picture should be removed from the DPB is called once per picture after decoding the slice header, ie, at the start of decoding the picture. For example, with reference to Figure 1, Pic ₃ is shown as reference Pic ₂ . Similarly, Pic ₄ is shown with reference to Pic ₁ . Regarding Figure 1, assuming that the number of pictures corresponds to the decoding order, the DPB will be padded as follows: after decoding Pic ₁ , the DPB will include {Pic ₁ }; at the beginning of decoding Pic ₂ , the DPB will include {Pic ₁ }; after decoding Pic ₂ After that, the DPB will include {Pic ₁ ,Pic ₂ }; at the beginning of decoding Pic ₃ , the DPB will include {Pic ₁ ,Pic ₂ }. Then, Pic ₃ will be decoded with reference to Pic ₂ , and after decoding Pic ₃ , the DPB will include {Pic ₁ , Pic ₂ , Pic ₃ }. At the beginning of decoding Pic ₄ , pictures Pic ₂ and Pic ₃ will be marked for removal from the DPB, as they are not required to decode Pic ₄ (or any subsequent pictures, not shown), and assuming Pic ₂ and Pic ₃ has been exported, the DPB will be updated to include {Pic ₁ }. Pic ₄ will then be decoded using reference Pic ₁ . The process of marking pictures for removal from the DPB may be referred to as reference picture set (RPS) management.

As described above, intra-frame prediction data or inter-frame prediction data is used to generate reference sample values for a block of sample values. Differences between sample values included in the current PB or another type of picture region structure and associated reference samples (eg, those generated using prediction) may be referred to as residual data. The residual data may include a respective array of difference values corresponding to each component of the video data. Residual data may be in the pixel domain. Transforms such as discrete cosine transforms (DCTs), discrete sine transforms (DSTs), integer transforms, wavelet transforms, or conceptually similar transforms may be applied to the difference array to generate transform coefficients. It should be noted that in ITU-T H.265, JVET-N1001 and JVET-O2001, a CU is associated with a Transform Unit (TU) structure having its root at the CU level. That is, to generate transform coefficients, the array of difference values may be divided (eg, four 8x8 transforms may be applied to a 16x16 array of residual values). For each component of video data, such subdivision of the difference may be referred to as a transform block (TB). It should be noted that, in some cases, a core transform and subsequent secondary transforms may be applied (in a video encoder) to generate transform coefficients. For video decoders, the order of transforms is reversed.

The quantization process may be performed directly on the transform coefficients or residual sample values (eg, in the case of palette-coded quantization). Quantization approximates transform coefficients by limiting the amplitude to a specified set of values. Quantization essentially scales transform coefficients in order to change the amount of data required to represent a set of transform coefficients. Quantization may include dividing the transform coefficients (or values resulting from adding an offset value to the transform coefficients) by the quantization scaling factor and any associated rounding function (eg, rounding to the nearest integer). The quantized transform coefficients may be referred to as coefficient scale values. Inverse quantization (or "dequantization") may include multiplying the coefficient scale value by the quantization scaling factor, as well as any reciprocal rounding or offset addition operations. It should be noted that, as used herein, the term quantization process may refer to dividing by a scale factor in some cases to generate a scale value, and in some cases to multiplying by a scale factor to restore transform coefficients. That is, the quantization process may refer to quantization in some cases and inverse quantization in some cases. Furthermore, it should be noted that while in some of the examples below the quantization process is described with respect to arithmetic operations related to decimal notation, such description is for illustrative purposes and should not be construed as limiting . For example, the techniques described herein may be implemented in devices that use binary arithmetic or the like. For example, the multiplication and division operations described herein may be implemented using shift operations and the like.

The quantized transform coefficients and syntax elements (eg, syntax elements indicating an encoding structure of a video block) may be entropy encoded according to entropy encoding techniques. The entropy encoding process includes encoding syntax element values using a lossless data compression algorithm. Examples of entropy coding techniques include Content Adaptive Variable Length Coding (CAVLC), Context Adaptive Binary Arithmetic Coding (CABAC), Probability Interval Partitioning Entropy Coding (PIPE), and the like. The entropy-encoded quantized transform coefficients and corresponding entropy-encoded syntax elements may form a compliant bitstream that may be used to reproduce video data at a video decoder. An entropy coding process, such as CABAC, may include binarizing syntax elements. Binarization refers to the process of converting the value of a syntax element into a sequence of one or more bits. These bits may be called "bins". Binarization may include one or a combination of the following encoding techniques: fixed-length encoding, unary encoding, truncated unary encoding, truncated Rice encoding, Golomb encoding, k-order exponential Golomb encoding, and Golomb-Rice encoding. For example, binarization may include representing the integer value 5 of the syntax element as 00000101 using an 8-bit fixed-length binarization technique, or representing the integer value 5 as 11110 using a unary coding binarization technique. As used herein, the terms fixed-length encoding, unary encoding, truncated unary encoding, truncated Rice encoding, Golomb encoding, k-order exponential Golomb encoding, and Golomb-Rice encoding may each refer to general implementations of these techniques and/or to these encoding techniques more specific implementation. For example, Golomb-Rice coding implementations may be specifically defined according to video coding standards. In the example of CABAC, for a particular bin, the context provides the maximum probability state (MPS) value of the bin (that is, the bin's MPS is one of 0 or 1), and the probability that the bin is the MPS or the minimum probability state (LPS) value. For example, the context may indicate that the MPS of a bin is 0, and the probability that a bin is 1 is 0.3. It should be noted that the context may be determined based on the values of previously encoded bins including bins in the current syntax element and/or previously encoded syntax elements. For example, the values of syntax elements associated with neighboring video blocks may be used to determine the context of the current bin.

2A-2B are conceptual diagrams illustrating an example of encoding a block of video data. As shown in FIG. 2A, scale values are generated for a current block of video data (eg, corresponding to CB) of the video component is encoded. As shown in Figure 2B, the current block of video data is decoded by performing inverse quantization on the scale values, performing an inverse transform, and adding a set of predicted values to the resulting residual. It should be noted that in the example of Figures 2A-2B, the sample values of the reconstructed block are different from the sample values of the current video block being encoded. Specifically, Figure 2B shows the reconstruction error, which is the difference between the current block and the reconstructed block. In this way, the encoding can be considered lossy. However, the difference in sample values may be considered acceptable or imperceptible to a viewer of the reconstructed video.

Additionally, as shown in Figures 2A-2B, the coefficient scale values are generated using an array of scaling factors. In ITU-T H.265, an array of scaling factors is generated by selecting a scaling matrix and multiplying each entry in the scaling matrix by a quantized scaling factor. In ITU-T H.265, scaling matrices are selected based in part on prediction mode and color components, where scaling matrices of the following sizes are defined: 4x4, 8x8, 16x16, and 32x32. It should be noted that in some examples, the scaling matrix may provide the same value for each entry (ie, scaling all coefficients according to a single value). In ITU-T H.265, the value of the quantization scaling factor may be determined by the quantization parameter QP. In ITU-T H.265, for a bit depth of 8 bits, the QP can take 52 values from 0 to 51, a QP change of 1 typically corresponds to about a 12% change in the value of the quantization scaling factor. Furthermore, in ITU-T H.265, a predicted quantization parameter value (which may be referred to as a predicted QP value or QP prediction value) and optionally a signaled quantization parameter increment value (which may be referred to as a QP increment) may be used. magnitude or delta QP value) to derive QP values for a set of transform coefficients. In ITU-T H.265, quantization parameters may be updated for each CU, and corresponding quantization parameters may be derived for each of the luma and chroma channels.

As described above, with respect to the examples shown in Figures 2A-2B, the sample values of the reconstructed block may be different from the sample values of the encoded current video block. Additionally, it should be noted that, in some cases, encoding video data block by block may result in artifacts (eg, so-called block artifacts, band artifacts, etc.). For example, blocking artifacts may cause encoded block boundaries of reconstructed video data to be visually perceptible by a user. In this way, the reconstructed sample values may be modified to minimize differences between the encoded sample values of the current video block and the reconstructed block and/or to minimize artifacts introduced by the video encoding process. Such modifications may generally be referred to as filtering. It should be noted that filtering may occur as part of an in-loop filtering process or a post-loop filtering process. For an in-loop filtering process, the resulting sample values of the filtering process may be used to predict the video block (eg, stored to a reference frame buffer for subsequent encoding at the video encoder and subsequent decoding at the video decoder). For a post-loop filtering process, the resulting sample values of the filtering process are output only as part of the decoding process (eg, not used for subsequent encoding). For example, in the case of a video decoder, for an in-loop filtering process, the sample values produced by filtering the reconstructed block will be used for subsequent decoding (eg, stored to a reference buffer) and will be output (eg, to a display). For the post-loop filtering process, the reconstructed block will be used for subsequent decoding, and the sample values resulting from filtering the reconstructed block will be output.

Deblocking (or deblocking), deblocking filtering, or applying a deblocking filter refers to the process of smoothing the boundaries of adjacent reconstructed video blocks (ie, making the boundaries less perceptible to an observer). Smoothing the boundaries of adjacent reconstructed video blocks may include modifying sample values included in rows or columns of adjacent boundaries. ITU-T H.265 provides scenarios where a deblocking filter is applied to reconstructed sample values as part of an in-loop filtering process. ITU-T H.265 includes two types of deblocking filters that can be used to modify luma samples: Strong Filter (strong filter), which modifies sample values in three rows or columns adjacent to the boundary; Weak Filter ( Weak filter) that modifies the sample values in the row or column immediately adjacent to the boundary and conditionally modifies the sample values in the second row or column from the boundary. Additionally, ITU-T H.265 includes one type of filter that can be used to modify chroma samples: the normal filter.

In addition to applying deblocking filters as part of the in-loop filtering process, ITU-T H.265 also provides scenarios where Sample Adaptive Offset (SAO) filtering can be applied in the in-loop filtering process. In ITU-T H.265, SAO is the process of modifying deblocked sample values in a region by conditionally adding offset values. ITU-T H.265 provides two types of SAO filters that can be applied to CTBs: band offset or edge offset. For each of the band offset and edge offset, four offset values are included in the bitstream. For band offsets, the applied offsets depend on the amplitudes of the sample values (eg, the amplitudes are mapped to bands that are mapped to the four signaled offsets). For edge offsets, the offset applied depends on the CTB with one of the horizontal, vertical, first-diagonal, or second-diagonal edge classifications (eg, classifications are mapped to the four signaled offset).

Another type of filtering process involves so-called adaptive loop filters (ALFs). ALF using block-based adaptation is specified in JEM. In JEM, ALF is applied after the SAO filter. It should be noted that ALF can be applied to reconstructed samples independently of other filtering techniques. The process of applying the ALF specified in JEM at the video encoder can be summarized as follows: (1) each 2x2 block used to reconstruct the luminance component of the image is classified according to the classification index; (2) each classification index is derived (3) determine filtering decisions for luma components; (4) determine filtering decisions for chroma components; and (5) signal filter parameters (eg, coefficients and decisions).

的量化值来导出：According to the ALF specified in JEM, each 2x2 block is classified according to the classification index C, where C is an integer in the range 0 to 24 inclusive. According to the following formula, C is based on its directionality D as well as its activity

quantized value to derive:

水平方向、垂直方向和两个对角线方向的梯度使用1-D拉普拉斯计算，如下所示：where D and

The gradients in the horizontal, vertical, and two diagonal directions are calculated using 1-D Laplacian as follows:

where the indices i and j refer to the coordinates of the upper left sample in the 2x2 block, and R(i,j) refers to the reconstructed sample with coordinates (i,j).

The maximum and minimum values of the gradients in the horizontal and vertical directions can be set as:

And the maximum and minimum values of the gradients in the two diagonal directions can be set as:

In JEM, to derive the value of the directivity D, the maximum and minimum values are compared with each other and with two thresholds t ₁ and t ₂ :

Step 1. Set D to 0 if both g ^max _hv ≤ t ₁ ·g ^min _hv and g ^max _d0,d1 ≤t ₁ ·g ^min _d0,d1 are true.

Step 2. If g ^max _hv /g ^min _hv >g ^max _d0,d1 /g ^min _d0,d1 , continue from step 3; otherwise, continue from step 4.

Step 3. If g ^max _hv >t ₂ ·g ^min _hv , set D to 2; otherwise, set D to 1.

Step 4. If g ^max _d0,d1 >t ₂ ·g ^min _d0,d1 , set D to 4; otherwise, set D to 3.

In JEM, the activity value A is calculated as follows:

where A is further quantized to a range of 0 to 4 inclusive, and the quantized value is expressed as

As described above, applying the ALF specified in JEM at the video encoder involves deriving a set of filter coefficients for each class index and determining filtering decisions. It should be noted that the derivation of the set of filter coefficients and the determination of the filtering decision may be an iterative process. That is, the set of filter coefficients may be updated based on the filtering decisions, and the filtering decisions may be updated based on the updated set of filter coefficients, and this may be repeated multiple times. Additionally, video encoders may implement various specialized algorithms to determine sets of filter coefficients and/or determine filtering decisions. Regardless of how the set of filter coefficients is derived for each classification index and how the filtering decision is determined, the techniques described herein generally apply.

According to one example, the set of filter coefficients is derived by initially deriving a set of optimal filter coefficients for each classification index. By comparing the desired sample value (ie, the sample value in the source video) with the reconstructed sample value after applying the filtering, and by comparing the error between the desired sample value and the reconstructed sample value after performing the filtering Sum of squares (SSE) minimization to derive optimal filter coefficients. The best coefficients derived for each group are then used to perform basic filtering on the reconstructed samples in order to analyze the effect of the ALF. That is, the desired sample value, the reconstructed sample value before applying ALF, and the reconstructed sample value after performing ALF can be compared to determine the effect of applying ALF using the best coefficients.

Each reconstructed sample R(i,j) is filtered according to the specified ALF in JEM by determining the resulting sample value R'(i,j) according to the following formula, where L represents the filter length , and f(k,l) represents the decoded filter coefficients.

It should be noted that JEM defines three filter shapes (5x5 diamond, 7x7 diamond and 9x9 diamond). It should be noted that in JEM, a geometric transformation is applied to the filter coefficients f(k,l), depending on the gradient values: g _v , g _h , g _d1 , g _d2 , as provided in Table 1.

gradient value transform g_d2<g_d1 and g_h<g_v do not transform g_d2<g_d1 and g_v<g_h diagonal g_d1<g_d2 and g_h<g_v flip vertically g_d1<g_d2 and g_v<g_h rotate

Table 1

where the diagonal, vertical flip and rotation are defined as follows:

Diagonal line f _D (k,l)=f(l,k),

Vertical flip: f _v (k,l)=f(k,Kl–1)

Rotation: f _R (k,l)=f(Kl-1,k)

where K is the size of the filter, and 0≤k, 1≤K-l are the coefficient coordinates such that position (0,0) is in the upper left corner and position (K-l, K-l) is in the lower right corner.

JEM provides scenarios where up to 25 sets of luminance filter coefficients (ie, one for each possible class index) can be signaled. Thus, the best coefficient can be signaled for each class index that occurs in the corresponding image region. However, in order to optimize the amount of data required to signal the relationship between the filter coefficient set and the filter effect, rate-distortion (RD) optimization can be performed. For example, JEM provides scenarios where filter coefficients from adjacent class groups can be combined and signaled using an array that maps a set of filter coefficients to each class index. In addition, JEM also provides scenarios where temporal coefficient prediction can be used to signal coefficients. That is, JEM provides the scenario of predicting the filter coefficient set of the current picture based on the filter coefficient set of the reference picture by inheriting the set of filter coefficients for the reference picture. JEM also provides scenarios where a set of 16 fixed filters can be used to predict a set of filter coefficients for intra-predicted pictures. As mentioned above, the derivation of the set of filter coefficients and the determination of the filtering decisions may be an iterative process. That is, for example, the shape of the ALF may be determined based on how many sets of filter coefficients are signaled, and similarly, whether the ALF is applied to a region of the image may be based on the signaled set of filter coefficients and/or the shape of the filter . It should be noted that for an ALF filter, each component uses a set of sample values from the corresponding component as input and derives output sample values. That is, the ALF filter is applied to each component independently of the data in the other component. Furthermore, it should be noted that JVET-N1001 and JVET-O2001 specify deblocking filters, SAO filters and ALF filters, which can be described as generally based on deblocking provided in ITU-T H.265 and JEM filter, SAO filter and ALF filter.

A video sampling format (which may also be referred to as a chroma format) may define the number of chroma samples included in a CU relative to the number of luma samples included in the CU. For example, for the 4:2:0 sampling format, the sampling rate of the luma component is twice the sampling rate of the chroma components in both the horizontal and vertical directions. Thus, for a CU formatted according to the 4:2:0 format, the width and height of the sample array for the luma component is twice the width and height of each sample array for the chroma component. 3 is a conceptual diagram illustrating an example of coding units formatted according to a 4:2:0 sample format. Figure 3 shows the relative positions of chroma samples with respect to luma samples within a CU. As mentioned above, a CU is typically defined in terms of the number of horizontal and vertical luma samples. Thus, as shown in Figure 3, a 16x16 CU formatted according to the 4:2:0 sample format includes 16x16 samples for the luma component and 8x8 samples for each chroma component. Furthermore, in the example shown in Figure 3, the relative positions of chroma samples relative to luma samples of adjacent video blocks of a 16x16 CU are shown. For a CU formatted according to the 4:2:2 format, the width of the sample array for the luma component is twice the width of the sample array for each chroma component, but the height of the sample array for the luma component is equal to the height of the sample array for each chroma component The height of the sample array. Furthermore, for a CU formatted according to the 4:4:4 format, the sample array for the luma component has the same width and height as the sample array for each chroma component. 3, for luma samples, the sample line immediately above the video block may be referred to as reference line 0 (RL ₀ ), and the subsequent above-mentioned sample lines may be referred to as reference line 1 (RL ₁ ), reference line 2 ( RL ₂ ) and reference line 3 (RL ₃ ). Similarly, sample columns to the left of the current video block may be classified as reference lines in a similar manner (ie, the sample line immediately to the left of the video block may be referred to as reference line 0 (RL ₀ ).

It should be noted that for sample formats, such as 4:2:0 sample format, the chroma position type can be specified. That is, for a 4:2:0 sample format, for example, a horizontal offset value and a vertical offset value indicating relative spatial positioning may be specified for chroma samples relative to luma samples. Table 2 provides the definitions of HorizontalOffsetC and VerticalOffsetC for the 5 chroma position types provided in JVET-N1001 and JVET-O2001. In addition, FIGS. 4A to 4F show the chroma position types specified for the 4:2:0 sample format in JVET-N1001 and JVET-O2001.

ChromaLocType HorizontalOffsetC VerticalOffsetC 0 0 0.5 1 0.5 0.5 2 0 0 3 0.5 0 4 0 1 5 0.5 1

Table 2

Regarding the formulas used in this article, the following arithmetic operators can be used:

+addition

- Subtraction

* Multiplication, including matrix multiplication

x ^y exponentiation. Specify x as a power of y. In other contexts, such notation is used for superscript and is not intended to be interpreted as exponentiation.

/Integer division that truncates the result towards zero. For example, 7/4 and -7/-4 are truncated to 1, and -7/4 and 7/-4 are truncated to -1.

÷ is used to represent division in mathematical formulas when truncation or rounding is not intended.

x/y is used to represent division in mathematical formulas when it is not intended to truncate or round.

x%y modulus. The remainder of dividing x by y, defined only for integers x and y where x ≥ 0 and y > 0.

Additionally, the following logical operators can be used:

x&& y Boolean logical "and" of x and y

x||y Boolean logical OR of x and y

! boolean logic "no"

x? y:z Evaluates to y if x is TRUE or not equal to 0; otherwise, evaluates to z.

Additionally, the following relational operators can be used:

> greater than

≥ greater than or equal to

< less than

≤ less than or equal to

== equal to

! = not equal to

Additionally, the following bitwise operators can be used:

& bitwise "and". When operating on integer variables, operate on the two's complement representation of the integer value. When operating on a binary variable that contains fewer bits than another variable, the shorter variable is extended by adding more significant bits equal to 0.

|Bitwise OR. When operating on integer variables, operate on the two's complement representation of the integer value. When operating on a binary variable that contains fewer bits than another variable, the shorter variable is extended by adding more significant bits equal to 0.

^ Bit-wise XOR. When operating on integer variables, operate on the two's complement representation of the integer value. When operating on a binary variable that contains fewer bits than another variable, the shorter variable is extended by adding more significant bits equal to 0.

x >> y The two's complement integer representation of x is an arithmetic right shift by y bins. The function is only defined for non-negative integer values of y. The bits shifted into the most significant bit (MSB) due to the right shift have a value equal to the MSB of x before the shift operation.

x<<y The two's complement integer representation of x is an arithmetic left shift by y bits. The function is only defined for non-negative integer values of y. The bits shifted into the least significant bit (LSB) due to the left shift have a value equal to zero.

Additionally, the following assignment operators can be used:

= assignment operator

++ increments, ie, x++ is equivalent to x=x+1; when used in array indexing, the value of the variable is evaluated before the increment operation.

--decrement, ie, x-- is equivalent to x=x-1; when used in array indexing, the value of the variable is evaluated before the decrement operation.

+= increments by the specified amount, ie x+=3 is equivalent to x=x+3, and x+=(-3) is equivalent to x=x+(-3).

-= decrements by the specified amount, ie x-=3 is equivalent to x=x-3, and x-=(-3) is equivalent to x=x-(-3).

In addition, the mathematical functions defined below can be used:

Floor(x), the largest integer less than or equal to x.

Log2(x), the base-2 logarithm of x.

5 is a block diagram illustrating an example of a system that may be configured to encode (eg, encode and/or decode) video data in accordance with one or more techniques of this disclosure. System 100 represents an example of a system that may perform video encoding using the partitioning techniques described in accordance with one or more techniques of this disclosure. As shown in FIG. 5 , the system 100 includes a source device 102 , a communication medium 110 and a target device 120 . In the example shown in FIG. 5 , source device 102 may include any device configured to encode video data and transmit the encoded video data to communication medium 110 . Target device 120 may include any device configured to receive and decode encoded video data via communication medium 110 . Source device 102 and/or target device 120 may include computing devices equipped for wired and/or wireless communications, and may include set-top boxes, digital video recorders, televisions, desktops, laptops or tablets, game controls Stations, mobile devices include, for example, "smart" phones, cellular phones, personal gaming devices, and medical imaging devices.

Communication media 110 may include any combination of wireless and wired communication media and/or storage devices. Communication medium 110 may include coaxial cables, fiber optic cables, twisted pair cables, wireless transmitters and receivers, routers, switches, repeaters, base stations, or any other device that may be used to facilitate communication between various devices and sites . Communication medium 110 may include one or more networks. For example, communication medium 110 may include a network configured to allow access to the World Wide Web, such as the Internet. The network may operate according to a combination of one or more telecommunications protocols. Telecommunications protocols may include proprietary aspects and/or may include standardized telecommunications protocols. Examples of standardized telecommunications protocols include the Digital Video Broadcasting (DVB) standard, the Advanced Television Systems Committee (ATSC) standard, the Integrated Services Digital Broadcasting (ISDB) standard, the Data over Cable Services Interface Specification (DOCSIS) standard, the Global System for Mobile Communications (GSM) standard , Code Division Multiple Access (CDMA) standards, 3rd Generation Partnership Project (3GPP) standards, European Telecommunications Standards Institute (ETSI) standards, Internet Protocol (IP) standards, Wireless Application Protocol (WAP) standards, and the Institute of Electrical and Electronics Engineers (IEEE) standard.

A storage device may include any type of device or storage medium capable of storing data. Storage media may include tangible or non-transitory computer readable media. Computer-readable media may include optical disks, flash memory, magnetic memory, or any other suitable digital storage medium. In some examples, a memory device, or portions thereof, may be described as non-volatile memory, and in other examples, portions of a memory device may be described as volatile memory. Examples of volatile memory may include random access memory (RAM), dynamic random access memory (DRAM), and static random access memory (SRAM). Examples of non-volatile memory may include magnetic hard disks, optical disks, floppy disks, flash memory, or the form of electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Storage devices may include memory cards (eg, secure digital (SD) memory cards), internal/external hard drives, and/or internal/external solid state drives. Data can be stored on storage devices according to a defined file format.

Referring again to FIG. 5 , source device 102 includes video source 104 , video encoder 106 and interface 108 . Video source 104 may include any device configured to capture and/or store video data. For example, video source 104 may include a video camera and a storage device operably coupled thereto. Video encoder 106 may include any device configured to receive video data and generate a compatible bitstream representing the video data. A compatible bitstream may refer to a bitstream from which a video decoder can receive and reproduce video data. Aspects of a compliant bitstream may be defined according to a video coding standard. When generating a compatible bitstream, video encoder 106 may compress the video data. Compression may be lossy (perceptible or imperceptible) or lossless. Interface 108 may include any device configured to receive a compatible video bitstream and transmit and/or store the compatible video bitstream to a communication medium. The interface 108 may include a network interface card such as an Ethernet card, and may include an optical transceiver, a radio frequency transceiver, or any other type of device that can transmit and/or receive information. Additionally, interface 108 may include a computer system interface that may allow compatible video bitstreams to be stored on a storage device. For example, the interface 108 may include a chipset supporting the Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe) bus protocols, a proprietary bus protocol, a Universal Serial Bus (USB ⁾ protocol, I2C, or a chipset available for interconnection Any other logical and physical structure of the peer device.

Referring again to FIG. 5 , target device 120 includes interface 122 , video decoder 124 and display 126 . Interface 122 may include any device configured to receive a compatible video bitstream from a communication medium. The interface 108 may include a network interface card such as an Ethernet card, and may include an optical transceiver, a radio frequency transceiver, or any other type of device that can receive and/or transmit information. Additionally, interface 122 may include a computer system interface that allows retrieval of compatible video bitstreams from storage devices. For example, interface 122 may include a chipset supporting PCI and PCIe bus protocols, proprietary bus protocols, USB protocols, ^I2C , or any other logical and physical structure that may be used to interconnect peer devices. Video decoder 124 may include any device configured to receive a compatible bitstream and/or acceptable variants thereof, and reproduce video data therefrom. Display 126 may include any device configured to display video data. Display 126 may include one of various display devices such as a liquid crystal display (LCD), plasma display, organic light emitting diode (OLED) display, or another type of display. Display 126 may include a high definition display or an ultra high definition display. It should be noted that although in the example shown in FIG. 5, video decoder 124 is described as outputting data to display 126, video decoder 124 may be configured to output video data to various types of devices and/or or its subcomponents. For example, video decoder 124 may be configured to output video data to any communication medium, as described herein.

6 is a block diagram illustrating an example of a video encoder 200 that may implement the techniques described herein for encoding video data. It should be noted that although the example video encoder 200 is shown as having different functional blocks, such illustration is intended for descriptive purposes and does not limit the video encoder 200 and/or its sub-components to a particular hardware or software architecture. The functions of video encoder 200 may be implemented using any combination of hardware, firmware and/or software implementations. In one example, video encoder 200 may be configured to encode video data according to the techniques described herein. Video encoder 200 may perform intra- and inter-predictive encoding of picture regions, and thus may be referred to as a hybrid video encoder. In the example shown in Figure 6, video encoder 200 receives source video blocks. In some examples, source video blocks may include picture regions that have been partitioned according to coding structures. For example, source video data may include macroblocks, CTUs, CBs, sub-partitions thereof, and/or other equivalent coding units. In some examples, video encoder 200 may be configured to perform additional subdivisions of source video blocks. It should be noted that some of the techniques described herein are generally applicable to video encoding regardless of how the source video data is partitioned before and/or during encoding. In the example shown in FIG. 6, the video encoder 200 includes a summer 202, a transform coefficient generator 204, a coefficient quantization unit 206, an inverse quantization/transform processing unit 208, a summer 210, an intra prediction processing unit 212, Inter prediction processing unit 214 , filter unit 216 , and entropy encoding unit 218 .

As shown in FIG. 6, video encoder 200 receives source video blocks and outputs a bitstream. Video encoder 200 may generate residual data by subtracting the prediction video block from the source video block. Summer 202 represents a component configured to perform this subtraction operation. In one example, the subtraction of video blocks occurs in the pixel domain. Transform coefficient generator 204 applies a transform, such as a Discrete Cosine Transform (DCT), Discrete Sine Transform (DST), or conceptually similar transform, to its residual block or sub-partition (eg, may Four 8x8 transforms are applied to the 16x16 residual value array) to generate a set of residual transform coefficients. Transform coefficient generator 204 may be configured to perform any and all combinations of transforms included in the series of discrete triangular transforms. As mentioned above, in ITU-T H.265, TB is restricted to the following sizes 4×4, 8×8, 16×16 and 32×32. In one example, transform coefficient generator 204 may be configured to perform transforms from arrays of size 4x4, 8x8, 16x16, and 32x32. In one example, transform coefficient generator 204 may be further configured to perform transforms from arrays of other sizes. Specifically, in some cases it may be useful to perform transformations on rectangular arrays of different values. In one example, transform coefficient generator 204 may be configured to perform transforms according to the following array sizes: 2x2, 2x4N, 4Mx2, and/or 4Mx4N. In one example, a two-dimensional (2D) M×N inverse transform can be implemented as a one-dimensional (1D) M-point inverse transform followed by a 1D N-point inverse transform. In one example, the 2D inverse transformation can be implemented as a 1D N-point vertical transformation followed by a 1D N-point horizontal transformation. In one example, the 2D inverse transformation can be implemented as a 1D N-point horizontal transformation followed by a 1D N-point vertical transformation. Transform coefficient generator 204 may output the transform coefficients to coefficient quantization unit 206 .

Coefficient quantization unit 206 may be configured to perform quantization of transform coefficients. As mentioned above, the degree of quantization can be modified by adjusting the quantization parameter. Coefficient quantization unit 206 may be further configured to determine quantization parameters and output QP data (eg, data used to determine quantization group sizes and/or delta QP values), which may be used by the video decoder to reconstruct the quantization parameters to Inverse quantization is performed during video decoding. It should be noted that in other examples, one or more additional or alternative parameters may be used to determine the quantization scale (eg, scaling factor). The techniques described herein are generally applicable to determining the quantization scale of transform coefficients corresponding to a component of video data based on the quantization scale of transform coefficients corresponding to another component of video data.

Referring again to FIG. 6 , the quantized transform coefficients are output to the inverse quantization/transform processing unit 208 . Inverse quantization/transform processing unit 208 may be configured to apply inverse quantization and inverse transform to generate reconstructed residual data. As shown in FIG. 6, at summer 210, reconstructed residual data may be added to the predicted video block. In this way, an encoded video block can be reconstructed, and the resulting reconstructed video block can be used to evaluate the encoding quality for a given prediction, transform, and/or quantization. Video encoder 200 may be configured to perform multiple encoding passes (eg, while changing one or more of prediction, transform parameters, and quantization parameters). The rate-distortion or other system parameters of the bitstream can be optimized based on the evaluation of the reconstructed video blocks. Additionally, reconstructed video blocks may be stored and used as references for predicting subsequent blocks.

As described above, video blocks may be encoded using intra prediction. Intra-prediction processing unit 212 may be configured to select an intra-prediction mode for a video block to be encoded. Intra-prediction processing unit 212 may be configured to evaluate the frame and/or regions thereof and determine an intra-prediction mode to use to encode the current block. As shown in FIG. 6 , intra-prediction processing unit 212 outputs intra-prediction data (eg, syntax elements) to entropy encoding unit 218 and transform coefficient generator 204 . As mentioned above, the transformation performed on the residual data may depend on the mode. As described above, possible intra prediction modes may include planar prediction mode, DC prediction mode and angular prediction mode. Furthermore, in some examples, prediction for chroma components may be inferred from intra prediction for luma prediction mode. Inter-prediction processing unit 214 may be configured to perform inter-prediction encoding for the current video block. Inter-prediction processing unit 214 may be configured to receive a source video block and calculate motion vectors for PUs of the video block. The motion vector may indicate the displacement of the PU (or similar coding structure) of the video block within the current video frame relative to the prediction block within the reference frame. Inter-predictive coding may use one or more reference pictures. Furthermore, motion prediction can be unidirectional prediction (using one motion vector) or bidirectional prediction (using two motion vectors). Inter-prediction processing unit 214 may be configured to select a prediction block by calculating pixel differences determined by, for example, Sum of Absolute Differences (SAD), Sum of Squared Differences (SSD), or other difference metrics. As described above, motion vectors can be determined and specified from motion vector prediction. As described above, inter-prediction processing unit 214 may be configured to perform motion vector prediction. Inter prediction processing unit 214 may be configured to generate prediction blocks using motion prediction data. For example, inter-prediction processing unit 214 may locate a predicted video block (not shown in FIG. 6 ) within a frame buffer. It should be noted that inter-prediction processing unit 214 may be further configured to apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values for motion estimation. Inter-prediction processing unit 214 may output motion prediction data for the calculated motion vector to entropy encoding unit 218 . As shown in FIG. 6 , inter-prediction processing unit 214 may receive reconstructed video blocks via filter unit 216 . Entropy encoding unit 218 receives the quantized transform coefficients and prediction syntax data (ie, intra prediction data, motion prediction data, QP data, etc.). It should be noted that, in some examples, coefficient quantization unit 206 may perform a scan of a matrix including quantized transform coefficients before outputting the coefficients to entropy encoding unit 218 . In other examples, entropy encoding unit 218 may perform scanning. Entropy encoding unit 218 may be configured to perform entropy encoding according to one or more of the techniques described herein. Entropy encoding unit 218 may be configured to output a compatible bitstream (ie, a bitstream from which a video decoder may receive and reproduce video data).

Referring again to FIG. 6, filter unit 216 may be configured to perform deblocking filtering, sample adaptive offset (SAO) filtering, and/or ALF filtering as described above. Additionally, filter unit 216 may be configured to perform one or more of the techniques described herein for reducing reconstruction error based on cross-component correlation. As mentioned above, for the ALF filter in JEM, each component uses a set of sample values from the corresponding component as input, and the output sample values are derived in a manner independent of the other components. Filtering by components independently may not be ideal because there may be correlations between components and/or channels of video data that can be used to minimize reconstruction errors. For example, referring to Figure 8, which shows an 8x8 luma source block and a corresponding 4x4 chroma source block (ie, according to the 4:2:0 sampling format) and the corresponding reconstructed block and reconstruction error Example. As shown in Figure 8, these two source blocks include edges around the diagonal, which would be typical in the case of textures, shape edges, etc. However, for reconstructed chroma components, fidelity is lost (eg, due to a high level of quantization, etc.), and edges are not recovered compared to the luma component.

In accordance with the techniques herein, a filter unit may be configured to predict and/or refine information in the first color channel and/or component from information in the second color channel and/or component, which may provide the first color channel and/or the Improved coding efficiency of/or components because the fidelity of color channels and/or components is increased with a small number of bits. 7 illustrates an example of a cross-component filter unit that may be configured to encode video data in accordance with one or more techniques of this disclosure. As shown in FIG. 7 , the cross component filter unit 300 includes a filter determination unit 302 and a sample modification unit 304 . It should be noted that cross component filter unit 300 shows an example of a cross component filter unit that may be present in a video encoder. Examples of corresponding cross-component filter units that may be present in a video decoder are described in more detail below. As shown in FIG. 7, filter determination unit 302 and sample modification unit 304 may receive encoding parameter information (eg, intra prediction mode) available when the current block is encoded/decoded, and as shown in FIG. 7, in video encoding The video block data at the processor may include: cross component source block; cross component reconstruction block; cross component reconstruction error; current component source block; current component reconstruction block; and current component reconstruction error. That is, referring to the example shown in FIG. 8, all the information in FIG. 8 is available at the cross component filter unit 300 when the chroma reconstruction block is to be filtered. Accordingly, filter determination unit 302 may derive filters to be used on the chroma reconstruction block based on the video data, and sample modification unit 304 may perform filtering according to the derived filters. As shown in FIG. 7, sample modification unit 304 may output the modified reconstructed block to a reference picture buffer (ie, as a loop filter), and output the modified reconstructed block to an output (eg, a display) ). Furthermore, as shown in FIG. 7 , the filter determination unit 302 may output filter data. That is, filter data specifying the derived filter may be signaled to the video decoder. Examples of such signaling are described in further detail below. It should be noted that with respect to FIG. 8, there may be several ways of reducing reconstruction error at the video encoder, eg, reducing quantization and/or performing improved prediction techniques. Furthermore, in some cases, the video encoder may directly signal the reconstruction error. However, cross-component filtering in accordance with the techniques herein provides a way to signal a relatively small amount of information while reducing reconstruction errors. That is, for example, the cross-component filtering techniques described herein may provide a way to reduce reconstruction error at a video decoder while being more effective than other techniques for reducing reconstruction error. For example, signaling filter data may cost fewer bits than signaling higher fidelity residual information for components.

Thus, the cross component filter unit 300 may operate by taking as input a first color component and one or more second color components, and provide an enhanced first color component as output. It should be noted that although the examples herein are described with respect to luma, Cb, and Cr components, the techniques described herein are generally applicable to other video formats (eg, RGB) and other types of video information such as infrared, depth, Parallax or other features.

The following formulas provide an example of a model for a filter that takes as input sample values from multiple components and outputs filtered sample values f _i (x,y), thus, in one example, a cross-component filter The unit 300 can implement the filtering process based on this formula.

in,

f _i (x,y)

is the output of component i at sample position (x,y);

S _i,0 ; S _i1 ; and S _i,2 : define a set of sample value positions relative to the origin in the corresponding points 0, 1, 2;

g(x,y,i,0) and h(x,y,i,0), g(x,y,i,1) and h(x,y,i,1), g(x,y, i,2) and h(x,y,i,2): Determine the supported origin based on x, y, i and input components. The functions g(), h() may also depend on chroma format, chroma position type, gamut, filter shape;

c ₀ (x ₀ , y ₀ ), c ₁ (x ₀ , y ₀ ) and c ₂ (x ₀ , y ₀ ): are the filter coefficient values for the support region of each component;

I ₀ , I ₁ and I ₂ : are the input sample values from each component; and

I _i (x, y): is the sample value of component i at sample position (x, y) before filtering.

Thus, in accordance with the techniques herein, cross component filter unit 300 may be configured to reduce the current component by adding refinement to the reconstructed sample values of the current component based on a derived filter function that takes as input the reconstructed sample values of the other components Component reconstruction error. In one example, the reconstructed sample values of other components used as input may be referred to as filter support. 9A-9F are conceptual diagrams illustrating examples of support samples that may be used for cross-component filtering in accordance with one or more techniques of this disclosure. In the examples shown in Figures 9A to 9F, for each of the 4:2:0 sample format chroma position types provided in JVET-N1001 and JVET-O2001, the chroma used for filtering is shown The brightness of the sample supports the sample. That is, 5x5, 5x6, 6x5, and/or 6x6 support samples may be used. It should be noted that in the examples of Figures 9A-9F, the luma support is defined to be symmetric with respect to the chroma sample values. It should be noted that in other examples, the luma support may undergo a phase shift that is dependent on the chroma position type before being input to a filtering stage that is independent of the chroma position type. As described in further detail below, for each support sample, filter coefficients may be determined and signaled. In one example, according to the techniques herein, for chroma samples included in a video block, the supported relative positions for each sample may be based on the sample format. For example, in one example, according to the techniques herein, for a 4:2:0 sample format, when a chroma sample in a video block at a chroma position (x _C , y _C ) corresponds to an origin at a luma position (x _L , y C ) y _L ), the origin of the support for the chroma samples at chroma position (x _C +m,y _C +n) in this video block may be at luma position (x _C +2m,y _C + 2n); for the 4:2:2 sample format, when the chroma sample at the chroma position (x _C , y _C ) in the video block corresponds to the support of the origin at the luma position (x _L , y _L ), The supported origin for chroma samples at chroma position (x _C +m, y _C + n) in this video block may be at luma position (x _C +2m, y _C +n); and for 4: 4:4 sample format, used for color in a video block when the chroma samples at the chroma position (x _C , y _C ) in the video block correspond to the support of the origin at the luma position (x _L , y _L ) The supported origin of the chroma samples at the degree position (x _C +m, y _C +n) may be at the luma position (x _C +m, y _C +n). It should be noted that in this example, the offset of the chroma sample position corresponds to the offset of the luma position of the supported origin, where the ratio between the two offsets is based on the chroma format.

In one example, in accordance with the techniques herein, the application of cross-component filtering may be based on properties of samples included in the filter support region. For example, in one example, luma sample values in the support region can be analyzed, and whether to apply cross-component filtering can be determined based on the analysis. For example, in one example, the variance and/or bias of the samples in the support region can be calculated, and if the variance and/or bias has certain characteristics, eg, the region is smooth (ie, the variance is less than a threshold), then the variance and/or bias can be calculated No cross component filtering is applied to this region. In one example, the cross-component filter selection (including whether and when to apply the filter, and which filter to apply) may be based on the luma classification filter index of the luma sample corresponding to the evaluated chroma sample. In one example, the classification filter index for luma samples can be derived as described in JVET-O2001. In one example, cross component filtering may not be applied when it is determined that the luma classification filter index is in a subset of the luma classification filter indexes. As described in further detail below, the value of the local region control flag and/or syntax element may be used to indicate/determine whether to apply cross-component filtering for the region, and if so, which cross-component filter to apply. In one example, the application of cross-component filtering may control the values of flags and/or syntax elements based on attributes of the samples included in the filter support region and/or local region control flags. That is, for example, how luma support samples are analyzed may control flags and/or syntax elements based on local regions (eg, if flag == 0, compute/evaluate variance, otherwise compute/evaluate luma classification filter indices). Furthermore, in one example, the filter selection is based on the value of the syntax element and the properties of the luma support samples. For example, a syntax element with a value of 0 may indicate that cross-component filtering is not applied to the region, a syntax element with a value of 1 and a variance of luma support greater than a threshold may indicate that a filter with the first set of filter coefficients is applied, and the syntax element with a value of 1 1 and the variance of the luma support is not greater than the threshold may indicate that the filter with the second set of filter coefficients is applied, the value of the syntax element is 2 and the variance of the luma support is greater than the threshold may indicate the application of the filter with the third set of filter coefficients, A syntax element with a value of 2 and a variance of luma support not greater than a threshold may indicate that a filter with a fourth set of filter coefficients is applied, and so on.

An example of a dataset corresponding to an implementation of the cross-component filter described herein is provided in the appendix herein. That is to say, in the appendix, the data set orgBlock represents the sample value of the original 32×32U component block; the data set preFilteringBlock represents the sample value of the reconstructed 32×32U component block; the data set orgError represents the original 32×32U component block and the repeated The reconstruction error between the reconstructed 32×32U component blocks; the dataset bestSupportY represents the sample value of the 67×68Y component block, which provides filter support for the filtered and reconstructed 32×32U component block; the dataset bestSupportU represents 36 The sample value of the ×36U component block, which provides support for the filtered and reconstructed 32×32U component block; the data set bestSupportV represents the sample value of the 36×36UV component block, which is the filtered and reconstructed 32×32U component block. Provide support; dataset coeffY represents filter coefficients in a 5x6 filter of sample values for a 67x68Y component support block; dataset coeffU represents a 5x5 filter of sample values for a 36x36U component support block filter coefficients in the filter; dataset coeffU represents the filter coefficients in the 5×5 filter for the sample values of the 36×36V component support block; dataset bestOutput represents the filtered samples of the reconstructed 32×32U component block value; dataset bestError represents the error between the original 32x32U component block and the filtered reconstructed 32x32U component block; dataset signedimprovement is equal to Abs(orgError)-Abs(bestError) and represents the reconstruction resulting from filtering The change in error; and the dataset positive improve represents the reconstructed sample values for which the reconstruction error is reduced due to filtering. Thus, in accordance with the techniques herein, the reconstruction error of one or more or most of the samples may be reduced by applying a cross-component filter. It should be noted that for certain types of video content, the amount of reconstruction error improved according to the mathematical relationship may have different consequences based on how the perceived visual quality of the video is improved. That is, for example, a relatively small signedimprovement value can result in a relatively significant improvement in visual quality.

As described above, the cross component filter unit 300 is generally operable by taking as input a first color component and one or more second color components, and providing an enhanced first color component as an output. That is, the filtering process performed by the cross-component filter unit 300 may take input luma sample values as input luma sample values that can be used to predict the difference between the original corresponding chroma sample values and based on the Predict to output refined chroma sample values. Referring again to the example shown in FIG. 8 , FIG. 10 is a conceptual diagram illustrating an example of reducing reconstruction error using cross-component filtering in accordance with one or more techniques of the present disclosure. Figure 10 provides an example in which the reconstruction error is reduced by taking the mean of the support samples and adding the mean divided by 10 to the reconstructed samples if the mean is greater than 90; and if the mean is greater than 90 Values not greater than 90, subtract the mean from the reconstructed samples and divide by 10. That is, in this example, the prediction filter is generally described as: if the support mean is greater than threshold1, then add weight1 times the support mean; otherwise, add weight2 times the support mean. As shown in the example shown in Figure 10, post-filtering the chroma reconstruction error provides reconstruction error reduction. Thus, according to the techniques herein, cross-component filtering may reduce reconstruction errors in terms of cross-component filters defined in terms of logistic functions, thresholds, weights, and the like.

As mentioned above, JVET-N1001 and JVET-O2001 include deblocking filters, SAO filters, and ALF filters, and the cross-component filter techniques described herein can be implemented as various points in the filter chain. That is, for example, performed at various stages of loop filtering. 11A-11D are block diagrams illustrating examples of cross-component filter units that may be configured to reduce reconstruction error in accordance with one or more techniques of the present disclosure. In Figures 11A-11D, luma SAO filter unit 402 represents a filter unit configured to perform SAO filtering (eg, SAO filtering provided in JVET-N1001 or JVET-O2001) on luma sample values Y; Cb SAO filter Unit 404 represents a filtering unit configured to perform SAO filtering (eg, SAO filtering provided in JVET-N1001 or JVET-O2001) on chroma Cb sample values; Cb SAO filter unit 406 represents a filter unit configured to perform SAO filtering on Cb sample values A filtering unit for SAO filtering (eg, SAO filtering provided in JVET-N1001 or JVET-O2001); luma ALF filter unit 408 represents a filtering unit configured to perform ALF filtering on luma sample value Y (eg, JVET-N1001 or JVET-O2001 ALF filtering provided in); chroma ALF filter unit 410 represents a filtering unit configured to perform ALF filtering (eg, ALF filtering provided in JVET-N1001 or JVET-O2001) on chroma sample values; luma Deblocking filter unit 416 represents a filtering unit configured to perform deblocking filtering (eg, as provided in JVET-N1001 or JVET-O2001) on luma sample values Y; Cb deblocking filter unit 418 represents a filtering unit configured is a filtering unit that performs deblocking filtering (eg, deblocking filtering provided in JVET-N1001 or JVET-O2001) on Cb sample values; and Cr deblocking filter unit 420 represents a filter unit configured to perform deblocking filtering on Cr sample values A filtering unit (eg, deblocking filtering provided in JVET-N1001 or JVET-O2001). Furthermore, in FIGS. 11A-11D , Cb cross component filter unit 412 represents an example of a cross component filter configured to generate a Cb refinement ΔCb according to one or more of the techniques described herein; and Cr cross Component filter unit 414 represents an example of a cross-component filter configured to generate a Cr refinement ΔCr according to one or more of the techniques described herein. Thus, as shown in FIGS. 11A-11D , cross-component filtering in accordance with the techniques herein may be applied as various points in the filter chain. That is, cross-component filtering inputs may be received at various points in the filtering chain, and cross-component filtering refinements may be output at various points in the filtering chain. It should be noted that in the example shown in Figure 1 IB, the input of the luma deblocking is used as the input for filtering, which may have the advantage of reducing line buffer requirements. It should be noted that in the example shown in Figure 11C, the output of the luma deblocking is used as the input for filtering, which may have the advantage of reducing line buffer requirements while slightly improving coding efficiency. It should be noted that in the example shown in Figure 1 ID, the output of the ALF luma is used as the input for filtering, which may have the advantage of improved coding efficiency.

Additionally, the cross-component filter techniques described herein may also include performing clipping operations at various points in the filter chain. That is, for example, performed at various stages of the loop filter. 12A-12B are block diagrams illustrating examples of cross-component filter units that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure. In Figures 12A-12B, the commonly numbered elements were described above with respect to Figures 11A-11B, and clipping units 422A-422D may be configured to perform a clipping function based on the output bit depth of the respective components, eg Clip3(0,2 ^BitDepthC -1,*). It should be noted that clipping units 422A-422D may be selectively enabled based on whether a particular type of filtering is performed.

13A-13B are block diagrams illustrating examples of cross-component filter units that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure. 13A-13B further illustrate that cross-component filtering in accordance with the techniques herein may be applied to various points in the filtering chain. In Figures 13A-13C, the commonly numbered elements are as described above.

Furthermore, it should be noted that in some cases there may be more than 3 video data components, eg YUV+depth. The cross-component filtering techniques described herein are generally applicable to these situations. In some cases, preprocessing of the input sample values from each component may be performed prior to the filtering operation. For example, input sample values can be clipped. Furthermore, in one example, the clipping range may vary for each coefficient and may be signaled in the bitstream. It should be noted that, in some examples, the following formulas provide options for preprocessing input sample values:

I _j (g(x, y, i, j)+x _j , h(x, y, i, j)+y _j )

=min(a,max(b, _I'j (g(x,y,i,j)+ _xj ,(x,y,i, _j )+yj)-derivedValue))

Additionally, another option for preprocessing input sample values can be as follows:

I _j (g(x, y, i, j)+x _j , (x, y, i, j)+y _j )

=derivedValue+min(a, max(b, I′ _j (g(x, y, i, j)+x _j , h(x, y, i, j)+y _j )-derivedValue))

in,

I' _j (u, v): sample value at position (u, V) before processing

derivedValue: is a value derived from a subset of the values in I', (*, *), e.g. (a) _Ij (g(x,y,i,j)+0,h(x,y) at the origin , i, j)+0), around the origin is (b)

a: is the value received in the bitstream/value inferred from the data received in the bitstream/value derived from a subset of the values in _I'j (*,*), and

b: is the value received in the bitstream/value inferred from the data received in the bitstream/value derived from a subset of the values in _I'j (*,*)

In one example, b can be derived from a (eg, b=-a) to reduce the amount of signaling required.

Furthermore, in one example, a generalization of the input used in the cross component filter operation can be as follows:

where Gn( ) is a function for combining sample values from the components and obtaining a derived value corresponding to each coefficient value with index (x _cj , y _cj ). The function G _i ( ) may depend on the chroma format, chroma position type, gamut, filter shape

In one example, cross-component filtering may be performed according to: defining a support region for luma; for 4:2:0, up-sampling with 2X chroma components for use as input; Subtract the derived value (e.g., 512 for 10-bit chroma, or the local average) from the support of The product is used as one of the inputs to the filtering operation.

Furthermore, it should be noted that, in some examples, the cross-component filtering techniques described herein may be performed on predictions or residuals. In one example, if domain coding is used instead of progressive coding, samples are supported for luma: in one example, sample values from one of the corresponding luma domains can be used, and in another example, samples from Sample values for the two luminance domains.

As described above, for each support sample, filter coefficients may be determined and signaled. That is, for example, 5x5, 5x6, 6x6, and/or 6x6 filter coefficients may be signaled. 14A-14C show examples of signaling filter coefficients for a 5x5 filter. 14D-14F show examples of signaling filter coefficients for a 5x6 (and similarly, 6x5) filter. 15A-15D illustrate examples of signaling filter coefficients for a 6x6 filter. In each of Figures 14A-15D, the corresponding filter coefficients of the filters are indicated by _CN . Therefore, in the case of multiple locations where the same filter is provided to the same C value, the filter coefficients are the same, ie shared. In this way, the number of filter coefficients signaled for the filter is reduced. For example, in Figure 14D, 14 filter coefficients are signaled for 18 support positions.

In one example, it may be desirable to limit the number of line buffers within an architecture that processes samples per CTU. That is, for example, a virtual line boundary provides each CTU with a location where samples above the horizontal VB can be processed before the lower CTU enters, but samples below the horizontal VB cannot be processed until the lower CTU becomes available. JVET-N1001 and JVET-O2001 define horizontal virtual line boundaries (VB) for luminance ALF and luminance SAO. According to the techniques herein, this VB can be reused for the luma input-chroma output filters defined herein. Furthermore, the luminance straight VB may be reused for the vertical luminance input-chroma output filter defined herein, and/or a subset of VB may be reused for the luminance input-chrominance output filter defined herein. Furthermore, there are two defined cases for which support samples in the luma component can be derived/modified: when a predetermined luma sample (corresponding to eg a chroma sample decoded based on a chroma position type) is above VB and when spanning VB is supported; and when predetermined luma samples (corresponding to, for example, chroma samples decoded based on chroma position type) are below VB and spanning VB is supported. In one example, the predetermined samples are samples at positions corresponding to coefficient C6 of the 5x6 luma support shown in Figure 14D. 16A-16D are conceptual diagrams illustrating examples of virtual line buffers that may be used for cross-component filtering in accordance with one or more techniques of this disclosure. In Figure 16A, the samples below the horizontal VB are obtained by duplicating the samples above and closest to the virtual line boundary and in the same column. In Figure 16B, the samples below the horizontal VB are obtained by duplicating the samples below and closest to the virtual line boundary and in the same column. In one example, luminance VB is four samples from the horizontal CTU boundary. In one example, each CTU, SAO and ALF can process samples on the left side of the vertical VB before the right CTU enters, but cannot process samples on the right side of the vertical VB until the right CTU is available. Exemplary modifications when supporting vertical virtual boundaries (VBs) are shown in Figures 16C-16D. In Figure 16C, the samples to the right of the vertical VB are obtained by duplicating the samples to the left and closest to the virtual line boundary and in the same row. In Figure 16D, the samples to the left of the vertical VB are obtained by duplicating the samples to the right and closest to the virtual line boundary and in the same row. In one example, luminance VB is four samples from vertical CTU boundaries. In one example, a vertical axis and a horizontal axis passing through the center of the support region may be considered relative to generating samples for horizontal VBs according to the techniques herein. A replicated sample can be obtained by replicating in a column samples that are the same distance from the vertical axis but on opposite sides of the vertical axis. In one example, replicated samples may be replicated from rows that are the same distance from the horizontal axis but on opposite sides. In one example, a vertical axis and a horizontal axis passing through the center of the support region may be considered relative to generating samples for vertical VBs according to the techniques herein. A replicated sample can be obtained by replicating in a row samples that are the same distance from the vertical axis but on opposite sides of the horizontal axis. In one example, replicated samples may be replicated from columns that are the same distance from the vertical axis but on opposite sides. In one example, in accordance with the techniques herein, samples may be obtained by symmetrical padding relative to generating samples for VB. That is, samples may be copied from the same column at the same sample distance from VB and relative to vertical VB, and samples may be copied from the same row at the same sample distance from VB, relative to horizontal VB. That is, the sample values are mirrored with respect to the VB. It should be noted that section 8.8.5.2 of JVET-O2001 "Coding treeblock filtering process for luma samples" provides a padding scheme for luma samples across virtual boundaries for use relative to the ALF process. In one example, a similar padding scheme may be used for cross-component filtering in accordance with the techniques herein.

In one example, according to the techniques herein, the cross-component filtering includes scaling the output of the cross-component filtering before adding the output to the corresponding chroma ALF output.

That is, a scaling operation can be used to convert filter coefficients to integers, for example as follows:

where factor=2 ^BitDepthC in one example, factor=2 ^{(BitDepthC-1)} ) in another example, factor=2 ^(8-1 ) in another example

In one example, a scaling factor can be used to adjust the output of the cross-component filtering as follows:

应当指出的是，如果factor＝2^X，则这对应于右移位整数舍入(f_i(x,y)+2^(x-1))>>x

It should be noted that if factor=2 ^X , this corresponds to right-shift integer rounding ( _fi (x,y)+2 ^(x-1) )>>x

As described above, filter data specifying the derived filter may be signaled to the video decoder. In one example, there can be three main aspects to signaling filter data: turning filters on/off; local control of tools, eg, enabling tools in some spatial regions but not others; and specific filters signaling. In one example, a parameter set (eg, a sequence parameter set) may conditionally include a flag to enable/disable the filter. In one example, the flag may indicate whether one or more filters are enabled, such as an ALF filter and a cross-component filter.

In one example, slice-level signaling of filter coefficients may be used. Tables 3-5 show examples of syntax that may be included in a slice header for signaling filter coefficients. It should be noted that in Table 3, for syntax elements lice_cross_component_alf_cb_log2_control_size_minus4 and slice_cross_component_alf_cr_log2_control_size_minus4, in one example, a truncated unary encoding may be used instead of ue(v), where the maximum value of the truncated unary is based on the valid range.

table 3

Table 4

table 5

For Tables 3 through 5, in one example, the semantics may be based on the following:

slice_cross_component_alf_cb_enabled_flag equal to 0 specifies that the cross-component adaptive loop filter is not applied to the Cb color components. slice_cross_component_alf_cb_enabled_flag equal to 1 indicates that the cross component adaptive loop filter is applied to the Cb color component.

slice_cross_component_alf_cr_enabled_flag equal to 0 specifies that the cross-component adaptive loop filter is not applied to the Cr color components. slice_cross_component_alf_cb_enabled_flag equal to 1 indicates that the cross component adaptive loop filter is applied to the Cr color components.

slice_cross_component_alf_cb_log2_control_size_minus4 specifies the value of the square block size in number of samples as follows:

AlfCCSamplesCbW=AlfCCSamplesCbH=2( ^{slice_cross_component_alf_cb_log2_control_size_minus4 +4} )

slice_cross_component_alf_cb_log2_control_size_minus4 should be in the range 0 to 3 inclusive.

slice_cross_component_alf_cr_log2_control size minus 4 specifies the value of the square block size in number of samples as follows:

AlfCCSamplesCrW=AlfCCSamplesCrH=2( ^{slice_cross_component_alf_cr_log2_control_size_minus4 +4} )

slice_cross_component_alf_cr_log2_control_size_minus4 should be in the range 0 to 3 inclusive.

It should be noted that, in one example, the orientation of slice_cross_component_alf_cb_log2_control_size_minus4 and/or slice_cross_component_alf_cr_log2_control_size_minus4 may be defined in a parameter set such as SPS.

In one example, minusX encoding depends on the minimum value defined for the valid range, eg, if the valid range is 2 to 5, then X=2.

In one example, slice_cross_component_alf_cb_log2_control_size_minus4 and/or slice_cross_component_alf_cr_log2_control_size_minus4 may be signaled in the SPS or derived from the CTU size (eg, the same as the CTU size in the chroma samples).

alf_cross_component_cb_filter_signal_flag equal to 1 specifies that the cross component Cb filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross component Cb filter bank is not signaled.

alf_cross_component_cb_min_eg_order_minus1 plus 1 specifies the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling. The value of alf_cross_component_cb_min_eg_order_minus1 should be in the range 0 to 9 inclusive. It should be noted that in some examples, this range may vary.

alf_cross_component_cb_eg_order_increase_flag[i] equal to 1 specifies that the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling is incremented by 1. alf_cross_component_cb_eg_order_increase_flag[i] equal to 0 specifies that the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling is not incremented by 1.

The order expGoOrderCb[i] of the exponential Golomb code used to decode the value of alf_cross_component_cb_coeff_delta_abs[j] is derived as follows:

expGoOrderCb[i]=(i==0?alf_cross_component_cb_min_eg_order_minus1+1:

expGoOrderCb[i-1])+alf_cross_component_cb_eg_order_increase_flag[i]

alf_cross_component_cb_coeff_delta_abs[j] specifies the absolute value of the jth coefficient delta of the signaled cross component Cb filter. When alf_luma_cross_component_cb_coeff_delta_abs[j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is derived as follows:

golombOrderIdxCb[]={0,2,2,2,1,2,2,2,2,2,2,1,2,1}

k=expGoOrderCb[golombOrderIdxCb[j]]

alf_cross_component_cb_coeff_sign[j] specifies the sign of the jth cross component Cb filter coefficient as follows:

- If alf_cross_component_cb_coeff_sign[j] is equal to 0, the corresponding chroma filter coefficient has a positive value.

- otherwise (alf_cross_component_cb_coeff_sign[j] is equal to 1), the corresponding chroma filter coefficients have negative values.

When alf_cross_component_cb_coeff_sign[j] does not exist, it is inferred to be equal to 0.

The cross component Cb filter coefficients AlfCCCoeffcb with elements AlfCCCoeffCb[j], j=0..13 are derived as follows:

AlfCCCoeffCb[j]=alf_cross_component_cb_coeff_abs[j]*(1-2*alf_cross_component_cb_coeff_sign[j])

Bitstream compliance requires AlfCCCoeffcb[j], the value of j=0..13 should be in the range -2 ¹⁰ -1 to 2 ¹⁰ -1 inclusive. It should be noted that in some examples, the range may depend on the bit depth of luma/chroma or a subset thereof.

alf_cross_component_cr_filter_signal_flag equal to 1 specifies that the cross component Cr filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross component Cr filter bank is not signaled.

alf_cross_component_cr_min_eg_order_minus1 plus 1 specifies the minimum order of exponential Golomb codes used for cross component Cr filter coefficient signaling. The value of alf_cross_component_cb_min_eg_order_minus1 should be in the range 0 to 9 inclusive. It should be noted that in some examples, this range may vary.

alf_cross_component_cr_eg_order_increase_flag[i] equal to 1 specifies that the minimum order of exponential Golomb codes used for cross component Cr filter coefficient signaling is incremented by 1.

alf_cross_component_cr_eg_order_increase_flag[i] equal to 0 specifies that the minimum order of exponential Golomb codes used for cross component Cr filter coefficient signaling is not incremented by 1.

The order expGoOrderCr[i] of the exponential Golomb code used to decode the value of alf_cross_component_cb_coeff_delta_abs[j] is derived as follows:

expGoOrderCr[i]=(i==0?alf_cross_component_cr_min_eg_order_minus1+1:

expGoOrderCrf i-1])+alf_cross_component_cr_eg_order_increase_flag[i]

alf_cross_component_cr_coeff_delta_abs[j] specifies the absolute value of the jth coefficient delta of the signaled cross component Cr filter. When alf_luma_cross component_cr_coeff_delta_abs[j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is derived as follows:

golombOrderIdxCr[]＝{0,1,2,1,0,1,2,2,2,2,2,1,2,1}

k=expGoOrderCr[golombOrderIdxCr[j]]

alf_cross_component_cr_coeff_sign[j] specifies the sign of the jth cross component Cr filter coefficient as follows:

- If alf_cross_component_cr_coeff_sign[j] is equal to 0, the corresponding chroma filter coefficient has a positive value.

- otherwise (alf_cross_component_cr_coeff_sign[j] is equal to 1), the corresponding chroma filter coefficients have negative values.

When alf_cross_component_cr_coeff_sign[j] does not exist, it is inferred to be equal to 0.

The cross component Cr filter coefficients AlfCCCoeff _Cr with elements AlfCCCoeff _Cr [j], j=0..13 are derived as follows:

AlfCCCoeff _Cr [j]=alf_cross_component_cr_coeff_abs[j]*(1-2*alf_cross_component_cr_coeff_sign[j])

Bitstream compliance requires AlfCCCoeff _Cr [j], the value of j=0..13 should be in the range -2 ¹⁰ -1 to 2 ¹⁰ -1 inclusive. It should be noted that in some examples, the range may depend on the bit depth of luma/chroma or a subset thereof.

In another example, one or more pointers to APSs containing corresponding filter coefficient data may be sent in the slice header. Tables 6 to 7 show examples of syntax that may be included in a slice header for signaling filter coefficients according to this example.

Table 6

Table 7

For Tables 6 through 7, in one example, the semantics can be based on the following:

slice_cross_component_alf_cb_enabled_flag equal to 0 specifies that the cross component Cb filter is not applied to the Cb color components. The slice_cross_component_alf cb_enabled flag equal to 1 indicates that the cross component adaptive loop filter is applied to the Cb color component.

slice_cross_component_alf_cr_enabled_flag equal to 0 specifies that the cross component Cr filter is not applied to the Cr color components. slice_cross_component_alf_cb_enabled_flag equal to 1 indicates that the cross component adaptive loop filter is applied to the Cr color components.

slice_cross_component_alf_cb_aps_id specifies the adaptation_parameter_set_id indexed by the slice's Cb color component. When slice_cross_component_alf_cb_aps_id does not exist, it is inferred to be equal to slice_alf_aps_id_luma[0]. The Temporalld of an ALF APS NAL unit with an adaptation_parameter_set_id equal to slice_cross_component_alf_cb_aps_id shall be less than or equal to the Temporalld of the encoded slice NAL unit.

slice_cross_component_alf_cr_aps_id specifies the adaptation_parameter_set_id to which the Cr color component of the slice is indexed. When slice_cross_component_alf_cr_aps_id does not exist, it is inferred to be equal to slice_alf_aps_id_luma[0]. The Temporalld of an ALF APS NAL unit with an adaptation_parameter_set_id equal to slice_cross_component_alf_cr_aps_id shall be less than or equal to the Temporalld of the coded slice NAL unit.

slice_cross_component_alf_cb_log2_control_size_minus4 specifies the value of the square block size in number of samples as follows:

AlfCCSamplesCbW=AlfCCSamplesCbH=2( ^{slice_cross_component_alf_cb_log2_control_size_minus4 +4} )

slice_cross_component_alf_cb_log2_control_size_minus4 should be in the range 0 to 3 inclusive.

slice_cross_component_alf_cr_log2_control_size_minus4 specifies the value of the square block size in number of samples as follows:

AlfCCSamplesCrW=AlfCCSamplesCrH=2( ^{slice_cross_component_alf_cb_log2_control_size_minus4 +4} )

slice_cross_component_alf_cr_log2_control_size_minus4 should be in the range 0 to 3 inclusive.

alf_luma_filter_signal_flag equal to 1 specifies signaling of the luma filter bank. alf_luma_filter_signal_flag equal to 0 specifies that the luma filter bank is not signaled. When alf_luma_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_chroma_filter_signal_flag equal to 1 specifies that the chroma filter is signaled. alf_chroma_filter_signal_flag equal to 0 specifies that the chroma filter is not signaled. When alf_chroma_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_cross_component_cb_filter_signal_flag equal to 1 specifies that the cross component Cb filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross component Cb filter bank is not signaled. When alf_cross_component_cb_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_cross_component_cr_filter_signal_flag equal to 1 specifies that the cross component Cr filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross component Cr filter bank is not signaled. When alf_cross_component_cr_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_cross_component_cb_min_eg_order_minus1 plus 1 specifies the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling. The value of arf_cross_component_cb_min_eg_order_minus1 should be in the range 0 to 9 inclusive. It should be noted that in some examples, this range may vary.

alf_cross_component_cr_min_eg_order_minus1 plus 1 specifies the minimum order of the exponential Golomb code used for cross component Cr filter coefficient signaling. The value of alf_cross_component_cb_min_eg_order_minus1 should be in the range 0 to 9 inclusive. It should be noted that in some examples, this range may vary.

alf_cross_component_cb_eg_order_increase_flag[i] equal to 1 specifies that the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling is incremented by 1. alf_cross_component_cb_eg_order_increase_flag[i] equal to 0 specifies that the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling is not incremented by 1.

The order expGoOrderCb[i] of the exponential Golomb code used to decode the value of alf_cross_component_cb_coeff_delta_abs[j] is derived as follows:

expGoOrderCb[i]=(i==0?alf_cross_component_cb_min_eg_order_minus1+1:

expGoOrderCb[i-1])+alf_cross_component_cb_eg_order_increase_flag[i]

alf_cross_component_cr_eg_order_increase_flag[i] equal to 1 specifies that the minimum order of the exponential Golomb code used for cross component Cr filter coefficient signaling is incremented by 1. alf_cross_component_cr_eg_order_increase_flag[i] equal to 0 specifies that the minimum order of exponential Golomb codes used for cross component Cr filter coefficient signaling is not incremented by 1.

The order expGoOrderCr[i] of the exponential Golomb code used to decode the value of alf_cross_component_cb_coeff_delta_abs[j] is derived as follows:

expGoOrderCr[i]=(i==0?alf_cross_component_cr_min_eg_order_minus1+1:

expGoOrderCr[i-1])+alf_cross_component_cr_eg_order_increase_flag[i]

alf_cross_component_cb_coeff_delta_abs[j] specifies the absolute value of the jth coefficient delta of the signaled cross component Cb filter. When alf_luma_cross_component_cb_coeff_delta_abs[j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is derived as follows:

golombOrderIdxCb[]={0,2,2,2,1,2,2,2,2,2,2,1,2,1}[These can classify the coefficients into 3 categories, each using the same k-order exponential Golomb code]

k=expGoOrderCb[golombOrderIdxCb[j]]

alf_cross_component_cr_coeff_delta_abs[j] specifies the absolute value of the jth coefficient delta of the signaled cross component Cr filter. When alf_luma_cross_component_cr_coeff_delta_abs[j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is derived as follows:

golombOrderIdxCr[] = {0,1,2,1,0,1,2,2,2,2,2,1,2,1 [These can classify the coefficients into 3 classes, each using the same k order index Golomb code]

k=expGoOrderCr[golombOrderldxCr[j]]

alf_cross_component_cb_coeff_sign[j] specifies the sign of the jth cross component Cb filter coefficient as follows:

- If alf_cross_component_cb_coeff_sign[j] is equal to 0, the corresponding cross component Cb filter coefficient has a positive value.

- otherwise (alf_cross_component_cb_coeff_sign[j] is equal to 1), the corresponding cross component Cb filter coefficient has a negative value.

When alf_cross_component_cb_coeff_sign[j] does not exist, it is inferred to be equal to 0.

The cross component Cb filter coefficients AlfCCCoeff _cb [adaptation_parameter_set_id] with elements AlfCCCoeff _cb [adaptation_parameter_set__id][j], j=0..13 are derived as follows:

AlfCCCoeff _cb [adaptation_parameter_set_id][j]=alf_cross_component_cb_coeff_abs[j]*(1-2*alf_cross_component_cb_coeff_sign[j])

Bitstream compliance requires AlfCCCoeff _cb [adaptation_parameter_set_id][j], the value of j=0..13 should be in the range -2 ¹⁰ -1 to 2 ¹⁰ -1 inclusive.

alf_cross_component_cr_coeff sign[j] specifies the sign of the jth cross component Cr filter coefficient as follows:

- If alf_cross_component_cr_coeff_sign[j] is equal to 0, the corresponding cross component Cr filter coefficient has a positive value.

- otherwise (alf_cross_component_cr_coeff_sign[j] is equal to 1), the corresponding cross component Cr filter coefficient has a negative value.

When alf_cross_component_cr_coeff_sign[j] does not exist, it is inferred to be equal to 0.

The cross-component Cr filter coefficients AlfCCCoeff _cr [adaptation_parameter_set_id] with elements AlfCCCoeff _Cr [adaptation_parameter_set_id][j], j=0..13 are derived as follows:

AlfCCCoeff _Cr [adaptation_parameter_set_id][j]=alf_cross_component_cr_coeff_abs[j]*(1-2*alf_cross_component_cr_coeff_sign[j])

Bitstream compliance requires AlfCCCoeff _Cr [adaptation_parameter_set_id][j], the value of j=0..13 should be in the range -2 ¹⁰ -1 to 2 ¹⁰ -1 inclusive.

It should be noted that the range of -2 ¹⁰ -1 to 2 ¹⁰ -1 can vary. It should be noted that in some examples, the range may depend on the bit depth of luma/chroma or a subset thereof.

For Table 6, in one example, the alf_data( ) syntax structure provided in Table 8A can be used.

Table 8A

For Table 8A, in one example, the semantics can be based on the following:

alf_luma_filter_signal_flag equal to 1 specifies signaling of the luma filter bank. alf_luma_filter_signal_flag equal to 0 specifies that the luma filter bank is not signaled. When alf_luma_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_chroma_filter_signal_flag equal to 1 specifies that the chroma filter is signaled. alf_chroma_filter_signal_flag equal to 0 specifies that the chroma filter is not signaled. When alf_chroma_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_cross_component_cb_filter_signal_flag equal to 1 specifies that the cross component Cb filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross component Cb filter bank is not signaled. When alf_cross_component_cb_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_cross_component_cr_filter_signal_flag equal to 1 specifies that the cross component Cr filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross component Cr filter bank is not signaled. When alf_cross_component_cr_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_cross_component_cb_min_eg_order_minus1 plus 1 specifies the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling. The value of alf_cross_component_cb_min_eg_order_minus1 should be in the range 0 to 9 inclusive. It should be noted that in some examples, this range may vary.

alf_cross_component_cr_min_eg_order_minus1 plus 1 specifies the minimum order of the exponential Golomb code used for cross component Cr filter coefficient signaling. The value of alf_cross_component_cb_min_eg_order_minus1 should be in the range 0 to 9 inclusive. It should be noted that in some examples, this range may vary.

alf_cross_component_cb_eg_order_increase_flag[i] equal to 1 specifies that the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling is incremented by 1. alf_cross_component_cb_eg_order_increase_flag[i] equal to 0 specifies that the minimum order of exponential Golomb codes used for cross component Cb filter coefficient signaling is not incremented by 1.

The order expGoOrderCb[i] of the exponential Golomb code used to decode the value of alf_cross_component_cb_coeff_abs[j] is derived as follows:

expGoOrderCb[i]=(i==0?alf_cross_component_cb_min_eg_order_minus1+1:expGoOrderCb[i-1])+alf_cross_component_cb_eg_order_increase_flag[i]

In one example, a predetermined value corresponding to the minimum order of the exponential Golomb code used for cross component Cb filter coefficient signaling may be used.

In one example, a single value corresponding to the minimum order of the exponential Golomb code for the cross components of all Cb filter coefficients may be signaled in the bitstream.

alf_cross_component_cr_eg_order_increase_flag[i] equal to 1 specifies that the minimum order of the exponential Golomb code used for cross component Cr filter coefficient signaling is incremented by 1. alf_cross_component_cr_eg_order_increase_flag[i] equal to 0 specifies that the minimum order of exponential Golomb codes used for cross component Cr filter coefficient signaling is not incremented by 1.

The order expGoOrderCr[i] of the exponential Golomb code used to decode the value of alf_cross_component_cb_coeff_abs[j] is derived as follows:

expGoOrderCr[i]=(i==0?alf_cross_component_cr_min_eg_order_minus1+1:

expGoOrderCr[i-1])+alf_cross_component_cr_cg order_increase_flag[i]

In one example, a predetermined value corresponding to the minimum order of the exponential Golomb code used for the signalling of the cross-component Cr filter coefficients is used.

In one example, a single value corresponding to the smallest order of the exponential Golomb code for the cross components of all Cr filter coefficients is signaled in the bitstream.

alf_cross_component_cb_coeff_abs[j] specifies the absolute value of the jth coefficient of the signaled cross component Cb filter. When alf_cross_component_cb_coeff_abs[j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is derived as follows:

golombOrderIdxCb[]={0,2,2,2,1,2,2,2,2,2,2,1,2,1}[These can classify the coefficients into 3 categories, each using the same k-order exponential Golomb code]

k=expGoOrderCb[golombOrderIdxCb[j]]

In one example, ue(v) encoding may be used to signal the value of the syntax element alf_cross_component_cb_coeff_abs[j].

alf_cross_component_cr_coeff_abs[j] specifies the absolute value of the jth coefficient of the signaled cross component Cr filter. When alf_cross_component_cr_coeff_abs[j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is derived as follows:

golombOrderIdxCr[]={0,1,2,1,0,1,2,2,2,2,2,1,2,1}[These can classify the coefficients into 3 categories, each using the same k-order exponential Golomb code]

k=expGoOrderCr[golombOrderIdxCr[j]]

In one example, the ue(v) encoding is used to signal the value of the syntax element alf_cross_component_cr_coeff_abs[j].

alf_cross_component_cb_coeff_sign[j] specifies the sign of the jth cross component Cb filter coefficient as follows:

- If alf_cross_component_cb_coeff_sign[j] is equal to 0, the corresponding cross component Cb filter coefficient has a positive value.

- otherwise (alf_cross_component_cb_coeff_sign[j] is equal to 1), the corresponding cross component Cb filter coefficient has a negative value.

When alf_cross_component_cb_coeff_sign[j] does not exist, it is inferred to be equal to 0.

The cross component Cb filter coefficients AlfCCCoeff _cb [adaptation_parameter_set_id] with elements AlfCCCoeff _Cb [adaptation_parameter_set_id][j], j=0..13 are derived as follows:

AlfCCCoeff _cb [adaptation_parameter_set_id][j]=alf_cross_component_cb_coeff_abs[j]*(1-2*alf_cross_component_cb_coeff_sign[j])

Bitstream compliance requires AlfCCCoeff _cb [adaptation_parameter_set_id][j], the value of j=0..13 should be in the range -2 ¹⁰ -1 to 2 ¹⁰ -1 inclusive.

alf_cross_component_cr_coeff_sign[j] specifies the sign of the jth cross component Cr filter coefficient as follows:

- If alf_cross_component_cr_coeff_sign[j] is equal to 0, the corresponding cross component Cr filter coefficient has a positive value.

- otherwise (alf_cross_component_cr_coeff_sign[j] is equal to 1), the corresponding cross component Cr filter coefficient has a negative value.

When alf_cross_component_cr_coeff_sign[j] does not exist, it is inferred to be equal to 0.

The cross-component Cr filter coefficients AlfCCCoeff _cr [adaptation_parameter_set_id] with elements AlfCCCoeff _Cr [adaptation_parameter_set_id][j], j=0..13 are derived as follows:

AlfCCCoeff _Cr [adaptation_parameter_set_id][j]=alf_cross_component_cr_coeff_abs[j]*(1-2*alf_cross_component_cr_coeff_sign[j])

Bitstream compliance requires AlfCCCoeff _Cr [adaptation_parameter_set_id][j], the value of j=0..13 should be in the range -2 ¹⁰ -1 to 2 ¹⁰ -1 inclusive.

In one example, the alf_data( ) syntax structure provided in Table 8B may be used. It should be noted that in Table 8B, the number of filters is signaled using minus1 encoding when signaling the coefficients in the APS.

Table 8B

For Table 8B, in one example, the semantics may be based on the following:

alf_cross_component_cb_filter_signal_flag equal to 1 specifies that the cross component Cb filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross component Cb filter bank is not signaled. When alf_cross_component_cb_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_cross_component_cr_filter_signal_flag equal to 1 specifies that the cross component Cr filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross component Cr filter bank is not signaled. When alf_cross_component_cr_filter_signal_flag is not present, it is inferred to be equal to 0.

alf_cross_component_cb_filters_signalled_minus1 plus 1 specifies the number of cross component Cb filter banks whose coefficients are signaled. The value of alf_cross_component_cb_filters_signalled_minus1 should be in the range 0 to NumCcAlfCbFilters-1 (inclusive).

NumCcAlfCbFilters represents the maximum number of cross component Cb filter banks allowed in the video sequence. In one example, NumCcAlfCbFilters may be set to a predetermined non-negative integer value. In one example, NumCcAlfCbFilters is signaled in a parameter set such as SPS, PPS.

alf_cross_component_cb_min_eg_order_minus1[k] plus 1 specifies the minimum order of the exponential Golomb code used for the signaling of the kth cross component Cb filter coefficient group. The value of alf_cross_component_cb_min_eg_order_minus1[k] should be in the range 0 to 9 inclusive.

alf_cross_component_cb_eg_order_increase_flag[k][i] equal to 1 specifies that the minimum order of the exponential Golomb code used for the signaling of the k-th cross component Cb filter coefficient group is incremented by 1. alf_cross_component_cb_eg_order_increase_flag[k][i] equal to 0 specifies that the minimum order of the exponential Golomb code used for the signaling of the k-th cross component Cb filter coefficient group is not incremented by one.

The order expGoOrderCb[k][i] of the exponential Golomb code used to decode the value of alf_cross_component_cb_coeff_abs[k][j] is derived as follows:

expGoOrderCb[k][i]=(i==0?alf_cross_component_cb_min_eg_order_minus1[k]+1:expGoOrderCbf k][i-1])+alf_cross_component_cb_eg_order_increase_flag[k][i]

alf_cross_component_cb_coeff_abs[k][j] specifies the absolute value of the jth coefficient of the signaled kth cross component Cb filterbank. When alf cross component_cb_coeff_abs[k][j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is derived as follows:

golombOrderIdxCb[]={0,2,2,2,1,2,2,2,2,2,2,1,2,1}[note that these can classify the coefficients into 3 categories, each using Same order 1 exponential Golomb code]

k=expGoOrderCb(golombOrderIdxCb[j]]

alf_cross_component_cb_coeff_sign[k][j] specifies the sign of the jth coefficient of the kth cross component Cb filter coefficient group as follows:

- If alf_cross_component_cb_coeff_sign[k][j] is equal to 0, the corresponding cross component Cb filter coefficient has a positive value.

- otherwise (alf_cross_component cb_coeff_sign[k][j] is equal to 1), the corresponding cross component Cb filter coefficient has a negative value.

When alf_cross_component_cb_coeff_sign[k][j] does not exist, it is inferred to be equal to 0.

The cross component Cb filter coefficients AlfCCCoeff _cb [adaptation_parameter_set_id][k] with elements AlfCCCoeff _cb [adaptation_parameter_set_id][k][j], j=0..13 are derived as follows:

AlfCCCoeff _cb [adaptation_parameter_set_id][k][j]=alf_cross_component_cb_coeff_abs[k][j]*(1-2*alf_cross_component_cb_coeff_sign[k][j])

Bitstream compliance requirements AlfCCCoeff _cb [adaptation parameier_set_id][k][j], the value of j=0..13 shall be in the range -2 ⁷ to 2 ⁷ -1 inclusive.

alf_cross_component_cr_fllters_signalled_minus1 plus 1 specifies the number of cross component Cr filterbanks whose coefficients are signaled. The value of alf_cross_component_cr_filters_signalled_minus1 should be in the range 0 to NumCcAlfCrFilters-1 inclusive.

NumCcAlfCrFilters represents the maximum number of cross component Cr filter banks allowed in the video sequence. In one example, NumCcAlfCrFilters may be set to a predetermined non-negative integer value. In one example, NumCcAlfCrFilters is signaled in a parameter set such as SPS, PPS.

alf_cross_component_cr_min_eg_order_minus1[k] plus 1 specifies the minimum order of the exponential Golomb code used for the signaling of the kth cross component Cr filter coefficient group. The value of alf_cross_component_cb_min_eg_order minus1[k] should be in the range 0 to 9 inclusive.

alf_cross_component_cr_eg_order_increase_flag[k][i] equal to 1 specifies that the minimum order of the exponential Golomb code used for the signalling of the k-th cross component Cr filter coefficient group is incremented by 1. alf_cross_component_cr_eg_order_increase_flag[k][i] equal to 0 specifies that the minimum order of the exponential Golomb code used for the signaling of the k-th cross component Cr filter coefficient group is not incremented by 1.

The order expGoOrderCr[k][i] of the exponential Golomb code used to decode the value of alf_cross_component_cb_coeff_abs[k][j] is derived as follows:

expGoOrderCr[k][i]=(i==0?alf_cross_component_cr_min_eg_order_minus1[k]+1:expGoOrderCr[k][i-1])+alf_cross_component_cr_eg_order_increase_flag[k][i]

alf_cross_component_cr_coeff_abs[k][j] specifies the absolute value of the jth coefficient of the signaled kth cross component Cr filterbank. When alf_cross_component_cr_coeff_abs[k][j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is derived as follows:

golombOrderIdxCr[]={0,1,2,1,0,1,2,2,2,2,2,1,2,1}[Note that these can classify the coefficients into 3 categories, each using Same k-order exponential Golomb code]

k=expGoOrderCr[golombOrderIdxCr[j]]

alf_cross_component_cr_coeff_slgn[k][i] specifies the sign of the jth coefficient of the kth cross component Cr filter coefficient group as follows:

- If alf_cross_component_cr_coeff_sign[k][j] is equal to 0, the corresponding cross component Cr filter coefficient has a positive value.

- otherwise (alf_cross_component_cr_coeff_sign[k][j] is equal to 1), the corresponding cross component Cr filter coefficient has a negative value.

When alf_cross_component_cr_coeff_sign[k][j] does not exist, it is inferred to be equal to 0.

The cross component Cr filter coefficients AlfCCCoeff _Cr [adaptation_parameter_set_id][k] with elements AlfCCCoeff _Cr [adaptation_parameter_set_id][k][j], j=0..13 are derived as follows:

AlfCCCoeff _Cr [adaptation_parameter_set_id][k][j]=alf_cross_component_cr_coeff_abs[k][j]*(1-2*alf_cross_componcnt_cr coeff_sign[k][j])

Bitstream compliance requires AlfCCCoeff _Cr [adaptation_parameter_set_id][k][j], the value of j=0..13 should be in the range -2 ⁷ to 2 ⁷ -1 inclusive.

For Table 8B, in one example, for syntax elements alf_cross_component_cb_coeff_abs[k][i] and alf_cross_component_cr_coeff_abs[k][i], k representing k-order exponential golomb encoded uek(v) may correspond to a predetermined value. Therefore, "k" does not have to be signaled in the bitstream. In one example, in this case, the alf_data( ) syntax structure provided in Table 8C may be used.

Table 8C

For Table 8C, in one example, the semantics may be based on the semantics provided above with respect to Table 8B. For syntax elements alf_cross_component_cb_coeff_abs[k][i] and alf_cross_component_cr_coeff_abs[k][i], in one example, the semantics can be based on the following:

alf_cross_component_cb_coeff_abs[k][j] specifies the absolute value of the jth coefficient of the signaled kth cross component Cb filterbank. When alf_cross_component_cb_coeff_abs[k][j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is set equal to 3.

alf_cross_component_cr_coeff_abs[k][j] specifies the absolute value of the jth coefficient of the signaled kth cross component Cr filterbank. When alf_cross_component_cr_coeff_abs[k][j] does not exist, it is inferred to be equal to 0.

The order k of the exponential Golomb binarization uek(v) is set equal to 3.

Also, for Tables 8A to 8C, in one example, the slice_header( ) syntax structure provided in Table 8D may be used. It should be noted that in Table 8D, the syntax element slice_cross_component_alf_cb_aps_id specifies the adaptation_parameter_set_id of the Cb color component index of the slice (in one example, the APS ID (eg, for cross component filters, luma filter, chroma filter)) Not received, and values inferred, eg, for a set of slice types (eg, I slices), for pictures with a set of NALU types (eg, corresponding to IRAP).

Table 8D

For Table 8D, in one example, the semantics can be based on the following:

slice_cross_component_alf_cb_enabled_flag equal to 0 specifies that the cross component Cb filter is not applied to the Cb color components. slice_cross_component_alf_cb_enabled_flag equal to 1 indicates that the cross component Cb filter is applied to the Cb color component.

slice_cross_component_alf_cr_enabled_flag equal to 0 specifies that the cross component Cr filter is not applied to the Cr color components. slice_cross_component_alf_cb_enabled_flag equal to 1 indicates that the cross component Cr filter is applied to the Cr color components.

For Table 8A:

slice_cross_component_alf_cb_reuse_temporal_layer_filter equal to 1 specifies that the cross component Cb filter coefficients (where j=0..13, inclusive) are set equal to AlfCCTemporalCoeff _cb [Temporalld][j].

slice_cross_component_alf_cb_reuse_temporal_layer_filter equal to 0 and slice_cross_component_alf_cb_enabled__flag equal to 1 specifies that the syntax element slice_cross_component_alf_cb_aps_id is present in the slice header.

When slice_cross_component_alf_cb_enabled_flag is equal to 1 and slice_cross_component_alf_cb_reuse_temporal_layer_filter is equal to 0, the elements of AlfCCTemporalCoeff _cb [Temporalld][j], j=0..13 are derived as follows:

AlfCCTemporalCoeff _Cb [Temporalld][j]=AlfCCCoeff _Cb [slice_cross_component_alf_cb_aps_id][j]

In one example, the cross component Cb coefficients (where j=0..13) may be set to the coefficients received in the corresponding APSAlfCCCoeff _Cb [slice_cross_component_alf_cb_aps_id][j].

slice_cross_component_alf_cr_reuse_temporal_layer_filter equal to 1 specifies that the cross component Cr filter coefficients (where j=0..13, inclusive) are set equal to AlfCCTemporalCoeff _Cr [TemporalId][j].

slice_cross_component_alf_cr_reuse_temporal_layer_filter equal to 0 and slice_cross_component_alf_cr_enabled_flag equal to 1 specifies that the syntax element slice_cross_component_alf_cr_aps_id is present in the slice header.

When slice_cross_component_alf_cr_enabled_flag is equal to 1 and slice_cross_component_alf_cr_reuse_temporal_layer_filter is equal to 0, the elements of AlfCCTemporalCoeff _Cr [TemporalId][j], j=0..13 are derived as follows:

AlfCCTemporalCoeff _Cr [TemporalId][j]=AlfCCCoeff _Cr [slice_cross__component_alf_cr_aps_id][j]

In one example, the cross component Cr coefficients (where j=0..13) may be set to the coefficients received in the corresponding APSAlfCCCoeff _Cr [slice_cross_component_alf_cr_aps_id][j].

For Table 8B and Table 8C:

slice_cross_component_alf_cb_reuse_temporal_layer_filter equal to 1 specifies that the cross component Cb filter coefficients (where j=0..13, k=0..(NumCcAlfCbFilters-1), inclusive) are set equal to AlfCCTemporalCoeff _Cb [TemporalId][k][j] .

slice_cross_component_alf_cb_reuse_temporal_layer_filter equal to 0 and slice_cross_component_alf_cb_enabled_flag equal to 1 specifies that the syntax element slice_cross_component_alf_cb_aps_id is present in the slice header.

When slice_cross_component_alf_cb_enabled_flag is equal to 1 and slice_cross_component_alf_cb_reuse_temporal_layer_filter is equal to 0, the elements of AlfCCTemporalCoeff _cb [TemporalId][k][j], j=0..13, k=0..(NumCcAlfCbFilters-1) are derived as follows:

AlfCCTemporalCoeff _Cb [TemporalId][k][j]=AlfCCCoeff _Cb [slice_cross_component_alf_cb_ap s_id][k][j]

slice_cross_component_alf_cr_reuse_temporal_layer_filter equal to 1 specifies that the cross component Cr filter coefficients (where j=0..13, k=0..(NumCcAlfCrFilters-1), inclusive) are set equal to AlfCCTemporalCoeff _Cr [TemporalId][k][j] .

slice_cross_component_alf_cr_reuse_temporal_layer_filter equal to 0 and slice_cross_component_alf_cr_enabled_flag equal to 1 specifies that the syntax element slice_cross_component_alf_cr_aps_id is present in the slice header.

When slice_cross_component_alf_cr_enabled_flag is equal to 1 and slice_cross_component alf_cr_reuse_tcmporal_layer_filter is equal to 0, the elements of AlfCCTemporalCoeff _Cr [TemporalId][k][j], j=0..13, k=0..(NumCcAlfCrFilters-1) are derived as follows:

AlfCCTemporalCoeff _Cr [TemporalId][k][j]=AlfCCCoeff _Cr [slice_cross_component_alf_cr_aps id][k][j]

It should be noted that when a filter coefficient set from the APS is used, then the corresponding temporal filter coefficient set buffer is filled with the filter coefficient set from the APS.

slice_cross_component_alf_cb_aps_id specifies the adaptation_parameter_set_id to which the Cb color components of the slice are indexed for the cross component Cb filter. When slice_cross_component_alf_cb_aps_id does not exist, it is inferred to be equal to slice_alf_aps_id_luma[0]. The TemporalId of an ALF APS NAL unit with an adaptation_parameter_set_id equal to slice_cross_component_alf_cb_aps_id shall be less than or equal to the TemporalId of the encoded slice NAL unit.

In one example, the APS may be reset, eg, for sets of NALU type (eg, corresponding to random access points such as IRAP), for sets of slice type (eg, I slices). For such pictures/slices, lice_cross_component_alf_cb_aps_id is not signaled. In one example, it can be inferred to be a predetermined value. In one example, it can be inferred as a derived value (eg, based on slice type, TemporalID, NALU type, QP).

In one example, slice_cross_component_alf_cb_aps_id is not received, and a value may be inferred for a set of slices (eg, the first slice) of a picture with a set of NALU types (eg, corresponding to IRAP).

slice_cross_component_alf_cr_aps_id specifies the adaptation_parameter_set_id to which the slice's Cr color components are indexed for the cross component Cb filter. When slice_cross_component_alf_cr_aps_id does not exist, it is inferred to be equal to slice_alf_aps_id_luma[0]. The TemporalId of an ALF APS NAL unit with slice_cross_component_alf_cr_aps_id equal to slice_cross_component_alf_cr_aps_id shall be less than or equal to the TemporalId of the encoded slice NAL unit.

In one example, the APS may be reset, eg, for sets of NALU type (eg, corresponding to random access points such as IRAP), for sets of slice type (eg, I slices). For such pictures/slices, slice_cross_component_alf_cr_aps_jd is not signaled and inferred, but inferred as a predetermined value. In one example, it can be inferred to be a predetermined value. In one example, it can be inferred as a derived value (eg, based on slice type, TemporalID, NALU type, QP).

In one example, slice_cross_component_alf_cr_aps_id is not received, and a value is inferred for a set of slices (eg, the first slice) of a picture with a set of NALU types (eg, corresponding to IRAP).

In one example, an APS reset operation may imply that an APS coded before an access unit (satisfying a predetermined set of conditions, such as NALU type indicating IRAP, slice type equal to I slice) may not be available for that access unit and subsequently coded access unit.

slice_cross_component_alf_cb_log2_control_size_minus4 specifies the value of the square block size in number of samples as follows:

AlfCCSamplesCbW=AlfCCSamplesCbH=2 ^{( slice_cross_component_alf_cb_log2_control_size_minus4+4)}

slice_cross_component_alf_cb_log2_control_size_minus4 should be in the range 0 to 3 inclusive.

slice_cross_component_alf_cr_log2_control_size_minus4 specifies the value of the square block size in number of samples as follows:

AlfCCSamplesCrW=AlfCCSamplesCrH=2 ^{( slice_cross_component_alf_cr_log2_control_size_minus4+4)}

slice_cross_component_alf_cr_log2_control_size_minus4 should be in the range 0 to 3 inclusive.

TemporalId is the temporal identifier of the current NAL unit.

It should be noted that in the above example, the coefficient value is indicated using a syntax element (eg, alf_cross_component_cr_coeff_sign) indicating the sign of the coefficient and a syntax element (eg, alf_cross_component_cr_coeff_abs) indicating the absolute value of the coefficient. In one example, in accordance with the techniques herein, one or more flags indicating whether the absolute value of the coefficient is greater than a particular value (eg, greater than a 1, greater than 2 flag, etc.) and the coefficient based on the value of the one or more flags may be used The absolute value of the syntax element to indicate the absolute value of the coefficient. For example, in one example, the encoding of a particular coefficient value may be based on the following semantics:

alf_cross_component_coeff_abs_greater_than_N_flag[k][j] specifies whether the absolute value of the jth coefficient of the signaled kth cross component filterbank is greater than N. In one example, the coefficients should be in the range -2 ⁷ to 2 ⁷ -1, inclusive, and N may be 64.

alf_cross_component_coeff_abs[k][j] specifies the absolute value of the jth coefficient of the kth cross component filterbank signaled. When alf_cross_component_coeff_abs[k][j] does not exist, it is inferred to be equal to 0.

alf_cross_component_coeff_sign[k][i] specifies the sign of the jth coefficient of the kth cross component filter coefficient group as follows:

- If alf_cross_component_coeff_sign[k][j] is equal to 0, the corresponding cross component filter coefficient has a positive value.

- otherwise (alf_cross_component_coeff_sign[k][j] is equal to 1), the corresponding cross component filter coefficient has a negative value.

When alf_cross_component_coeff_sign[k][j] does not exist, it is inferred to be equal to 0.

The cross component filter coefficients AlfCCCoeff[adaptation_parameter_set_id][k] with elements AlfCCCoeff[adaptation_parameter_set_id][k][j] are derived as follows:

AlfCCCoeff[adaptation_parameter_set_id][k][j]=(N*alf_cross_component_coeff_abs_greater than N flag[k][j]+alf_cross_component_coeff_abs[k][j])*(1-2*alf_cross_component_coeff_sign[k][j])

In one example, a set of cross-component filter coefficients may be signaled for a cross-component color (Cb and/or Cr) filter. Each set of cross component filter coefficients may be assigned a cross component filter index. In one example, the set of cross component filter coefficients may be signaled in the APS. In one example, the sample values may be partitioned (eg, determined using techniques similar to the partitioning used for control flag signaling, or any suitable alternative). A filter index may be signaled for each partition of sample values, where the filter index identifies a cross-component filter to apply to the samples in the partition. Partitions may be communicated using parameters such as block size (which may be the same as the control block size parameter, or may be independent). Partition regions can be derived using parameter values, picture/slice/tile group/MCTS size. In one example, the set of only one cross-component filter coefficient may be signaled in the APS for each color component. An APS identifier may be signaled for each sample value partition identifying a cross component filter to be applied to the samples in the partition.

In one example, for a subset of temporal layers or for all temporal layers may be reset, eg, for a set of NALU types (eg, corresponding to random access points such as IRAP), for a set of slice types (eg, I slices) buffer. In one example, a reset may imply a clear operation. In one example, a reset may imply setting the buffer to a predetermined set of values (eg, 0, a fixed set of values for each TemporalID). A buffer reset operation may imply that the value stored in the buffer prior to the access unit (satisfying a predetermined set of conditions, such as NALU type indicating IRAP, slice type equal to I slice) may not be available for that access unit and subsequent encoding access unit. In one example, when the buffer does not contain any coefficients, then the syntax element indicating whether the filter coefficients from the buffer are to be used may not be signaled but its value is inferred. For example, the first slice in the IRAP picture does not need to signal slice_cross_component_alf_cb_reuse_temporal_layer_filter and/or slice_cross_component_alf_cr_reuse_temporal_layer_filter when the buffer is emptied for an IRAP picture. In one example, when the buffer does not contain any coefficients, then a syntax element indicating whether filter coefficients from the buffer are to be used may be signaled to be limited to a predetermined value. For example, when flushing the buffer for an IRAP picture, the syntax elements slice_cross_component_alf_cb_reuse_temporal_layer_filter and/or slice_cross_component_alf_cr_reuse_temporal_layer_filter in the first slice in the IRAP picture need to be 0.

Also, in one example, the filter for the leading picture is signaled that it should not be used by the trailing picture of the associated IRAP picture. This is because leading pictures may be discarded from the bitstream during random access operations of the bitstream. As described above, in accordance with the techniques herein, a cross-component filter may be signaled using re-use of a filter in the corresponding temporal sublayer buffer and/or a filter in the APS. It should be noted that in some cases the APS may be signaled out-of-band, so in some cases bitstream compliance may only require that the indexed APS should be available. Thus, in one example, bitstream compliance requirements may be implemented using syntax elements slice_cross_component_alf_cb_reuse_temporal_layer_filter and slice_cross_component_alf_cr_reuse_temporal_layer_filter. In one example, the syntax elements slice_cross_component_alf_cb_reuse_temporal_layer_filter and slice_cross_component_alf_cr_reuse_temporal_layer_filter may have the following constraints:

When deriving the filter coefficients in the temporal sublayer buffer AlfCCTemporalCoeffCb[TemporalId][k][j] with the temporal identifier TemporalId for the leading picture of the associated IRAP picture, the bitstream is compliant for the temporal identifier TemporalId The trailing picture of the associated IRAP picture, the value of the syntax element slice_cross_component_alf_cb_reuse_temporal_layer_filter shall be 0.

When deriving the filter coefficients in the temporal sublayer buffer AlfCCTemporalCoeffCr[TemporalId][k][j] with the temporal identifier TemporalId for the leading picture of the associated IRAP picture, the bitstream is compliant for the temporal identifier TemporalId The trailing picture of the associated IRAP picture, the value of the syntax element slice_cross_component_alf_cr_reuse_temporal_layer_filter shall be 0.

As described above with respect to Figures 9A-9F, the filter shape may be determined based on the chroma position type. It should be noted that filter shapes may include filter shapes for various types of filters. Furthermore, the filter shape can generally be described as representing the support and relative to the origin of the filtered samples. In one example, the filter shape may be signaled for each cross component filter in the parameter set: eg SPS, PPS, VUI. In one example, the filter shape may also be signaled in the APS or slice header, such as when the filter shape affects the number of filter coefficients that are encoded. In one example, the filter shape may be used to determine the number of filter coefficients. In one example, filter coefficients may be reused. That is, in one example, a first-in, first-out (FIFO) buffer may be maintained for each component Cb/Cr for each temporal layer. In one example, the size of the FIFO buffer is 1 for each component, each time horizon. In such an example, a flag may be signaled to indicate whether to use the filter coefficients in the corresponding (temporal layer) FIFO buffer or to receive a new set of coefficients. When a new set of filter coefficients is received, they replace the contents of the corresponding (temporal layer) FIFO buffers. In one example, the size of the FIFO buffer is 1 for each component, each time horizon. In such an example, filter coefficients belonging to the same temporal layer or to a lower temporal layer in the FIFO buffer may be reused. Receive a syntax element (eg, a flag) to indicate whether a filter coefficient in one of the FIFO buffers is reused, and if it is reused (eg, a flag value of 1), receive a FIFO buffer of coefficients to be reused index of the device. The range of valid values for this index is determined based on the current temporal layer ID (eg, 0 to the current temporal layer ID). The ue(v) encoding can be used to signal a value such as -(time layer of FIFO buffer - current time layer). In another example, a truncated unary (with a TU maximum value based on the current temporal layer ID) may be used.

In one example, signaling of local control of the cross component filter may include sending all cross component Cb and Cr block level control flags for the slice in the first CTU of the slice. In one example, when the control block size is larger than the CTU size, the control flag may be sent in the first encoded CTU of the control block. The remaining CTUs in the control block may infer the same values as in the first encoded CTU of the control block. When the first coded CTU in the control block does receive the control flag, it can be inferred that the control flag has a value of 0. In one example, control flags are sent for each CTU. In one example, the control flag may be signaled in the first CTU of a slice/tile group. Furthermore, in one example, four control flags may be signaled for each CTU of a tile group/slice. In one example, when there are four control blocks within a CTU, there may be a different number of control block markers for a partial CTU (eg, at boundaries) than a full CTU. In one example, one control flag may be signaled for each CTU of a tile group/slice. In one example, a control flag may be signaled for the first CTU in a set of CTUs, and the same flag value may be inferred for the remaining CTUs in the set.

Table 9 shows the syntax in the coding_tree_unit( ) syntax structure for signaling in the first CTU of a control block, and an example of multiple flags when the control block is smaller than the CTU. It should be noted that in Table 9, the function isInSliceCb() returns TRUE when the passed Cb chroma position represents a Cb sample within the slice being encoded, otherwise it returns FALSE, and when the passed Cr chroma position represents a positive The function isInSliceCr() returns TRUE when there are Cr samples in the encoded slice, otherwise it returns FALSE.

Table 9

Table 10 shows the syntax in the coding_tree_unit( ) syntax structure for signaling in the first CTU of a control block, and an example of multiple flags when the control block is smaller than the CTU.

Table 10

For Tables 9 through 10, in one example, the semantics can be based on the following:

cross_component_alf_cb_control_flag[x][y] equal to 1 specifies that the cross component Cb filter is applied to the block of color component Cb at the chroma position (xCtb/SubWidthC+x*AlfCCSamplesCbW,yCtb/SubHeightC+y*AlfCCSamplesCbH).

cross_component_alf_cb_flag[x][y] equal to 0 specifies that the cross-component Cb adaptive loop filter is not applied to blocks of color component Cb at chroma positions (xCtb/SubWidthC+x*AlfCCSamplesCbW,yCtb/SubHeightC+y*AlfCCSamplesCbH) .

When cross_component_alf_cb_flag[x][y] does not exist, it is inferred to be equal to 0.

cross_component_alf_cr_control_flag[x][y] equal to 1 specifies that the cross component Cr filter is applied to the block at the chroma position (xCtb/SubWidthC+x*AlfCCSamplesCrW,yCtbISubHeightC+y*AlfCCSamplesCrH) of the color component Cr.

cross_component_alf_cr_flag[x][y] equal to 0 specifies that the cross component Cr adaptive loop filter is not applied to the block at the chroma position (xCtb/SubWidthC+x*AlfCCSamplesCrW,yCtb/SubHeightC+y*AlfCCSamplesCrH) of the color component Cr .

When cross_component_alf_cr_flag[x][y] does not exist, it is inferred to be equal to 0.

In one example, according to the techniques herein, the values of spatially adjacent markers are used to select a context for encoding a control marker. In one example, there are a total of 3 contexts for cross_component_alf_cb_control_flag and cross_component_alf_cr_control_flag, which can be determined as follows:

In one example, the cross-component filter coefficients for the cross-component filter carry its own independent set of parameters, such as APS. In one example, the cross component filter coefficients are carried in a different parameter set than the non-cross component filter, eg, APS (eg, ALF in JVET-N1001-v8). In one example, instead of a 5x6 filter, one implementation may use the 7x7 ALF filtering process described in JVET-N1001-v8 in the subsection "Coding Treeblock Filtering Process for Luma Samples". This will further reduce the number of coefficients that need to be signaled. In the above description, filtering operations are applied to refine samples in color components and/or channels, and signaling is provided that can enable/disable operations on a frame-by-frame and position-by-position basis. In one example, filtering operations may also be implemented such that at each frame and/or location, multiple filtering operations are available, and the signaling may be used to transmit the multiple filters and select among the available filters .

In one example, according to the techniques herein, local area control flags may be shared among different chroma channels. That is, for example, the syntax elements cross_component_alf_cb_control_flag and cross_component_alf_cr_control_flag may be replaced with the syntax element cross_component_chroma_alf_control_flag, where, in one example, the semantics of cross_component_chroma_alf_control_flag are based on the following:

cross_componcnt_chroma_alf_control_flag[x][y] equal to 1 and slice_cross_component_alf_cb_enabled_flag equal to 1 specifies that the cross component Cb adaptive loop filter is applied to the color component Cb at the chroma position (xCtb/SubWidthC+x*AlfCCSamplesCbW,yCtb/SubHeightC+y*AlfCCSamplesCbH ) within the block of samples. cross_component_chroma_alf_flag[x][y] equal to 1 and slice_cross_component_alf_cr_enabled_flag equal to 1 specifies that the cross component Cr adaptive loop filter is applied to the color component Cr at the chroma position (xCtb/SubWidthC+x*AlfCCSamplesCbW,yCtb/SubHeightC+y*AlfCCSamplesCbH ) within the block of samples. cross_component_chroma_alf_flag[x][y] equal to 0 specifies that the cross-component chroma adaptive loop filter is not applied to color components Cb and Cr at chroma positions (xCtb/SubWidthC+x*AlfCCSamplesCbW,yCtb/SubHeightC+y*AlfCCSamplesCbH ) sample block.

When cross component_chroma_alf_flag[x][y] is absent, it is inferred to be equal to 0.

此外，在一个示例中，语法元素slice_cross_component_alf_cb_enabled_flag和slice_cross_component_alf_cr_enabled_flag可以用语法元素slice_cross_component_chroma_alf_enabled_flag替换，语法元素cross_component_alf_cb_control_flag和cross_component_alf_cr_control_flag可以用语法元素cross_component_chroma_alf_control_flag替换，其中，在一个示例中，slice_cross_component_chroma_alf_enabled_flag和cross_component_chroma_alf_control_flag的语义基于以下内容：

cross_component_chroma_alf_control_flag[x][y] equal to 1 and slice_cross_component_alf_chroma_enabled_flag equal to 1 specifies that the cross component Cb adaptive loop filter is applied to the color component Cb at the chroma position (xCtb/SubWidthC+x*AlfCCSamplesCbW,yCtb/SubHeightC+y*AlfCCSamplesCbH ) within the block of samples.

cross_component_chroma_alf_flag[x][y] equal to 1 and slice_cross_component_alf_chroma_enabled_flag equal to 1 specifies that the cross component Cr adaptive loop filter is applied to the color component Cr at the chroma position (xCtb/SubWidthC+x*AlfCCSamplesCbW,yCtb/SubHeightC+y*AlfCCSamplesCbH ) within the block of samples.

cross_component_chroma_alf_flag[x][y] equal to 0 specifies that the cross-component chroma adaptive loop filter is not applied to color components Cb and Cr at chroma positions (xCtb/SubWidthC+x*AlfCCSamplesCbW,yCtb/SubHeightC+y*AlfCCSamplesCbH ) sample block.

When cross_component_chroma_alf_flag[x][y] is not present, it is inferred to be equal to 0.

For these examples, Table 11 shows an example of the syntax included in the coding_tree_unit( ) syntax structure for the first CTU of the slice, and Table 12 shows the syntax included in the coding_tree_unit( ) syntax structure for the corresponding CTU Example of syntax.

Table 11

Table 12

As described above, the application of cross-component filtering may be based on properties (eg, variance and/or bias) of the samples included in the filter support region. In one example, a shared control flag (eg, cross_component_chroma_alf_control_flag) and attributes of samples included in the filter support region may be used to determine whether to apply cross-component filtering for one or both of the chroma channels. For example, in one example, for Cb, the value of cross_component_chroma_alf_control_flag may determine whether cross-component filtering is applied, and for Cr, the value of cross_component_chroma_alf_control_flag may additionally determine whether cross-component filtering is applied.

As described above, in JVET-N1001 and JVET-O2001, CTUs are partitioned according to a quadtree plus multi-type tree (QTMT or QT+MTT) structure. In JVET-N1001 and JVET-O2001, for I slices, implicit quadtree partitioning can be used to split each CTU into coding units with 64x64 luma samples, and these coding units can be two separate coding trees The roots of the syntax structure, ie, one for the luma channel and one for the chroma channel. In either case, the local region control flag value may be signaled/determined within the syntax of partition tree signaling. That is, for example, the syntax and semantics for partitioning chroma channels into CUs (ie, a chroma coding tree) may include signaling (implicit and/or explicit) indicating local region control flag values. For example, JVET-N1001 and JVET-O2001 define the variable cbSubdiv=2*cqtDepth, cqtDepth is the current coding quadtree depth, and the depth at the CTU is 0. In one example, according to the techniques herein, the smallest tree node with cbSubdiv less than or equal to a given threshold may represent a parent node control flag signaling group, wherein all blocks resulting from further partitioning belong to the same control flag signaling group. That is, the local region control flags at the parent CU can be used to infer the value of the local region control flags at any resulting child CUs. Tables 13 and 14 show examples of syntax and variable assignments for determining local area control flag values. That is, in Table 13, the smallest tree node whose cbSubdiv is less than or equal to a given threshold may represent a parent node control flag signaling group. Table 14 provides the corresponding coding unit syntax.

Table 13

Table 14

In the example shown in Table 13, the CC ALF control signaling depth for the slice represents the threshold. In one example, the threshold may be signaled for a slice, sequence or picture. For Table 13, the luma position ((xCtrlBlk, yCtrlBlk) specifies the top-left luma sample of the current chroma control block relative to the top-left luma sample of the current picture. The horizontal position xCtrlBlk and vertical position yCtrlBlk are set equal to CuCcAlfTopLeftX and CuCcAlfTopLeftY, respectively. In addition, the current A chrominance control block is a rectangular area within a coding tree block that shares the same CC Alf control flag value (shared or independent for chroma components). Its width and height are equal to the width and height of the coding tree node whose upper-left luma sample is The positions are assigned to the variables CuCcAlfTopLeftX and CuAlfCcTopLeft Y. It should be noted that, in one example, there may be an independent set of variables for each chrominance component.

For Table 14, in one example, when cross_component_chroma_alf_control_flag (shared or independent) is not present, it is inferred to be equal to 0, and when cross_component_chroma_alf_control_flag (shared or independent) is present, the variable IsCuCcAlfControlFlagCoded is set to 1. Also, the Cu CC Alf control flag Vai is set to cross_component_chroma_alf_control_flag. Therefore, in this example, the internal flag "IsCuCcAlfControlFlagCoded" is set to 0 as long as the condition for starting a new control flag signaling set is true (ie, CC ALF is enabled for the slice and cuSubdiv is not above the limit) , and the origin of the current tree node is saved as the origin of the control flag signaling group in the variables CuCcAlfTopLeftX and CuCcAlfTopLeftY. Later, in the coding unit syntax, if "IsCuCcAlfControlFlagCoded" is zero, the control signaling group flag is encoded and the "IsCuCcAlfControlFlagCoded" flag is set to 1, preventing other control block flags from being encoded until a new control is found until the signaling group is marked. A coding unit may inherit its control flag value from the origin of the last coding tree node until a new control flag signaling group is found. In one example, IsCuCcAlfControlFlagCoded is set equal to 1 when the local control region syntax element is present in the coding unit. It should be noted that JVET-N1001 and JVET-O2001 provide a set of quantization parameters indicating the lowest depth of the signaled QP value. In one example, the CC ALF control signaling may be an aligned set of quantization parameters. That is, child nodes within a quantization parameter group share QP values and CC ALF control values. Additionally, in one case, the value of the CC ALF control value may be based on the QP value or derived entirely from the QP value (eg, if the QP value is less than a threshold, the CC ALF control flag is not signaled to the group but inferred as 0).

As discussed above, signaling of cross-component filtering may include signaling of specific filters (eg, filter shape and/or filter coefficients). In one example, in accordance with the techniques herein, the value of the syntax element may indicate whether to apply cross-component filtering for a region, and when applying cross-component filtering for a region, indicate a particular filter for the region. For example, a value of 0 may indicate that cross-component filtering is not applied for a region, a value of 1 may indicate that a filter with a first set of filter coefficients is applied, a value of 2 may indicate that a filter with a second set of filter coefficients is applied, and so on . In one example, the region may be a CTU. Table 15 shows an example of syntax included in the coding_tree_unit( ) syntax structure in accordance with the techniques herein. That is, in the example shown in Table 15, the syntax elements alf_cross_component_cb_idc and alfcross coinponent cr idc indicate whether to apply cross-component filtering, and indicate a filter when cross-component filtering is applied.

Table 15

For Table 15, in one example, the semantics can be based on the following:

PicWidthlnChromaSamples=pic_width_in_luma__samples/SubWidthC

PicHeightlnChromaSamples=pic_height_in_luma_samples/SubHeightC

AlfCCSamplesCbLog2W=AlfCCSamplesCbLog2H=slice_cross_component_alf_cb_log2_control_size_minus4+4

AlfCCSamplesCrLog2W=AlfCCSamplesCrLog2H=slice_cross_component_alf_cr_log2_control_size_minus4+4

Furthermore, it should be noted that:

In one example, xStartC corresponds to the top edge of the CTU. In one example, yStartC corresponds to the left edge of the CTU.

When the local control region does not span a CTU, the check (xCtbC==xStartC&& yCtbC==yStartC) can be omitted.

In one example, (xEndC>=PicWidthlnChromaSamples) and (yEndC>=PicHeightlnChromaSamples), the upper bounds provided by PicWidthlnChromaSamples and PicHeightlnChromaSamples may alternatively correspond to the right and bottom slice/tile/tile/CTU boundaries, respectively.

alf_cross_component_cb_idc[xC>>AlfCCSamplesCbLog2W][yC>>AlfCCSamplesCbLog2H] equal to 0 indicates that the cross component Cb filter is not applied to the block of Cb chroma samples with the upper left chroma position (xC, yC). alf_cross_component_cb_idc[xC>>AlfCCSamplesCbLog2W][yC>>AlfCCSamplesCbLog2H] is equal to m, where m greater than 0 indicates that the k=(m-l)th cross component Cb filterbank is applied to the Cb color with the upper left chroma position (xC,yC) block of degree samples

alf_cross_component_cr_idc[xC>>AlfCCSamplesCrLog2W][yC>>AlfCCSamplesCrLog2H] equal to 0 indicates that the cross component Cr filter is not applied to the block of Cr chroma samples with the upper left chroma position (xC, yC). alf_cross_component_cr_idc[xC>>AlfCCSamplesCrLog2W][yC>>AlfCCSamplesCrLog2H] equals m, where m greater than 0 indicates that the k=(m-l)th cross component Cr filter bank is applied to the Cr color with the upper left chroma position (xC,yC) block of degree samples

When alf_cross_component_cb_idc[xC>>AlfCCSamplesCbLog2W][yC>>AlfCCSamplesCbLog2H] corresponding to chroma sample position (xC,yC) is not available, such as when (xC,yC) is in a different slice/tile than the current CTU , the function UnavailableCb(xC,yC) returns TRUE, otherwise it returns FALSE

When alf_cross_component_cr_idc[xC>>AlfCCSamplesCrLog2W][yC>>AlfCCSamplesCrLog2H] corresponding to the chroma sample position (xC,yC) is not available, such as when (xC,yC) is in a different slice/tile than the current CTU, The function UnavailableCr(xC, yC) returns TRUE, otherwise it returns FALSE.

In one example, in accordance with the techniques herein, the binarization of alf_cross_component_cb_idc and/or alf_cross_component_cr_idc may be a truncated Rice (TR) binarization with a maximum value cMax (according to the number of signaled filter coefficient sets), and cRiceParam equal to 0. Table 16 shows an example of truncated Rice binarization of alf_cross_component_cb_idc and/or alf_cross_component_cr_idc.

Indicated value TR binarization (cRiceParam equals 0) 0 0 1 10 2 110 3 1110 cMax-1 1....10 contains (cMax-1) l cMax 1....11 contains cMax l

Table 16

in,

For CC ALF Cb, cMax is set to the corresponding (alf_cross component cbfilters_signalled_minus1 plus 1)

For CC ALF Cr, cMax is set to the corresponding (alf_cross_componentcr_filterssignalled_minus1 plus 1)

In one example, for alf_cross_component_cb_idc and/or alf_cross_component_cr_ide, only the first bin may be context encoded (ie, other bins may be bypass encoded). In one example, the export of the context of the first bin can be as follows:

The input of this process is to specify the luma position (x0, y0) of the upper-left luma sample of the current luma block relative to the upper-left sample of the current picture, the color component cIdx, the current coding quadtree depth cqtDepth, the dual-tree channel type chType, the luma sample in The width and height of the current coding block, cbWidth and cbHeight, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor and allowSplitQt derived in coding tree semantics.

The output of this process is ctxInc.

position (xNbL, yNbL) is set equal to (x0-l, y0), and the derivation process for the specified neighbor block availability is invoked, where position (xCurr, yCurr) is set equal to (x0, y0), Neighbor position (xNbY, yNbY) is set equal to (xNbL, yNbL), checkPredModeY is set equal to FALSE, and cIdx as input, output is assigned to availableL.

position (xNbA, yNbA) is set equal to (x0, y0-1), and the derivation procedure for the specified neighbor block availability is invoked, where position (xCurr, yCurr) is set equal to (x0, y0), The adjacent position (xNbY, yNbY) is set equal to (xNbA, yNbA), checkPredModeY is set equal to FALSE, and cIdx is the input and the output is assigned to availableA.

The assignment of ctxInc is specified as follows, where condL and condA are specified in Table 17:

For syntax elements alf_cross_component_cb_idc[x0][y0] and alf_cross_component_cr_idc[x0][y0]:

ctxInc=(condL&&availableL)+(condA&&availableA)+ctxSetIdx*3

Table 17

In one example, for alf_cross_component_cb_idc and/or alf_cross_component_cr_idc, all bins can be context encoded, and each bin can use a separate set of contexts as shown in Table 18.

Table 18

For Table 18, in one example, the derivation of the context can be as follows:

The input of this process is to specify the luma position (x0, y0) of the upper-left luma sample of the current luma block relative to the upper-left sample of the current picture, the color component cIdx, the current coding quadtree depth cqtDepth, the dual-tree channel type chType, the luma sample in The width and height of the current coding block, cbWidth and cbHeight, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor and allowSplitQt derived in coding tree semantics.

The output of this process is ctxInc.

position (xNbL, yNbL) is set equal to (x0-l, y0), and the derivation process for the specified neighbor block availability is invoked, where position (xCurr, yCurr) is set equal to (x0, y0), Neighbor position (xNbY, yNbY) is set equal to (xNbL, yNbL), checkPredModeY is set equal to FALSE, and cIdx as input, output is assigned to availableL. position (xNbA, yNbA) is set equal to (x0, y0-1), and the derivation procedure for the specified neighbor block availability is invoked, where position (xCurr, yCurr) is set equal to (x0, y0), The adjacent position (xNbY, yNbY) is set equal to (xNbA, yNbA), checkPredModeY is set equal to FALSE, and cIdx is the input and the output is assigned to availableA. The assignment of ctxInc is specified as follows, where condL and condA are specified in Table 19:

For syntax elements alf_cross_component_cb_idc[x0][y0] and alf_cross_component_cr_idc[x0][y0]:

ctxInc=(condL&&availableL)+(condA&&availableA)+ctxSetIdx*3

Table 19

In one example, for alf_cross_component_cb_idc and/or alf_cross_component_cr_idc, all bins can be context encoded and all bins use the same context, ie each binIdx uses the same context. In some cases, a subset of binIdx does not apply, for example, NumCcAlfCbFilters is 3, binIdx>3 does not apply to alf_cross_component_cb_idc[][], NumCcAlfCrFilters is 3, binIdx>3 does not apply to alf_cross_component_cr_idc[][].

In one example, for alf_cross_component_cb_idc and/or alf_cross_component_cr_idc, all bins can be context encoded and each bin can use the same set of contexts as shown in Table 20. For Table 20, it should be noted that in some cases a subset of binIdx does not apply, for example, NumCcAlfCbFilters is 3, binIdx>3 does not apply to alf_cross_component_cb_idc[][], NumCcAlfCrFilters is 3, binIdx>3 does not apply to alf_cross_component_cr_idc[] [].

Table 20

For Table 20, in one example, the derivation of the context can be as follows:

The input of this process is to specify the luma position (x0, y0) of the upper-left luma sample of the current luma block relative to the upper-left sample of the current picture, the color component cIdx, the current coding quadtree depth cqtDepth, the dual-tree channel type chType, the luma sample in The width and height of the current coding block, cbWidth and cbHeight, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor and allowSplitQt derived in coding tree semantics.

The output of this process is ctxInc.

position (xNbL, yNbL) is set equal to (x0-l, y0), and the derivation process for the specified neighbor block availability is invoked, where position (xCurr, yCurr) is set equal to (x0, y0), Neighbor position (xNbY, yNbY) is set equal to (xNbL, yNbL), checkPredModeY is set equal to FALSE, and cIdx as input, output is assigned to availableL.

position (xNbA, yNbA) is set equal to (x0, y0-1), and the derivation procedure for the specified neighbor block availability is invoked, where position (xCurr, yCurr) is set equal to (x0, y0), The adjacent position (xNbY, yNbY) is set equal to (xNbA, yNbA), checkPredModeY is set equal to FALSE, and cIdx is the input and the output is assigned to availableA. The assignment of ctxInc is specified as follows, where condL and condA are specified in Table 21:

For syntax elements alf_cross_component_cb_idc[x0][y0] and alf_cross_component_cr_idc[x0][y0]:

ctxInc=(condL&&availableL)+(condA&&availableA)+ctxSetIdx*3

Table 21

In one example, a video encoder represents an example of a device configured to: receive reconstructed sample data for a current component of video data, receive reconstructed samples for one or more additional components of video data data, deriving a cross-component filter based on data associated with the one or more additional components of the video data, and deriving the cross-component filter based on the derived cross-component filter and reconstructed sample data for the one or more additional components of the video data The filter is applied to the reconstructed sample data for the current component of the video data.

17 is a block diagram illustrating an example of a video decoder that may be configured to decode video data in accordance with one or more techniques of this disclosure. In one example, video decoder 500 may be configured to reconstruct video data based on one or more of the techniques described above. That is, the video decoder 500 may operate in a reciprocal manner with the video encoder 200 described above. Video decoder 500 may be configured to perform intra-frame prediction decoding and inter-frame prediction decoding, and thus may be referred to as a hybrid decoder. In the example shown in FIG. 18, the video decoder 500 includes an entropy decoding unit 502, an inverse quantization unit 504, an inverse transform processing unit 506, an intra prediction processing unit 508, an inter prediction processing unit 510, a summer 512, a filter unit 514 and reference buffer 516. Video decoder 500 may be configured to decode video data in a manner consistent with a video encoding system that may implement one or more aspects of a video encoding standard. It should be noted that although the example video decoder 500 is shown with different functional blocks, such illustration is intended for descriptive purposes and does not limit the video decoder 500 and/or its subcomponents to a particular hardware or software architecture. The functions of video decoder 500 may be implemented using any combination of hardware, firmware and/or software implementations.

As shown in FIG. 17, the entropy decoding unit 502 receives the entropy-encoded bitstream. Entropy decoding unit 502 may be configured to decode quantized syntax elements and quantized coefficients from the bitstream according to a process that is the reciprocal of an entropy encoding process. Entropy decoding unit 502 may be configured to perform entropy decoding according to any of the entropy encoding techniques described above. The entropy decoding unit 502 may parse the encoded bitstream in a manner consistent with video encoding standards. Video decoder 500 may be configured to parse an encoded bitstream, wherein the encoded bitstream is generated based on the techniques described above.

Referring again to FIG. 17 , the inverse quantization unit 504 receives quantized transform coefficients (ie, scale values) and quantization parameter data from the entropy decoding unit 502 . The quantization parameter data may include any and all combinations of the aforementioned incremental QP values and/or quantization group size values, and the like. Video decoder 500 and/or inverse quantization unit 504 may be configured to determine QP values for inverse quantization based on values signaled by the video encoder and/or through video properties and/or encoding parameters. That is, the inverse quantization unit 504 may operate in a mutually inverse manner with the coefficient quantization unit 206 described above. For example, inverse quantization unit 504 may be configured to infer a predetermined value), an allowed quantization group size, and the like according to the techniques described above. Inverse quantization unit 504 may be configured to apply inverse quantization. Inverse transform processing unit 506 may be configured to perform an inverse transform to generate reconstructed residual data. The techniques performed by inverse quantization unit 504 and inverse transform processing unit 506, respectively, may be similar to those performed by inverse quantization/transform processing unit 208 described above. Inverse transform processing unit 506 may be configured to apply an inverse DCT, inverse DST, inverse integer transform, non-separable quadratic transform (NSST), or conceptually similar inverse transform process to transform the coefficients to produce a residual block in the pixel domain. Also, as described above, whether to perform a specific transform (or the type of a specific transform) may depend on the intra prediction mode. As shown in FIG. 17 , the reconstructed residual data may be provided to summer 512 . Summer 512 may add reconstructed residual data to the predicted video block and generate reconstructed video data. Predictive video blocks may be determined according to predictive video techniques (ie, intra-prediction and inter-prediction).

Intra-prediction processing unit 508 may be configured to receive intra-prediction syntax elements and retrieve predicted video blocks from reference buffer 516 . Reference buffer 516 may include a memory device configured to store one or more frames of video data. The intra-prediction syntax element may identify an intra-prediction mode, such as the intra-prediction modes described above. In one example, intra-prediction processing unit 508 may reconstruct the video block using one or more of the intra-prediction encoding techniques described herein. Inter-prediction processing unit 510 may receive inter-prediction syntax elements and generate motion vectors to identify prediction blocks in one or more reference frames stored in reference buffer 516 . Inter-prediction processing unit 510 may generate motion compensation blocks, possibly performing interpolation based on interpolation filters. Identifiers of interpolation filters for motion estimation with sub-pixel precision may be included in the syntax element. Inter-prediction processing unit 510 may use interpolation filters to calculate interpolated values for sub-integer pixels of the reference block.

Filter unit 514 may be configured to perform filtering on the reconstructed video data. For example, filter unit 514 may be configured to perform deblocking and/or SAO filtering, as described above with respect to filter unit 216 . In an example, filter unit 514 may include cross-component filter unit 600 described below. Furthermore, it should be noted that, in some examples, filter unit 514 may be configured to perform dedicated arbitrary filtering (eg, visual enhancement). As shown in FIG. 17, video decoder 500 may output reconstructed video blocks.

As described above, FIG. 7 illustrates an example of a cross-component filter unit that may be configured to encode video data in accordance with one or more techniques of this disclosure. 18 illustrates an example of a cross-component filter unit that may be configured to decode video data in accordance with one or more techniques of this disclosure. That is, the cross-component filter unit 600 may operate in a reciprocal manner to the cross-component filter unit 300 . As shown in FIG. 18 , the component filter unit 600 includes a filter determination unit 602 and a sample modification unit 604 . Sample modification unit 604 may operate in a manner similar to sample modification unit 304 . That is, sample modification unit 604 may perform filtering according to the derived filters, including one or more of the filters described herein. As shown in FIG. 18, sample modification unit 604 may output the modified reconstructed block to a reference picture buffer (ie, as a loop filter), and output the modified reconstructed block to an output (eg, a display) ). Filter determination unit 602 may receive encoding parameter information (eg, intra-prediction) and available video block data available when the current block is decoded, as shown in FIG. 18, at the video decoder, the available video block data may include: Cross component reconstruction block and current component reconstruction block. However, as shown in FIG. 18, filter determination unit 602 may receive filter data. That is, filter data specifying the derived filter may be signaled to filter determination unit 602 . Examples of such signaling are described above. Accordingly, filter determination unit 302 may derive filters to be used on the chroma reconstruction block based on the video data, encoding parameters, and/or filter data.

As noted above, the cross-component filtering techniques described herein are generally applicable to each component of video data. Thus, one or more combinations of components of video data may be used to reduce reconstruction error of one or more other components of video data. 19A-19C are block diagrams illustrating examples of cross-component filter units that may be configured to reduce reconstruction error in accordance with one or more techniques of the present disclosure. That is, FIGS. 19A to 19C show examples of loop filters that may be included in the filtering unit 514 . In Figures 19A-19C, the commonly numbered elements are as described above. The Cr cross component filter unit 702 is an example of a filter unit configured to filter the Cr component based on the luma component, the Cb component, the filter data and the coding parameters. The luma cross component filter unit 704 is an example of a filter unit configured to filter the luma component based on the luma component, the Cb component, the Cr component, the filter data and the coding parameters. Accordingly, video decoder 500 represents an example of an apparatus configured to: receive reconstructed sample data for a current component of video data, receive reconstructed sample data for one or more additional components of video data, A cross-component filter is derived based on data associated with the one or more additional components of the video data, and the filter is derived based on the derived cross-component filter and reconstructed sample data for the one or more additional components of the video data Applied to reconstructed sample data for the current component of video data.

In one or more examples, the functions may be implemented by hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or propagation media including any medium that facilitates transfer of a computer program from one place to another, eg, according to a communication protocol. As such, a computer-readable medium may generally correspond to: (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. Data storage media can be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementing the techniques described in this disclosure. The computer program product may comprise a computer readable medium.

By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or may be used to store instructions or required program code in the form of data structures and any other medium that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave are used to transmit instructions from a website, server, or other remote source, coaxial cable, fiber optic cable, dual Stranded wire, DSL or wireless technologies such as infrared, radio and microwave are all included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but are instead directed to non-transitory, tangible storage media. As used herein, magnetic disks and optical disks include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, where disks usually reproduce data magnetically, while disks use lasers to optically reproduce data way to copy data. Combinations of the above should also be included within the scope of computer-readable media.

may be implemented by one or more processors such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs) or other equivalent integrated or discrete logic circuits Execute the instruction. Accordingly, the term "processor," as used herein may refer to any of the foregoing structure or any other structure suitable for implementing the techniques described herein. Furthermore, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules configured for encoding and decoding, or incorporated into a combined codec. Moreover, these techniques may be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in various devices or apparatuses, including wireless handsets, integrated circuits (ICs), or sets of ICs (eg, chip sets). Various components, modules or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, various units may be combined in a codec hardware unit, as described above, or provided by an interoperable hardware unit comprising a collection of one or more processors as described above, in conjunction with suitable software and/or firmware various units.

Furthermore, each functional block or various features of the base station apparatus and terminal apparatus used in each of the above-described embodiments may be implemented or performed by a circuit, typically an integrated circuit or multiple integrated circuits. Circuits designed to perform the functions described in this specification may include general purpose processors, digital signal processors (DSPs), application specific or general purpose integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices , discrete gate or transistor logic or discrete hardware components or a combination thereof. A general-purpose processor may be a microprocessor, or, alternatively, the processor may be a conventional processor, controller, microcontroller, or state machine. A general-purpose processor or each of the above circuits may be configured by digital circuits, or may be configured by analog circuits. In addition, when a technology for making integrated circuits that replace current integrated circuits emerges due to advances in semiconductor technology, integrated circuits produced by this technology can also be used.

Various examples have been described. These and other examples are within the scope of the following claims.

<Summary of the Invention>

In one example, a method of reducing reconstruction error in video data is provided, the method comprising: receiving reconstructed sample data for a current component of the video data; receiving one or more additional data for the video data reconstructed sample data for the components; deriving a cross-component filter based on data associated with one or more additional components of the video data; and deriving a cross-component filter based on the derived cross-component filter and for the one or more additional components of the video data The reconstructed sample data applies a filter to the reconstructed sample data for the current component of the video data.

In one example, the method further includes signaling information associated with the derived cross-component filter.

In one example, the method is provided wherein deriving a cross-component filter includes parsing signaling to determine cross-component filter parameters.

In one example, the method is provided wherein deriving a cross-component filter based on data associated with one or more additional components of video data includes deriving a cross-component filter based on a known reconstruction error.

In one example, the method is provided to specify a cross-component filter based on filter coefficients.

In one example, an apparatus for encoding video data is provided that includes one or more processors configured to perform any and all combinations of the steps.

In one example, an apparatus is provided, wherein the apparatus includes a video encoder.

In one example, an apparatus is provided, wherein the apparatus includes a video decoder.

In one example, a system is provided, the system comprising: an apparatus comprising a video encoder; and the apparatus comprising a video decoder.

In one example, an apparatus for encoding video data includes means for performing any and all combinations of steps.

In one example, a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed, cause an apparatus for encoding video data to or multiple processors performing any and all combinations of steps.

In one example, a method of filtering reconstructed video data is provided, the method comprising: inputting reconstructed luma component sample values; reconstructing luma by using cross component filter coefficients and reconstructing luma prior to an adaptive loop filtering process component sample values to derive filtered sample values; use the filtered sample values to derive refinement values for the chroma components; and derive refinement values by using the sum of the sample values for the chroma components and the refinement values for the chroma components Chroma sample value.

In one example, the method further includes performing a clipping function using the sum and bit depth.

In one example, the method further includes decoding a first filter coefficient syntax element specifying cross component filter coefficients for the Cb component in the adaptive loop filter data syntax structure and decoding a second filter coefficient syntax element specifying the sign of the cross component filter coefficients for the Cb component in the adaptive loop filter data syntax structure.

In one example, the method further includes: decoding a first cross-component syntax element specifying whether to apply a cross-component filter to the Cb color component; and decoding a second cross-component syntax element , the second cross-component syntax element specifies whether to apply a cross-component filter to the Cr color components.

In one example, a decoder for decoding encoded data is provided, the decoder comprising: a processor, and a memory associated with the processor; wherein the processor is configured to perform the steps of: inputting reconstructed luminance component sample values; deriving filtered sample values by using cross component filter coefficients and reconstructing luma component sample values prior to the adaptive loop filtering process; deriving refinement values for the chroma components by using the filtered sample values; and The refined chroma sample values are derived by using the sum of the sample values for the chroma components and the refinement values for the chroma components.

In one example, there is provided an encoder for encoding video data, the encoder comprising: a processor, and a memory associated with the processor; wherein the processor is configured to perform the steps of: inputting reconstructed luminance component sample values; deriving filtered sample values by using cross component filter coefficients and reconstructing luma component sample values prior to the adaptive loop filtering process; deriving refinement values for the chroma components by using the filtered sample values; and The refined chroma sample values are derived by using the sum of the sample values for the chroma components and the refinement values for the chroma components.

<cross reference>

This non-provisional patent application requires provisional application 62/865,933 filed on June 24, 2019, provisional application filed on July 4, 2019 62 under 35 U.S.C. /870,752, priority to provisional application 62/886,891, filed August 14, 2019, the entire contents of which are hereby incorporated by reference.

Claims (6)

1. A method of filtering reconstructed video data, the method comprising: Input reconstructed luminance component sample value; deriving filtered sample values by using cross component filter coefficients and the reconstructed luma component sample values prior to an adaptive loop filtering process; deriving refinement values for the chroma components by using the filtered sample values; and The refined chroma sample values are derived by using the sum of the sample values for the chroma components and the refined values for the chroma components. 2. The method of claim 1, further comprising: The clipping function is performed by using the sum and bit depth. 3. The method of claim 1, further comprising: decoding a first filter coefficient syntax element that specifies the absolute value of the cross component filter coefficient for the Cb component in the adaptive loop filter data syntax structure, and A second filter coefficient syntax element is decoded, the second filter coefficient syntax element specifying a sign of the cross component filter coefficient for the Cb component in the adaptive loop filter data syntax structure. 4. The method of claim 1, further comprising: decoding a first cross-component syntax element specifying whether to apply a cross-component filter to the Cb color components, and Decodes a second cross-component syntax element that specifies whether to apply a cross-component filter to the Cr color component. 5. A decoder for decoding encoded data, the decoder comprising: processor; and a memory associated with the processor; wherein the processor is configured to perform the following steps: Input reconstructed luminance component sample value; deriving filtered sample values by using cross component filter coefficients and the reconstructed luma component sample values prior to an adaptive loop filtering process; deriving refinement values for the chroma components by using the filtered sample values; and The refined chroma sample values are derived by using the sum of the sample values for the chroma components and the refined values for the chroma components. 6. An encoder for encoding video data, the encoder comprising: processor; and a memory associated with the processor; wherein the processor is configured to perform the steps of: Input reconstructed luminance component sample value; deriving filtered sample values by using cross component filter coefficients and the reconstructed luma component sample values prior to an adaptive loop filtering process; deriving refinement values for the chroma components by using the filtered sample values; and The refined chroma sample values are derived by using the sum of the sample values for the chroma components and the refined values for the chroma components.

Images