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

Abstract

The present invention discloses a method for filtering reconstructed video data. The method comprises: parsing a first syntax element for setting cross-component filter coefficients; inputting a reconstructed luma picture sample array; deriving a luma position by using a position corresponding to a current chroma sample; deriving a filter coefficient array by using the cross-component filter coefficients; deriving a variable by using the filter coefficient array and the reconstructed luma picture sample array defined by the luma position; and deriving a scaling variable by using the variable, wherein the variable is modified by a sum of samples of the current chroma block defined by a predetermined position and the scaling variable.

Description

Technical Field

[0001] The present disclosure relates to video coding and, more particularly, to techniques for reducing reconstruction error. Background Art

[0002] 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 gaming devices, cellular phones (including so-called smartphones), medical imaging devices, and the like. Digital video can be encoded according to a video coding standard. A video coding standard defines the format of a compatible bitstream that encapsulates coded video data. A compatible bitstream is a data structure that can be received and decoded by a video decoding device to generate reconstructed video data. A video coding standard can 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 the ITU-T H.265 Recommendation for High Efficiency Video Coding (HEVC), December 2016, which is incorporated herein by reference and referred to herein as ITU-T H.265. Extensions and improvements to ITU-T H.265 are currently under consideration for developing the next generation of video coding standards. For example, the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Moving Picture Experts Group (MPEG), collectively referred to as the Joint Video Study Group (JVET), are working to standardize video coding techniques with compression capabilities significantly exceeding the current HEVC standard. The Joint Exploration Model 7 (JEM7), the algorithmic description of the Joint Exploration Test Model 7 (JEM 7), ISO / IEC JTC1 / SC29 / WG11 document: JVET-G1001 (July 2017, Torino, Italy), incorporated herein by reference, describes the coding features studied by JVET under the Joint Test Model, which is a potential enhanced video coding technology that exceeds the capabilities of ITU-T H.265. It should be noted that the coding features of JEM 7 are implemented in the JEM reference software. As used herein, the term JEM may refer collectively to the algorithms included in JEM 7 and the specific implementations of the JEM reference software. In addition, in response to the "Joint Call for Proposals on Video Compression with Capabilities beyond HEVC" jointly issued by VCEG and MPEG, at the 10th meeting of ISO / IEC JTC1 / SC29 / WG11 held in San Diego, California (San Diego, CA) from April 16 to 20, 2018, various groups proposed multiple descriptions of video coding tools.Based on the various descriptions of the video coding tools, the final initial draft text of the video coding specification was described in "Versatile Video Coding (Draft 1)" (document JVET-J1001-v2), presented at the 10th meeting of ISO / IEC JTC1 / SC29 / WG11, held in San Diego, California, from April 16 to 20, 2018, which is incorporated herein by reference and referred to as JVET-J1001. The current development of the next-generation video coding standard by JVET and MPEG is known as the Versatile Video Coding (VVC) project. "Versatile Video Coding (Draft 5)" (document JVET-N1001-v8, presented at the 14th meeting of ISO / IEC JTC1 / SC29 / WG11, held in Geneva, Switzerland, from March 19 to 27, 2019, which is incorporated herein by reference and referred to as JVET-N1001, represents a new version of the draft text of the video coding specification corresponding to the VVC project. "Versatile Video Coding (Draft 6)" from the 15th meeting of ISO / IEC JTC1 / SC29 / WG11, held in Gothenburg, Sweden, from July 3 to 12, 2019 (document JVET-O2001-vE, which is incorporated herein by reference and referred to as JVET-O2001) is a version of the draft text of the video coding specification corresponding to the VVC project.

[0003] Video compression technology can reduce the data requirements for storing and transmitting video data. Video compression technology can reduce data requirements by exploiting the redundancy inherent in video sequences. Video compression technology can subdivide a video sequence into successively smaller parts (i.e., a group of pictures within a video sequence, pictures within a group of pictures, regions within pictures, sub-regions within regions, etc.). Intra-frame prediction coding techniques (e.g., spatial prediction techniques within pictures) and inter-frame prediction techniques (i.e., techniques (temporal) between pictures) can be used to generate the difference between the unit video data to be encoded and the reference unit of video data. This difference can be called residual data. The residual data can be encoded as quantized transform coefficients. Syntax elements can involve residual data and reference coding units (e.g., intra-frame prediction mode index and motion information). The residual data and syntax elements can be entropy encoded. The entropy-coded residual data and syntax elements can be included in the data structure that forms a compatible bitstream. Summary of the Invention

[0004] In one example, a method of filtering reconstructed video data includes parsing a first syntax element for setting cross-component filter coefficients; inputting a reconstructed luma picture sample array; deriving a luma position by using a position corresponding to a current chroma sample; deriving a filter coefficient array by using the cross-component filter coefficients; deriving a variable by using the filter coefficient array and the reconstructed luma picture sample array defined by the luma position; and deriving a scaling variable by using the variable, wherein the variable is modified by a sum of samples of the current chroma block defined by a predetermined position and the scaling variable.

[0005] In one example, a device for encoding video data includes one or more processors configured to: encode a first syntax element for setting cross-component filter coefficients; input a reconstructed luma picture sample array; derive a luma position by using a position corresponding to a current chroma sample; derive a filter coefficient array by using the cross-component filter coefficients; derive a variable by using the filter coefficient array and the reconstructed luma picture sample array defined by the luma position; and derive a scaling variable by using the variable, wherein the variable is modified by a sum of samples of the current chroma block defined by a predetermined position and the scaling variable.

[0006] In one example, a device for decoding video data includes one or more processors configured to: decode a first syntax element for setting cross-component filter coefficients; input a reconstructed luma picture sample array; derive a luma position by using a position corresponding to a current chroma sample; derive a filter coefficient array by using the cross-component filter coefficients; derive a variable by using the filter coefficient array and the reconstructed luma picture sample array defined by the luma position; and derive a scaling variable by using the variable, wherein the variable is modified by a sum of samples of the current chroma block defined by a predetermined position and the scaling variable. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] [ Figure 1 ] Figure 1 is a conceptual diagram illustrating an example of a set of pictures encoded according to quadtree multitree partitioning, in accordance with one or more techniques of this disclosure.

[0008] [ Figure 2A ] Figure 2A is a conceptual diagram illustrating an example of encoding a block of video data, in accordance with one or more techniques of this disclosure.

[0009] [ Figure 2B ] Figure 2Bis a conceptual diagram illustrating an example of encoding a block of video data, in accordance with one or more techniques of this disclosure.

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

[0011] [ Figure 4A ] Figure 4A is a conceptual diagram illustrating examples of location types of video component sampling formats that may be used in accordance with one or more techniques of this disclosure.

[0012] [ Figure 4B ] Figure 4B is a conceptual diagram illustrating examples of location types of video component sampling formats that may be used in accordance with one or more techniques of this disclosure.

[0013] [ Figure 4C ] Figure 4C is a conceptual diagram illustrating examples of location types of video component sampling formats that may be used in accordance with one or more techniques of this disclosure.

[0014] [ Figure 4D ] Figure 4D is a conceptual diagram illustrating examples of location types of video component sampling formats that may be used in accordance with one or more techniques of this disclosure.

[0015] [ Figure 4E ] Figure 4E is a conceptual diagram illustrating examples of location types of video component sampling formats that may be used in accordance with one or more techniques of this disclosure.

[0016] [ Figure 4F ] Figure 4F is a conceptual diagram illustrating examples of location types of video component sampling formats that may be used in accordance with one or more techniques of this disclosure.

[0017] [ Figure 5 ] Figure 5 is a block diagram illustrating an example of a system that may be configured to encode and decode video data in accordance with one or more techniques of this disclosure.

[0018] [ Figure 6 ] Figure 6 is a block diagram illustrating an example of a video encoder that may be configured to encode video data in accordance with one or more techniques of this disclosure.

[0019] [ Figure 7 ] Figure 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.

[0020] [ Figure 8 ] Figure 8 is a conceptual diagram illustrating an example of reconstruction error for multiple components of video data, in accordance with one or more techniques of this disclosure.

[0021] [ Figure 9A ] Figure 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 this disclosure.

[0022] [ Figure 9B ] Figure 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 this disclosure.

[0023] [ Figure 9C ] Figure 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 this disclosure.

[0024] [ Figure 9D ] Figure 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 this disclosure.

[0025] [ Figure 9E ] Figure 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 this disclosure.

[0026] [ Figure 9F ] Figure 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 this disclosure.

[0027] [ Figure 10 ] Figure 10 is a conceptual diagram illustrating an example of using cross-component filtering to reduce reconstruction error, in accordance with one or more techniques of this disclosure.

[0028] [ Figure 11A ] Figure 11A is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0029] [ Figure 11B ] Figure 11B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0030] [ Figure 11C ] Figure 11Cis a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0031] [ Figure 11D ] Figure 11D is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0032] [ Figure 12A ] Figure 12A is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0033] [ Figure 12B ] Figure 12B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0034] [ Figure 13A ] Figure 13A is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0035] [ Figure 13B ] Figure 13B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0036] [ Figure 13C ] Figure 13C is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0037] [ Figure 14A ] Figure 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 this disclosure.

[0038] [ Figure 14B ] Figure 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 this disclosure.

[0039] [ Figure 14C ] Figure 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 this disclosure.

[0040] [ Figure 14D ] Figure 14Dis 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.

[0041] [ Figure 14E ] Figure 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 this disclosure.

[0042] [ Figure 14F ] Figure 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 this disclosure.

[0043] [ Figure 15A ] Figure 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 this disclosure.

[0044] [ Figure 15B ] Figure 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 this disclosure.

[0045] [ Figure 15C ] Figure 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 this disclosure.

[0046] [ Figure 15D ] Figure 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.

[0047] [ Figure 16A ] Figure 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 this disclosure.

[0048] [ Figure 16B ] Figure 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 this disclosure.

[0049] [ Figure 16C ] Figure 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 this disclosure.

[0050] [ Figure 16D ] Figure 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 this disclosure.

[0051] [ Figure 17 ] Figure 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.

[0052] [ Figure 18 ] Figure 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.

[0053] [ Figure 19A ] Figure 19A is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0054] [ Figure 19B ] Figure 19B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0055] [ Figure 19C ] Figure 19C is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure.

[0056] [ Figure 20A ] Figure 20A 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 this disclosure.

[0057] [ Figure 20B ] Figure 20B 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 this disclosure. DETAILED DESCRIPTION

[0058] This patent application is related to: U.S. Provisional Application No. 62 / 865,933 filed on June 24, 2019; U.S. Provisional Application No. 62 / 870,752 filed on July 4, 2019; U.S. Provisional Application No. 62 / 886,891 filed on August 14, 2019; U.S. Provisional Application No. 62 / 899,053 filed on September 11, 2019; U.S. Provisional Application No. 62 / 901,679; U.S. Provisional Application No. 62 / 904,399, filed September 23, 2019; U.S. Provisional Application No. 62 / 905,312, filed September 24, 2019; U.S. Provisional Application No. 62 / 910,317, filed October 3, 2019; and U.S. Provisional Application No. 62 / 913,065, filed October 9, 2019; each of which is incorporated herein by reference in its entirety.

[0059] In general, the present disclosure describes various techniques for encoding video data. Specifically, the present disclosure describes techniques for reducing reconstruction errors. It should be noted that although the techniques of the present disclosure are described with respect to ITU-T H.264, ITU-T H.265, JEM, JVET-N1001, and JVET-O2001, the techniques of the present disclosure are generally applicable to video coding. For example, in addition to those included in ITU-T H.265, JEM, JVET-N1001, and JVET-O2001, the encoding 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-frame prediction techniques, inter-frame prediction techniques, transform techniques, filtering techniques, and / or other entropy coding techniques. Therefore, 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. In addition, it should be noted that the incorporation of references herein is for descriptive purposes and should not be construed as limiting or creating ambiguity regarding the terms used herein. For example, where an incorporated reference provides a definition of a term that differs from another incorporated reference and / or from that term as used herein, the term should be interpreted in a manner that includes both the broadest possible definition and / or the specific alternatives.

[0060] 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, deriving a cross-component filter based on data associated with the one or more additional components of the video data, and applying a filter to the reconstructed sample data for the current component of the video data based on the derived cross-component filter and the reconstructed sample data for the one or more additional components of the video data.

[0061] In one example, a device 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 the video data, derive a cross-component filter based on data associated with the one or more additional components of the video data, and apply a filter to the reconstructed sample data for the current component of the video data based on the derived cross-component filter and the reconstructed sample data for the one or more additional components of the video data.

[0062] 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 reconstructed sample data for a current component of video data, receive reconstructed sample data for one or more additional components of the video data, derive a cross-component filter based on data associated with the one or more additional components of the video data, and apply a filter to the reconstructed sample data for the current component of the video data based on the derived cross-component filter and the reconstructed sample data for the one or more additional components of the video data.

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

[0064] 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.

[0065] 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 may be divided into one or more regions. Regions may be defined based on a basic unit (e.g., a video block) and a set of rules for defining regions. For example, a rule for defining a region may be that a region must be an integer number of video blocks arranged in a rectangular shape. Furthermore, video blocks within a region may be ordered according to a scanning pattern (e.g., raster scan). As used herein, the term "video block" may generally refer to a region of a picture, or more specifically, to a maximum array of sample values that can be predictively encoded, its subpartitions, and / or corresponding structures. 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 comprising sample values of corresponding components of video data, which may also be referred to as color components (e.g., luminance (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" may be used interchangeably. Additionally, in some cases, a pixel or sample may be referred to as a pel. A video sampling format (also 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 a 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.

[0066] A video encoder may perform predictive coding on a video block and its subpartitions. A video block and its subpartitions may be referred to as a node. ITU-T H.264 specifies a macroblock comprising 16×16 luma samples. That is, in ITU-T H.264, a picture is segmented into macroblocks. ITU-T H.265 specifies a similar coding tree unit (CTU) structure (which may be referred to as a largest coding unit (LCU)). In ITU-T H.265, a picture is segmented into CTUs. In ITU-T H.265, for a picture, the CTU size may be set to include 16×16, 32×32, or 64×64 luma samples. In ITU-T H.265, a CTU consists of a corresponding coding tree block (CTB) for each component of the video data, e.g., luma (Y) and chroma (Cb and Cr). It should be noted that a video having one luma component and two corresponding chroma components may be described as having two channels, i.e., a luma channel and a chroma channel. In addition, in ITU-T H.265, the CTU can be divided according to a quadtree (QT) partitioning structure, which allows the CTB of the CTU to be divided into coding blocks (CBs). That is, in ITU-T H.265, the CTU can be divided into quadtree leaf nodes. According to ITU-T H.265, a luma CB together with two corresponding chroma CBs and associated syntax elements is called a coding unit (CU). In ITU-TH.265, the minimum allowed size of the CB can be signaled. In ITU-T H.265, the minimum allowed minimum size of the luma CB is 8×8 luma samples. In ITU-T H.265, the decision to encode a picture area using intra prediction or inter prediction is made at the CU level.

[0067] In ITU-T H.265, a CU is associated with a prediction unit (PU) structure having its root at the CU. In ITU-T H.265, the PU structure allows the partitioning of luma CB and chroma CB to generate corresponding reference samples. That is, in ITU-T H.265, the luma CB and chroma CB can be partitioned into corresponding luma prediction blocks and chroma prediction blocks (PBs), where the PBs include blocks of sample values to which the same prediction is applied. In ITU-T H.265, a CB can be divided into 1, 2, or 4 PBs. ITU-T H.265 supports PB sizes from 64×64 samples down to 4×4 samples. In ITU-T H.265, square PBs are supported for intra prediction, where the CB can form a PB or the CB can be partitioned into four square PBs. In ITU-T H.265, in addition to square PBs, rectangular PBs are also supported for inter prediction, where the CB can be halved vertically or horizontally to form a PB. In addition, it should be noted that in ITU-T H.265, for inter prediction, four asymmetric PB partitions are supported, where the CB is divided into two PBs at one-quarter of the height (top or bottom) or width (left or right) of the CB. Intra-frame prediction data (e.g., intra-frame prediction mode syntax element) or inter-frame prediction data (e.g., motion data syntax element) corresponding to the PB is used to generate reference and / or prediction sample values for the PB.

[0068] JEM specifies a CTU with a maximum size of 256×256 luma samples. JEM specifies a quadtree plus binary tree (QTBT) block structure. In JEM, the QTBT structure allows quadtree leaf nodes to be further divided by a binary tree (BT) structure. That is, in JEM, the binary tree structure allows quadtree leaf nodes to be recursively divided 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. The QTMT in JVET-N1001 and JVET-O2001 is similar to the QTBT in JEM. However, in JVET-N1001 and JVET-O2001, in addition to indicating binary partitioning, the multi-type tree can also indicate a so-called ternary (or ternary tree (TT)) partitioning. Ternary partitioning divides a block into three blocks vertically or horizontally. In case of vertical TT splitting, the block is split at one quarter of its width from the left edge and at one quarter of its width from the right edge, and in case of horizontal TT splitting, the block is split at one quarter of its height from the top edge and at one quarter of its height from the bottom edge. Figure 1 , Figure 1 1 shows an example in which a CTU is divided into quad-tree leaf nodes and the quad-tree leaf nodes are further divided according to BT partitioning or TT partitioning. Figure 1 In , the dashed lines indicate additional binary and ternary splits in the quadtree.

[0069] As described above, each video frame or picture can be divided into one or more regions. For example, according to ITU-T H.265, each video frame or picture can be divided into one or more slices, and further divided into one or more tiles, wherein each slice includes a CTU sequence (e.g., arranged in raster scan order), and wherein a tile is a CTU sequence corresponding to a rectangular area of the picture. It should be noted that in ITU-T H.265, a slice is a sequence of one or more slice segments that starts with an independent slice segment and contains all subsequent dependent slice segments (if any) before the next independent slice segment (if any). Slice segments (such as slices) are CTU sequences. Therefore, in some cases, the terms "slice" and "slice segment" can be used interchangeably to indicate a sequence of CTUs arranged in raster scan order. In addition, it should be noted that in ITU-T H.265, a tile can be composed of CTUs contained in more than one slice, and a slice can 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 segment belong to the same tile; and (2) all CTUs in a tile belong to the same slice.

[0070] With respect to JVET-N1001 and JVET-O2001, a slice needs to consist of an integer number of bricks, rather than just an integer number of CTUs. In JVET-N1001 and JVET-O2001, a brick is a rectangular area of CTU rows within a particular tile in a picture. Furthermore, in JVET-N1001 and JVET-O2001, a tile may be divided into multiple bricks, each brick consisting of one or more CTU rows within the tile. Tiles that are not divided into multiple bricks are also referred to as bricks. However, bricks that are true subsets of tiles are not referred to as tiles. Therefore, in some video coding techniques, slices that include a group of CTUs that do not form a rectangular area of a picture may or may not be supported. Furthermore, it should be noted that in some cases a slice may need to consist of an integer number of complete tiles, and in this case, a slice is referred to as a tile group. The techniques described herein may be applicable to bricks, slices, tiles, and / or tile groups. Figure 1 is a conceptual diagram showing an example of a picture group including slices. Figure 1 In the example shown, Pic3 is shown to include two slices (ie, slice 0 and slice 1). Figure 1In the example shown, slice 0 includes one brick, brick 0, and slice 1 includes two bricks, brick 1 and brick 2. It should be noted that in some cases, slice 0 and slice 1 may meet the requirements of a tile and / or tile group and be classified as a tile and / or tile group.

[0071] For intra-frame prediction coding, the intra-frame prediction mode may specify the position of the reference sample within the picture. In ITU-TH.265, the possible intra-frame prediction modes defined include a planar (i.e., surface fitting) prediction mode, a DC (i.e., flat overall average) prediction mode, and 33 angular prediction modes (predMode: 2-34). In JEM, the possible intra-frame prediction modes defined include a planar prediction mode, a DC prediction mode, and 65 angular prediction modes. It should be noted that the planar prediction mode and the DC prediction mode may be referred to as non-directional prediction mode, and the angular prediction mode may be referred to as a directional prediction mode. It should be noted that the technology described herein may be generally applicable regardless of the number of possible prediction modes defined.

[0072] For inter-frame prediction coding, a reference picture is determined, and a motion vector (MV) identifies samples in the reference picture that are used to generate a prediction for the current video block. For example, the current video block may be predicted using reference sample values located in one or more previously coded pictures, and a motion vector is used to indicate the position of the reference block relative to the current video block. The motion vector may describe, for example, the horizontal displacement component of the motion vector (i.e., the MV x ), the vertical displacement component of the motion vector (ie MV y) and the resolution of the motion vector (e.g., 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) can be organized into one or more reference picture lists and identified using reference picture index values. In addition, in inter-frame prediction coding, uni-prediction refers to generating a prediction using sample values from a single reference picture, and bi-prediction refers to generating a prediction using corresponding sample values from two reference pictures. That is, in uni-prediction, a single reference picture and the corresponding motion vector are used to generate a prediction for the current video block, while in bi-prediction, a first reference picture and the corresponding first motion vector and a second reference picture and the corresponding second motion vector are used to generate a prediction for the current video block. In bi-prediction, corresponding sample values are combined (e.g., added, rounded and clipped, or averaged according to a weight) to generate a prediction. Pictures and their regions can be classified based on which types of prediction modes can be used to encode their video blocks. That is, for regions with a B type (e.g., B slices), bi-prediction, uni-prediction, and intra-prediction modes are available, for regions with a P type (e.g., P slices), uni-prediction and intra-prediction modes are available, and for regions with an I type (e.g., I slices), only intra-prediction mode is available. As described above, reference pictures are identified by reference indexes. For example, for P slices, there may be a single reference picture list RefPicList0, and for B slices, there may be a second independent reference picture list RefPicList1 in addition to RefPicList0. It should be noted that for uni-prediction in B slices, predictions may be generated using either RefPicList0 or RefPicList1. Furthermore, it should be noted that during the decoding process, at the start of decoding a picture, a reference picture list is generated from previously decoded pictures stored in the decoded picture buffer (DPB).

[0073] 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 can be derived from the spatially neighboring blocks and the temporally neighboring blocks of the current video block. In addition, 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), the so-called "merge" mode, and "skip" and "direct" motion inference. In addition, 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.

[0074] As mentioned above, for inter-frame prediction coding, reference samples in a previously encoded picture are used to encode the video block 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, that is, the temporal order of pictures in a video sequence. In ITU-T H.265, when a picture is decoded, it is stored to a decoded picture buffer (DPB) (which may be called a frame buffer, a reference buffer, a reference picture buffer, etc.). In ITU-T H.265, pictures stored to the DPB are removed from the DPB when they are output and are no longer needed for encoding subsequent pictures. In ITU-T H.265, the determination of whether the picture should be removed from the DPB is called once for each picture after decoding the slice header, that is, at the beginning of decoding the picture. For example, the reference Figure 1 , Pic3 is shown as reference to Pic2. Similarly, Pic4 is shown as reference to Pic1. Figure 1, the number of wiggly pictures corresponds to the decoding order, and the DPB will be filled as follows: after decoding Pic1, the DPB will include {Pic1}; at the start of decoding Pic2, the DPB will include {Pic1}; after decoding Pic2, the DPB will include {Pic1, Pic2}; at the start of decoding Pic3, the DPB will include {Pic1, Pic2}. Pic3 will then be decoded with reference to Pic2, and after decoding Pic3, the DPB will include {Pic1, Pic2, Pic3}. At the start of decoding Pic4, pictures Pic2 and Pic3 will be marked for removal from the DPB because they are not required for decoding Pic4 (or any subsequent pictures, not shown), and assuming that Pic2 and Pic3 have been output, the DPB will be updated to include {Pic1}. Pic4 will then be decoded with reference to Pic1. The process of marking pictures to remove them from the DPB can be called reference picture set (RPS) management.

[0075] 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. The difference between the sample values included in the current PB or another type of picture region structure and the associated reference samples (e.g., those generated using prediction) can be referred to as residual data. The residual data can include a respective array of difference values corresponding to each component of the video data. The residual data may be in the pixel domain. A transform such as a discrete cosine transform (DCT), discrete sine transform (DST), integer transform, wavelet transform, or a conceptually similar transform can be applied to the difference value 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 can be partitioned (e.g., four 8×8 transforms can be applied to a 16×16 array of residual values). For each component of the video data, this subdivision of the difference values can be referred to as a transform block (TB). It should be noted that in some cases a core transform and a subsequent secondary transform may be applied (in a video encoder) to generate transform coefficients. For a video decoder, the order of transforms is reversed.

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

[0077] Quantized transform coefficients and syntax elements (e.g., syntax elements indicating the coding structure of a video block) may be entropy encoded according to entropy coding techniques. The entropy coding process involves 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), and probability interval partitioning entropy coding (PIPE). The entropy-encoded quantized transform coefficients and the corresponding entropy-encoded syntax elements may form a compatible bitstream that can be used to reproduce the video data at a video decoder. Entropy coding processes, such as CABAC, may include binarizing the 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 referred to as "bins." Binarization may include one or a combination of the following coding techniques: fixed-length coding, unary coding, truncated unary coding, truncated Rice coding, Golomb coding, k-order exponential Golomb coding, and Golomb-Rice coding. For example, binarization may include representing the integer value 5 of a 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, each of the terms fixed-length coding, unary coding, truncated unary coding, truncated Rice coding, Golomb coding, k-order exponential Golomb coding, and Golomb-Rice coding may refer to general implementations of these techniques and / or more specific implementations of these coding techniques. For example, a Golomb-Rice coding implementation may be specifically defined according to a video coding standard. In the example of CABAC, for a particular bin, the context provides the maximum probability state (MPS) value of the bin (i.e., the MPS of the bin is one of 0 or 1), as well as the probability value of the bin being the MPS or the minimum probability state (LPS). For example, the context may indicate that the MPS of the bin is 0 and that the probability of the bin being 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.

[0078] Figures 2A to 2B is a conceptual diagram showing an example of encoding a video data block. Figure 2A As shown, a current block of video data (e.g., corresponding to a CB of a video component) is encoded by subtracting a set of prediction values from the current block of video data to generate a residual, performing a transform on the residual, and quantizing the transform coefficients to generate a scale value. Figure 2B As shown in , the current video data block is decoded by performing inverse quantization on the level values, performing inverse transform, and adding a set of prediction values to the resulting residual. Figures 2A to 2BIn the example of , the sample values of the reconstructed block are different from the sample values of the current video block being encoded. Specifically, Figure 2B The reconstruction error is shown, 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 can be considered acceptable or imperceptible to viewers of the reconstructed video.

[0079] In addition, if Figures 2A to 2B As shown, the coefficient level values are generated using a scaling factor array. In ITU-T H.265, the scaling factor array is generated by selecting a scaling matrix and multiplying each entry in the scaling matrix by a quantization scaling factor. In ITU-T H.265, the scaling matrix is selected based in part on the prediction mode and the color component, with scaling matrices of the following sizes defined: 4×4, 8×8, 16×16, and 32×32. It should be noted that in some examples, the scaling matrix may provide the same value for each entry (i.e., all coefficients are scaled according to a single value). In ITU-T H.265, the value of the quantization scaling factor may be determined by a quantization parameter QP. In ITU-T H.265, for a bit depth of 8 bits, QP can take 52 values from 0 to 51, with a QP change of 1 typically corresponding to a change in the value of the quantization scaling factor of approximately 12%. In addition, in ITU-T H.265, a predicted quantization parameter value (which may be referred to as a predicted QP value or a QP prediction value) and an optionally signaled quantization parameter delta value (which may be referred to as a QP delta value or a delta QP value) may be used to derive a QP value for a set of transform coefficients. In ITU-T H.265, a quantization parameter may be updated for each CU, and a corresponding quantization parameter may be derived for each of the luma and chroma channels.

[0080] As mentioned above, relative to Figures 2A to 2BIn the example shown, the sample values of the reconstructed block may differ from the sample values of the current video block being encoded. Furthermore, it should be noted that, in some cases, encoding video data block by block may result in artifacts (e.g., so-called blocking artifacts, banding artifacts, etc.). For example, blocking artifacts may cause the boundaries of the encoded blocks of the reconstructed video data to be visually perceptible to the user. Thus, the reconstructed sample values may be modified to minimize the difference between the sample values of the current video block being encoded and the reconstructed block and / or to minimize artifacts introduced by the video encoding process. Such modifications are generally referred to as filtering. It should be noted that filtering can occur as part of an in-loop filtering process or a post-loop filtering process. For an in-loop filtering process, the sample values obtained from the filtering process may be used to predict the video block (e.g., stored in 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 sample values obtained from the filtering process are only output as part of the decoding process (e.g., not used for subsequent encoding). For example, in the case of a video decoder, for the in-loop filtering process, the sample values generated by filtering and reconstructing the block will be used for subsequent decoding (e.g., stored in a reference buffer) and will be output (e.g., output to a display). For the post-loop filtering process, the reconstructed block will be used for subsequent decoding, and the sample values generated by filtering and reconstructing the block will be output.

[0081] Deblocking (or deblocking), deblocking filtering, or applying a deblocking filter refers to the process of smoothing the boundaries of adjacent reconstructed video blocks (i.e., making the boundaries less noticeable to the viewer). Smoothing the boundaries of adjacent reconstructed video blocks may include modifying the sample values included in the rows or columns adjacent to the boundary. ITU-T H.265 provides for the scenario in which a deblocking filter is applied to the 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: a Strong Filter, which modifies the sample values in three rows or columns adjacent to the boundary; and a Weak Filter, which modifies the sample values in the rows or columns immediately adjacent to the boundary and conditionally modifies the sample values in the second row or column from the boundary. In addition, ITU-T H.265 includes one type of filter that can be used to modify chroma samples: a Normal Filter.

[0082] In addition to applying a deblocking filter as part of the in-loop filtering process, ITU-T H.265 also provides for scenarios in which Sample Adaptive Offset (SAO) filtering can be applied during 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 an offset value. ITU-T H.265 provides two types of SAO filters that can be applied to CTBs: band offset or edge offset. For each of band offset and edge offset, four offset values are included in the bitstream. For band offset, the applied offset depends on the amplitude of the sample value (e.g., the amplitude is mapped to bands, which are mapped to four signaled offsets). For edge offset, the applied offset depends on whether the CTB has one of the edge classifications: horizontal, vertical, first diagonal, or second diagonal (e.g., the classification is mapped to four signaled offsets).

[0083] Another type of filtering process includes the so-called adaptive loop filter (ALF). An ALF using block-based adaptation is specified in JEM. In JEM, the ALF is applied after the SAO filter. It should be noted that the ALF can be applied to the 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 2×2 block of the luma component used to reconstruct the image is classified according to a classification index; (2) a set of filter coefficients for each classification index is derived; (3) a filtering decision is determined for the luma component; (4) a filtering decision is determined for the chroma components; and (5) the filter parameters (e.g., coefficients and decisions) are signaled.

[0084] According to the ALF specified in JEM, each 2×2 block is classified according to a classification index C, where C is an integer in the range of 0 to 24, inclusive. C is based on its directionality D and activity according to the following formula The quantized value is derived:

[0085]

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

[0087]

[0088]

[0089]

[0090]

[0091] Here, the indices i and j refer to the coordinates of the top left sample in the 2×2 block, and R(i, j) indicates the reconstructed sample with coordinates (i, j).

[0092] The maximum and minimum values of the horizontal and vertical gradients can be set as:

[0093]

[0094]

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

[0096]

[0097]

[0098] In JEM, to derive the value of the directivity D, the maximum and minimum values are compared with each other and with two thresholds t1 and t2:

[0099] Step 1. If and If both are true, set D to 0.

[0100] Step 2. If Then continue from step 3; otherwise, continue from step 4.

[0101] Step 3. If Then set D to 2; otherwise, set D to 1.

[0102] Step 4. If Then set D to 4; otherwise, set D to 3.

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

[0104]

[0105] Here, A is further quantized into a range from 0 to 4 inclusive, and the quantized value is expressed as

[0106] As described above, applying the ALF specified in the JEM at the video encoder includes deriving a filter coefficient set for each classification index and determining a filtering decision. It should be noted that the derivation of the filter coefficient set and the determination of the filtering decision can be an iterative process. That is, the filter coefficient set can be updated based on the filtering decision, and the filtering decision can be updated based on the updated filter coefficient set, and this can be repeated multiple times. In addition, the video encoder can implement various dedicated algorithms to determine the filter coefficient set and / or determine the filtering decision. Regardless of how the filter coefficient set is derived for each classification index and how the filtering decision is determined, the techniques described herein are generally applicable.

[0107] According to one example, a set of filter coefficients is derived by initially deriving a set of optimal filter coefficients for each classification index. The optimal filter coefficients are derived by comparing desired sample values (i.e., sample values in the source video) with reconstructed sample values after filtering is applied, and by minimizing the sum of squared errors (SSE) between the desired sample values and the reconstructed sample values after filtering is performed. The optimal coefficients derived for each set are then used to perform basic filtering on the reconstructed samples to analyze the effects of the ALF. That is, the desired sample values, the reconstructed sample values before applying the ALF, and the reconstructed sample values after applying the ALF can be compared to determine the effects of applying the ALF using the optimal coefficients.

[0108] According to the specified ALF in JEM, each reconstructed sample R(i, j) is filtered 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 coefficient.

[0109]

[0110] It should be noted that JEM defines three filter shapes (5×5 diamond, 7×7 diamond and 9×9 diamond). It should be noted that in JEM, the geometric transformation is applied to the filter coefficients f(k, l) depending on the gradient value: g v 、g h 、g d1 、g d2 As provided in Table 1.

[0111] Gradient value Transform <![CDATA[g d2 <g d1 And g h <g v ]]> No change <![CDATA[g d2 <g d1 And g v <g h ]]> diagonal <![CDATA[g d1 <g d2 And g h <g v ]]> Flip vertically <![CDATA[g d1 <g d2 And g v <g h ]]> Rotation

[0112] Table 1

[0113] The diagonal, vertical flip and rotation are defined as follows:

[0114] Diagonal: f D (k, l) = f(l, k),

[0115] Flip vertically: fv (k, l) = f(k, Kl-1)

[0116] Rotation: f R (k, l) = f(Kl-1, k)

[0117] Where K is the size of the filter, and 0≤k, 1≤K-1 are the coefficient coordinates, such that the position (0, 0) is located at the upper left corner, and the position (K-1, K-1) is located at the lower right corner.

[0118] JEM provides for signaling up to 25 sets of luma filter coefficients (i.e., one for each possible class index). Therefore, the optimal coefficients can be signaled for each class index that appears in the corresponding image region. However, to optimize the amount of data required to signal the relationship between the filter coefficient sets and the filter effect, rate-distortion (RD) optimization can be performed. For example, JEM provides for signaling filter coefficients of adjacent class groups using an array that maps a set of filter coefficients to each class index. Furthermore, JEM provides for signaling coefficients using temporal coefficient prediction. Specifically, JEM provides for predicting the filter coefficient set for the current picture based on the filter coefficient set of a reference picture by inheriting the filter coefficient set used for the reference picture. JEM also provides for predicting the filter coefficient set for intra-predicted pictures using a set of 16 fixed filters. As described above, the derivation of the filter coefficient sets and the determination of filtering decisions can be an iterative process. For example, the shape of the ALF can be determined based on the number of signaled filter coefficient sets, and similarly, whether the ALF is applied to a region of the image can be based on the signaled filter coefficient sets and / or filter shapes. It should be noted that for the 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. In addition, it should be noted that JVET-N1001 and JVET-O2001 specify deblocking filters, SAO filters, and ALF filters, which can be described as being generally based on the deblocking filters, SAO filters, and ALF filters provided in ITU-T H.265 and JEM.

[0119] The video sampling format (also referred to as the chroma format) can define the number of chroma samples included in a CU relative to the number of luma samples included in the CU. For example, for a 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. Therefore, for a CU formatted according to the 4:2:0 format, the width and height of the sample array for the luma component are twice the width and height of each sample array for the chroma components. Figure 3is a conceptual diagram illustrating an example of coding units formatted according to the 4:2:0 sample format. Figure 3 shows the relative position of chroma samples with respect to luma samples within a CU. As mentioned above, a CU is usually defined based on the number of horizontal and vertical luma samples. Therefore, Figure 3 As shown, a 16×16 CU formatted according to the 4:2:0 sample format includes 16×16 samples for the luma component and 8×8 samples for each chroma component. Figure 3 In the example shown, the relative positions of the chroma samples of adjacent video blocks of a 16×16 CU with respect to the luma samples are shown. For a CU formatted according to the 4:2:2 format, the width of the sample array of the luma component is twice the width of the sample array of each chroma component, but the height of the sample array of the luma component is equal to the height of the sample array of each chroma component. In addition, for a CU formatted according to the 4:4:4 format, the sample array of the luma component has the same width and height as the sample array of each chroma component. Figure 3 For luma samples, the sample line immediately above the video block can be referred to as reference line 0 (RL0), and the subsequent sample lines can be referred to as reference line 1 (RL1), reference line 2 (RL2), and reference line 3 (RL3), respectively. Similarly, the sample columns to the left of the current video block can be classified as reference lines in a similar manner (i.e., the sample line immediately to the left of the video block can be referred to as reference line 0 (RL0).

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

[0121]

[0122]

[0123] Table 2

[0124] The following arithmetic operators can be used with the formulas used in this article:

[0125] + Addition

[0126] - Subtraction

[0127] * Multiplication, including matrix multiplication

[0128] x y Exponentiation. Raises x to the power of y. In other contexts, this notation is used for superscripts and is not intended to be interpreted as exponentiation.

[0129] / Integer division truncates the result towards zero. For example, 7 / 4 and -7 / -4 truncate to 1, and -7 / 4 and 7 / -4 truncate to -1.

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

[0131] Used to express division in mathematical formulas without the intention of truncation or rounding.

[0132] x%y modulus. The remainder when x is divided by y. Defined only for integers x and y where x ≥ 0 and y > 0.

[0133] Additionally, the following logical operators can be used:

[0134] x&&y Boolean logical "AND" of x and y

[0135] x||y Boolean logical OR of x and y

[0136] ! Boolean logic "NO"

[0137] x?y:z If x is TRUE or not equal to 0, then evaluate to y; otherwise, evaluate to z.

[0138] Additionally, the following relational operators can be used:

[0139] > greater than

[0140] ≥ greater than or equal to

[0141] < less than

[0142] ≤ less than or equal to

[0143] == equal to

[0144] ! = Not equal to

[0145] Additionally, the following bitwise operators can be used:

[0146] & Bitwise AND. When operating on integer variables, the operation is performed on the two's complement representation of the integer value. When operating on a binary variable containing fewer bits than another variable, the shorter variable is extended by adding more significant bits equal to 0.

[0147] | Bitwise OR. When operating on integer variables, the operation is performed on the two's complement representation of the integer value. When operating on a binary variable containing fewer bits than another variable, the shorter variable is extended by adding more significant bits equal to 0.

[0148] ∧ Bitwise exclusive OR. When operating on integer variables, the operation is performed on the two's complement representation of the integer value. When operating on a binary variable containing fewer bits than another variable, the shorter variable is extended by adding more significant bits equal to 0.

[0149] Arithmetic right shift of the two's complement integer representation of the binary digit x>>y. This function is defined only for non-negative integer values of y. The bits shifted into the most significant bit (MSB) as a result of the right shift have the same value as the MSB of x before the shift operation.

[0150] Arithmetic left shift of the two's complement integer representation of x times y binary digit. This function is defined only 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 0.

[0151] Additionally, the following assignment operators can be used:

[0152] = assignment operator

[0153] ++ Increment, i.e., x++ is equivalent to x=x+1; when used in array indexing, the value of the variable is evaluated before the increment operation.

[0154] -- Decrement, i.e., x-- is equivalent to x = x-1; when used in array indexing, the value of the variable is evaluated before the decrement operation.

[0155] += Increments by the specified amount, i.e., x+=3 is equivalent to x=x+3, and x+=(-3) is equivalent to x=x+(-3).

[0156] -= decrements by the specified amount, i.e. x-=3 is equivalent to x=x-3, and x-=(-3) is equivalent to x=x-(-3).

[0157] Additionally, the following mathematical functions are defined:

[0158]

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

[0160] Log2(x) is the base-2 logarithm of x.

[0161]

[0162]

[0163]

[0164] Figure 5 is a block diagram illustrating an example of a system that can be configured to encode (e.g., 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 can perform video encoding using the partitioning techniques described in accordance with one or more techniques of this disclosure. Figure 5 As shown, system 100 includes a source device 102, a communication medium 110, and a target device 120. Figure 5 In the example shown, source device 102 may include any device configured to encode video data and transmit the encoded video data to communication medium 110. Destination device 120 may include any device configured to receive the encoded video data via communication medium 110 and decode the encoded video data. Source device 102 and / or destination device 120 may include computing devices equipped for wired and / or wireless communication, and may include set-top boxes, digital video recorders, televisions, desktop, laptop or tablet computers, game consoles, mobile devices including, for example, "smart" phones, cellular phones, personal gaming devices, and medical imaging devices.

[0165] The communication medium 110 may include any combination of wireless and wired communication media and / or storage devices. The 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 can be used to facilitate communication between various devices and sites. The communication medium 110 may include one or more networks. For example, the 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 telecommunication protocols. The telecommunication protocols may include proprietary aspects and / or standardized telecommunication protocols. Examples of standardized telecommunication protocols include the Digital Video Broadcasting (DVB) standard, the Advanced Television Systems Committee (ATSC) standard, the Integrated Services Digital Broadcasting (ISDB) standard, the Cable Data Service Interface Specification (DOCSIS) standard, the Global System for Mobile Communications (GSM) standard, the Code Division Multiple Access (CDMA) standard, the 3rd Generation Partnership Project (3GPP) standard, the European Telecommunications Standards Institute (ETSI) standard, the Internet Protocol (IP) standard, the Wireless Application Protocol (WAP) standard, and the Institute of Electrical and Electronics Engineers (IEEE) standard.

[0166] A storage device may include any type of device or storage medium capable of storing data. The storage medium may include a tangible or non-transitory computer-readable medium. The computer-readable medium may include an optical disc, a flash memory, a magnetic memory, or any other suitable digital storage medium. In some examples, a memory device or portion thereof may be described as a non-volatile memory, and in other examples, portions of a memory device may be described as a 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 a magnetic hard disk, an optical disc, a floppy disk, a flash memory, or an electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. The storage device may include a memory card (e.g., a secure digital (SD) memory card), an internal / external hard drive, and / or an internal / external solid-state drive. Data may be stored on the storage device according to a defined file format.

[0167] Reference again Figure 5 , source device 102 includes a video source 104, a video encoder 106, and an 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 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. Various aspects of a compatible bitstream may be defined according to a video coding standard. When generating a compatible bitstream, video encoder 106 may compress the video data. The 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. 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 send and / or receive information. In addition, the interface 108 may include a computer system interface that may allow a compatible video bitstream to be stored on a storage device. For example, the interface 108 may include a computer system interface that supports the Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe) bus protocols, proprietary bus protocols, Universal Serial Bus (USB) protocols, I 2 C's chipset, or any other logical and physical structure that can be used to interconnect peer devices.

[0168] Reference again Figure 5, target device 120 includes an interface 122, a video decoder 124, and a display 126. Interface 122 may include any device configured to receive a compatible video bitstream from a communication medium. 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 send information. In addition, interface 122 may include a computer system interface that allows a compatible video bitstream to be retrieved from a storage device. For example, interface 122 may include a computer system interface that supports PCI and PCIe bus protocols, proprietary bus protocols, USB protocols, I 2 C chipset, or any other logical and physical structure that can be used to interconnect peer devices. Video decoder 124 may include any device configured to receive a compatible bitstream and / or an acceptable variant 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), a plasma display, an 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 Figure 5 In the example shown, video decoder 124 is described as outputting data to display 126, but video decoder 124 can be configured to output video data to various types of devices and / or subcomponents thereof. For example, video decoder 124 can be configured to output video data to any communication medium, as described herein.

[0169] Figure 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 exemplary video encoder 200 is illustrated as having different functional blocks, such illustration is intended for descriptive purposes and does not limit the video encoder 200 and / or its subcomponents to a particular hardware or software architecture. The functionality of the video encoder 200 may be implemented using any combination of hardware, firmware, and / or software implementations. In one example, the video encoder 200 may be configured to encode video data according to the techniques described herein. The video encoder 200 may perform both intra-frame predictive encoding and inter-frame predictive encoding of picture regions, and therefore may be referred to as a hybrid video encoder. In Figure 6In the example shown, the video encoder 200 receives a source video block. In some examples, the source video block may include a picture region that has been divided according to a coding structure. For example, the source video data may include macroblocks, CTUs, CBs, sub-partitions thereof, and / or other equivalent coding units. In some examples, the video encoder 200 may be configured to perform additional subdivisions of the source video block. It should be noted that some of the techniques described herein are generally applicable to video coding regardless of how the source video data is divided before and / or during encoding. Figure 6 In the example shown, 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-frame prediction processing unit 212, an inter-frame prediction processing unit 214, a filter unit 216 and an entropy coding unit 218.

[0170] like Figure 6As shown, the video encoder 200 receives a source video block and outputs a bitstream. The video encoder 200 can generate residual data by subtracting the predicted video block from the source video block. The summer 202 represents a component configured to perform this subtraction operation. In one example, the subtraction of the video blocks occurs in the pixel domain. The transform coefficient generator 204 applies a transform, such as a discrete cosine transform (DCT), a discrete sine transform (DST), or a conceptually similar transform, to its residual block or subpartition (for example, four 8×8 transforms can be applied to a 16×16 residual value array) to generate a set of residual transform coefficients. The transform coefficient generator 204 can be configured to perform any and all combinations of transforms included in the discrete triangular transform family. As described above, in ITU-T H.265, TBs are restricted to the following sizes: 4×4, 8×8, 16×16, and 32×32. In one example, the transform coefficient generator 204 may be configured to perform transforms based on arrays of sizes 4×4, 8×8, 16×16, and 32×32. In one example, the transform coefficient generator 204 may be further configured to perform transforms based on arrays of other sizes. Specifically, in some cases, it may be useful to perform transforms on rectangular arrays of different values. In one example, the transform coefficient generator 204 may be configured to perform transforms based on the following array sizes: 2×2, 2×4N, 4M×2, and / or 4M×4N. In one example, a two-dimensional (2D) M×N inverse transform may be implemented as a one-dimensional (1D) M-point inverse transform followed by a 1D N-point inverse transform. In one example, a 2D inverse transform may be implemented as a 1D N-point vertical transform followed by a 1D N-point horizontal transform. In one example, a 2D inverse transform may be implemented as a 1D N-point horizontal transform followed by a 1D N-point vertical transform. The transform coefficient generator 204 may output the transform coefficients to the coefficient quantization unit 206.

[0171] The coefficient quantization unit 206 can be configured to perform quantization of the transform coefficients. As described above, the degree of quantization can be modified by adjusting a quantization parameter. The coefficient quantization unit 206 can be further configured to determine the quantization parameter and output QP data (e.g., data used to determine a quantization group size and / or a delta QP value), which a video decoder can use to reconstruct the quantization parameter to perform inverse quantization during video decoding. It should be noted that in other examples, one or more additional or alternative parameters can be used to determine the quantization scale (e.g., a scaling factor). The techniques described herein are generally applicable to determining the quantization scale of transform coefficients corresponding to one component of video data based on the quantization scale of transform coefficients corresponding to another component of video data.

[0172] See again Figure 6, the quantized transform coefficients are output to the inverse quantization / transform processing unit 208. The inverse quantization / transform processing unit 208 may be configured to apply inverse quantization and inverse transformation to generate reconstructed residual data. Figure 6 As shown, at summer 210, the reconstructed residual data can be added to the predicted video block. In this way, the encoded video block can be reconstructed, and the resulting reconstructed video block can be used to evaluate the encoding quality of a given prediction, transform, and / or quantization. The video encoder 200 can be configured to perform multiple encoding passes (e.g., performing encoding while changing one or more of the 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 block. In addition, the reconstructed video block can be stored and used as a reference for predicting subsequent blocks.

[0173] As described above, intra-frame prediction may be used to encode a video block. The intra-frame prediction processing unit 212 may be configured to select an intra-frame prediction mode for a video block to be encoded. The intra-frame prediction processing unit 212 may be configured to evaluate a frame and / or a region thereof and determine an intra-frame prediction mode to be used to encode a current block. Figure 6 As shown, the intra-frame prediction processing unit 212 outputs intra-frame prediction data (e.g., syntax elements) to the entropy coding unit 218 and the transform coefficient generator 204. As described above, the transform performed on the residual data may depend on the mode. As described above, possible intra-frame prediction modes may include planar prediction mode, DC prediction mode, and angular prediction mode. In addition, in some examples, the prediction of the chrominance component may be inferred from the intra-frame prediction used for the luma prediction mode. The inter-frame prediction processing unit 214 may be configured to perform inter-frame prediction coding for the current video block. The inter-frame prediction processing unit 214 may be configured to receive the source video block and calculate the motion vector of the PU of the video block. The motion vector may indicate the displacement of the PU (or similar coding structure) of the video block in the current video frame relative to the prediction block in the reference frame. Inter-frame prediction coding may use one or more reference pictures. In addition, the motion prediction may be unidirectional (using one motion vector) or bidirectional (using two motion vectors). The inter-frame 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, the motion vector may be determined and assigned based on motion vector prediction. As described above, the inter-frame prediction processing unit 214 may be configured to perform motion vector prediction. The inter-frame prediction processing unit 214 may be configured to generate a prediction block using motion prediction data. For example, the inter-frame prediction processing unit 214 may locate a prediction video block within a frame buffer ( Figure 6(not shown in FIG. 1 ). It should be noted that the inter-frame 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. The inter-frame prediction processing unit 214 may output the motion prediction data of the calculated motion vector to the entropy coding unit 218. Figure 6 As shown, the inter-frame prediction processing unit 214 may receive the reconstructed video block via the filter unit 216. The entropy coding unit 218 receives the quantized transform coefficients and prediction syntax data (i.e., intra-frame prediction data, motion prediction data, QP data, etc.). It should be noted that in some examples, the coefficient quantization unit 206 may perform a scan of the matrix including the quantized transform coefficients before outputting the coefficients to the entropy coding unit 218. In other examples, the entropy coding unit 218 may perform the scan. The entropy coding unit 218 may be configured to perform entropy coding according to one or more of the techniques described herein. The entropy coding unit 218 may be configured to output a compatible bitstream (i.e., a bitstream from which a video decoder can receive and reproduce video data).

[0174] Reference again Figure 6 , the filter unit 216 may be configured to perform deblocking filtering, sample adaptive offset (SAO) filtering, and / or ALF filtering as described above. In addition, the 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 described above, for the ALF filter in JEM, each component uses a set of sample values from the corresponding component as input, and derives output sample values in a manner independent of other components. Filtering independently by component may not be ideal because there may be correlations between components and / or channels of the video data that can be used to minimize reconstruction errors. For example, referring to Figure 8 , Figure 8 An example of an 8×8 luma source block and a corresponding 4×4 chroma source block (ie, according to a 4:2:0 sampling format) as well as the corresponding reconstructed block and reconstruction error is shown. Figure 8 As shown, the two source blocks include edges around diagonals, which would be typical in the case of textures, shape edges, etc. However, for the reconstructed chroma components, fidelity is lost compared to the luma components (e.g., due to a high level of quantization, etc.), and the edges are not restored.

[0175] According to the techniques herein, a filter unit may be configured to predict and / or refine information in a first color channel and / or component from information in a second color channel and / or component, which may provide improved coding efficiency for the first color channel and / or component because the fidelity of the color channel and / or component is increased with a small number of bits. Figure 71 shows an example of a cross-component filter unit that can be configured to encode video data according to one or more techniques of this disclosure. Figure 7 As shown, the cross component filter unit 300 includes a filter determination unit 302 and a sample modification unit 304. It should be noted that the cross component filter unit 300 shows an example of a cross component filter unit that may be present in a video encoder. An example of a corresponding cross component filter unit that may be present in a video decoder is described in more detail below. Figure 7 As shown, the filter determination unit 302 and the 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. Figure 7 As shown, the video block data at the video encoder may include: cross-component source blocks; cross-component reconstruction blocks; cross-component reconstruction errors; current component source blocks; current component reconstruction blocks; and current component reconstruction errors. Figure 8 In the example shown, when filtering the chroma reconstruction block, Figure 8 All information in may be available at the cross-component filter unit 300. Thus, the filter determination unit 302 may derive the filter to be used on the chroma reconstructed block based on the video data, and the sample modification unit 304 may perform filtering according to the derived filter. Figure 7 As shown, the sample modification unit 304 may output the modified reconstructed block to the reference picture buffer (ie, as a loop filter), and output the modified reconstructed block to an output terminal (eg, a display). Figure 7 As shown, the filter determination unit 302 may output filter data. That is, the 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 Figure 8 There may be several ways to reduce the reconstruction error at a video encoder, for example, reducing quantization and / or performing improved prediction techniques. Furthermore, in some cases, a video encoder may directly signal the reconstruction error. However, cross-component filtering according to the techniques herein provides a way to reduce the reconstruction error while signaling a relatively small amount of information. That is, for example, the cross-component filtering techniques described herein may provide a way to reduce the reconstruction error at a video decoder while being more efficient than other techniques for reducing the reconstruction error. For example, signaling filter data may cost fewer bits than signaling higher-fidelity residual information for the components.

[0176] Thus, the cross component filter unit 300 can operate by taking a first color component and one or more second color components as input and providing 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 (e.g., RGB) and other types of video information, such as infrared, depth, parallax, or other features.

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

[0178]

[0179] in,

[0180] f i (x, y):

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

[0182] S i，0 ;S i，1 ; and S i，2 : Defines a set of sample value positions relative to the origin in the corresponding points 0, 1, and 2;

[0183] g(x, yi, 0) and h(x, yi, 0), g(x, y, i, 1) and h(x, y, i, 1), and g(x, yi, 2) and h(x, y, i, 2): Determine the supported origins based on x, y, i, and the input components. Functions g() and h() may also depend on the chroma format, chroma location type, color gamut, and filter shape;

[0184] c0(x0, y0), c1(x0, y0), and c2(x0, y0): are the filter coefficient values of the support region of each component;

[0185] I0, I1, and I2: are the input sample values from each component; and

[0186] Ii(x,y): is the sample value of component i at sample position (x,y) before filtering.

[0187] Thus, according to the techniques herein, the cross-component filter unit 300 can be configured to reduce the reconstruction error of the current component by adding refinement to the reconstructed sample values of the current component based on a derived filter function that takes the reconstructed sample values of other components as input. In one example, the reconstructed sample values of the other components used as input can be referred to as a filter support. 9A to 9F is a conceptual diagram illustrating an example of support samples that can be used for cross-component filtering according to one or more techniques of this disclosure. 9A to 9F In the example shown, for each of the 4:2:0 sample format chroma position types provided in JVET-N1001 and JVET-O2001, luma support samples for the chroma samples to be filtered are shown. That is, 5×5, 5×6, 6×5 and / or 6×6 support samples may be used. It should be noted that in 9A to 9F In the example of , the luma support is defined as symmetric about the chroma sample values. It should be noted that in other examples, the luma support may undergo a phase shift before being input to a filtering stage that is independent of the chroma position type, with the phase shift being specific to the chroma position type. As described in further detail below, for each support sample, a filter coefficient may be determined and signaled. In one example, according to the techniques herein, for chroma samples included in a video block, the relative position of the support 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 the chroma position (x C ,y C ) corresponds to the chroma sample at the origin at the luminance position (x L ,y L ) is supported at the chroma position (x C +m,y C The origin of support for chroma samples at (x + n) can be at the luma position (x C +2m,y C +2n); for 4:2:2 sample format, when the chroma position (x C ,y C ) corresponds to the chroma sample at the origin at the luminance position (x L ,y L ) is supported at the chroma position (x C +m,y C The origin of support for chroma samples at (x + n) can be at the luma position (x C +2m,y C +n); and for the 4:4:4 sample format, when the chroma position (x C ,y C ) corresponds to the chroma sample at the origin at the luminance position (x L,y L ) is supported at the chroma position (x C +m,y C The origin of support for chroma samples at (x + n) can be at the luma position (x C +m,y C It should be noted that in this example, the offset of the chroma sample positions corresponds to the offset of the luma position of the supported origin, where the ratio between these two offsets is based on the chroma format.

[0188] In one example, according to the techniques herein, the application of cross-component filtering can be based on properties of samples included in a filter support region. For example, in one example, luma sample values in the support region can be analyzed, and based on this analysis, a determination can be made as to whether to apply cross-component filtering. For example, in one example, the variance and / or deviation of samples in the support region can be calculated, and if the variance and / or deviation exhibit certain characteristics, such as that the region is smooth (i.e., the variance is less than a threshold), cross-component filtering can be omitted from the region. In one example, cross-component filter selection (including whether to apply a filter, when to apply the filter, and which filter to apply) can 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 the luma sample can be derived as described in JVET-02001. In one example, when it is determined that the luma classification filter index is within a subset of the luma classification filter indexes, cross-component filtering can be omitted. As described in further detail below, the value of a local region control flag and / or syntax element can be used to indicate / determine whether cross-component filtering is applied for a region, and if so, which cross-component filter to apply for the region. In one example, the application of cross-component filtering can be based on the properties of samples included in the filter support region and / or the value of a local region control flag and / or syntax element. That is, for example, how to analyze the luma support sample can be based on the local region control flag and / or syntax element (e.g., if the flag == 0, then calculate / evaluate the variance, otherwise calculate / evaluate the luma classification filter index). In addition, in one example, filter selection is based on the value of the syntax element and the properties of the luma support sample. For example, a value of 0 for the syntax element can indicate that cross-component filtering is not applied to the region, a value of 1 for the syntax element and the variance of the luma support is greater than a threshold can indicate that a filter with a first filter coefficient set is applied, a value of 1 for the syntax element and the variance of the luma support is not greater than a threshold can indicate that a filter with a second filter coefficient set is applied, a value of 2 for the syntax element and the variance of the luma support is greater than a threshold can indicate that a filter with a third filter coefficient set is applied, a value of 2 for the syntax element and the variance of the luma support is not greater than a threshold can indicate that a filter with a fourth filter coefficient set is applied, and so on.

[0189] The Appendix to commonly assigned U.S. Provisional Patent Application No. 62 / 865,933, filed June 24, 2019, which is incorporated herein by reference, provides examples of datasets corresponding to implementations of the cross-component filter described herein. That is, in the Appendix, the dataset orgBlock represents the sample values of the original 32×32U component block; the dataset preFilteringBlock represents the sample values of the reconstructed 32×32U component block; the dataset orgError represents the reconstruction error between the original 32×32U component block and the reconstructed 32×32U component block; the dataset bestSupportY represents the sample values of the 67×68Y component block that provides filter support for the filtered reconstructed 32×32U component block; the dataset bestSupportU represents the sample values of the 36×36U component block that provides support for the filtered reconstructed 32×32U component block; the dataset bestSupportV represents the sample values of the 36×36UV block that provides support for the filtered reconstructed 32×32U component block; The dataset coeffY represents the filter coefficients in a 5×6 filter applied to the sample values of the 67×68 Y component support block; the dataset coeffU represents the filter coefficients in a 5×5 filter applied to the sample values of the 36×36 U component support block; the dataset coeffU represents the filter coefficients in a 5×5 filter applied to the sample values of the 36×36 V component support block; the dataset bestOutput represents the sample values of the filtered reconstructed 32×32 U component block; the dataset bestError represents the error between the original 32×32 U component block and the filtered reconstructed 32×32 U component block; the dataset signedimprovement equals Abs(orgError) - Abs(bestError) and represents the change in reconstruction error resulting from filtering; and the dataset positiveimprovement represents the reconstructed sample values for which the reconstruction error is reduced due to filtering. Thus, according to the techniques herein, the reconstruction error of one or more or a majority of samples can be reduced by applying a cross-component filter. It should be noted that for specific types of video content, the amount of reconstruction error improved according to the mathematical relationship can have different results based on how the perceived visual quality of the video is improved. That is, for example, a relatively small signedimprovement value may result in a relatively significant improvement in visual quality.

[0190] As described above, the cross-component filter unit 300 can generally operate by taking a first color component and one or more second color components as input and providing an enhanced first color component as output. That is, the filtering process performed by the cross-component filter unit 300 can take as input luma sample values, which can be used to predict the difference between the original corresponding chroma sample values and output refined chroma sample values based on the prediction. Referring again to Figure 8 The example shown, Figure 10 is a conceptual diagram illustrating an example of using cross-component filtering to reduce reconstruction error, in accordance with one or more techniques of this disclosure. Figure 10 An example is provided in which the reconstruction error is reduced by taking the average of the support samples, and if the average is greater than 90, adding the average divided by 10 to the reconstructed samples; and if the average is not greater than 90, subtracting the average divided by 10 from the reconstructed samples. That is, in this example, the prediction filter is generally described as follows: if the support average is greater than threshold1, then weight1 multiplied by the support average is added; otherwise, weight2 multiplied by the support average is added. Figure 10 As shown in the illustrated example, post-filtering the chrominance reconstruction error provides reconstruction error reduction.Thus, according to the techniques herein, cross-component filtering can reduce reconstruction error according to cross-component filters defined in terms of logistic functions, thresholds, weights, and the like.

[0191] As described above, JVET-N1001 and JVET-O2001 include a deblocking filter, a SAO filter, and an ALF filter, and the cross-component filter technique described herein can be performed at various points in the filter chain, i.e., at various stages of loop filtering. 11A to 11D is a block diagram illustrating an example of a cross-component filter unit that can be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure. 11A to 11D, the luma SAO filter unit 402 represents a filtering unit configured to perform SAO filtering (e.g., the SAO filtering provided in JVET-N1001 or JVET-O2001) on the luma sample value Y; the Cb SAO filter unit 404 represents a filtering unit configured to perform SAO filtering (e.g., the SAO filtering provided in JVET-N1001 or JVET-O2001) on the chroma Cb sample value; The SAO filter unit 406 represents a filtering unit configured to perform SAO filtering (e.g., the SAO filtering provided in JVET-N1001 or JVET-O2001) on the Cb sample value; the luma ALF filter unit 408 represents a filtering unit configured to perform ALF filtering (e.g., the ALF filtering provided in JVET-N1001 or JVET-O2001) on the luma sample value Y; the chroma ALF filter unit 410 represents a filtering unit configured to perform ALF filtering (e.g., the ALF filtering provided in JVET-N1001 or JVET-O2001) on the chroma sample value. Unit; Luma deblocking filter unit 416 represents a filtering unit configured to perform deblocking filtering (e.g., the deblocking filtering provided in JVET-N1001 or JVET-O2001) on luma sample values Y; Cb deblocking filter unit 418 represents a filtering unit configured to perform deblocking filtering (e.g., the deblocking filtering provided in JVET-N1001 or JVET-O2001) on Cb sample values; and Cr deblocking filter unit 420 represents a filtering unit configured to perform deblocking filtering (e.g., the deblocking filtering provided in JVET-N1001 or JVET-O2001) on Cr sample values. In addition, in 11A to 11D , Cb cross-component filter unit 412 represents an example of a cross-component filter configured to generate 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 Cr refinement ΔCr according to one or more of the techniques described herein. 11A to 11D As shown, cross-component filtering according to the techniques herein can be applied at various points in the filter chain. That is, a cross-component filtering input can be received at various points in the filter chain, and a cross-component filtering refinement can be output at various points in the filter chain. It should be noted that in Figure 11B In the example shown, the input to the luma deblocking is used as the input to the filtering, which may have the advantage of reducing the line buffer requirements. Figure 11C In the example shown, the output of luma deblocking is used as input to filtering, which may have the advantage of reducing line buffer requirements while slightly improving coding efficiency. Figure 11DIn the example shown, the output of the ALF luma is used as input to the filtering, which may have the advantage of improved coding efficiency.

[0192] Furthermore, the cross-component filter techniques described herein may also include performing clipping operations at various points in the filter chain, i.e., for example, at various stages of the loop filter. FIG. 12A to FIG. 12B is a block diagram illustrating an example of a cross-component filter unit that can be configured to reduce reconstruction error according to one or more techniques of this disclosure. FIG. 12A to FIG. 12B , the elements with the same number are referred to above with respect to Figures 11A to 11B As described above, the clipping units 422A to 422D may be configured to perform a clipping function based on the output bit depth of the corresponding component, such as Clip3 (0, 2 BitDepthC -1, *). It should be noted that the clipping units 422A to 422D may be selectively enabled based on whether a particular type of filtering is performed.

[0193] 13A to 13B is a block diagram illustrating an example of a cross-component filter unit that may be configured to reduce reconstruction error in accordance with one or more techniques of this disclosure. 13A to 13B It is further shown that cross-component filtering according to the techniques herein can be applied at various points in the filtering chain. 13A to 13C , the commonly numbered elements are as described above.

[0194] Furthermore, it should be noted that in some cases, there may be more than three video data components, e.g., YUV+depth. The cross-component filtering techniques described herein are generally applicable to these cases. In some cases, pre-processing of the input sample values from each component may be performed prior to the filtering operation. For example, the input sample values may 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 formula provides an option for pre-processing the input sample values:

[0195] I j (g(x,y,i,j)+x j , h(x, y, i, j)+y j )

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

[0197] Furthermore, another option for preprocessing the input sample values may be as follows:

[0198] I j (g(x,y,i,j)+x j , h(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))

[0199] in,

[0200] I'j(u, v): the sample value at position (u, v) before processing

[0201] derivedValue: is a value derived from a subset of the values in I'j(*), such as (a)I at the origin j (g(x, y, i, j) + 0, h(x, y, i, j) + 0), the area around the origin is (b)

[0202] a: is a value received in the bitstream / a value inferred from data received in the bitstream / a value derived from a subset of the values in I'j(*), *); and

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

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

[0205] Furthermore, in one example, a generalization of the input used in the cross-component filter operation may be as follows:

[0206]

[0207] in,

[0208] G n () is used to combine the sample values from the components and obtain the value corresponding to the cj ,y cj ) is a function of the derived value of each coefficient value. Function G i () may depend on chroma format, chroma location type, color gamut, filter shape

[0209] In one example, cross-component filtering can be performed based on: defining a region of support for luma; upsampling the chroma components by 2X for 4:2:0 to use as input; subtracting a derived value (e.g., 512 for 10-bit chroma, or a local average) from the support for the corresponding chroma component; then taking the sample product of the luma sample values and the chroma sample values corresponding to the defined region of support; and using the product as one of the inputs to the filtering operation.

[0210] Furthermore, it should be noted that in some examples, the cross-component filtering techniques described herein can be performed on the prediction or the residual. In one example, if domain coding is used instead of progressive coding, then for luma support samples: in one example, sample values from one of the corresponding luma domains can be used, and in another example, sample values from both luma domains can be used.

[0211] As described above, for each support sample, a filter coefficient may be determined and signaled. That is, for example, 5×5, 5×6, 6×6, and / or 6×6 filter coefficients may be signaled. 14A to 14C An example of signaling filter coefficients for a 5x5 filter is shown. Figures 14D to 14F An example of signaling filter coefficients for a 5x6 (and similarly, 6x5) filter is shown. 15A to 15D An example of signaling filter coefficients for a 6×6 filter is shown. 14A to 15D In each figure of , the corresponding filter coefficient of the filter is represented by C N Therefore, in the same C N In the case where multiple locations of the same filter are provided, the filter coefficients are the same, i.e. shared. This way, the number of filter coefficients signaled for the filter is reduced. For example, in Figure 14D In , 14 filter coefficients are signaled for 18 supporting positions.

[0212] In one example, it may be desirable to limit the number of line buffers within an architecture that processes samples on a CTU-by-CTU basis. That is, for example, a virtual line boundary provides a location for each CTU where samples above the horizontal VB can be processed before a lower CTU comes in, but samples below the horizontal VB cannot be processed until a lower CTU becomes available. JVET-N1001 and JVET-O2001 define a horizontal virtual line boundary (VB) for luma ALF and luma SAO. According to the techniques herein, this VB may be reused for the luma input-chroma output filters defined herein. Furthermore, a vertical VB may be reused for the vertical luma input-chroma output filters defined herein, and / or a subset of the VB may be reused for the luma input-chroma output filters defined herein. Furthermore, there are two defined cases for which supported samples in the luma component may be derived / modified: when a predetermined luma sample (corresponding to, for example, a chroma sample decoded based on a chroma position type) is above the VB and support spanning the VB is supported; and when a predetermined luma sample (corresponding to, for example, a chroma sample decoded based on a chroma position type) is below the VB and support spanning the VB is supported. In one example, the predetermined sample is at a position corresponding to a chroma sample decoded based on a chroma position type. Figure 14D The 5×6 luma support is shown with samples at position C6 of coefficient. 16A to 16D is a conceptual diagram illustrating an example of a virtual line buffer that may be used for cross-component filtering according to one or more techniques of this disclosure. Figure 16A In , 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. Figure 16B In

[15] , samples below the horizontal VB are obtained by duplicating samples below and closest to the virtual line boundary and in the same column. In one example, the luma VB is four samples from the horizontal CTU boundary. In one example, each CTU, SAO, and ALF can process samples to the left of the vertical VB before the right CTU enters, but cannot process samples to the right of the vertical VB before the right CTU is available. Example modifications when supporting crossing vertical virtual boundaries (VBs) are in

[15] 16C to 16D As shown in Figure 16C In , the samples to the right of vertical VB are obtained by copying the samples to the left and closest to the virtual line boundary and in the same row. Figure 16DIn the example, samples to the left of the vertical VB are obtained by copying the samples to the right and closest to the imaginary line boundary and in the same row. In one example, the luma VB is four samples from the vertical CTU boundary. In one example, according to the techniques herein, with respect to generating samples for the horizontal VB, the vertical and horizontal axes passing through the center of the support region can be considered. The copied samples can be obtained by copying samples that are the same distance from the vertical axis but on opposite sides of the vertical axis in a column. In one example, the copied samples can be copied from rows that are the same distance from the horizontal axis but on opposite sides. In one example, according to the techniques herein, with respect to generating samples for the vertical VB, the vertical and horizontal axes passing through the center of the support region can be considered. The copied samples can be obtained by copying samples that are the same distance from the vertical axis but on opposite sides in a row. In one example, the copied samples can be copied from columns that are the same distance from the vertical axis but on opposite sides. In one example, according to the techniques herein, with respect to generating samples for the VB, samples can be obtained by symmetrical padding. That is, with respect to the horizontal VB, samples can be copied from the same column at the same sample distance from the VB and with respect to the vertical VB, samples can be copied from the same row at the same sample distance from the 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 tree block filtering process for luma samples," provides a padding scheme for luma samples across virtual boundaries for use with respect to the ALF process. In one example, according to the techniques herein, a similar padding scheme can be used for cross-component filtering. In one example, according to the techniques herein, cross-component filtering can be disabled when one or more supporting samples are unavailable, for example due to VB.

[0213] In one example, according to the techniques herein, cross-component filtering includes scaling the output of the cross-component filtering before adding the output to the corresponding chroma ALF output. That is, the scaling operation can be used to convert the filter coefficients to integers, such as as follows:

[0214]

[0215] In one example, factor = 2 BitDepthC , in another example, factor = 2 (BitDepthC-1) ), in another example, factor = 2 (8-1)

[0216] In one example, the scaling factor may be used to adjust the output of the cross-component filtering as follows:

[0217]

[0218] It should be noted that if factor = 2 x , then this corresponds to right shift integer rounding (f i (x, y)+2 (x-1) )>>x

[0219] As described above, filter data specifying the derived filters may be signaled to a video decoder. In one example, there may be three main aspects to signaling filter data: turning filters on / off; local control of tools, e.g., enabling tools in some spatial regions but not in others; and signaling of specific filters. In one example, a parameter set (e.g., a sequence parameter set) may conditionally include a flag to enable / disable a filter. In one example, the flag may indicate whether one or more filters, e.g., an ALF filter and a cross-component filter, are enabled. In one example, slice-level signaling of filter coefficients may be used. In another example, one or more pointers to an APS containing the corresponding filter coefficient data may be sent in a slice header. Tables 3 to 4 show examples of syntax that may be included in a slice header for signaling filter coefficients according to this example.

[0220]

[0221] Table 3

[0222]

[0223]

[0224] Table 4

[0225] For Tables 3 and 4, in one example, the semantics may be based on the following:

[0226] slice_cross_component_alf_cb_enabled_flag equal to 0 specifies that the cross-component Cb filter is not applied to the Cb color component. 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.

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

[0228] slice_cross_component_alf_cb_aps_id specifies the adaptation_parameter_set_id indexed by the Cb color component of the slice. When slice_cross_component_alf_cb_aps_id is not present, it is inferred to be equal to slice_alf_aps_id_luma[0]. The TemporalId of ALF APS NAL units with adaptation_parameter_set_id equal to slice_cross_component_alf_cb_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0229] slice_cross_component_alf_cr_aps_id specifies the adaptation_parameter_set_id indexed by the Cr color component of the slice. When slice_cross_component_alf_cr_aps_id is not present, it is inferred to be equal to slice_alf_aps_id_luma[0]. The TemporalId of the ALF APS NAL unit with the same value as slice_cross_component_alf_cr_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit.

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

[0231] AltCCSamplesCbW=AltCCSamplesCbH=2 (slice _cross_component_alf_cb_log2_control_size_minus4+4)

[0232] slice_cross_component_alf_cb_log2_control_size_minus4 shall be in the range of 0 to 3, inclusive.

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

[0234] AlfCCSamplesCrW=AlfCCSamplesCrH=2 (slice _cross_component_alf_cr_log2_control_size_minus4+4)

[0235] slice_cross_component_alf_cr_log2_control_size_minus4 shall be in the range of 0 to 3, inclusive.

[0236] alf_luma_filter_signal_flag equal to 1 specifies that the luma filter bank is signaled. 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.

[0237] 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.

[0238] 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.

[0239] alf_cross_component_cr_filter_signal_flag equal to 1 specifies that a cross-component Cr filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that a 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.

[0240] alf_cross_component_cb_min_eg_order_minus1 plus 1 specifies the minimum order of the exponential Golomb code used for cross-component Cb filter coefficient signaling. The value of alf_cross_component_cb_min_eg_order_minus1 should be in the range of 0 to 9 (inclusive). It should be noted that in some examples, this range may change.

[0241] 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 of 0 to 9 (inclusive). It should be noted that in some examples, this range may change.

[0242] 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.

[0243] 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:

[0244] 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]

[0245] 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.

[0246] 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:

[0247] 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]

[0248] alf_cross_component_cb_coeff_delta_abs[j] specifies the absolute value of the j-th coefficient delta of the cross-component Cb filter being signaled. When alf_luma_cross_component_cb_coeff_delta_abs[j] is not present, it is inferred to be equal to 0.

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

[0250] 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]

[0251] k=expGoOrderCb[golombOrderIdxCb[j]]

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

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

[0254] 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]

[0255] k=expGoOrderCr[golombOrderIdxCr[j]]

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

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

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

[0259] When alf_cross_component_cb_coeff_sign[j] is not present, it is inferred to be equal to 0.

[0260] With element AlfCCCoeff Cb [adaptation_parameter_set_id][j], cross-component Cb filter coefficient AlfCCCoeff for j=0..13 Cb [adaptation_parameter_set_id] is derived as follows:

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

[0262] Bitstream compliance requirements AlfCCCoeff Cb [adaptation_parameter_set_id][j] with j=0..13 should have a value between -2 10 -1 to 210 The range is -1 (including the end value).

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

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

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

[0266] When alf_cross_component_cr_coeff_sign[j] is not present, it is inferred to be equal to 0.

[0267] With element AlfCCCoeff Cr [adaptation_parameter_set_id][j], cross-component Cr filter coefficient AlfCCCoeff, j=0..13 Cr [adaptation_parameter_set_id] is derived as follows:

[0268] AlfCCCoeffx r [adaptation_parameter_set_id][j]=alf_cross_component_cr_coeff_abs[j]*(1-2*alf_cross_component_cr_coeff_sign[j])

[0269] Bitstream compliance requirements AlfCCCoeff Cr [adaptation_parameter_set_id][j], the value of j=0..13 should be between -2 10 -1 to 2 10 The range is -1 (including the end value).

[0270] It should be noted that -2 10 -1 to 2 10 The range of -1 may vary. Note that in some examples, the range may depend on the bit depth of luma / chroma or a subset thereof.

[0271] For Table 4, in one example, the alf_data() syntax structure provided in Table 5A may be used.

[0272]

[0273] Table 5A

[0274] For Table 5A, in one example, the semantics may be based on the following:

[0275] alf_luma_filter_signal_flag equal to 1 specifies that the luma filter bank is signaled. 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.

[0276] 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.

[0277] alf_cross_component_cb_filter_signal_flag equal to 1 specifies that a cross-component Cb filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that a 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.

[0278] 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.

[0279] alf_cross_component_cb_min_eg_order_minus1 plus 1 specifies the minimum order of the exponential Golomb code used for cross-component Cb filter coefficient signaling. The value of alf_cross_component_cb_min_eg_order_minus1 should be in the range of 0 to 9 (inclusive). It should be noted that in some examples, this range may change.

[0280] 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 of 0 to 9 (inclusive). It should be noted that in some examples, this range may change.

[0281] 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.

[0282] 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:

[0283] 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]

[0284] 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.

[0285] 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.

[0286] 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.

[0287] 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:

[0288] expGoOrderCr[i]=(i==0?alf_cross_component_cr_min_eg_orderminus1+1:expGoOrderCr[i-1])+alf__cross_component_cr_eg_order_increase_flag[i]

[0289] In one example, a predetermined value corresponding to the minimum order of the exponential Golomb code used for cross-component Cr filter coefficient signaling is used.

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

[0291] alf_cross_component_cb_coeff_abs[j] specifies the absolute value of the j-th coefficient of the signaled cross-component Cb filter. When alf_cross_component_cb_coeff_abs[j] is not present, it is inferred to be equal to 0.

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

[0293] 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]

[0294] k=expGoOrderCb[golombOrderIdxCb[j]]

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

[0296] alf_cross_component_cr_coeff_abs[j] specifies the absolute value of the j-th coefficient of the signaled cross-component Cr filter. When alf_cross_component_cr_coeff_abs[j] is not present, it is inferred to be equal to 0.

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

[0298] 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]

[0299] k=expGoOrderCr[golombOrderIdxCr[j]]

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

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

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

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

[0304] When alf_cross_component_cb_coeff_sign[j] is not present, it is inferred to be equal to 0.

[0305] With element AlfCCCoeff Cb [adaptation_parameter_set_id][j], cross-component Cb filter coefficient AlfCCCoeff for j=0..13 Cb[adaptation_parameter_set_id] is derived as follows:

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

[0307] Bitstream compliance requirements AlfCCCoeff Cb [adaptation_parameter_set_id][j], the value of j=0..13 should be between -2 10 -1 to 2 10 The range is -1 (including the end value).

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

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

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

[0311] When alf_cross_component_cr_coeff_sign[j] is not present, it is inferred to be equal to 0.

[0312] With element AlfCCCoeff Cr [adaptation_parameter_set_id][j], cross-component Cr filter coefficient AlfCCCoeff, j=0..13 Cr [adaptation_parameter_set_id] is derived as follows:

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

[0314] Bitstream compliance requirements AlfCCCoeff Cr [adaptation_parameter_set_id][j], the value of j=0..13 should be between -2 10 -1 to 2 10 The range is -1 (including the end value).

[0315] In one example, the alf_data() syntax structure provided in Table 5B may be used. Note that in Table 5B, when signaling coefficients in APS, minus 1 encoding is used to signal the number of filters.

[0316]

[0317]

[0318] Table 5B

[0319] For Table 5B, in one example, the semantics may be based on the following:

[0320] alf_cross_component_cb_filter_signal_flag equal to 1 specifies that a cross-component Cb filter bank is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that a 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.

[0321] 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.

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

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

[0324] alf_cross_component_cb_min_eg_order_minus1[k] plus 1 specifies the minimum order of the exponential Golomb code used for signaling the k-th cross-component Cb filter coefficient set. The value of alf_cross_component_cb_min_eg_order_minus1[k] shall be in the range of 0 to 9, inclusive.

[0325] 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 k-th cross-component Cb filter coefficient set signaling 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 k-th cross-component Cb filter coefficient set signaling is not incremented by 1.

[0326] 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:

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

[0328] alf_cross_component_cb_coeff_abs[k][j] specifies the absolute value of the j-th coefficient of the k-th cross-component Cb filter bank being signaled. When alf_cross_component_cb_coeff_abs[k][j] is not present, it is inferred to be equal to 0.

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

[0330] golombOrderIdxCb[] = {0, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1, 2, 1} [Note that these can be used to categorize the coefficients into 3 categories, each using the same order 1 exponential Golomb code]

[0331] k=expGoOrderCb[golombOrderIdxCb[j]]

[0332] alf_cross_component_cb_coeff_sign[k][j] specifies the sign of the j-th coefficient of the k-th cross-component Cb filter coefficient set as follows:

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

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

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

[0336] With element AlfCCCoeff Cb [adaptation_parameter_set_id][k][j], cross-component Cb filter coefficient AlfCCCoeff, j=0..13 Cb [adaptation_parameter_set_id][k] is derived as follows:

[0337] 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])

[0338] Bitstream compliance requirements AlfCCCoeff Cb [adaptation_parameter_set_id][k][j], the value of j=0..13 should be between -2 7 to 2 7 The range is -1 (including the end value).

[0339] alf_cross_component_cr_filters_signalled_minus1 specifies the number of cross-component Cr filter banks whose coefficients are signaled plus 1. The value of alf_cross_component_cr_filters_signalled_minus1 should be in the range of 0 to NumCcAlfCrFilters-1, inclusive.

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

[0341] alf_cross_component_cr_min_eg_order_minus1[k] plus 1 specifies the minimum order of the exponential Golomb code used for signaling the k-th cross-component Cr filter coefficient set. The value of alf_cross_component_cb_min_eg_order_minus1[k] shall be in the range of 0 to 9, inclusive.

[0342] 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 k-th cross-component Cr filter coefficient group signaling 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 k-th cross-component Cr filter coefficient group signaling is not incremented by 1.

[0343] 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:

[0344] 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_incrcase_flag[k][i]

[0345] alf_cross_component_cr_coeff_abs[k][j] specifies the absolute value of the j-th coefficient of the k-th cross-component Cr filterbank being signaled. When alf_cross_component_cr_coeff_abs[k][j] is not present, it is inferred to be equal to 0.

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

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

[0348] k=expGoOrderCr[golombOrderIdxCr[j]]

[0349] alf_cross_component_cr_coeff_sign[k][i] specifies the sign of the j-th coefficient of the k-th cross-component Cr filter coefficient set as follows:

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

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

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

[0353] The cross-component Cr filter coefficients AlfCCCoeffcr[adaptation_parameter_set_id][k][j] with elements AlfCCCoeffCr[adaptation_parameter_set_id][k][j], _i = 0..13 are derived as follows:

[0354] AlfCCCoeff Cr [adaptation_parameter_set_id][k][j]=alf_cross_component_cr_coeff_abs[k][j]*(1-2*alf_cross_component_cr_coeff_sign[k][j])

[0355] Bitstream compliance requirements AlfCCCoeff Cr [adaptation_parameter_set_id][k][j], the value of j=0..13 should be between -2 7 to 2 7 The range is -1 (including the end value).

[0356] For Table 5B, in one example, for the syntax elements alf_cross_component_cb_coeff_abs[k][i] and alf_cross_component_cr_coeff_abs[k][i], k representing the k-order exponential golomb-coded uek(v) may correspond to a predetermined value. Therefore, it is not necessary to signal "k" in the bitstream. In one example, in this case, the alf_data() syntax structure provided in Table 5C may be used.

[0357]

[0358] Table 5C

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

[0360] alf_cross_component_cb_coeff_abs[k][j] specifies the absolute value of the j-th coefficient of the k-th cross-component Cb filter bank being signaled. When alf_cross_component_cb_coeff_abs[k][j] is not present, it is inferred to be equal to 0.

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

[0362] alf_cross_component_cr_coeff_abs[k][j] specifies the absolute value of the j-th coefficient of the k-th cross-component Cr filterbank being signaled. When alf_cross_component_cr_coeff_abs[k][j] is not present, it is inferred to be equal to 0.

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

[0364] It should be noted that in the above examples, the coefficient values are indicated using a syntax element indicating the sign of the coefficient (e.g., alf_cross_component_cr_coeff_sign) and a syntax element indicating the absolute value of the coefficient (e.g., alf_cross_component_cr_coeff_abs). In one example, according to the techniques herein, one or more flags indicating whether the absolute value of the coefficient is greater than a specific value (e.g., greater than 1, greater than 2, etc.) and a syntax element indicating the absolute value of the coefficient based on the value of the one or more flags can be used to indicate the absolute value of the coefficient. For example, in one example, the encoding of a specific coefficient value can be based on the following semantics:

[0365] alf_cross_component_coeff_abs_greater_than_N_flag[k][j] specifies whether the absolute value of the j-th coefficient of the k-th cross-component filterbank being signaled is greater than N. In one example, the coefficient should be between -2 7 to 2 7-1 is within the range of (including the end value), and N can be 64.

[0366] alf_cross_component_coeff_abs[k][j] specifies the absolute value of the j-th coefficient of the k-th cross-component filterbank being signaled. When alf_cross_component_coeff_abs[k][j] is not present, it is inferred to be equal to 0.

[0367] alf_cross_component_coeff_sign[k][i] specifies the sign of the j-th coefficient of the k-th cross-component filter coefficient set as follows:

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

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

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

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

[0372] 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][_i])

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

[0374] In one example, the buffer for a subset of temporal layers or all temporal layers may be reset, for example, for a set of NALU types (e.g., corresponding to random access points such as IRAPs) or for a set of slice types (e.g., I-slices). In one example, the reset may imply a flush operation. In one example, the reset may imply setting the buffer to a predetermined set of values (e.g., 0, a fixed set of values for each TemporalID). The buffer reset operation may imply that the values stored in the buffer prior to an access unit (satisfying a predetermined set of conditions, e.g., NALU type indicating IRAP, slice type equal to I-slice) may not be used for that access unit and subsequently coded access units. In one example, when the buffer does not contain any coefficients, the syntax element indicating whether the filter coefficients from the buffer will be used may not be signaled but rather its value may be inferred. In one example, when the buffer does not contain any coefficients, the syntax element indicating whether the filter coefficients from the buffer will be used may be signaled as being restricted to a predetermined value.

[0375] Furthermore, in one example, filters signaled for leading pictures should not be used by trailing pictures of the associated IRAP picture. This is because leading pictures may be dropped from the bitstream during random access operations of the bitstream. As described above, according to the techniques herein, cross-component filters may be signaled using the following operations: reusing filters in the corresponding temporal sub-layer buffer and / or filters in the APS. It should be noted that in some cases, the APS may be signaled out-of-band, and thus in some cases, bitstream compliance may only require that the referenced APS be available.

[0376] As above relative to 9A to 9F As described above, the filter shape can be determined based on the chroma position type. It should be noted that the filter shape can include filter shapes for various types of filters. Furthermore, the filter shape can generally be described as representing the support and origin relative to the sample being filtered. In one example, the filter shape can be signaled for each cross-component filter in a parameter set: for example, SPS, PPS, VUI. In one example, when the filter shape affects the number of encoded filter coefficients, the filter shape can also be signaled in the APS or slice header. In one example, the filter shape can be used to determine the number of filter coefficients. In one example, filter coefficients can be reused. That is, in one example, a first-in-first-out (FIFO) buffer can be maintained for each component Cb / Cr for each temporal layer. In one example, the FIFO buffer size is 1 for each component and each temporal layer. In such an example, a flag can 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 buffer. In one example, the FIFO buffer size is 1 for each component and each temporal layer. In such an example, filter coefficients belonging to the same time layer or a lower time layer in the FIFO buffer can be reused. A syntax element (e.g., a flag) is received to indicate whether the filter coefficient in one of the FIFO buffers is reused, and if it is reused (e.g., the flag value is 1), the index of the FIFO buffer of the coefficient to be reused is received. The range of valid values of the index is determined based on the current time layer ID (e.g., 0 to the current time layer ID). ue(v) coding can be used to signal a value such as -(time layer of the FIFO buffer - current time layer). In another example, a truncated unary (with a TU maximum value based on the current time layer ID) can be used.

[0377] In one example, signaling local control of cross-component filters may include sending block-level control flags for all cross-components Cb and Cr 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 coded CTU of the control block. The remaining CTUs in the control block may infer the same value as in the first coded CTU of the control block. When the first coded CTU in the control block does receive a control flag, the control flag value may be inferred to be 0. In one example, the control flag is 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 four control blocks are present within a CTU, a different number of control block flags may be present for a partial CTU (e.g., at a boundary) compared to a full CTU. In one example, one control flag may be signaled for each CTU of a tile group / slice. In one example, the control flag may be signaled for the first CTU in a group of CTUs, and the same flag value may be inferred for the remaining CTUs in the group.

[0378] In one example, the cross-component filter coefficients for the cross-component filters carry their own independent parameter set, such as an APS. In one example, the cross-component filter coefficients are carried in a different parameter set, such as an APS, than the non-cross-component filters (e.g., ALF in JVET-N1001-v8). In one example, instead of a 5×6 filter, one embodiment may use the 7×7 ALF filtering process described in JVET-N1001-v8 regarding "Coding Treeblock Filtering Process for Luma Samples." This further reduces 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 to enable / disable the operations on a frame-by-frame and position-by-position basis. In one example, the filtering operations may also be implemented so that multiple filtering operations are available at each frame and / or position, and the signaling may be used to transmit these multiple filters and select among the available filters. In one example, an embodiment may use a 3×4 diamond filter. It should be noted that in other examples, other filter sizes and shapes (e.g., 3×3, 4×3, 4×4, etc.) may be used. In one example, when a 3×4 diamond filter is used, eight unique coefficients may be used. It should be noted that in other examples, for each filter size and shape described herein, the number of unique coefficients used and / or signaled may vary in order to optimize signaling overhead. In one example, when a 3×4 diamond filter is used, up to four unique filters may be specified for each component (e.g., at the sequence, picture, tile, or slice level), and one of the four may be selected when filtering is applied. In one example, according to the techniques herein, local region control flags may be shared between different chroma channels.

[0379] As described above, the application of cross-component filtering can be based on properties (e.g., variance and / or deviation) of samples included in the filter support region. In one example, a shared control flag and the properties of the samples included in the filter support region can be used to determine whether cross-component filtering is applied for one or both chroma channels. For example, in one example, for Cb, the value of the shared control flag can determine whether cross-component filtering is applied, and for Cr, the value of the shared control flag can further determine whether cross-component filtering is applied. As described above, in one example, cross-component filtering can be disabled when one or more support samples are unavailable, for example, due to VB. Therefore, the sample properties included in the filter support region used to determine whether cross-component filtering is applied can include availability. In one example, according to the techniques herein, whether cross-component filtering is applied can be based on whether a threshold number of support samples are available (e.g., whether 50% or more of the support samples are available). Similarly, when one or more support samples are unavailable, whether cross-component filtering is applied can be based on whether a defined padding process can generate values for each of the unavailable support samples. That is, cross-component filtering can be disabled if the defined padding process does not provide a mechanism for generating values for the unavailable samples. Additionally, cross-component filtering may be disabled if the location of the filter support region according to a specified support sample (e.g., the center sample of a diamond support) is within a specified range of the VB. For example, in one example, cross-component filtering may be disabled if the center sample of the diamond filter support region is below and within 2 samples of the horizontal VB.

[0380] As described above, in JVET-N1001 and JVET-O2001, the CTU is partitioned according to a quadtree plus multi-type tree (QTMT or QT+MTT) structure. In JVET-N1001 and JVET-O2001, for I slices, each CTU can be partitioned into coding units with 64×64 luma samples using implicit quadtree partitioning, and these coding units can be the roots of two separate coding tree syntax structures, i.e., one for the luma channel and one for the chroma channel. In either case, the local region control flag value can be signaled / determined within the syntax of the partition tree signaling. That is, for example, the syntax and semantics for partitioning the chroma channels into CUs (i.e., the chroma coding tree) can include signaling (implicit and / or explicit) indicating the local region control flag value. For example, JVET-N1001 and JVET-O2001 define the variable cbSubdiv=2*cqtDepth, where cqtDepth is the current coding quadtree depth, and the depth at the CTU is 0. In one example, according to the technology of this article, the minimum tree node with cbSubdiv less than or equal to a given threshold can represent a parent node control flag signaling group, where all blocks resulting from further partitioning belong to the same control flag signaling group. That is, the local area control flag at the parent CU can be used to infer the value of the local area control flag at any resulting child CU. Tables 6 and 7 show examples of syntax and variable assignments for determining local area control flag values. That is, in Table 6, the minimum tree node with cbSubdiv less than or equal to a given threshold can represent a parent node control flag signaling group. Table 7 provides the corresponding coding unit syntax.

[0381]

[0382] Table 6

[0383]

[0384] Table 7

[0385] In the example shown in Table 6, the CC ALF control signaling depth representation threshold for a slice. In one example, the threshold can be signaled for a slice, sequence, or picture. 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 the vertical position yCtrlBlk are set equal to CuCcAlfTopLeftX and CuCcAlfTopLeftY, respectively. In addition, the current chroma control block is a rectangular area within the 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, and the top left luma sample position of the coding tree node is assigned to the variables CuCcAlfTopLeftX and CuAlfCcTopLeftY. It should be noted that in one example, there may be a separate set of variables for each chroma component.

[0386] For Table 7, 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. In addition, the Cu CC Alf control flag Val is set to cross_component_chroma_alf_control_flag. Therefore, in this example, as long as the condition for starting a new control flag signaling group is true (i.e., CC ALF is enabled for the slice and cuSubdiv is not above the limit), the internal flag "IsCuCcAlfControlFlagCoded" is set to 0 and the current tree node origin is saved as the control flag signaling group origin in the CuCcAlfTopLeftX, CuCcAlfFopLeftY variables. 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 flag signaling group is found. A coding unit may inherit its control flag values from the last coding tree node origin until a new control flag signaling group is found. In one example, when a local control region syntax element is present in a coding unit, then IsCuCcAlfControlFlagCoded is set equal to 1. It should be noted that JVET-N1001 and JVET-O2001 provide for indicating the quantization parameter group at which the lowest depth of the QP value is signaled. In one example, the CC ALF control signaling may be an aligned quantization parameter group. That is, child nodes within a quantization parameter group share QP values and CC ALF control values. Furthermore, in one case, the value of the CC ALF control value may be based on or completely derived 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 to be 0).

[0387] As described above, the signaling of cross-component filtering may include signaling of a specific filter (e.g., a filter shape and / or filter coefficients). In one example, according to the techniques herein, the value of a syntax element may indicate whether cross-component filtering is applied for a region, and when cross-component filtering is applied for a region, indicate a specific filter used 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 having a first filter coefficient group is applied, a value of 2 may indicate that a filter having a second filter coefficient group is applied, and so on. In one example, the region may be a CTU. Table 8 shows an example of the syntax included in the coding_tree_unit() syntax structure according to the techniques herein. That is, in the example shown in Table 8, the syntax elements alf_cross_component_cb_idc and alf_cross_component_cr_idc indicate whether cross-component filtering is applied, and when cross-component filtering is applied, indicate the filter.

[0388]

[0389]

[0390] Table 8

[0391] For Table 8, in one example, the semantics may be based on the following:

[0392] PicWidthInChromaSamples=pic_width_in_luma_samples / SubWidthC

[0393] PicHeightInChromaSamples=pic_height_in_luma_samples / SubHeightC

[0394] AlfCCSamplesCbLog2W=AlfCCSamplesCbLog2H=slice_cross_component_alf_cb_log2_control_size_minus4+4

[0395] AlfCCSamplesCrLog2W=AlfCCSamplesCrLog2H=slice_cross_component_alf_cr_log2_control_size_minus4+4

[0396] In addition, it should be noted that:

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

[0398] When the local control region does not span CTUs, the check (xCtbC == xStartC &&yCtbC == yStartC) can be omitted.

[0399] In one example, (xEndC>=PicWidthInChromaSamples) and (yEndC>=PicHeightInChromaSamples), the upper limits provided by PicWidthInChromaSamples and PicHeightInChromaSamples may instead correspond to the right and bottom slice / tile / brick / CTU boundaries, respectively.

[0400] 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 with the Cb chroma sample at the top left chroma position (xC, yC). alf_cross_component_cb_idc[xC>>AlfCCSamplesCbLog2W][yC>>AlfCCSamplesCbLog2H] equal to m, where m is greater than 0, indicates that the k=(m-1)th cross-component Cb filter bank is applied to the block with the Cb chroma sample at the top left chroma position (xC, yC)

[0401] 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 with the Cr chroma sample at the top left chroma position (xC, yC). alf_cross_component_cr_idc[xC>>AlfCCSamplesCrLog2W][yC>>AlfCCSamplesCrLog2H] equal to m, where m is greater than 0, indicates that the k=(m-1)th cross-component Cr filter bank is applied to the block with the Cr chroma sample at the top left chroma position (xC, yC)

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

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

[0404] In one example, according to the techniques herein, the binarization of alf_cross_component_cb_idc and / or alf_cross_component_cr_idc can be truncated Rice (TR) binarization with a maximum value cMax (according to the number of signaled filter coefficient sets), and cRiceParam is equal to 0. Table 9 shows an example of truncated Rice binarization of alf_cross_component_cb_idc and / or alf_cross_component_cr_idc.

[0405] Indication value TR binarization (cRiceParam equals 0) 0 0 1 10 2 110 3 1110 … … cMax-1 1....10 contains (cMax-1) 1s cMax 1....11 contains cMax 1s

[0406] Table 9

[0407] in,

[0408] For CC ALF Cb, cMax is set to the corresponding (alf_cross_component_cb_filters_signalled_minus1 plus 1)

[0409] For CC ALF Cr, cMax is set to the corresponding (alf_cross_component_cr_filters_signalled_minus1 plus 1)

[0410] In one example, for alf_cross_component_cb_idc and / or alf_cross_component_cr_idc, only the first bin may be context coded (ie, other bins may be bypass coded). In one example, the context of the first bin may be derived as follows:

[0411] The inputs to this process are the luma position (x0, y0) specifying 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 width and height cbWidth and cbHeight of the current coding block in luma samples, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, and allowSplitQt derived in the coding tree semantics.

[0412] The output of this process is ctxInc.

[0413] The position (xNbL, yNbL) is set equal to (x0-1, y0), and the derivation process for the specified neighbor block availability is called, where the position (xCurr, yCurr) is set equal to (x0, y0), the neighboring position (xNbY, yNbY) is set equal to (xNbL, yNbL), checkPredModeY is set equal to FALSE, and cIdx is taken as input and the output is assigned to availableL.

[0414] The position (xNbA, yNbA) is set equal to (x0, y0-1), and the derivation process for the specified neighbor block availability is called, where the position (xCurr, yCurr) is set equal to (x0, y0), the neighboring position (xNbY, yNbY) is set equal to (xNbA, yNbA), checkPredModeY is set equal to FALSE, and cIdx is used as input, and the output is assigned to availableA.

[0415] The allocation of ctxInc is specified as follows, where condL and condA are specified in Table 10:

[0416] For the syntax elements alf_cross_component_cb_idc[x0][y0] and alf_cross_component_cr_idc[x0][y0]: ctxInc = (condL && availableL) + (condA && availableA) + ctxSetIdx * 3

[0417]

[0418] Table 10

[0419] For Table 17, in one example, each of the "==0" tests may be replaced with "!=0".

[0420] In one example, for alf_cross_component_cb_idc and / or alf_cross_component_cr_idc, all bins may be context coded, and each bin may use a separate context set as shown in Table 11.

[0421]

[0422]

[0423] Table 11

[0424] For Table 11, in one example, the derivation of the context may be as follows:

[0425] The inputs to this process are the luma position (x0, y0) specifying 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 width and height cbWidth and cbHeight of the current coding block in luma samples, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, and allowSplitQt derived in the coding tree semantics.

[0426] The output of this process is ctxInc.

[0427] The position (xNbL, yNbL) is set equal to (x0-1, y0), and the derivation process for the specified neighbor block availability is called, where the position (xCurr, yCurr) is set equal to (x0, y0), the neighboring position (xNbY, yNbY) is set equal to (xNbL, yNbL), checkPredModeY is set equal to FALSE, and cIdx is taken as input and the output is assigned to availableL.

[0428] The position (xNbA, yNbA) is set equal to (x0, y0-1), and the derivation process for the specified neighbor block availability is called, where the position (xCurr, yCurr) is set equal to (x0, y0), the neighboring position (xNbY, yNbY) is set equal to (xNbA, yNbA), checkPredModeY is set equal to FALSE, and cIdx is used as input, and the output is assigned to availableA.

[0429] The allocation of ctxInc is specified as follows, where condL and condA are specified in Table 12:

[0430] For the syntax elements alf_cross_component_cb_idc[x0][y0] and alf_cross_component_cr_idc[x0][y0]: ctxInc = (condL && availableL) + (condA && availableA) + ctxSetIdx * 3

[0431]

[0432] Table 12

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

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

[0435]

[0436] Table 13

[0437] For Table 13, in one example, the derivation of the context may be as follows:

[0438] The inputs to this process are the luma position (x0, y0) specifying 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 width and height cbWidth and cbHeight of the current coding block in luma samples, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, and allowSplitQt derived in the coding tree semantics.

[0439] The output of this process is ctxInc.

[0440] The position (xNbL, yNbL) is set equal to (x0-1, y0), and the derivation process for the specified neighbor block availability is called, where the position (xCurr, yCurr) is set equal to (x0, y0), the neighboring position (xNbY, yNbY) is set equal to (xNbL, yNbL), checkPredModeY is set equal to FALSE, and cIdx is taken as input and the output is assigned to availableL.

[0441] The position (xNbA, yNbA) is set equal to (x0, y0-1), and the derivation process for the specified neighbor block availability is called, where the position (xCurr, yCurr) is set equal to (x0, y0), the neighboring position (xNbY, yNbY) is set equal to (xNbA, yNbA), checkPredModeY is set equal to FALSE, and cIdx is used as input, and the output is assigned to availableA.

[0442] The allocation of ctxInc is specified as follows, where condL and condA are specified in Table 14:

[0443] For the syntax elements alf_cross_component_cb_idc[x0][y0] and alf_cross_component_cr_idc[x0][y0]: ctxInc = (condL && availableL) + (condA && availableA) + ctxSetIdx * 3

[0444]

[0445] Table 14

[0446] As provided above, with respect to the examples corresponding to Tables 8 and 9, the syntax elements a1f_cross_component_cb_idc[][] and alf_cross_component_cr_idc[][] are signaled in coding_tree_unit(), and the binarization of alf_cross_component_cb_idc[][] and alf_cross_component_cr_idc[][] depends on the corresponding values of the syntax elements alf_cross_component_cb_filters_signalled_minus1 and alf_cross_component_cr_filters_signalled_minus1. If alf_cross_component_cb_filters_signalled_minus1 and alf_cross_component_cr_filters_signalled_minus1 are included in an APS, then losing the APS containing the corresponding alf_cross_component_cb_filters_signalled_minus1 and alf_cross_component_cr_filters_signalled_minus1 will mean that the syntax elements alf_cross_component_cb_idc[][] and alf_cross_component_cr_idc[][] cannot be parsed. In one example, to mitigate / prevent potential unparseable syntax elements, the syntax element specifying the number of cross-component Cb / Cr filter banks, their coefficients and / or the binarization thereof providing alf_cross_component_cb_idc[][] and alf_cross_component_cr_idc[][] can be signaled in another syntax structure. For example, in one example, the syntax elements slice_alf_cross_component_cb_filters_signalled_minus1 and slice_alf_cross_component_cr_filters_signalled_minus1 based on the following semantics may be signaled in the slice header, and their values may be used for binarization of alf_cross_component_cb_idc[][] and alf_cross_component_cr_idc[][].That is, in TR binarization, cMax is equal to slice_alf_cross_component_cb_filters_signalled_minus1+1 for alf_cross_component_cb_idc[][], and cMax is equal to slice_alf_cross_component_cr_filters_signalled_minus1+1 for alf_cross_component_cr_idc[][]. It should be noted that, in one example, slice_alf_cross_component_cb_filters_signalled_minus1 may be included in the slice header syntax structure immediately following slice_cross_component_alf_cb_log2_control_size_minus4, and slice_alf_cross_component_cr_filters_signalled_minus1 may be included in the slice header syntax structure immediately following slice_cross_component_alf_cr_log2_control_size_minus4.

[0447] slice_cross_component_alf_cb_signalled_minus1 plus 1 specifies the maximum value of the syntax element alf_cross_component_cb_idc[][].

[0448] slice_cross_component_alf_cr_signalled_minus1 plus 1 specifies the maximum value of the syntax element alf_cross_component_cr_idc[][].

[0449] It should be noted that although signaling the number of filters in the slice header removes parsing dependencies, it may be beneficial to limit the number of filter syntax elements included in the slice header. In one example, the number of filter syntax elements in the slice header may be required to be the same as the number of filters signaled in the APS. Furthermore, in one example, the number of filter syntax elements in the slice header may not be required to be the same as the number of filters in the APS.

[0450] When the number of filter syntax elements in the slice header is not required to be the same as the number of filters in the APS, there are cases where (1) the number of filters signaled in the slice header is less than or equal to the number of filters signaled in the APS and (2) the number of filters signaled in the slice header is greater than the number of filters signaled in the APS. When the number of filters signaled in the slice header is greater than the number of filters signaled in the APS, filters must be defined for filter indices that exceed the number of filters in the APS. For example, if there are two signaled filters in the APS, but the signaling in the slice header indicates that four filters are available, the video decoder must take defined actions when receiving filter index 3 or 4. In one example, the decoder can disable CC-ALF processing in the region of filter index 3 or 4 (which may include using filters with all zero tap values). In another example, the video decoder can use filters that already exist in the APS. For example, if filter index 3 or 4 is received, the filter with index 2 can be used. In another example, if filter index 3 is received, the filter with index 1 may be used, and if filter index 4 is received, the filter with index 2 may be used. In another example, when filter index 3 and filter index 4 are received, fixed filters known at the encoder and decoder may be used. In the case where the number of filters signaled in the slice header is less than or equal to the number of filters signaled in the APS, no additional video decoder actions must be defined. However, asserting that this condition is allowed can have coding efficiency benefits. For example, a first slice can reference a first APS and use all M filters from the APS, and a second slice can also reference the first APS but use only the first N filters in the APS. This improves coding efficiency because (i) a second APS does not have to be sent for the second slice, and (ii) the bits required to signal the filter index in the second slice are smaller due to the smaller number of filters.

[0451] In one example, according to the techniques herein, implementation of cross-component filtering can be based on the following syntax and semantics. For the following syntax and semantics, in Table 15, the syntax elements alf_cross_component_cb_filter_signal_flag, alf_cross_component_cr_filter_signal_flag, alf_cross_component_cb_coeff_abs, alf_cross_component_cb_coeff_sign, alf_cross_component_cr_coeff_abs, and alf_cross_component_cr_coeff_sign are added to the alf_data() syntax structure provided in JVET-O2001. It should be noted that the alf_data() syntax structure provided in JVET-O2001 is provided in the adaptation parameter set syntax structure. In Table 16, the syntax elements slice_cross_component_alf_cb_enabled_flag, slice_cross_component_alf_cb_reuse_temporal_layer_filter_flag, slice_cross_component_alf_cb_aps_id, slice_cross_component_alf_cb_log2_control_size_minus4, slice_cross_component_alf_cr_enabled_flag, slice_cross_component_alf_cr_reuse_temporal_layer_filter_flag, slice_cross_component_alf_cr_aps_id and slice_cross_component_alf_cb_log2_control_size_minus4 are added to the slice_header() syntax structure provided in JVET-O2001. In Table 17, the syntax elements alf_cross_component_cb_flag and alf_cross_component_cr_flag are added to the coding_tree_unit() syntax structure provided in JVET-O2001.

[0452]

[0453]

[0454] Table 15

[0455]

[0456]

[0457] Table 16

[0458]

[0459]

[0460] Table 17

[0461] For Table 15, in one example, the semantics may be based on the following:

[0462] alf_luma_fiher_signal_flag equal to 1 specifies that the luma filter bank is signaled. alf_luma_fiher_signal_flag equal to 0 specifies that the luma filter bank is not signaled.

[0463] 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 ChromaArrayType is equal to 0, alf_chroma_filter_signal_flag shall be equal to 0.

[0464] The variable NumAlfFilters, which specifies the number of different adaptive loop filters, is set equal to 25.

[0465] alf_cross_component_cb_filter_signal_flag equal to 1 specifies that the cross-component Cb filter is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross-component Cb filter is not signaled. When ChromaArrayType is equal to 0, alf_cross_component_cb_filter_signal_flag shall be equal to 0.

[0466] alf_cross_component_cr_filter_signal_flag equal to 1 specifies that the cross-component Cr filter is signaled, and alf_cross_component_cr_filter_signal_flag equal to 0 specifies that the cross-component Cr filter is not signaled. When ChromaArrayType is equal to 0, alf_cross_component_cr_filter_signal_flag shall be equal to 0.

[0467] alf_luma_clip_flag equal to 0 specifies that linear adaptive loop filtering is applied to the luma component. alf_luma_clip_flag equal to 1 specifies that nonlinear adaptive loop filtering may be applied to the luma component.

[0468] alf_luma_num_filter_signalled_minus1 plus 1 specifies the number of adaptive loop filter categories whose luma coefficients can be signaled. The value of alf_luma_num_filters_signalled_minus1 should be in the range of 0 to NumAlfFilters-1, inclusive.

[0469] alf_luma_coeff_delta_idx[filtIdx] specifies the index of the signaled adaptive loop filter luma coefficient delta for the filter type indicated by filtIdx, ranging from 0 to NumAlfFilters-1. When alf_luma_coeff_delta_idx[filtIdx] is not present, it is inferred to be equal to 0. The length of alf_luma_coeff_delta_idx[filtIdx] is Ceil(Log2(alf_luma_filters_signalled_minus1+1)) bits.

[0470] alf_luma_coeff_signalled_flag equal to 1 indicates that alf_luma_coeff_flag[sfIdx] is signaled. alf_luma_coeff_signalled_flag equal to 0 indicates that alf_luma_coeff_flag[sfIdx] is not signaled.

[0471] alf_luma_coeff_flag[sfIdx] equal to 1 specifies that the coefficients of the luma filter indicated by sfIdx are signaled. alf_luma_coeff_flag[sfIdx] equal to 0 specifies that all filter coefficients of the luma filter indicated by sfidx are set equal to 0. When not present, alf_luma_coeff_flag[sfIdx] is set equal to 1.

[0472] alf_luma_coeff_abs[sfidx][j] specifies the absolute value of the j-th coefficient of the signaled luma filter indicated by sfIdx. When alf_luma_coeff_abs[sfIdx][j] is not present, it is inferred to be equal to 0.

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

[0474] alf_luma_coeff_sign[sfIdx][j] specifies the sign of the j-th luma coefficient of the filter indicated by sfIdx as follows:

[0475] If alf_luma_coeff_sign[sfIdx][j] is equal to 0, the corresponding luma filter coefficient has a positive value.

[0476] - Otherwise (alf_luma_coeff_sign[sfIdx][j] is equal to 1), the corresponding luma filter coefficient has a negative value.

[0477] When alf_luma_coeff_sign[sfIdx][j] is not present, it is inferred to be equal to 0.

[0478] The variable filtCoeff[sfIdx][j] with sfIdx=0..alf_luma_num_filters_signalled_minus1, j=0..11 is initialized as follows:

[0479] filtCoeff[sfIdx][j]=alf_luma_coeff_abs[sfIdx][j]*(1-2*alf_luma_coeff_sign[sfIdx][j])

[0480] With element AlfCoeff L[adaptation_parameter_set_id][filtIdx][j], filtIdx=0..NumAlfFilters-1 and luma filter coefficients AlfCoeff j=0..11 L [adaptation_parameter_set_id] is derived as follows:

[0481] Alf Coeff L [adaptation_parameter_set_id][filtIdx][j]=filtCoeff[alf_luma_coeff_delta_idx[filtIdx]][j]

[0482] The fixed filter coefficients AlfFixFiltCoeff[i][j], i=0..64, j=0..11 and the class to filter maps AlfClassToFiltMap[m][n], m=0..15 and n=0..24 are derived as follows:

[0483]

[0484]

[0485]

[0486]

[0487]

[0488] Bitstream compliance requirement AlfCoeff L [adaptation_parameter_set_id][filtIdx][j], filtIdx=0..NumAlfFilters-1, j=0..11, the value should be between -2 7 to 2 7 The range is -1 (including the end value).

[0489] alf_luma_clip_idx[sfIdx][j] specifies the clipping index of the clipping value used before multiplication by the j-th coefficient of the signaled luma filter indicated by sfIdx. Bitstream conformance requires that the value of alf_luma_clip_idx[sfIdx][j], sfIdx=0..alf_luma_num_filters_signalled_minus1 and j=0..11, shall be in the range of 0 to 3 (inclusive).

[0490] Has element AlfClip L [adaptation_parameter_set_id][filtIdx][j], luminance filter clipping value AlfClip where filtIdx=0..NumAlfFilters-1 and j=0..11 L [adaptation_parameter_set_id] is derived as specified in Table 18, depending on bitDepth being set equal to BitDepth Y And clipIdx is set equal to alf_luma_clip_idx[alf_luma_coeff_delta_idx[filtIdx]][j].

[0491] alf_chroma_num_alt_flter_minus1 plus 1 specifies the number of alternative filters for chroma components.

[0492] alf_chroma_clip_flag[altIdx] equal to 0 specifies that linear adaptive loop filtering is applied to the chroma components when the chroma filter with index altIdx is used; alf_chroma_clip_flag[altIdx] equal to 1 specifies that nonlinear adaptive loop filtering is applied to the chroma components when the chroma filter with index altIdx is used. When not present, alf_chroma_clip_flag[altIdx] is inferred to be equal to 0.

[0493] alf_chroma_coeff_abs[altIdx][j] specifies the absolute value of the j-th chroma filter coefficient for the alternative chroma filter with index altIdx. When alf_chroma_coeff_abs[altIdx][j] is not present, it is inferred to be equal to 0. Bitstream conformance requirements require that the value of alf_chroma_coeff_abs[altIdx][j] shall be between 0 and 2. 7 The range is -1 (including the end value).

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

[0495] alf_chroma_coeff_sign[altIdx][j] specifies the sign of the j-th chroma filter coefficient for the alternative chroma filter with index altIdx as follows:

[0496] If alf_chroma_coeff_sign[altIdx][j] is equal to 0, the corresponding chroma filter coefficient has a positive value.

[0497] Otherwise (alf_chroma_coeff_sign[altIdx][j] is equal to 1), the corresponding chroma filter coefficient has a negative value.

[0498] When alf_chroma_coeff_sign[altIdx][j] is not present, it is inferred to be equal to 0.

[0499] With element AlfCoeff C [adaptation_parameter_set_id][altIdx][j], altIdx=0..alf_chroma_num_alt_filters_minus1, chroma filter coefficients AlfCoeff j=0..5 C [adaptation_parameter_set_id][altIdx] is derived as follows:

[0500] Alf Coeff C [adaptation_parameter_set_id][altIdx][j]=alf_chroma_coeff_abs[altIdx][j]*(1-2*alf_chroma_coeff_sign[altIdx][j])

[0501] Bitstream compliance requirement AlfCoeff C [adaptation_parameter_set_id][altIdx][j], altIdx=0..alf_chroma_num_alt_filters_minus1, j=0..5 should be between -2 7 -1 to 2 7 The range is -1 (including the end value).

[0502] alf_cross_component_cb_coeff_abs[j] specifies the absolute value of the j-th cross-component Cb filter coefficient. When alf_cross_component_cb_coeff_abs[j] is not present, it is inferred to be equal to 0.

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

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

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

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

[0507] When alf_cross_component_cb_coeff_sign[j] is not present, it is inferred to be equal to 0.

[0508] With element CcAlfApsCoeff Cb [adaptation_parameter_set_id][j], cross-component Cb filter coefficients CcAlfApsCoeff of j=0..13 Cb [adaptation_parameter_set_id] is derived as follows:

[0509] CcAlfApsCoeff Cb [adaptation_parameter_set_id][j]=alf_cross_component_cb_coeff_abs[j]*(1-2*alf_cross_component_cb_coeff_sign[j])

[0510] Bitstream conformance requirement CcAlfApsCoeff Cb [adaptation_parameter_set_id][j], the value of j=0..13 should be between -2 7 to 2 7 The range is -1 (including the end value).

[0511] alf_cross_component_cr_coeff_abs[j] specifies the absolute value of the j-th cross-component Cr filter coefficient. When alf_cross_component_cr_coeff_abs[j] is not present, it is inferred to be equal to 0. The order k of the exponential Golomb binarization uek(v) is set to 3.

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

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

[0514] Otherwise (alf_cross_component_cr_sign[j] is equal to 1), the corresponding cross_component_Cr filter coefficient has a negative value.

[0515] When alf_cross_component_cr_coeff_sign[j] is not present, it is inferred to be equal to 0.

[0516] With element CcAlfApsCoeff Cr [adaptation_parameter_set_id][j], cross-component Cr filter coefficients CcAlfApsCoeff for j=0..13 Cr [adaptation_parameter_set_id] is derived as follows:

[0517] CcAlfApsCoeff Cr [adaptation_parameter_set_id][_i]=alf_cross_component_cr_coeff_abs[j]*((1-2*alf_cross_component_cr_coeff_sign[j])

[0518] Bitstream conformance requirement CcAlfApsCoeff Cr [adaptation_parameter_set_id][j], the value of j=0..13 should be between -2 7 to 2 7 The range is -1 (including the end value).

[0519] alf_chroma_clip_idx[altIdx][j] specifies the clipping index of the clipping value used before multiplication by the j-th coefficient of the alternative chroma filter with index altIdx. Bitstream conformance requires that the values of alf_chroma_clip_idx[altIdx][j], altIdx=0..alf_chroma_num_alt_filters_minus1, j=0..5 shall be in the range of 0 to 3 (inclusive).

[0520] Has element AlfClip C [adaptation_parameter_set_id][altIdx][j], altIdx=0..alf_chroma_num_alt_filters_minus1, chroma filter clipping value AlfClip of j=0..5 C [adaptation_parameter_set_id][altIdx] is derived as specified in Table 18, subject to bitDepth being set equal to BitDepth C And clipIdx is set equal to alf_chroma_clip_idx[altIdx][j].

[0521]

[0522]

[0523] Table 18

[0524] Additionally, with respect to Table 15, it should be noted that JVET-2001 provides the following syntax and semantics for the adaptation_parameter_set syntax structure:

[0525]

[0526] Table 19

[0527] Each APS RBSP shall be available to the decoding process before being referenced, included in at least one access unit where the TemporalId is less than or equal to the TemporalId of the coded slice NAL unit that references it or is provided by external means.

[0528] Let aspLayerId be the nuh_layer_id of the APS NAL unit. If the layer with nuh_layer_id equal to aspLayerId is an independent layer (i.e., vps_independent_layer_flag[GeneralLayerIdx[aspLayerId]] is equal to 1), then the nuh_layer_id of the APS NAL unit containing the APS RBSP shall be equal to the nuh_layer_id of the coded slice NAL unit that references it. Otherwise, the nuh_layer_id of the APS NAL unit containing the APS RBSP shall be equal to the nuh_layer_id of the coded slice NAL unit that references it, or equal to the nuh_layer_id of the directly dependent layer of the layer containing the coded slice NAL unit that references it.

[0529] All APS NAL units with a specific value of adaptation_parameter_set_id and a specific value of aps_params_type within an access unit shall have the same content.

[0530] adaptation_parameter_set_id provides an identifier of the APS for reference by other syntax elements. When aps_params_type is equal to ALF_APS or SCALING_APS, the value of adaptation_parameter_set_id shall be in the range of 0 to 7 (inclusive).

[0531] When aps_params_type is equal to LMCS_APS, the value of adaptation_parameter_set_id shall be in the range of 0 to 3 (inclusive).

[0532] aps_params_type specifies the type of APS parameters carried in the APS as specified in Table 20. When aps_params_type is equal to 1 (LMCS_APS), the value of adaptation_parameter_set_id shall be in the range of 0 to 3, inclusive.

[0533] aps_params_type The name of aps_params_type Types of APS parameters 0 ALF_APS ALF parameters 1 LMCS__APS LMCS parameters 2 SCALING_APS Scaling List Parameters 3..7 Reserve Reserve

[0534] Table 20

[0535] NOTE - Each type of APS uses a separate value space for adaptation_parameter_set_id.

[0536] NOTE—APS NAL units (with a specific value of adaptation_parameter_set_id and a specific value of aps_params_type) may be shared across pictures, and different slices within a picture may refer to different ALF APSs.

[0537] aps_extension_flag equal to 0 specifies that the aps_extension_data_flag syntax element is not present in the APS RBSP syntax structure. aps_extension_flag equal to 1 specifies that the aps_extension_data_flag syntax element is present in the APS RBSP syntax structure.

[0538] aps_extension_data_flag can have any value. Its presence and value do not affect the conformance of a decoder to the profile specified in this version of this specification. Decoders conforming to this version of this specification shall ignore all aps_extension_data_flag syntax elements.

[0539] For Table 15, in one example, the syntax elements alf_chroma_filter_signal_flag, alf_cross_component_cb_filter_signal_flag, and / or alf_cross_component_cr_filter_signal_flag can be conditionally signaled only when ChormaArrayType is not equal to 0, and their values are recommended when they are not present. Conditional signaling saves bits. That is, in one example, Table 15 can be modified as follows:

[0540]

[0541] The semantics are as follows:

[0542] 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 not present, alf_chroma_filter_signal_flag is inferred to be equal to 0.

[0543] The variable NumAlfFilters, which specifies the number of different adaptive loop filters, is set equal to 25.

[0544] alf_cross_component_cb_filter_signal_flag equal to 1 specifies that the cross-component Cb filter is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross-component Cb filter is not signaled. When not present, alf_cross_component_cb_filter_signal_flag is inferred to be equal to 0.

[0545] alf_cross_component_cr_filter_signal_flag equal to 1 specifies that a cross-component Cr filter is signaled. alf_cross_component_cr_filter_signal_flag equal to 0 specifies that a cross-component Cr filter is not signaled. When not present, alf_cross_component_cr_filter_signal_flag is inferred to be equal to 0.

[0546] For Table 16, in one example, the semantics may be based on the following:

[0547] slice_pic_parameter_set_id specifies the value of pps_pic_parameter_set_id of the PPS in use. The value of slice_pic_parameter_set_id should be in the range of 0 to 63 (inclusive).

[0548] Bitstream conformance requires that the value of TemporalId of the current picture shall be greater than or equal to the value of TemporalId of the PPS with pps_pic_parameter_set_id equal to slice_pic_parameter_set_id.

[0549] cabac_init_flag specifies the method for determining the initialization table to use during the initialization process for context variables. When cabac_init_flag is not present, it is inferred to be equal to 0.

[0550] slice_qp_delta specifies the Qp to be used for the coded blocks in the slice Y The initial value of until modified by the value of CuQpDeltaVal in the coding unit layer. Y The initial value of the quantization parameter SliceQp Y Export as follows:

[0551] SliceQp Y=26+init_qp_minus26+slice_qp_delta

[0552] SliceQp Y The value of -QpBdOffset should be Y to +63 (inclusive).

[0553] in,

[0554] init_qp_minus26 plus 26 specifies the initial value of SliceQpY for each slice that references the PPS. When slice_qp_delta is decoded to a non-zero value, SliceQp is modified at the slice level. Y The value of init_qp_minus26 should be in the range of -(26+QpBdOffsetY) to +37 (inclusive).

[0555] slice_sao_luma_flag equal to 1 specifies that SAO is enabled for the luma components in the current slice; slice_sao_luma_flag equal to 0 specifies that SAO is disabled for the luma components in the current slice; when slice_sao_luma_flag is not present, it is inferred to be equal to 0.

[0556] slice_sao_chroma_flag equal to 1 specifies that SAO is enabled for the chroma components in the current slice; slice_sao_chroma_flag equal to 0 specifies that SAO is disabled for the chroma components in the current slice; when slice_sao_chroma_flag is not present, it is inferred to be equal to 0.

[0557] slice_alf_enabled_flag equal to 1 specifies that the adaptive loop filter is enabled in the slice and may be applied to the Y, Cb, or Cr color components. slice_alf_enabled_flag equal to 0 specifies that the adaptive loop filter is disabled for all color components in the slice.

[0558] slice_num_alf_aps_ids_luma specifies the number of ALF_APS referenced by the slice. The value of slice_num_alf_aps_ids_luma should be in the range of 0 to 7 (inclusive).

[0559] slice_alf_aps_id_luma[i] specifies the adaptation_parameter_set_id of the i-th ALF APS referenced by the luma component of the slice. The TemporalId of the APS NAL unit with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_alf_aps_id_luma[i] shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0560] For intra slices and slices in an IRAP picture, slice_alf_aps_id_luma[i] shall not reference an ALF APS associated with a picture other than the picture containing the intra slice or the IRAP picture.

[0561] slice_alf_chroma_idc equal to 0 specifies that the adaptive loop filter is not applied to the Cb and Cr color components. slice_alf_chroma_idc equal to 1 indicates that the adaptive loop filter is applied to the Cb color component. slice_alf_chroma_idc equal to 2 indicates that the adaptive loop filter is applied to the Cr color components. slice_alf_chroma_idc equal to 3 indicates that the adaptive loop filter is applied to the Cb and Cr color components. When slice_alf_chroma_idc is not present, it is inferred to be equal to 0.

[0562] slice_alf_aps_id_chroma specifies the adaptation_parameter_set_id of the ALF APS referenced by the chroma components of the slice. The TemporalId of the APS NAL unit with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_alf_aps_id_chroma shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0563] For intra slices and slices in IRAP pictures, slice_alf_aps_id_chroma shall not reference ALF APS associated with pictures other than the picture containing the intra slice or the IRAP picture.

[0564] slice_cross_component_alf_cb_enabled_flag equal to 0 specifies that the cross-component Cb filter is not applied to the Cb color component. slice_cross_component_alf_cb_enabled_flag equal to 1 indicates that the cross-component Cb filter is applied to the Cb color component. When slice_cross_component_alf_cb_enabled_flag is not present, it is inferred to be equal to 0.

[0565] slice_cross_component_alf_cb_reuse_temporal_layer_filter_flag equal to 1 specifies that the cross-component Cb filter coefficients (where j = 0..13, inclusive) are set equal to CcAlfTemporalCoeff Cb [TemporalId][j].

[0566] slice_cross_component_alf_cb_reuse_temporal_layer_filter_flag equal to 0 and slice_cross_component_alf_cb_enabled_flag equal to 1 specify that the syntax element slice_cross_component_alf_cb_aps_id is present in the current slice header.

[0567] When slice_cross_component_alf_cb_enabled_flag is equal to 1 and slice_cross_component_alf_cb_reuse_temporal_layer_filter_flag is equal to 0, CcAlfTemporalCoeff is derived as follows Cb [TemporalId][j] and CcAlfCoeffx b [j], elements of j = 0..13:

[0568] CcAlfTemporalCoeff Cb [TemporalId][j]=CcAlfApsCoeff Cb [slice_cross_component_alf_cb_aps_id][j]

[0569] CcAlfCoeff Cb [j] = CcAlfApsCoeff Cb[slice_cross_component_alf_cb_aps_id][j]

[0570] When slice_cross_component_alf_cb_enabled_flag is equal to 1 and slice_cross_component_alf_cb_reuse_temporal_layer_filter_flag is equal to 1, CcAlfCoeff is derived as follows Cb [j], elements of j = 0..13:

[0571] CcAlfCoeff Cb [j] = CcAlfTemporalCoeff Cb [TemporalId][j]

[0572] It should be noted that in some examples slice_cross_component_alf_cb_reuse_temporal_layer_filter_flag may be conditionally signaled by if (slice_type != 1) and / or NAL unit type is non-IRAP and non-GDR, and inferred to be equal to 0 when not present.

[0573] The NAL unit type being non-IRAP and non-GDR can be expressed by the following conditional statement:

[0574] if(nal_unit_type!=IDR_W_RADL&&nal_unit_type!=IDR_N_LP&&nal_unit_type!=CRA_NUT&&nal_unit_type!=GDR_NUT)

[0575] The NAL unit type is non-IRAP and non-GDR and if (slice_type != 1) can be expressed by the following conditional statement:

[0576] if(nal_unit_type!=IDR_W_RADL&&nal_unit_type!=IDR_N_LP&&nal_unit_type!=CRA_NUT&&nal_unit_type!=GDR_NUT&&slice_type!=I)

[0577] slice_cross_component_alf_cb_aps_id specifies the adaptation_parameter_set_id indexed by the Cb color component of the slice. The TemporalId of the APS NAL unit with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_cross_component_alf_cb_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0578] For intra slices and slices in IRAP pictures, slice_cross_component_alf_cb_aps_id shall not reference ALF APS associated with other pictures than the picture containing the intra slice or the IRAP picture.

[0579] When slice_cross_component_alf_cb_enabled_flag is equal to 1, bitstream conformance requires that the ALF APS referenced by slice_cross_component_alf_cbaps_id shall be the same for all slices of the current picture.

[0580] slice_cross_component_alf_cb_log2_control_size_minus4 specifies the control block size of the Cb color component in units of the number of chroma samples. slice_cross_component_alf_cb_log2_control_size_minus4 should be in the range of 0 to Min(Log2(CtbWidthC), Log2(CtbHeightC))-4, inclusive.

[0581] The variables CcAlfWidthCbL and CcAlfHeightCbL are derived as follows:

[0582] CcAlfWidthCbL=(1<<(slice_cross_component_alf_cb_log2_control_size_minus4+4))*SubWidthC

[0583] CcAlfHeightCbL=(1<<(slice_cross_component_alf_cb_log2_control_size_minus4+4))*SubHeightC

[0584] 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. When slice_cross_component_alf_cr_enabled_flag is not present, it is inferred to be equal to 0.

[0585] For Table 16, slice_cross_component_alf_cb_enabled_flag and slice_cross_component_alf_cr_enabled_flag may be grouped into a single if(ChromaArrayType!=0){} statement in one example syntax element.

[0586] slice_cross_component_alf_cr_reuse_temporal_layer_filterflag equal to 1 specifies that the cross-component Cr filter coefficients (where j = 0..13, inclusive) are set equal to CcAlfTemporalCoeff Cr [TemporalId][j].

[0587] slice_cross_component_alf_cr_reuse_temporal_layer_filter_flag equal to 0 and slice_cross_component_alf_cr_enabled_flag equal to 1 specify that the syntax element slice_cross_component_alf_cr_aps_id is present in the current slice header.

[0588] When slice_cross_component_alf_cr_enabled_flag is equal to 1 and slice_cross_component_alf_cr_reuse_temporal_layer_filter_flag is equal to 0, CcAlfTemporalCoeff is derived as follows Cr [TemporalId][j] and CcAlfCoeff Cr [j], elements of j = 0..13:

[0589] CcAIfTemporalCoeffCr [TemporalId][j]=CcAlfApsCoeff Cr [slice_cross_component_alf_cr_aps_id][j]

[0590] CcAlfCoeff Cr [j] = CcAlfApsCoeff Cr [slice_cross_component_alf_cr_aps_id][j]

[0591] When slice_cross_component_alf_cb_enabled_flag is equal to 1 and slice_cross_component_alf_cb_reuse_temporal_layer_filter_flag is equal to 1, CcAlfCoeff is derived as follows Cr [j], elements of j = 0..13:

[0592] CcAlfCoeff Cr [j] = CcAlfTemporalCoeff Cr [TemporalId][j]

[0593] It should be noted that in some examples slice_cross_component_alf_cr_reuse_temporal_layer_filter_flag may be conditionally signaled by if (slice_type != 1) and / or NAL unit type is non-IRAP and non-GDR, and inferred to be equal to 0 when not present.

[0594] slice_cross_component_alf_cr_aps_id specifies the adaptation_parameter_set_id indexed by the Cr color component of the slice. The TemporalId of the APS NAL unit with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_cross_component_alf_cr_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0595] For intra slices and slices in IRAP pictures, slice_cross_component_alf_cr_aps_id shall not reference ALF APS associated with other pictures than the picture containing the intra slice or the IRAP picture.

[0596] When slice_cross_component_alf_cr_enabled_flag is equal to 1, bitstream conformance requires that the ALF APS referenced by slice_cross_component_alf_cr_aps_id shall be the same for all slices of the current picture.

[0597] slice_cross_component_alf_cr_log2_control_size_minus4 specifies the control block size of the Cr color component in units of the number of chroma samples. slice_cross_component_alf_cb_log2_control_size_minus4 should be in the range of 0 to Min(Log2(CtbWidthC), Log2(CtbHeightC))-4, inclusive.

[0598] The variables CcAlfWidthCrL and CcAlfHeightCrL are derived as follows:

[0599] CcAlfWidthCrL=(1<<(slice_cross_component_alf_cr_log2_control_size_minus4+4))*SubWidth

[0600] CCcAlfHeightCrL=(1<<(slicc_cross_component_alf_cr_log2_control_size_minus4+4))*SubHeightC

[0601] deblocking_filter_override_flag equal to 1 specifies that deblocking parameters are present in the slice header. deblocking_filter_override_flag equal to 0 specifies that deblocking parameters are not present in the slice header. When not present, the value of deblocking_filter_override_flag is inferred to be equal to 0.

[0602] slice_deblocking_filter_disabled_flag equal to 1 specifies that the operation of the deblocking filter is not applied to the current slice. slice_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter is applied to the current slice. When slice_deblocking_filter_disabled_flag is not present, it is inferred to be equal to pps_deblocking_filter_disabled_flag.

[0603] slice_beta_offset_div2 and slice_tc_offset_div2 specify the deblocking parameter offsets (divided by 2) for beta and tc of the current slice. The values of slice_beta_offset_div2 and slice_tc_offset_div2 should both be in the range of -6 to 6 (inclusive). When not present, the values of slice_beta_offset_div2 and slice_tc_offset_div2 are inferred to be equal to pps_beta_offset_div2 and pps_tc_offset_div2, respectively.

[0604] slice_lmcs_enabled_flag equal to 1 specifies that luma mapping with chroma scaling is enabled for the current slice. slice_lmcs_enabled_flag equal to 0 specifies that luma mapping with chroma scaling is disabled for the current slice. When slice_lmcs_enabled_flag is not present, it is inferred to be equal to 0.

[0605] slice_lmcs_aps_id specifies the adaptation_parameter_set_id of the LMCS APS referenced by the slice. The TemporalId of the APS NAL unit with aps_params_type equal to LMCS_APS and adaptation_parameter_set_id equal to slice_lmcs_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0606] When present, the value of slice_lmcS_aps_id shall be the same for all slices of a picture.

[0607] slice_chroma_residual_scale_flag equal to 1 specifies that chroma residual scaling is enabled for the current slice. slice_chroma_residual_scale_flag equal to 0 specifies that chroma residual scaling is not enabled for the current slice. When slice_chroma_residual_scale_flag is not present, it is inferred to be equal to 0.

[0608] As provided above, slice_cross_component_alf_cb_log2_control_size_minus4 and slice_cross_component_alf_cr_log2_control_size_minus4 limit the maximum block size indicated by the local control filter (i.e., to Min(Log2(CtbWidthC), Log2(CtbHeightC))). In one example, the maximum block size indicated by the local control filter can be limited to Min(Floor(Log2(CtbWidthC)), Floor(Log2(CtbHeightC))). Furthermore, in one example, the maximum block size indicated by the local control can be limited so that the control block cannot span more than one CTU. This can make processing across tile / slice boundaries simpler because tiles / slices are described in units of CTUs. In one example, the maximum block size limit is derived based on the maximum CTU size (block and / or width) and / or chroma format.

[0609] It should be noted that JVET-O2001 provides the following syntax and semantics for the syntax element non_reference_picture_flag:

[0610]

[0611] non_reference_picture_flag equal to 1 specifies that the picture containing the slice must not be used as a reference picture. non_reference_picture_flag equal to 0 specifies that the picture containing the slice may or may not be used as a reference picture.

[0612] In one example, according to the techniques herein, the semantics of the syntax elements slice_alf_aps_id_luma[i], slice_alf_chroma_idc, and slice_alf_aps_id_chroma may be based on the following operations:

[0613] slice_alf_aps_id_luma[i] specifies the adaptation_parameter_set_id of the i-th ALF APS referenced by the luma component of the slice. The TemporalId of the APS NAL unit with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_alf_aps_id_luma[i] shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0614] For intra slices and slices in an IRAP picture, slice_alf_aps_id_luma[i] shall not reference an ALF APS associated with a picture other than the picture containing the intra slice or the IRAP picture.

[0615] For i in the range of 0 to slice_num_alf_aps_ids_luma (inclusive), bitstream conformance requires that the ALF APS with adaptation_parameter_set_id equal to slice_alf_aps_id_luma[i], alf_luma_filter_signal_flag equal to 1.

[0616] slice_alf_chroma_idc equal to 0 specifies that the adaptive loop filter is not applied to the Cb and Cr color components. slice_alf_chroma_idc equal to 1 indicates that the adaptive loop filter is applied to the Cb color component. slice_alf_chroma_idc equal to 2 indicates that the adaptive loop filter is applied to the Cr color components, and slice_alf_chroma_idc equal to 3 indicates that the adaptive loop filter is applied to the Cb and Cr color components. When slice_alf_chroma_idc is not present, it is inferred to be equal to 0.

[0617] slice_alf_aps_id_chroma specifies the adaptation_parameter_set_id of the ALF APS referenced by the chroma components of the slice. The TemporalId of the APS NAL unit with aps_params_type equal to the ALF APS and adaptation_parameter_set_id equal to slice_alf_aps_id_chroma shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0618] For intra slices and slices in IRAP pictures, slice_alf_aps_id_chroma shall not reference ALF APS associated with pictures other than the picture containing the intra slice or the IRAP picture.

[0619] Bitstream conformance requires that for the ALF APS with adaptation_parameter_set_id equal to slice_alf_aps_id_chroma, alf_chroma_filter_signal_flag is equal to 1.

[0620] Additionally, JVET-O2001 includes the following syntax elements in the sequence parameter set syntax structure:

[0621] sps_sao_enabled_flag equal to 1 specifies that the sample adaptive offset process is applied to the reconstructed picture after the deblocking filter process. sps_sao_enabled_flag equal to 0 specifies that the sample adaptive offset process is not applied to the reconstructed picture after the deblocking filter process.

[0622] sps_alf_enabled_flag equal to 0 specifies that the adaptive loop filter is disabled. sps_alf_cnablcd_flag equal to 1 specifies that the adaptive loop filter is enabled.

[0623] sps_lmcs_enabled_flag equal to 1 specifies that luma mapping with chroma scaling is used in CVS. sps_lmcs_enabled_flag equal to 0 specifies that luma mapping with chroma scaling is not used in CVS.

[0624] When loop_filter_across_subpic_enabled_flag[i] is equal to 1, it specifies that the in-loop filtering operation may be performed across the boundaries of the i-th sub-picture of each coded picture in the CVS. When loop_filter_across_subpic_enabled_flag[i] is equal to 0, it specifies that the in-loop filtering operation is not performed across the boundaries of the i-th sub-picture of each coded picture in the CVS. When not present, the value of loop_filter_across_subpic_enabled_pic_flag[i] is inferred to be equal to 1.

[0625] And the following syntax elements in the picture parameter set syntax structure:

[0626] cabac_init_present_flag equal to 1 specifies that cabac_init_flag is present in the slice header referencing the PPS. cabac_init_present_flag equal to 0 specifies that cabac_init_flag is not present in the slice header referencing the PPS.

[0627] deblocking_filter_override_enabled_flag equal to 1 specifies that the deblocking_filter_override_flag is present in the slice header of the picture referencing the PPS. deblocking_filter_override_enabled_flag equal to 0 specifies that the deblocking_filter_override_flag is not present in the slice header of the picture referencing the PPS. When not present, the value of deblocking_filter_override_enabled_flag is inferred to be equal to 0.

[0628] loop_filter_across_bricks_enabled_flag equal to 1 specifies that in-loop filtering operations may be performed across brick boundaries in pictures that reference the PPS. loop_filter_across_bricks_enabled_flag equal to 0 specifies that in-loop filtering operations are not performed across brick boundaries in pictures that reference the PPS. In-loop filtering operations include deblocking filter, sample adaptive offset filter, and adaptive loop filter operations. When not present, the value of loop_filter_across_bricks_enabled_flag is inferred to be 1.

[0629] loop_filter_across_slices_enabled_flag equal to 1 specifies that in-loop filtering operations may be performed across slice boundaries in pictures that reference the PPS. loop_filter_across_slice_enabled_flag equal to 0 specifies that in-loop filtering operations are not performed across slice boundaries in pictures that reference the PPS. In-loop filtering operations include deblocking filter, sample adaptive offset filter, and adaptive loop filter operations. When not present, the value of loop_filter_across_slices_enabled_flag is inferred to be 0.

[0630] Additionally, for Table 16, the variables ChromaArrayType, SubWidthC, and SubHeightC may be derived as provided in Table 21:

[0631] chroma_format_idc separate__colour_plane__flag Chroma format ChromaArray type SubWidthC SubHeightC 0 0 monochrome 0 1 1 1 0 4:2:0 1 2 2 2 0 4:2:2 2 2 1 3 0 4:4:4 3 1 1 3 1 4:4:4 0 1 1

[0632] Table 21

[0633] In addition, for Table 16, JVET-O2001 includes the following syntax elements in the sequence parameter set syntax structure:

[0634] log2_ctu_size_minus5 plus 5 specifies the luma coding tree block size for each CTU. Bitstream conformance requires that the value of log2_ctu_size_minus5 be less than or equal to 2.

[0635] log2_min_luma_coding_block_size_minus2 plus 2 specifies the minimum luma coding block size.

[0636] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are exported as follows:

[0637] CtbLog2SizeY=log2_ctu_size_minus5+5

[0638] CtbSizeY=1<<CtbLog2SizeY

[0639] MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2

[0640] MinCbSizeY=1<<MinCbLog2SizeY

[0641] IbcBufWidthY=128*128 / CtbSizeY

[0642] IbcBufWidthC=IbcBufWidthY / SubWidthC

[0643] VSize = Min(64, CtbSizeY)

[0644] The variables CtbWidthC and CtbHeightC specify the width and height of the array of each chroma CTB respectively. These two variables can be derived as follows:

[0645] - If chroma_format_idc is equal to 0 (monochrome) or separate_colour_plane_flag is equal to 1, CtbWidthC and CtbHeightC are both equal to 0.

[0646] Otherwise, CtbWidthC and CtbHeightC are derived as follows:

[0647] CtbWidthC=CtbSizeY / SubWidthC

[0648] CtbHeightC=CtbSizeY / SubHeightC

[0649] For Table 17, in one example, the semantics may be based on the following:

[0650] CTU is the root node of the coding tree structure.

[0651] The array IsAvailable[cIdx][x][y] specifies whether the sample at (x, y) is available for the derivation process of the specified neighboring block availability and is initialized as follows for cIdx=0..2, x=0..CtbSizeY-1 and y=0..CtbSizeY-1:

[0652] IsAvailable[cIdx][x][y]=FALSE

[0653] The array IsInSmr[x][y] specifies whether the sample at (x, y) is within the shared merge candidate list region and is initialized as follows for x=0..CtbSizeY-1 and v=0..CtbSizeY-1:

[0654] IsInSmr[x][y]=FALSE

[0655] alf_ctb_flag[cIdx][xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] equal to 1 specifies that an adaptive loop filter is applied to the coding tree block of the color component indicated by cIdx of the coding tree unit at the luma position (xCtb, yCtb). alf_ctb_flag[cIdx][xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] equal to 0 specifies that an adaptive loop filter is not applied to the coding tree block of the color component indicated by cIdx of the coding tree unit at the luma position (xCtb, yCtb).

[0656] When alf_ctb_flag[cIdx][xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] is not present, it is inferred to be equal to 0.

[0657] alf_cTB_use_first_aps_flag equal to 1 specifies that the filter information in the APS with adaptive_parameter_set_id equal to slice_alf_aps_id_luma[0] is used. alf_ctb_use_first_aps_flag equal to 0 specifies that the luma CTB does not use the filter information in the APS with adaptive_p_parameter_set_id equal to slice_alf_aps_id_luma[0]. When alf_ctb_use_first_aps_flag is not present, it is inferred to be 0.

[0658] alf_use_aps_flag equal to 0 specifies that one of the fixed filter sets is applied to the luma CTB. alf_use_aps_flag equal to 1 specifies that the filter set from the APS is applied to the luma CTB. When alf_use_aps_flag is not present, it is inferred to be equal to 0.

[0659] alf_luma_prev_filter_idx_minus1 plus 1 specifies the previous filter applied to the luma CTB. The value of alf_luma_prev_filter_idx_minus1 should be in the range of 0 to slice_num_alf_aps_ids_luma-2, inclusive. When alf_luma_prev_filter_idx_minus1 is not present, it is inferred to be equal to 0.

[0660] The variable AlfCtbFiltSetIdxY[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] that specifies the filter bank index of the luma CTB at position (xCtb, yCtb) is derived as follows:

[0661] If alf_ctb_use_first_aps_flag is equal to 1, then set AlfCtbFiltSetIdxY[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] to 16.

[0662] Otherwise, if alf_use_aps_flag is equal to 0, then set AlfCtbFiltSetIdxY[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] equal to alf_luma_fixed_filter_idx.

[0663] - Otherwise, set AlfCtbFiltSetIdxY[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] equal to 17+alf_luma_prev_filter_idx_minus1.

[0664] alf_luma_fixed_filter_idx specifies the fixed filter applied to the luma CTB. The value of alf_luma_fixed_filter_idx should be in the range of 0 to 15 (inclusive).

[0665] alf_ctb_filter_alt_idx[chromaIdx][xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] specifies the index of the alternative chroma filter applied to the coding tree block of the chroma component in the coding tree unit of luma position (xCtb, yCtb), where chromaIdx is equal to 0 for Cb and 1 for Cr. When alf_ctb_filter_alt_idx[chromaIdx][xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] is not present, it is inferred to be zero.

[0666] alf_cross_component_cb_flag[xL / CcAlfWidthCbL][yL / CcAlfHeightCbL] equal to 0 indicates that a cross-component Cb filter is not applied to the Cb color component sample block at the luma position (xL, yL). alf_cross_component_cb_flag[xL / CcAlfWidthCbL][yL / CcAlfHeightCbL] equal to 1 indicates that a cross-component Cb filter is applied to the Cb color component sample block at the luma position (xL, yL).

[0667] alf_cross_component_cr_flag[xL / CcAlfWidthCbL][yL / CcAlfHeightCbL] equal to 0 indicates that a cross-component Cr filter is not applied to the Cr color component sample block at the luma position (xL, yL). alf_cross_component_cr_flag[xL / CcAlfWidthCbL][yL / CcAlfHeightCbL] equal to 1 indicates that a cross-component Cr filter is applied to the Cr color component sample block at the luma position (xL, yL).

[0668] It should be noted that, in one example, [xL / CcAlfWidthCbL][yL / CcAlfHeightCbL] can be expressed using a shift operation instead of / .

[0669] In addition, for Table 17, JVET-O2001 includes the following syntax elements in the picture parameter set syntax structure:

[0670] pic_width_in_luma_samples specifies the width of each decoded picture that references the PPS, in units of luma samples. pic_width_in_luma_samples shall not be equal to 0, shall be an integer multiple of Max(8, MinCbSizeY), and shall be less than or equal to pic_width_max_in_luma_samples.

[0671] When subpics_present_flag is equal to 1, the value of pic_width_in_luma_samples shall be equal to pic_width_max_in_luma_samples.

[0672] pic_height_in_luma_samples specifies the height of each decoded picture that references the PPS, in units of luma samples. pic_height_in_luma_samples shall not be equal to 0 and shall be an integer multiple of Max(8, MinCbSizeY) and shall be greater than or equal to pic_height_max_in_luma_samples.

[0673] When subpics_present_flag is equal to 1, the value of pic_height_in_luma_samples shall be equal to pic_height_max_in_luma_samples.

[0674] Let refPicWidthInLumaSamples and refPicHeighfInLumaSamples be the pic_width_in_luma_samples and pic_height_in_luma_samples, respectively, of the reference picture that references the current picture of this PPS. Bitstream conformance requires that all of the following conditions be met:

[0675] -pic_width_in_luma_samples*2 should be greater than or equal to refPicWidthInLumaSamples.

[0676] -pic_height_in_luma_samples*2 should be greater than or equal to refPicHeigtInLumaSamples.

[0677] -pic_width_in_luma_samples should be greater than or equal to refPicWidthInLumaSamples*8.

[0678] -pic_height_in_luma_samples should be greater than or equal to refPicHeightInLumaSamples*8.

[0679] The variables PicWidthInCtbsY, PicHeightInCtbsY, PicSizeInCtbsY, PicWidthInMjnCbsY, PicHeightInMinCbsY, PicSizeInMinCbsY, PicSizeInSamplesY, PicWidthInSamplesC, and PicHeightInSamplesC are derived as follows:

[0680] PicWidthInCtbsY=Ceil(pic_width_in_luma_samples÷CtbSizeY)

[0681] PicHeightInCtbsY=Ceil(pic_height_in_luma_samples÷CtbSizeY)

[0682] PicSizeInCtbsY=PicWidthInCtbsY*PicHeightInCtbsY

[0683] PicWidthInMinCbsY=pic_width_in_luma_samples / MinCbSizeY

[0684] PicHeightInMinCbsY=pic_height_in_luma_samples / MinCbSizeY

[0685] PicSizeInMinCbsY=PicWidthInMinCbsY*PicHeightInMinCbsY

[0686] PicSizeInSamplesY=pic_width_in_luma_samples*pic_height_in_luma_samples

[0687] PicWidthInSamplesC=pic_width_in_luma_samples / SubWidthC

[0688] PicHeightInSamplesC=pic_height_in_luma_samples / SubHeightC

[0689] Additionally, JVET-O2001 includes the following syntax elements in the picture parameter set syntax structure:

[0690] pps_loop_filter_across_virtual_boundaries_disabled_flag equal to 1 specifies that in-loop filtering operations are disabled across virtual boundaries in pictures that reference the PPS. pps_loop_filter_across_virtual_boundaries_disabled_flag equal to 0 specifies that such disabling of in-loop filtering operations is not applied in pictures that reference the PPS. In-loop filtering operations include deblocking filter, sample adaptive offset filter, and adaptive loop filter operations. When not present, the value of pps_loop_filter_across_virtual_boundaries_disabled_flag is inferred to be 0.

[0691] pps_num_ver_virtual_boundaries specifies the number of pps_virtual_boundaries_pos_x[i] syntax elements present in the PPS. When pps_virtual_boundariespos_x[i] is not present, it is inferred to be equal to 0.

[0692] pps_virtual_boundaries_pos_x[i] is used to calculate the value of PpsVirtualBoundariesPosX[i], which specifies the position of the i-th vertical virtual boundary in luma samples. pps_virtual_boundaries_pos_x[i] should be in the range of 1 to Ceil(pic_width_in_luma_samples÷a8)-1 (inclusive).

[0693] The positions of the vertical virtual boundaries PpsVirtualBoundariesPosX[i] are derived as follows:

[0694] PpsVirtualBoundariesPosX[i]=pps_virtual_boundaries_pos_x[i]*8

[0695] The distance between any two vertical virtual boundaries should be greater than or equal to CtbSizeY luma samples.

[0696] pps_num_hor_virtual_boundaries specifies the number of pps_virtual_boundaries_pos_y[i] syntax elements present in the PPS. When pps_num_hor_virtual_boundaries is not present, it is inferred to be equal to 0.

[0697] pps_virtual_boundaries_pos_y[i] is used to calculate the value of PpsVirtualBoundariesPosY[i], which specifies the position of the i-th horizontal virtual boundary in luma samples. pps_virtual_boundaries_pos_y[i] should be in the range of 1 to Ceil(pic_height_in_luma_samples÷8)-1 (inclusive).

[0698] The positions of the horizontal virtual boundaries PpsVirtualBoundariesPosY[i] are derived as follows:

[0699] PpsVirtualBoundariesPosY[i]=pps_virtual boundaries_pos_y[i]*8

[0700] The distance between any two horizontal virtual boundaries should be greater than or equal to CtbSizeY luma samples.

[0701] As provided above, for example, for Table 5C and Table 15, one or more filter syntax elements cross component Cb and Cr filter banks (e.g., in alf_data()) can be signaled. In one example, according to the technology herein, one or more cross component filter banks can be limited for a decoder (e.g., stored in a decoder memory). That is, a default cross component filter bank can be limited. In addition, in one example, the cross component filter bank can be indexed, and the index value can be signaled to indicate the cross component filter bank to be applied. In addition, the default cross component filter bank can be used in combination with the signaled cross component filter bank. That is, for example, in one example, a signaling flag can be signaled to indicate whether the index is used to indicate the cross component filter bank to be applied or whether the cross component filter bank is signaled. In one example, different default filter banks can be defined for Cb and Cr, respectively. In addition, it should be noted that in some examples, the fixed filter bank and the signaled coefficient filter can have different sizes and / or shapes. In such examples, the filtering process can describe the filtering of each filter with a specific shape / size.

[0702] In one example, according to the techniques herein, for example, for the syntax and semantics provided above for Tables 15 to 21, an adaptive loop filter process may be performed based on:

[0703] The input to this process is the adaptive loop filter recPicture L The previous reconstructed picture sample array and when ChromaArrayType is not equal to 0, the array recPicture Cb and recPicture Cr .

[0704] The output of this process is the adaptive loop filter alfPicture L The modified reconstructed picture sample array and when ChromaArrayType is not equal to 0, the array ccAlfPicture Cb and ccAlfPicture Cr .

[0705] Adaptive loop filter alfPicture L The sample values in the modified reconstructed image sample array, and when ChromaArrayType is not equal to 0, the array alfPicture Cb and alfPicture Cr Initially set equal to the adaptive loop filter recPicture LThe sample values in the previous reconstructed image sample array, and when ChromaArrayType is not equal to 0, the array recPicture Cb and recPicture Cr .

[0706] Apply the following sequential steps:

[0707] For each CTU with luma CTB position (rx, fy), where rx = 0..PicWidthInCtbsY-1 and ry = 0..PicHeightInCtbsY-1, the following applies:

[0708] - When alf_ctb_flag[0][rx][ry] is equal to 1, the coding tree block filtering process is called for the specified luma sample, where recPicture L 、alfPicture L and the luma coding tree block position (xCtb, yCtb) set equal to (rx<<CtbLog2SizeY, ry<<CtbLog2SizeY) as input, and the output is the modified filtered picture alfPicture L .

[0709] - When ChromaArrayType is not equal to 0 and alf_ctb_flag[1][rx][ry] is equal to 1, call the following coded tree block filtering process for the specified chroma samples, with recPicture set equal to recPicture Cb , alfPicture is set equal to alfPicture Cb , the chroma coding tree block position (xCtbC, yCtbC) is set equal to ((rx<<CtbLog2SizeY) / SubWidthC, (ry<<CtbLog2SizeY) / SubHeightC), and the alternative chroma filter index altIdx is set equal to alf_ctb_filter_alt_idx[0][rx][ry] as input, and the output is the modified filtered picture alfPicture Cb .

[0710] - When ChromaArrayType is not equal to 0 and alf_ctb_flag[2][rx][ry] is equal to 1, call the following CTBB filtering process for the specified chroma samples, where recPicture is set equal to recPicture Cr, alfPicture is set equal to alfPicture Cr , the chroma coding tree block position (xCtbC, yCtbC) is set equal to ((rx<<CtbLog2SizeY) / SubWidthC, (ry<<CtbLog2SizeY) / SubHeightC), and the alternative chroma filter index altIdx is set equal to alf_ctb_filter_alt_idx[0][rx][ry] as input, and the output is the modified filtered picture alfPicture Cr .

[0711] For each luma position (rx, ry), where rx = 0..pic_width_in_luma_samples / CcAlfWidthCbL-1 and ry = 0..pic_height_in_luma_samples / CcAlfHeightCbL-1, the following applies:

[0712] - When ChromaArrayType is not equal to 0 and alf_cross_component_cb_flag[rx][ry] is equal to 1, call the following cross-component filtering process for the specified chroma sample block, where recPicture L is set equal to recPicture L ,alfPicture C is set equal to alfPicture Cb , the chroma sample block position (xC, yC) is set equal to (rx*CcAlfWidthCbL / SubWidthC, ry*CcAlfHeightCbL / SubHeightC), ccAlfWidth is set equal to CcAlfWidthCbL / SubWidthC, ccAlfHeight is set equal to CcAlfHeightCbL / SubHeightC, and the cross-component filter coefficient CcAlfCoeff[j] is set equal to CcAlfCoeff Cb [j], j = 0..13 as input, and output as modified filtered picture ccAlfPicture Cb .

[0713] For each luma position (rx, ry), where rx = 0..pic_width_in_luma_samples / CcAlfWidthCrL-1 and ry = 0..pic_height_in_luma_samples / CcAlfHeightCrL-1, the following applies:

[0714] - When ChromaArrayType is not equal to 0 and alf_cross_component_cr_flag[rx][ry] is equal to 1, call the following cross-component filtering process for the specified chroma sample block, where recPicture L is set equal to recPicture L ,alfPicture C is set equal to alfPicture Cr , the chroma sample block position (xC, yC) is set equal to (rx*CcAlfWidthCrL / SubWidthC, ry*CcAlfHeightCrL / SubHeightC), ccAlfWidth is set equal to CcAlfWidthCrL / SubWidthC, ccAlfHeight is set equal to CcAlfHeightCrL / SubHeightC, and the cross-component filter coefficient CcAlfCoeff[j] is set equal to CcAlfCoeff Cr [j], j = 0..13 as input, and output as modified filtered picture ccAlfPicture Cr .

[0715] Cross-component filtering process for blocks of chroma samples

[0716] The input to this process is:

[0717] -recPicture, the reconstructed luminance picture sample array before the luminance adaptive loop filtering process L ,

[0718] -Filtered reconstructed chrominance image sample array alfPicture C ,

[0719] - chroma position (xC, yC), which specifies the top left sample of the current chroma sample block relative to the top left sample of the current picture,

[0720] - ccAlfWidth, the width of the chroma sample block

[0721] - The height of the chroma sample block ccAlfHeight

[0722] - Cross-component filter coefficients CcAlfCoeff[j], j = 0..13

[0723] The output of this process is the modified filtered reconstructed chroma picture sample array ccAlfPicmre. The coding tree block luma position (xCtb, yCtb) is derived as follows:

[0724] xCtb=(((xC*SubWidthC)>>CtbLog2SizeY)<<CtbLog2SizeY

[0725] yCtb=(((yC*SubHeightC)>>CtbLog2SizeY)<<CtbLog2SizeY

[0726] For the derivation of the filtered reconstructed chroma samples ccAlfPicture[xC+x][yC+y], each reconstructed chroma sample alfPicture within the current chroma block of samples C [xC+x][yC+y], x=0..ccAlfWidth-1, y=0..ccAlfHeight-1 is filtered as follows:

[0727] - Set the luma position (xL, yL) corresponding to the current chroma sample at chroma position (xC+x, yC+y) equal to ((xC+x)*SubWidthC, (yC+y)*SubHeightC)

[0728] -Array recPicture L The internal brightness position (h xL+i , v yL+j ), i = -2..2, j = -2..3 are derived as follows:

[0729] If pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_ver_virtual_boundaries-1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is not equal to 0, and xL-PpsVirtualBoundariesPosX[n] is greater than or equal to 0 and less than 3, then the following applies:

[0730] h xL+i =Clip3(PpsVirtualBoundariesPosX[n], pic_width_in_luma_samples-1, xL+i)

[0731] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_ver_virtual_boundaries-1, and PpsVirtualBoundariesPosX[n]%CtbSizeY is not equal to 0, and PpsVirtualBoundariesPosX[n]-xL is greater than 0 and less than 4, then the following applies: h x+i =Clip3(0,PpsVirtualBoundariesPosXf n]-1,xL+i)

[0732] - Otherwise, the following applies:

[0733] h x+i =Clip3(0,pic_width_in_luma_samples-1,xL+i)

[0734] If pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_hor_virtual_boundaries-1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is not equal to 0, and yL-PpsVirtuaIBoundariesPosY[n] is greater than or equal to 0 and less than 3, then the following applies:

[0735] v y+j =Clip3(PpsVirtualBoundariesPosY[n], pic_height_in_luma_samples-1, yL+j)

[0736] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_hor_virtual_boundaries-1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is not equal to 0, and PpsVirtualBoundariesPosY[n]-yL is greater than 0 and less than 4, then the following applies:

[0737] v y+j=Clip3(0,PpsVirtualBoundariesPosY[n]-1,yL+j)

[0738] - Otherwise, the following applies:

[0739] v y+j =Clip3(0,pic_height_in_luma_samples-1,yL+j)

[0740] -The variables clipLeftPos, clipRightPos, clipTopPos and clipBottomPos are derived by calling the ALF boundary position derivation process specified below with (xCtb, yCtb) and (xL-xCtb, yL-yCtb) as input.

[0741] - The vertical sample position offsets yM2, yM1, yP1, yP2, and yP3 are specified in Table 22 according to the vertical luma sample position yL, clipLeftPos, and clipRightPos.

[0742] - The horizontal sample position offsets xM1, xM2, xP1, and xP2 are specified in Table 23 according to the horizontal luma sample position xL, clipLeftPos, and clipRightPos.

[0743] -The variable curr is derived as follows:

[0744] curr=alfPicture C [xC+x,yC+y]

[0745] - The array of cross-component filter coefficients f[j], where j = 0..13, is derived as follows: f[j] = CcAlfCoeff[j]

[0746] -The variable sum is exported as follows:

[0747] sum=f[0]*recPicture L [h x , v y+yM2 ]+

[0748] f[1]*recPicture L [h x+xM1 , v y+yM1 ]+

[0749] f[2]*recPicture L [h x , v y+yM1 ]+

[0750] f[3]*recPicture L [h x+xP1 ,v y+yM1 ]+

[0751] f[4]*recPicture L [h x+xM2 ,v y ]+

[0752] f[5]*recPicture L [h x+xM1 ,v y ]+

[0753] f[6]*recPicture L [h x ,v y ]+

[0754] f[7]*recPicture L [h x+xP1 ,v y ]+

[0755] f[4]*recPicture L [h x+xP2 ,V y ]+

[0756] f[4]*recPicture L [h x+xM2 ,v y+yP1 ]+

[0757] f[8]*recPicture L [h x+xM1 ,v y+yP1 ]+

[0758] f[9]*recPicture L [h x ,v y+yP1 ]+

[0759] f

[10] *recPicture L [h x+xP1 ,v y+yP1 ]+

[0760] f[4]*recPicture L [h x+xP2 ,v y+yP1 ]+

[0761] f

[11] *recPicture L [h x+xM1 ,vy+yP2 ]+

[0762] f

[12] *recPicture L [h x , v y+yP2 ]+

[0763] f

[13] *recPicture L [h x+xP1 , v y+yP2 ]+

[0764] f[0]*recPicture L [h x , vy+yP3 ]+

[0765] sum=curr+(sum+64)>>7)

[0766] - modified filtered reconstructed chroma picture sample array ccAlfPicture[xC+x][yC

[0767] +y] is derived as follows:

[0768] ccAlfPicture[xC+x][yC+y]=Clip3(0, (1<<BitDepth C )-1, sum)

[0769] condition yM2 yM1 yP1 yP2 yP3 yL == clipTopPos + 1 -1 -1 1 2 3 yL==clipTopPos 0 0 1 2 3 yL==clipBottomPos-1 -2 -1 0 0 0 yL==clipBottomPos-2 -2 -1 1 1 1 yL==clipBottomPos-3 -2 -1 1 2 2 Other situations -2 -1 1 2 3

[0770] Table 22

[0771] condition xM2 xM1 yP1 xP2 xL == clipLeftPos+1 -1 -1 1 2 xL==clipLeftPos 0 0 1 2 xL==clipRightPos-1 -2 -1 0 0 xL==clipRightPos-2 -2 -1 1 1 Other situations -2 -1 1 2

[0772] Table 23

[0773] ALF boundary position derivation

[0774] The input to this process is:

[0775] - luma position (xCb, yCb), which specifies the top left sample of the current luma coding tree block relative to the top left sample of the current picture,

[0776] - Luma position (x, y), which specifies the upper left sample of the current sample relative to the current luma coding treeblock.

[0777] The output of this process is:

[0778] -left vertical border position clipLeftPos,

[0779] -right vertical border position clipRightPos,

[0780] - Upper horizontal border position clipTopPos,

[0781] - The bottom horizontal border position clipBottomPos.

[0782] Set the variables clipLeftPos, clipRightPos, clipTopPos, and clipBottomPos equal to -128.

[0783] The variable clipTopPos is modified as follows:

[0784] If the bottom boundary of the current coding tree block is not the bottom boundary of the picture and y-(CtbSizeY-4) is greater than or equal to 0, then set the variable clipTopPos equal to yCtb+CtbSizeY-4.

[0785] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is equal to 0, and yCtb+y-PpsVirtualBoundariesPosY[n] is greater than or equal to 0 and less than 3, the following applies: clipTopPos=PpsVirtualBoundariesPosY[n]

[0786] Otherwise, if y is less than 3, and the top boundary of the current coding treeblock is not the top boundary of the picture, and one or more of the following conditions are true, then set the variable clipTopPos equal to yCtb:

[0787] - If the top boundary of the current coding tree block is the top boundary of a brick and loop_filter_across_bricks_enabled_flag is equal to 0.

[0788] - If the top boundary of the current coding tree block is the top boundary of a slice, and loop_filter_across_slices_enabled_flag is equal to 0.

[0789] - If the top boundary of the current coding tree block is the top boundary of a sub-picture and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[0790] The variable clipBottomPos is modified as follows:

[0791] If the bottom boundary of the current coding tree block is not the bottom boundary of the picture and CtbSizeY-4-v is greater than 0 and less than 4, then set the variable clipBottomPos equal to yCtb+CtbSizeY-4.

[0792] Otherwise, if for any n = 0..pps_num_hor_virtual_boundaries-1, pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1, PpsVirtualBoundariesPosY[n] % CtbSizeY is equal to 0, PpsVirtualBoundariesPosY[n] is not equal to pic_height_in_luma_samples-1 or 0, and PpsVirtualBoundariesPosY[n]-yCtb-y is greater than 0 and less than 4, then the following applies:

[0793] clipBottomPos=PpsVirtualBoundariesPosY[n]

[0794] Otherwise, if CtbSizeY - y is less than 4, and the bottom boundary of the current coding tree block is not the bottom boundary of the picture, and one or more of the following conditions are true, then set the variable clipBottomPos equal to yCtb + CtbSizeY:

[0795] - If the bottom boundary of the current coding tree block is the bottom boundary of a brick and loop_filter_across_bricks_enabled_flag is equal to 0.

[0796] - If the bottom boundary of the current coding tree block is the bottom boundary of a slice, and loop_filter_across_slices_enabled_flag is equal to 0.

[0797] - If the bottom boundary of the current coding tree block is the bottom boundary of a sub-picture and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[0798] The variable clipLeftPos is modified as follows:

[0799] If, for any n = 0..pps_num_ver_virtual_boundaries-1, pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is equal to 0, and xCtb+x-PpsVirtualBoundariesPosX[n] is greater than or equal to 0 and less than 3, then the following applies: clipLeftPos=PpsVirtualBoundariesPosX[n]

[0800] Otherwise, if x is less than 3, the left boundary of the current coding tree block is not the left boundary of the picture, and one or more of the following conditions are true, then set the variable clipLeftPos equal to xCtb:

[0801] - If the left border of the current coding treeblock is the left border of a brick, and loop_filter_across_bricks_enabled_flag is equal to 0.

[0802] - If the left boundary of the current coding tree block is the left boundary of a slice, and loop_filter_across_slices_enabled_flag is equal to 0.

[0803] - If the left boundary of the current coding treeblock is the left boundary of a sub-picture, and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[0804] The variable clipRightPos is modified as follows:

[0805] - If pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is equal to 0, and PpsVirtualBoundariesPosX[n] - xCtb - x is greater than 0 and less than 4, then the following applies: clipRightPos = PpsVirtualBoundariesPosX[n]

[0806] Otherwise, if CtbSizeY-x is less than 4, and the right boundary of the current coding tree block is not the right boundary of the picture, and one or more of the following conditions are true, then set the variable clipRightPos equal to xCtb+CtbSizeY:

[0807] - If the right border of the current coding treeblock is the right border of a brick, and loop_filter_across_bricks_enabled_flag is equal to 0.

[0808] - If the right boundary of the current coding tree block is the right boundary of a slice, and loop_filter_across_slices_enabled_flag is equal to 0.

[0809] - If the right boundary of the current coding treeblock is the right boundary of a sub-picture, and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[0810] As described above, the syntax elements may be entropy coded according to CABAC or the like. In one example, according to the techniques herein, the binarization of alf_cross_component_cb_flag and / or alf_cross_component_cr_flag may be fixed-length FL binarization with a maximum value cMax=1. In addition, in one example, according to the techniques herein, for alf_cross_component_cb_flag and / or alf_cross_component_cr_flag, two variables pStateIdx0 and pStateIdx1 corresponding to the probability state index of the CABAC coding may be initialized as follows:

[0811] Tables 24 and 25 contain the values of the 6-bit variable initValue used in initializing the context variables assigned to the syntax elements alf_cross_component_cb_flag and alf_cross_component_cr_flag. In Tables 24 and 25, the value of the variable ctxIdx is mapped to initValue and shiftIdx. It should be noted that in Tables 24 and 25, the shiftIdx value is the shift value used to derive the state transition process. In addition, the value EP indicates equivalence and corresponds to the value 35 in JVET-O2001.

[0812]

[0813] Table 24

[0814]

[0815] Table 25

[0816] From the 6-bit table entry initValue, the two 3-bit variables slopeIdx and offsetIdx are derived as follows:

[0817] slopeIdx=initValue>>3

[0818] offsetIdx=initValue&7

[0819] The variables m and n used in the initialization of the context variables are derived from slopeIdx and offsetIdx as follows:

[0820] m=slopeIdx-4

[0821] n=(offsetIdx*18)+1

[0822] The two values assigned to pStateIdx0 and pStateIdx1 for initialization are from SliceQp Y Derived, which is derived as provided above:

[0823] Given variables m and n, the initialization is specified as follows:

[0824] preCtxState=Clip3(1,127,((m*(Clip3(0,51,SliceQp Y )-16))>>1)+n)

[0825] The two values assigned to initialize pStateIdx0 and pStateIdx1 are derived as follows: pStateIdx0 = preCtxState<<3

[0826] pStateIdx1=preCtxState<<7

[0827] The ctxIdx that needs to be initialized for each of the three initialization types specified by the variable initType is listed in Table 26. For P and B slice types, the derivation of initType depends on the value of the cabac_init_flag syntax element. The variable initType is derived as follows:

[0828]

[0829]

[0830] Table 26

[0831] The variable ctxIdxOffset is set equal to initType according to Table 26. The variable ctxIdx is set equal to the sum of ctxInc and ctxIdxOffset.

[0832] In one example, the allocation of ctxInc is specified as follows, where condL and condA are specified in Table 27:

[0833] - For the syntax elements alf_cross_component_cb_flag[x0 / CcAlfWidthCbL][y0 / CcAlfHeightCbL] and alf_cross_component_cr_flag[x0 / CcAlfWidthCrL][y0 / CcAlfHeightCrL]:

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

[0835]

[0836]

[0837] Table 27

[0838] For Table 27, in one example, each of the syntax elements in condL and / or condA may be compared to 0, eg, a "==0" test may be added.

[0839] In one example, according to the techniques herein, cross-component filtering may include using a filter with zero gain. In one example, the coefficients of a zero-gain filter sum to zero. It should be noted that a zero-gain filter with a coefficient sum of zero can provide better coding efficiency for multiple signaled coefficients because unsignaled filter coefficients can be determined and used. That is, when the coefficients of a zero-gain filter sum to zero, if the values of the remaining filter coefficients are known, the values of the filter coefficients can be derived, and therefore, there is no need to explicitly signal one of these coefficients, resulting in bitrate savings. Furthermore, it should be noted that in other examples, the filter can be divided into two or more coefficient subsets, and the coefficient values in each subset may need to sum to a specific value (e.g., a value that is not necessarily zero). For example, in one example, the filter can be divided (e.g., horizontally, vertically, or approximately diagonally) into two equal halves. The coefficients in the first half can be constrained to sum to a predetermined value (e.g., a fixed point representation of 0.5), and the coefficients in the second half can be constrained to sum to the predetermined value minus the predetermined value. The predetermined value can also be zero.

[0840] FIG. 20A to FIG. 20B shows an example of a zero-gain filter, where the coefficients sum to zero. That is, FIG. 20A to FIG. 20B As shown, for the number of filter support samples, N, N-1 coefficients are signaled and one coefficient is derived. It should be noted that the use of a zero gain filter where the coefficients sum to zero can be applied to any filter size and shape described herein.

[0841] for Figure 20A In one example, the corresponding filtering process may be based on the following:

[0842] Cross-component filtering process for blocks of chroma samples

[0843] The input to this process is:

[0844] -recPicture, the reconstructed luminance picture sample array before the luminance adaptive loop filtering process L ,

[0845] -Filtered reconstructed chrominance image sample array alfPicture C ,

[0846] - chroma position (xC, yC), which specifies the top left sample of the current chroma sample block relative to the top left sample of the current picture,

[0847] - ccAlfWidth, the width of the chroma sample block

[0848] - The height of the chroma sample block ccAlfHeight

[0849] - Cross-component filter coefficients CcAlfCoeff[j], j = 0..7

[0850] The output of this process is the modified filtered reconstructed chroma picture sample array ccAlfPicture.

[0851] The coding tree block luma position (xCtb, yCtb) is derived as follows:

[0852] xCtb=(((xC*SubWidthC)>>CtbLog2SizeY)<<CtbLog2SizeY

[0853] yCtb=(((yC*SubHeightC)>>CtbLog2SizeY)<<CtbLog2SizeY

[0854] For the derivation of the filtered reconstructed chroma samples ccAlfPicture[xC+x][yC+y], each reconstructed chroma sample alfPicture within the current chroma block of samples C [xC+x][yC+y], x=0..ccAlfWidth-1, y=0..ccAlfHeight-1 is filtered as follows:

[0855] - Set the luma position (xL, yL) corresponding to the current chroma sample at chroma position (xC+x, yC+y) equal to ((xC+x)*SubWidthC, (yC+y)*SubHeightC)

[0856] -Array recPicture L The internal brightness position (h xL+i , v yL+j ), i = -1..1, j = -1..2 are derived as follows:

[0857] If, for any n=0..pps num_ver_virtual_boundaries-1, pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is not equal to 0, and xL-PpsVirtualBoundariesPosX[n] is greater than or equal to 0 and less than 3, the following applies:

[0858] h xL+i=Clip3(PpsVirtualBoundariesPosX[n], pic_width_in_luma_samples-1, xL+i)

[0859] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_ver_virtual_boundaries-1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is not equal to 0, and PpsVirtualBoundariesPosX[n]-xL is greater than 0 and less than 4, then the following applies:

[0860] h x+i =Clip3(0,PpsVirtualBoundariesPosX[n]-1,xL+i)

[0861] - Otherwise, the following applies:

[0862] h x+i =Clip3(0,pic_width_in_luma_samples-1,xL+i)

[0863] If pps_loop_fbter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_hor_virtual_boundaries-1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is not equal to 0, and yL-PpsVirtualBoundariesPosY[n] is greater than or equal to 0 and less than 3, then the following applies:

[0864] v y+j =Clip3(PpsVirtualBoundariesPosY[n], pic_height_in_luma_samples-1, yL+j)

[0865] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_hor_virtual_boundaries-1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is not equal to 0, and PpsVirtualBoundafiesPosY[n]-yL is greater than 0 and less than 4, then the following applies:

[0866] v y+j =Clip3(0,PpsVirtualBoundariesPos Y[n]-1,yL+j)

[0867] - Otherwise, the following applies:

[0868] v y+j =Clip3(0,pic_height_in_luma_samples-1,yL+j)

[0869] -The variables clipLeftPos, clipRightPos, clipTopPos and clipBottomPos are derived by calling the ALF boundary position derivation process specified below with (xCtb, yCtb) and (xL-xCtb, yL-yCtb) as input.

[0870] - The vertical sample position offsets yM2, yM1, yP1, yP2, and yP3 are specified in Table 22 according to the vertical luma sample position yL, clipLeftPos, and clipRightPos.

[0871] - The horizontal sample position offsets xM1, xM2, yP1, and xP2 are specified in Table 23 based on the horizontal luma sample position xL, clipLeftPos, and clipRightPos.

[0872] -The variable curr is derived as follows:

[0873] curr=alfPicture C [xC+x,yC+y]

[0874] The array of cross-component filter coefficients f[j] is derived as follows, where j = 0..7:

[0875] f[j]=CcAlfCoeff[j]

[0876] The variables centerValue and sum are derived as follows:

[0877] centerValue = recPicture L [h x , v y ]

[0878] sum=f[0]*(recPicture L [h x , v y+yM1 ]-centerValue)+

[0879] f[1]*(recPicture L [h x+xM1 , v y ]-centerValue)+

[0880] f[2]*(recPicture L [h x+xP1 , v y+yM1 ]-centerValue)+

[0881] f[3]*(recPicture L [h x+xP1 , v y ]-centerValue)+

[0882] f[4]*(recPicture L [h x+xM1 , v y+yP1 ]-centerValue)+

[0883] f[5]*(recPicture L [h x , v y+yP1 ]-centerValue)+

[0884] f[6]*(recPicture L [h x+xP1 , v y+yP1 ]-centerValue)+

[0885] f[7]*(recPicture L [h x , v y+yP2 ]-centerValue)

[0886] sum=curr+(sum+64)>>7)

[0887] The modified filtered reconstructed chroma picture sample array ccAlfPicture[xC+x][yC+y] is derived as follows:

[0888] ccAlfPicture[xC+x][yC+y]=Clip3(0, (1<<BitDepth C )-1, sum)

[0889] for Figure 20B In one example, the corresponding filtering process may be based on the following:

[0890] Cross-component filtering process for blocks of chroma samples

[0891] The input to this process is:

[0892] -recPicture, the reconstructed luminance picture sample array before the luminance adaptive loop filtering process L ,

[0893] -Filtered reconstructed chrominance image sample array alfPicture C ,

[0894] - chroma position (xC, yC), which specifies the top left sample of the current chroma sample block relative to the top left sample of the current picture,

[0895] - ccAlfWidth, the width of the chroma sample block

[0896] - The height of the chroma sample block ccAlfHeight

[0897] - Cross-component filter coefficients CcAlfCoeff[j], j = 0..5

[0898] The output of this process is the modified filtered reconstructed chroma picture sample array ccAlfPicture. The coding tree block luma position (xCtb, yCtb) is derived as follows:

[0899] xCtb=(((xC*SubWidthC)>>CtbLog2SizeY)< <CtbLog2SizeY

[0900] yCtb=(((yC*SubHeightC)>>CtbLog2SizeY)<<CtbLog2SizeY

[0901] For derivation of the filtered reconstructed chroma samples ccAlfPicture[xC+x][yC+y], each reconstructed chroma sample alfPictureC[xC+x][yC+y] within the current chroma block of samples, x=0..ccAlfWidth-1, y=0..ccAlfHeight-1 is filtered as follows:

[0902] - Set the luma position (xL, yL) corresponding to the current chroma sample at chroma position (xC+x, yC+y) equal to ((xC+x)*SubWidthC, (yC+y)*SubHeightC)

[0903] -Array recPicture L The internal brightness position (h xL+i , v yL+j ), i = -1..1, j = -1..1 is derived as follows:

[0904] If pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_ver_virtual_boundaries-1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is not equal to 0, and xL-PpsVirtualBoundariesPosX[n] is greater than or equal to 0 and less than 3, then the following applies:

[0905] h sL+i =Clip3(PpsVirtualBoundariesPosX[n], pic_width_in_luma_samples-1, xL+i)

[0906] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_ver_virtual_boundaries-1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is not equal to 0, and PpsVirtualBoundariesPosX[n]-xL is greater than 0 and less than 4, then the following applies:

[0907] h x+i =Clip3(0,PpsVirtualBoundariesPosX[n]-1,xL+i)

[0908] - Otherwise, the following applies:

[0909] h x+i =Clip3(0,pic_width_in_luma_samples-1,xL+i)

[0910] If pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_hor_virtual_boundaries-1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is not equal to 0, and yL-PpsVirtualBoundariesPosY[n] is greater than or equal to 0 and less than 3, then the following applies:

[0911] v y+j =Clip3(PpsVirtualBoundariesPosY[n], pic_height_in_luma_samples-1, yL+j)

[0912] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_hor_virtual_boundaries-1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is not equal to 0, and PpsVirtualBoundariesPosY[n]-yL is greater than 0 and less than 4, then the following applies:

[0913] vy+j=Clip3(0,PpsVirtualBoundariesPosY[n]-1,yL+j)

[0914] - Otherwise, the following applies:

[0915] v y+ j=Clip3(0,pic_height_in_luma_samples-1,yL+j)

[0916] -The variables clipLeftPos, clipRightPos, clipTopPos and clipBottomPos are derived by calling the ALF boundary position derivation process specified below with (xCtb, yCtb) and (xL-xCtb, yL-yCtb) as input.

[0917] - The vertical sample position offsets yM2, yM1, yP1, yP2, and yP3 are specified in Table 22 according to the vertical luma sample position yL, clipLeftPos, and clipRightPos.

[0918] - The horizontal sample position offsets xM1, xM2, xP1, and xP2 are specified in Table 23 according to the horizontal luma sample position xL, clipLeftPos, and clipRightPos.

[0919] -The variable curr is derived as follows:

[0920] curt=alfPicture C [xC+x,yC+y]

[0921] - The array of cross-component filter coefficients f[j], where j = 0..5, is derived as follows: f[j] = CcAlfCoeff[j]

[0922] The variables centerValue and sum are derived as follows:

[0923] centerValue = recPicture L [h x , v y ]

[0924] sum=f[0]*(recPicture L [h x , v y+yM1 ]-centerValue)+

[0925] f[1]*(recPicture L [h x+xM1 , v y ]-centerValue)+

[0926] f[2]*(recPicture L [h x+xP1 , v y ]-centerValue)+

[0927] f[3]*(recPicture L [h x+xM1 , v y+yP1 ]-centerValue)+

[0928] f[4]*(recPicture L [h x , v y+yP1 ]-centerValue)+

[0929] f[5]*(recPicture L [h x+xP1 , v y+yP1 ]-centerValue)+

[0930] sum=curr+(sum+64)>>7)

[0931] The modified filtered reconstructed chroma picture sample array ccAlfPicture[xC+x][yC+y] is derived as follows:

[0932] ccAlfPicture[xC+x][yC+y]=Clip3(0, (1<<BitDepth C )-1, sum)

[0933] "Versatile Video Coding (Draft 7)" from the 16th meeting of ISO / IEC JTC1 / SC29 / WG11, held in Geneva, Switzerland, from October 1 to 11, 2019 (document JVET-P2001-vE, incorporated herein by reference and referred to as JVET-P2001) is an update to JVET-O2001 and represents the current version of the draft text of the video coding specification corresponding to the VVC project. JVET-P2001 includes a picture header syntax structure that includes information common to all slices of a coded picture associated with a picture (PH). Table 28 shows the portion of the syntax structure of the picture header provided in JVET-P2001 that is relevant to filtering operations.

[0934]

[0935]

[0936] Table 28

[0937] For Table 28, JVET-P2001 provides the following semantics:

[0938] A PH includes information that is common to all slices of the coded picture associated with the PH.

[0939] …

[0940] pic_sao_enabled_present_flag equal to 1 specifies that pic_sao_luma_flag and pic_sao_chroma_flag are present in the PH, and pic_sao_enabled_present_flag equal to 0 specifies that pic_sao_luma_flag and pic_sao_chroma_flag are not present in the PH. When pic_sao_enabled_present_flag is not present, it is inferred to be equal to 0.

[0941] pic_sao_luma_flag equal to 1 specifies that SAO is enabled for luma components in all slices associated with the PH; pic_sao_luma_flag equal to 0 specifies that SAO for luma components may be disabled for one or more or all slices associated with the PH. When pic_sao_luma_flag is not present, it is inferred to be equal to 0.

[0942] pic_sao_chroma_flag equal to 1 specifies that SAO is enabled for chroma components in all slices associated with the PH; pic_sao_chroma_flag equal to 0 specifies that SAO for chroma components may be disabled for one or more or all slices associated with the PH. When pic_sao_chroma_flag is not present, it is inferred to be equal to 0.

[0943] pic_alf_enabled_present_flag equal to 1 specifies that pic_alf_enabled_present_flag, pic_num_alf_aps_ids_luma, pic_alf_aps_id_luma[i], pic_alf_chroma_idc, and pic_alf_aps_id_chroma are present in the PH. pic_alf_enabled_present_flag equal to 0 specifies that pic_alf_enabled_flag, pic_num_alf_aps_ids_luma, pic_alf_aps_id_luma[i], pic_alf_chroma_idc, and pic_alf_aps_id_chroma are not present in the PH. When pic_alf_enabled_present_flag is not present, it is inferred to be 0.

[0944] pic_alf_enabled_flag equal to 1 specifies that the adaptive loop filter is enabled for all slices associated with the PH and may be applied to the Y, Cb, or Cr color components in the slices. pic_alf_enabled_flag equal to 0 specifies that the adaptive loop filter may be disabled for one or more or all slices associated with the PH. When not present, pic_alf_enabled_flag is inferred to be equal to 0.

[0945] pic_num_alf_aps_ids_luma specifies the number of ALF APSs referenced by the slice associated with the PH.

[0946] pic_alf_aps_id_luma[i] specifies the adaptation_parameter_set_id of the i-th ALFAPS referenced by the luma component of the slice associated with the PH.

[0947] The value of alf_luma_filter_signal_flag shall be equal to 1 for APS NAL units with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to pic_alf_aps_id_lumma[i].

[0948] pic_alf_chroma_idc equal to 0 specifies that the adaptive loop filter is not applied to the Cb and Cr color components. pic_alf_chroma_idc equal to 1 indicates that the adaptive loop filter is applied to the Cb color component. pic_alf_chroma_idc equal to 2 indicates that the adaptive loop filter is applied to the Cr color components. pic_alf_chroma_idc equal to 3 indicates that the adaptive loop filter is applied to the Cb and Cr color components. When pic_alf_chroma_idc is not present, it is inferred to be equal to 0.

[0949] pic_alf_aps_id_chroma specifies the adaptation_parameter_set_id of the ALF APS referenced by the chroma components of the slice associated with the PH.

[0950] The value of alf_chroma_filter_signal_flag shall be equal to 1 for APS NAL units with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to pic_alf_aps_id_chroma.

[0951] pic_dep_quant_enabled_flag equal to 0 specifies that dependent quantization is disabled for slices associated with the PH. pic_dep_quant_enabled_flag equal to 1 specifies that dependent quantization is enabled for slices associated with the PH. When not present, the value of pic_dep_quant_enabled_flag is inferred to be equal to pps_dep_quant_enable_idc-1.

[0952] sign_data_hiding_enabled_flag equal to 0 specifies that sign bit hiding is disabled. sign_data_hiding_enabled_flag equal to 1 specifies that sign bit hiding is enabled. When sign_data_hiding_enabled_flag is not present, it is inferred to be equal to 0.

[0953] pic_deblocking_filter_override_present_flag equal to 1 specifies that pic_deblocking_filter_override_flag is present in the PH. pic_deblocking_filter_override_present_flag equal to 0 specifies that pic_deblocking_filter_override_flag is not present in the PH. When pic_deblocking_filter_override_present_flag is not present, it is inferred to be equal to 0.

[0954] pic_deblocking_filter_override_flag equal to 1 specifies that deblocking parameters are present in the PH. pic_deblocking_filter_override_flag equal to 0 specifies that deblocking parameters are not present in the PH. When not present, the value of pic_pic_deblocking_filter_override_flag is inferred to be equal to 0.

[0955] pic_deblocking_filter_disabled_flag equal to 1 specifies that the operation of the deblocking filter is not applied to the slices associated with the PH. pic_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter is applied to the slices associated with the PH. When pic_deblocking_filter_disabled_flag is not present, it is inferred to be equal to pps_deblocking_filter_disabled_flag.

[0956] pic_beta_offset_div2 and pic_tc_offset_div2 specify the deblocking parameter offsets (divided by 2) for beta and tc of the slice associated with the PH. The values of pic_beta_offset_div2 and pic_tc_offset_div2 should both be in the range of -6 to 6, inclusive. When not present, the values of pic_beta_offset_div2 and pic_tc_offset_div2 are inferred to be equal to pps_beta_offset_div2 and pps_tc_offset_div2, respectively.

[0957] In one example, according to the techniques herein, implementation of cross-component filtering using picture header syntax structure can be based on the following syntax and semantics:

[0958]

[0959]

[0960] Table 29

[0961]

[0962]

[0963] Table 30

[0964]

[0965]

[0966] Table 31

[0967]

[0968]

[0969] Table 32

[0970] For Tables 29 to 32, in one example, the semantics may be based on the semantics provided above and the following:

[0971] A value of pic_alf_enabled_present_flag equal to 1 indicates the presence of pic_alf_enabled_flag, pic_num_alf_aps_ids_luma, pic_alf_aps_id_luma[i], pic_alf_chroma_idc, pic_alf_aps_id_chroma, pic_cross_component_alf_cb_enabled_flag, pic_cross_component_alf_cb_aps_id, pic_cross_component_cb_filters_signalled_minus1, pic_cross_component_alf_cr_enabled_flag, pic_cross_component_alf_cr_aps_id, and pic_cross_component_cr_filters_signalled_minus1 in the PH. A value of pic_alf_enabled_present_flag equal to 0 indicates the absence of pic_alf_enabled_flag, pic_num_alf_aps_ids_luma, pic_alf_aps_id_luma[i], pic_alf_chroma_idc, pic_alf_aps_id_chroma, pic_cross_component_alf_cb_enabled_flag, pic_cross_component_alf_cb_aps_id, pic_cross_component_cb_filters_signalled_minus1, pic_cross_component_alf_cr_enabled flag, pic_cross_component_alf_cr_aps_id, and pic_cross_component_cr_filters_signalled_minus1 in the PH. When pic_alf_enabled_present_flag is not present, it is inferred to be equal to 0.

[0972] pic_cross_component_alf_cb_enabled_flag equal to 1 specifies that the cross-component Cb filter is enabled for all slices associated with the PH and may be applied to the Cb color components in the slices. pic_cross_component_alf_cb_enabled_flag equal to 0 specifies that the cross-component Cb filter may be disabled for one or more or all slices associated with the PH. When not present, pic_cross_component_alf_cb_enabled_flag is inferred to be equal to 0.

[0973] pic_cross_component_alf_cb_aps_id specifies the adaptation_parameter_set_id of the ALF APS referenced by the Cb color component of the slice associated with the PH.

[0974] The value of alf_cross_component_cb_filter_signal_flag shall be equal to 1 for APS NAL units with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to pic_cross_component_alf_cb_aps_id.

[0975] pic_cross_component_cb_filters_signalled_minus1 plus 1 specifies the number of cross-component Cb filters. The value of pic_cross_component_cb_filters_signalled_minus1 should be in the range of 0 to 3.

[0976] When pic_cross_component_alf_cb_enabled_flag is equal to 1, bitstream conformance requires that pic_cross_component_cb_filters_signalled_minus1 shall be less than or equal to the value of alf_cross_component_cb_filters_signalled_minus1 in the indexed ALF APS referenced by pic_cross_component_alf_cb_aps_id.

[0977] pic_cross_component_alf_cr_enabled_flag equal to 1 specifies that the cross-component Cr filter is enabled for all slices associated with the PH and may be applied to Cr color components in the slices. pic_cross_component_alf_cr_enabled_flag equal to 0 specifies that the cross-component Cr filter may be disabled for one or more or all slices associated with the PH. When not present, pic_cross_component_alf_cr_enabled_flag is inferred to be equal to 0.

[0978] pic_cross_component_alf_cr_aps_id specifies the adaptation_parameter_set_id of the ALF APS referenced by the Cr color component of the slice associated with the PH.

[0979] The value of alf_cross_component_cr_filter_signal_flag shall be equal to 1 for APS NAL units with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to pic_cross_component_alf_cr_aps_id.

[0980] pic_cross_component_cr_filters_signalled_minus1 plus 1 specifies the number of cross-component Cr filters. The value of pic_cross_component_cr_filters_signalled_minus1 should be in the range of 0 to 3.

[0981] When pic_cross_component_alf_cr_enabled_flag is equal to 1, bitstream conformance requires that pic_cross_component_cr_filters_signalled_minus1 shall be less than or equal to the value of alf_cross_component_cr_filters_signalled_minus1 in the indexed ALF APS referenced by pic_cross_component_alf_cr_aps_id.

[0982] alf_luma_filter_signal_flag equal to 1 specifies that the luma filter set is signaled. alf_luma_filter_signal_flag equal to 0 specifies that the luma filter set is not signaled.

[0983] 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 ChromaArrayType is equal to 0, alf_chroma_filter_signal_flag shall be equal to 0.

[0984] The values of alf_luma_filter_signal_flag, alf_chroma_filter_signal_flag, alf_cross_component_cb_filter_signal_flag, and alf_cross_component_cr_filter_signal_flag shall not all be equal to 0.

[0985] The variable NumAlfFilters, which specifies the number of different adaptive loop filters, is set equal to 25.

[0986] alf_cross_component_cb_filter_signal_flag equal to 1 specifies that the cross-component Cb filter is signaled. alf_cross_component_cb_filter_signal_flag equal to 0 specifies that the cross-component Cb filter is not signaled. When ChromaArrayType is equal to 0, alf_cross_component_cb_filtersignal_flag shall be equal to 0.

[0987] alf_cross_component_cb_filter_signalled_minus1 plus 1 specifies the number of cross-component Cb filters signaled in the current ALF APS. The value of alf_cross_component_cb_filters_signalled_minus1 shall be in the range of 0 to 3.

[0988] alf_cross_component_cb_coeff_plus32[k][j] minus 32 specifies the value of the j-th coefficient of the signaled k-th cross-component Cb filter bank. When alf_cross_component_cb_coeff_plus32[k][j] is not present, it is inferred to be equal to 32.

[0989] With element CcAlfApsCoeff Cb[adaptation_parameter_set_id][k][j], signaled k-th cross-component Cb filter coefficient CcAlfApsCoeff for j=0..7 Cb [adaptation_parameter_set_id][k] is derived as follows:

[0990] CcAlfApsCoeff Cb [adaptation_parameter_set_id][k][j]=alf_cross_component_cb_coeff_plus32[k][j]-32

[0991] alf_cross_component_cr_filter_signal_flag equal to 1 specifies that the cross-component Cr filter is signaled. alf_cross_component_cr_filter_signal_flag equal to 0 specifies that the cross-component Cr filter is not signaled. When ChromaArrayType is equal to 0, alf_cross_component_cr_filter_signal_flag shall be equal to 0.

[0992] alf_cross_component_cr_filters_signalled_minus1 plus 1 specifies the number of cross-component Cr filters signaled in the current ALF APS. The value of alf_cross_component_cr_filters_signalled_minus1 shall be in the range of 0 to 3.

[0993] alf_cross_component_cr_coeff_plus32[k][j] minus 32 specifies the value of the j-th coefficient of the signaled k-th cross-component Cr filter bank. When alf_cross_component_cr_coeff_abs[k][j] is not present, it is inferred to be equal to 32.

[0994] With element CcAlfApsCoeff Cr [adaptation_parameter_set_id][k][j], signaled k-th cross-component Cr filter coefficient CcAlfApsCoeff for j=0..7 Cr [adaptation_parameter_set_id][k] is derived as follows:

[0995] CcAlfApsCoeff Cr [adaptation_parameter_set_id][k][j]=alf_cross_component_cr_coeff_plus32[k][j]-32

[0996] slice_cross_component_alf_cb_enabled_flag equal to 0 specifies that the cross-component Cb filter is not applied to the Cb color component. slice_cross_component_alf_cb_enabled_flag equal to 1 indicates that the cross-component Cb filter is applied to the Cb color component. When slice_cross_component_alf_cb_enabled_flag is not present, it is inferred to be equal to pic_cross_component_alf_cb_enabled_flag.

[0997] slice_cross_component_alf_cb_aps_id specifies the adaptation_parameter_set_id indexed by the Cb color component of the slice. The TemporalId of APS NAL units with apsparamstype equal to ALF_APS and adaptation_parameter_set_id equal to slice_cross_component_alf_cb_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit. When slice_cross_component_alf_cb_enabled_flag is equal to 1 and slicec_cross_component_alf_cb_aps_id is not present, the value of slice_cross_component_alf_cb_aps_id is inferred to be equal to the value of pic_cross_component_alf_cb_aps_id.

[0998] The value of alf_cross_component_cb_filter_signal_flag shall be equal to 1 for APS NAL units with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_cross_componcnt_alf_cb_aps_id.

[0999] slice_cross_component_cb_filters_signalled_minus1 plus 1 specifies the number of cross-component Cb filters. The value of slice_cross_component_cb_filters_signalled_minus1 shall be in the range of 0 to 3. When slice_cross_component_alf_cb_enabled_flag is equal to 1 and slice_cross_component_cb_filters_signalled_minus1 is not present, the value of slice_cross_component_cb_filters_signalled_minus1 is inferred to be equal to the value of pic_cross_component_cb_filters_signalled_minus1.

[1000] When slice_cross_component_alf_cb_enabled_flag is equal to 1, bitstream conformance requires that slice_cross_component_cb_filters_signalled_minus1 shall be less than or equal to the value of alf_cross_component_cb_filters_signalled_minus1 in the ALF APS referenced by slice_cross_component_alf_cb_aps_id of the current slice.

[1001] 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. When slice_cross_component_alf_cr_enabled_flag is not present, it is inferred to be equal to pic_cross_component_alf_cr_enabled_flag.

[1002] slice_cross_component_alf_cr_aps_id specifies the adaptation_parameter_set_id indexed by the Cr color component of the slice. The TemporalId of APS NAL units with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_cross_component_alf_cr_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit. When slice_cross_component_alf_cr_enabled_flag is equal to 1 and slice_cross_component_alf_cr_aps_id is not present, the value of slice_cross_component_alf_cr_aps_id is inferred to be equal to the value of pic_cross_component_alf_cr_aps_id.

[1003] The value of alf_cross_component_cr_filter_signal_flag shall be equal to 1 for APS NAL units with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_cross_component_alf_cr_aps_id.

[1004] slice_cross_component_cr_filters_signalled_minus1 plus 1 specifies the number of cross-component Cr filters. The value of slice_cross_component_cr_filters_signalled_minus1 shall be in the range of 0 to 3. When slice_cross_component_alf_cr_enabled_flag is equal to 1 and slice_cross_component_cr_filters_signalled_minus1 is not present, the value of slice_cross_component_cr_filters_signalled_minus1 is inferred to be equal to the value of pic_cross_component_cr_filters_signalled_minus1.

[1005] When slice_cross_component_alf_cr_enabled_flag is equal to 1, bitstream conformance requires that slice_cross_component_cr_filters_signalled_minus1 shall be less than or equal to the value of alf_cross_component_cr_filters_signalled_minus1 in the indexed ALF APS referenced by slice_cross_component_alf_cr_aps_id of the current slice.

[1006] alf_ctb_cross_component_cb_idc[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] equal to 0 indicates that the cross-component Cb filter is not applied to the block of Cb color component samples at the luma position (xCtb, yCtb). alfcross_component_cb_idc[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] not equal to 0 indicates that the alf_cross_component cb_idc[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY]th cross-component Cb filter is applied to the block of Cb color component samples at the luma position (xCtb, yCtb). When alf_ctb_cross_component_cb_idc[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] does not exist, it is inferred to be equal to 0.

[1007] alf_ctb_cross_component_cr_idc[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] equal to 0 indicates that a cross-component Cr filter is not applied to the block of Cr color component samples at the luma position (xCtb, yCtb). alf_cross_component_cr_idc[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] not equal to 0 indicates that alf_cross_component cr_idc[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY]th cross-component Cr filter is applied to the block of Cr color component samples at the luma position (xCtb, yCtb). When alf_ctb_cross_component_cr_idc[xCtb>>CtbLog2SizeY][yCtb>>CtbLog2SizeY] does not exist, it is inferred to be equal to 0.

[1008] In one example, according to the techniques herein, for example, for the syntax and semantics provided above for Tables 29 to 32, an adaptive loop filter process may be performed based on:

[1009] The input to this process is the adaptive loop filter recPicture L The previous reconstructed picture sample array and when ChromaArrayType is not equal to 0, the array recPicture Cb and recPicture Cr .

[1010] The output of this process is the adaptive loop filter alfPicture L The modified reconstructed picture sample array and when ChromaArrayType is not equal to 0, the array ccAlfPictur Cb and ccAlfPicture Cr .

[1011] Adaptive loop filter alfPicture L The sample values in the modified reconstructed image sample array, and when ChromaArrayType is not equal to 0, the array alfPicture Cb and alfPicture Cr Initially set equal to the adaptive loop filter recPicture LThe sample values in the previous reconstructed image sample array, and when ChromaArrayType is not equal to 0, the array recPicture Cb and recPicture Cr .

[1012] Apply the following sequential steps:

[1013] For each CTU with luma CTB position (rx, ry), where rx = 0..PicWidthInCtbsY-1 and ry = 0..PicHeightInCtbsY-1, the following applies:

[1014] - When alf_ctb_flag[0][rx][ry] is equal to 1, the coding tree block filtering process is called for the specified luma sample, where recPicture L 、alfPicture L and the luma coding tree block position (xCtb, yCtb) set equal to (rx<<CtbLog2SizeY, ry<<CtbLog2SizeY) as input, and the output is the modified filtered picture alfPicture L .

[1015] - When ChromaArrayType is not equal to 0 and alf_ctb_flag[1][rx][ry] is equal to 1, call the following coded tree block filtering process for the specified chroma samples, with recPicture set equal to recPicture Cb , alfPicture is defined as equal to alfPicture Cb , the chroma coding tree block position (xCtbC, yCtbC) is set equal to ((rx<<CtbLog2SizeY) / SubWidthC, (ry<<CtbLog2SizeY) / SubHeightC), and the alternative chroma filter index altIdx is set equal to alf_ctb_filter_alt_idx[0][rx][ry] as input, and the output is the modified filtered picture alfPicture Cb .

[1016] - When ChromaArrayType is not equal to 0 and alf_ctb_flag[2][rx][ry] is equal to 1, call the following coded tree block filtering process for the specified chroma samples, with recPicture set equal to recPicture Cr, alfPicture is set equal to alfPicture Cr , the chroma coding tree block position (xCtbC, yCtbC) is set equal to ((rx<<CtbLog2SizeY) / SubWidthC, (ry<<CtbLog2SizeY) / SubHeightC), and the alternative chroma filter index altIdx is set equal to alf_ctb_filter_alt_idx[0][rx][ry] as input, and the output is the modified filtered picture alfPicture Cr .

[1017] -When ChromaArrayType is not equal to 0, the array ccAlfPicture Cb and ccAlfPicture Cr The sample values in the array alfPicture are set equal to Cb and alfPicture Cr The sample values in .

[1018] For each CTU with luma CTB position (rx, ry), where rx = 0..PicWidthInCtbsY-1 and ry = 0..PicHeightInCtbsY-1, the following applies:

[1019] - When ChromaArrayType is not equal to 0 and alf_ctb_cross_component_cb_idc[rx][ry] is not equal to 0, call the following cross-component filtering process for the specified chroma sample block, where recPicture L is set equal to recPicture L ,alfPicture C is set equal to alfPicture Cb, the chroma coding tree block position (xCtbC, yCtbC) is set to be equal to ((rx << CtbLog2SizeY) / SubWidthC, (ry << CtbLog2SizeY) / SubHeightC)), the luma coding tree block position (xCtb, yCtb) is set to be equal to (rx << CtbLog2SizeY, ry << CtbLog2SizeY), ccAlfWidth is set to be equal to (1 << << CtbLog2SizeY) / SubWidthC, ccAlfHeight is set to be equal to (1 << << CtbLog2SizeY) / SubHeightC, and the cross-component filter coefficient CcAlfCoeff[j] is set to be equal to CcAlfCoeff Cb [slice_cross_component_alf_cb_aps_id][alf_ctb_cross_component_cb_idc[rx][ry]-1][j], where j = 0..7 is taken as input, and the output is the modified filtered picture ccAlfPicture Cb .

[1020] - When ChromaArrayType is not equal to 0 and alf_ctb_cross_component_cr_idc[rx][ry] is not equal to 0, the following cross-component filtering process for the specified chroma sample block is called, where recPicture L is set to be equal to recPicture L , alfPicture C is set to be equal to alfPicture Cr , the chroma coding tree block position (xCtbC, yCtbC) is set to be equal to ((rx << CtbLog2SizeY) / SubWidthC, (ry << CtbLog2SizeY) / SubHeightC)), the luma coding tree block position (xCtb, yCtb) is set to be equal to (rx << CtbLog2SizeY, ry << CtbLog2SizeY), ccAlfWidth is set to be equal to (1 << << CtbLog2SizeY) / SubWidthC, ccAlfHeight is set to be equal to (1 << << CtbLog2SizeY) / SubHeightC, and the cross-component filter coefficient CcAlfCoeff[j] is set to be equal to CcAlfCoeff Cr[slice_cross_component_alf_cr_aps_id][alf_ctb_cross_component_cr_idc[rx][ry]-1][j], j=0..7 as input and output as modified filtered picture ccAlfPicture Cr .

[1021] Cross-component filtering process for blocks of chroma samples

[1022] The input to this process is:

[1023] -recPicture, the reconstructed luminance picture sample array before the luminance adaptive loop filtering process L ,

[1024] -Filtered reconstructed chrominance image sample array alfPicture C ,

[1025] - chroma position (xCtbC, yCtbC), which specifies the top left sample of the current chroma coding treeblock relative to the top left sample of the current picture,

[1026] - Luma position (xCb, yCb), which specifies the top left sample of the current luma coding tree block relative to the top left sample of the current picture

[1027] - ccAlfWidth, the width of the chroma sample block

[1028] - The height of the chroma sample block ccAlfHeight

[1029] - Cross-component filter coefficients CcAlfCoeff[j], j = 0..7

[1030] The output of this process is the modified filtered reconstructed chroma picture sample array ccAlfPicture.

[1031] For the derivation of the filtered reconstructed chroma samples ccAlfPicture[xCtbC+x][yCtbC+y], each reconstructed chroma sample alfPicture within the current chroma block of samples C [xCtbC+x][yCtbC+y], x=0..ccAlfWidth-1, y=0..ccAlfHeight-1 is filtered as follows:

[1032] - Set the luma position (xL, yL) corresponding to the current chroma sample at chroma position (xCtbC+x, yCtbC+y) equal to ((xCtbC+x)*SubWidthC, (yCtbC+y)*SubHeightC)

[1033] -Array recPicture L The internal brightness position (h xL+i , v yL+j ), i = -1..1, j = -1..2 are derived as follows:

[1034] If pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_ver_virtual_boundaries-1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is not equal to 0, and xL-PpsVirtualBoundariesPosX[n] is greater than or equal to 0 and less than 3, then the following applies:

[1035] h xL+i =Clip3(PpsVirtualBoundariesPosX[n], pic_width_in_luma_samples-1, xL+i)

[1036] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_ver_virtual_boundaries-1, and PpsVirtualBoundariesPosX[n] % CtbSizeY is not equal to 0, and PpsVirtualBoundariesPosX[n]-xL is greater than 0 and less than 4, then the following applies:

[1037] h x+i =Clip3(0,PpsVinualBoundariesPosX[n]-1,xL+i)

[1038] - Otherwise, the following applies:

[1039] h x+i =Clip3(0,pic_width_in_luma_samples-1,xL+i)

[1040] If pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_hor_virtual_boundaries-1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is not equal to 0, and yL-PpsVirtualBoundariesPosY[n] is greater than or equal to 0 and less than 3, then the following applies:

[1041] v y+j =Clip3(PpsVirtualBoundariesPosY[n], pic_height_in_luma_samples-1, yL+j)

[1042] Otherwise, if pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 1 for any n=0..pps_num_hor_virtual_boundaries-1, and PpsVirtualBoundariesPosY[n] % CtbSizeY is not equal to 0, and PpsVirtualBoundafiesPosY[n]-yL is greater than 0 and less than 4, then the following applies:

[1043] v y+j =Clip3(0,PpsVirtualBoundariesPosY[n]-1,yL+j)

[1044] - Otherwise, the following applies:

[1045] v y+j =Clip3(0,pic_height_in_luma_samples-1,yL+j)

[1046] -The variables clipLeftPos, clipRightPos, clipTopPos and clipBottomPos are derived by calling the ALF boundary position derivation process specified below with (xCtb, yCtb) and (xL-xCtb, yL-yCtb) as input.

[1047] - The vertical sample position offsets yM1, yP1, and yP2 are specified in Table 33 based on the vertical luma sample position yL, clipLeftPos, and clipRightPos.

[1048] - The horizontal sample position offsets xM1 and xP1 are specified in Table 34 based on the horizontal luma sample position xL, clipLeftPos, and clipRightPos.

[1049] -The variable curr is derived as follows:

[1050] curr=alfPicture C [xCtbC+x,yCtbC+y]

[1051] - The array of cross-component filter coefficients f[j], where j = 0..7, is derived as follows: f[j] = CcAlfCoeff[j]

[1052] -The variable sum is exported as follows:

[1053] sum=f[0]*recPicture L [h x , v y+yM1 ]+

[1054] f[1]*recPicture L [h x+xM1 , v y ]+

[1055] f[2]*recPicture L [h x , v y ]+

[1056] f[3]*recPicture L [h x+xP1 , v y ]+

[1057] f[4]*recPicture L [h x+xM1 , v y+yP1 ]+

[1058] f[5]*recPicture L [h x , v y+yP1 ]+

[1059] f[6]*recPicture L [h x+xP1 , v y+yP1 ]+

[1060] f[7]*recPicture L [h x , v y+yP2 ]

[1061] deltaBitDepth=BitDepth Y -BitDepth C

[1062] scaledSum=(sum+(1<<(6+deltaBitDepth)))>>(7+deltaBitDepth)

[1063] scaledSum=Clip3(-(1<<(BitDepth C -1)), (1<<(BitDepth C -1, scaledSum)

[1064] sum=curr+scaledSum

[1065] - The modified filtered reconstructed chroma picture sample array ccAlfPicture[xCtbC+x][yCtbC+y] is derived as follows:

[1066] ccAlfPicture[xCtbC+x][yCtbC+y]=Clip3(0, (1<<BitDepth C )-1, sum)

[1067]

[1068]

[1069] Table 33

[1070] condition xM1 yP1 xL==clipLeftPos 0 0 xL==clipRightPos-1 0 0 xL==clipRightPos-2 -1 1 Other situations -1 1

[1071] Table 34

[1072] It should be noted that an embodiment of cross-component filtering based on the syntax and semantics provided for Tables 29 to 32 provides an 8-tap filter. An example embodiment of a corresponding 6-tap filter is provided in U.S. Provisional Application No. 62 / 913,065, filed October 9, 2019, each of which is incorporated herein by reference in its entirety.

[1073] In one example, according to the techniques herein, the ALF boundary position derivation process can be based on the following, where the input includes a virtual boundary offset vbOffset that specifies the distance in luma samples between the bottom boundary of the current coding treeblock and the virtual boundary.

[1074] ALF boundary position derivation

[1075] The input to this process is:

[1076] - luma position (xCb, yCb), which specifies the top left sample of the current luma coding tree block relative to the top left sample of the current picture,

[1077] - Luma position (x, y), which specifies the upper left sample of the current sample relative to the current luma coding treeblock.

[1078] The output of this process is:

[1079] -left vertical border position clipLeftPos,

[1080] -right vertical border position clipRightPos,

[1081] - Upper horizontal border position clipTopPos,

[1082] - lower horizontal border position clipBottomPos,

[1083] - Upper left border mark clipTopLeftFlag,

[1084] - Lower right border flag clipBotRightFlag.

[1085] Set the variables clipLeftPos, clipRightPos, clipTopPos, and clipBottomPos equal to -128.

[1086] The variables clipTopLeftFlag and clipBotRightFlag are both set equal to 0.

[1087] The variable clipTopPos is modified as follows:

[1088] -If y-(CtbSizeY-4) is greater than or equal to 0, then the variable clipTopPos is set equal to yCtb+CtbSizeY-4.

[1089] Otherwise, if VirtualBoundariesDisabledFlag is equal to 1 for any n = 0..VirtualBoundariesNumHor-1, and yCtb+y-VirtualBoundariesPosY[n] is greater than or equal to 0 and less than 3, then the following applies: clipTopPos=VirtualBoundariesPosY[n]

[1090] Otherwise, if y is less than 3 and one or more of the following conditions are true, the variable clipTopPos is set equal to yCtb:

[1091] - The top boundary of the current coding tree block is the top boundary of the slice, and loop_filter_across_tiles_enabled_flag is equal to 0.

[1092] - The top boundary of the current coding tree block is the top boundary of the slice, and loop_filter_across_slices_enabled_flag is equal to 0.

[1093] - The top boundary of the current coding tree block is the top boundary of the sub-picture, and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[1094] The variable clipBottomPos is modified as follows:

[1095] - If for any n = 0..VirtualBoundariesNumHor-1, VirtualBoundariesDisabledFlag is equal to 1, VirtualBoundariesPosY[n] is not equal to pic_height_in_luma_samples-1 or 0, and VirtualBoundariesPosY[n]-yCtb-y is greater than 0 and less than 5, then the following applies: clipBottomPos = VirtualBoundariesPosY[n]

[1096] Otherwise, if CtbSizeY-4-y is greater than 0 and less than 5, the variable clipBottomPos is set equal to yCtb+CtbSizeY-4.

[1097] Otherwise, if CtbSizeY-y is less than 5 and one or more of the following conditions are true, the variable clipBottomPos is set equal to yCtb+CtbSizeY:

[1098] - The bottom boundary of the current coding tree block is the bottom boundary of the slice, and loop_filter_across_tiles_enabled_flag is equal to 0.

[1099] - The bottom boundary of the current coding tree block is the bottom boundary of the slice, and loop_filter_across_slices_enabled_flag is equal to 0.

[1100] - The bottom boundary of the current coding tree block is the bottom boundary of the sub-picture, and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[1101] The variable clipLeftPos is modified as follows:

[1102] - If VirtualBoundariesDisabledFlag is equal to 1 for any n = 0..VirtualBoundafiesNumVer-1, and xCtb+x-VirtualBoundariesPosX[n] is greater than or equal to 0 and less than 3, then the following applies: clipLeftPos=VirtualBoundariesPosX[n]

[1103] Otherwise, if x is less than 3 and one or more of the following conditions are true, the variable clipLeftPos is set equal to xCtb:

[1104] - The left boundary of the current coding tree block is the left boundary of the slice, and loop_filter_across_tiles_enabled_flag is equal to 0.

[1105] - The left boundary of the current coding tree block is the left boundary of a slice, and loop_filter_across_slices_enabled_flag is equal to 0.

[1106] - The left boundary of the current coding tree block is the left boundary of the sub-picture, and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[1107] The variable clipRightPos is modified as follows:

[1108] - If VirtualBoundariesDisabledFlag is 1 for any n = 0..Virtua1BoundariesNumVer-1, and VirtualBoundariesPosX[n]-xCtb-x is greater than 0 and less than 5, then the following applies: clipRightPos = VirtualBoundariesPosX[n]

[1109] Otherwise, if CtbSizeY-x is less than 5 and one or more of the following conditions are true, the variable clipRightPos is set equal to xCtb+CtbSizeY:

[1110] - The right border of the current coding tree block is the right border of the tile, and loop_filter_across_tiless_enabled_flag is equal to 0.

[1111] - The right boundary of the current coding tree block is the right boundary of a slice, and loop_filter_across_slices_enabled_flag is equal to 0.

[1112] - The right boundary of the current coding tree block is the right boundary of the sub-picture, and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[1113] The variables clipTopLeftFlag and clipBotRightFlag are modified as follows:

[1114] If the coding tree block covering luma position (xCtb, yCtb) and the coding tree block covering luma position (xCtb-CtbSizeY, yCtb-CtbSizeY) belong to different slices and loop_filter_across_slices_enabled_flag is equal to 0, clipTopLeftFlag is set equal to 1.

[1115] If the CTB covering luma position (xCtb, yCtb) and the CTB covering luma position (xCtb+CtbSizeY, yCtb+CtbSizeY) belong to different slices and loop_filter_across_slices_enabled_flag is equal to 0, then clipBotRightFlag is set equal to 1.

[1116] As described above, the syntax elements may be entropy coded according to CABAC, etc. In one example, according to the techniques herein, binarization of alf_cross_component_cb_idc[][] and / or alf_cross_component_cr_idc[][] may be as provided in Table 35.

[1117]

[1118] Table 35

[1119] Furthermore, in one example, according to the techniques herein, for alf_cross_component_cb_idc[][] and / or alf_cross_component_cr_idc[][], two variables pStateIdx0 and pStateIdx1 corresponding to probability state indices of CABAC coding may be initialized as follows:

[1120] Tables 36 and 37 contain the values of the 6-bit variable initValue used in initializing the context variables assigned to the syntax elements alf_cross_component_cb_flag and alf_cross_component_cr_flag. In Tables 36 and 37, the value of the variable ctxIdx is mapped to initValue and shiftIdx. It should be noted that in Tables 36 and 37, the shiftIdx value is the shift value used to derive the state transition process. In addition, the value EP indicates equivalence and corresponds to the value 35 in JVET-P2001.

[1121]

[1122] Table 36

[1123]

[1124] Table 37

[1125] From the 6-bit table entry initValue, the two 3-bit variables slopeIdx and offsetIdx are derived as provided above:

[1126] The variables m and n used in the initialization of the context variables are derived from slopeldx and offsetldx as provided above.

[1127] The two values assigned to pStateIdx0 and pStateIdx1 for initialization are from SliceQp Y Exported, exported as provided above.

[1128] The two values assigned to pStateIdx0 and pStateIdx1 for initialization are derived as provided above.

[1129] The ctxIdx that needs to be initialized for each of the three initialization types specified by the variable initType is listed in Table 38. For P and B slice types, the derivation of initType depends on the value of the cabac_init_flag syntax element. The variable initType is derived as follows:

[1130]

[1131]

[1132]

[1133] Table 38

[1134] The variable ctxIdxOffset is set equal to initType according to Table 38. The variable ctxIdx is set equal to the sum of ctxlnc and ctxIdxOffset.

[1135] In one example, the assignment of ctxInc is specified as follows:

[1136]

[1137] Table 39

[1138] - For the syntax elements alf__ctb_cross_component_cb_idc[x0>>CtbLog2SizeY][y0>>CtbLog2SizeY] and alf_ctb_cross_component_cr_idc[x0>>CtbLog2SizeY][y0>>CtbLog2SizeY]:

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

[1140]

[1141] Table 40

[1142] 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 sample data for one or more additional components of the video data, derive a cross-component filter based on data associated with the one or more additional components of the video data, and apply a filter to the reconstructed sample data for the current component of the video data based on the derived cross-component filter and the reconstructed sample data for the one or more additional components of the video data.

[1143] Figure 17is a block diagram illustrating an example of a video decoder that can be configured to decode video data according to one or more techniques of the present disclosure. In one example, the video decoder 500 can be configured to reconstruct the video data based on one or more of the techniques described above. That is, the video decoder 500 can operate in a manner that is inverse to the video encoder 200 described above. The video decoder 500 can be configured to perform intra-frame prediction decoding and inter-frame prediction decoding, and therefore can be referred to as a hybrid decoder. Figure 18 In the example shown, video decoder 500 includes an entropy decoding unit 502, an inverse quantization unit 504, an inverse transform processing unit 506, an intra-frame prediction processing unit 508, an inter-frame prediction processing unit 510, a summer 512, a filter unit 514, and a reference buffer 516. Video decoder 500 can be configured to decode video data in a manner consistent with a video coding system that can implement one or more aspects of a video coding standard. It should be noted that although the exemplary 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 specific hardware or software architecture. The functionality of video decoder 500 can be implemented using any combination of hardware, firmware, and / or software implementations.

[1144] like Figure 17 As shown, entropy decoding unit 502 receives an entropy-encoded bitstream. Entropy decoding unit 502 can be configured to decode quantized syntax elements and quantized coefficients from the bitstream according to a process that is inverse to the entropy encoding process. Entropy decoding unit 502 can be configured to perform entropy decoding according to any of the entropy encoding techniques described above. Entropy decoding unit 502 can parse the encoded bitstream in a manner consistent with a video coding standard. Video decoder 500 can be configured to parse an encoded bitstream generated based on the techniques described above.

[1145] Reference again Figure 17The inverse quantization unit 504 receives quantized transform coefficients (i.e., 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 delta QP values and / or quantization group size values. The video decoder 500 and / or the inverse quantization unit 504 may be configured to determine the QP value used for inverse quantization based on a value signaled by the video encoder and / or via video attributes and / or coding parameters. In other words, the inverse quantization unit 504 may operate in a manner reciprocal to the coefficient quantization unit 206 described above. For example, the inverse quantization unit 504 may be configured to infer a predetermined value, an allowed quantization group size, etc., according to the techniques described above. The inverse quantization unit 504 may be configured to apply inverse quantization. The inverse transform processing unit 506 may be configured to perform an inverse transform to generate reconstructed residual data. The techniques performed by the inverse quantization unit 504 and the inverse transform processing unit 506, respectively, may be similar to those performed by the inverse quantization / transform processing unit 208 described above. The inverse transform processing unit 506 may be configured to apply an inverse DCT, an inverse DST, an inverse integer transform, a non-separable quadratic transform (NSST), or a conceptually similar inverse transform process to transform the coefficients so as to produce a residual block in the pixel domain. Furthermore, as described above, whether a particular transform (or type of particular transform) is performed may depend on the intra prediction mode. Figure 17 As shown, the reconstructed residual data may be provided to summer 512. Summer 512 may add the reconstructed residual data to the predicted video block and generate reconstructed video data. The predicted video block may be determined based on a predictive video technique (ie, intra prediction and inter prediction).

[1146] The intra-prediction processing unit 508 may be configured to receive intra-prediction syntax elements and retrieve a predicted video block from a reference buffer 516. The reference buffer 516 may include a memory device configured to store one or more frames of video data. The intra-prediction syntax elements may identify an intra-prediction mode, such as the intra-prediction modes described above. ...

Claims

1. A method for filtering reconstructed video data, the method comprising: Parsing a first syntax element from a slice header according to a value of a cross-component adaptive loop filter enable flag; parsing a second syntax element from a coding tree unit syntax element according to a value of the cross-component adaptive loop filter enable flag; Parsing a third syntax element from a picture header syntax element; In a case where the cross-component adaptive loop filter enable flag is equal to 1 and the first syntax element does not exist, inferring that the value of the first syntax element is equal to the value of the third syntax element; setting cross-component filter coefficients by using the first syntax element and the second syntax element; Inputting the reconstructed luminance picture sample array before the luminance adaptive loop filtering process; Input is a reconstructed chroma picture sample array filtered according to the chroma adaptive loop filtering process; deriving a luma position by using the position corresponding to the current chroma sample; deriving a filter coefficient array by using the cross-component filter coefficients; deriving variables by using the array of filter coefficients and the array of reconstructed luma picture samples defined by the luma positions; deriving a scaling variable by using the variable; deriving a modified variable by summing the reconstructed chroma picture sample array and the scaling variable; as well as A modified filtered reconstructed chroma picture sample array is derived by using the modified variable.

2. A device for decoding video data, the device comprising one or more processors configured to: decoding a first syntax element from a slice header according to a value of a cross-component adaptive loop filter enable flag; parsing a second syntax element from a coding tree unit syntax element according to a value of the cross-component adaptive loop filter enable flag; Parsing a third syntax element from a picture header syntax element; In a case where the cross-component adaptive loop filter enable flag is equal to 1 and the first syntax element does not exist, inferring that the value of the first syntax element is equal to the value of the third syntax element; setting cross-component filter coefficients by using the first syntax element and the second syntax element; Inputting the reconstructed luminance picture sample array before the luminance adaptive loop filtering process; Input is a reconstructed chroma picture sample array filtered according to the chroma adaptive loop filtering process; deriving a luma position by using the position corresponding to the current chroma sample; deriving a filter coefficient array by using the cross-component filter coefficients; deriving variables by using the array of filter coefficients and the array of reconstructed luma picture samples defined by the luma positions; deriving a scaling variable by using the variable; deriving a modified variable by summing the reconstructed chroma picture sample array and the scaling variable; as well as A modified filtered reconstructed chroma picture sample array is derived by using the modified variable.

Images