Controlling cross-border filtering in video coding

Abstract

Methods, apparatuses, and systems for controlling in-loop filtering processes across boundaries during video encoding and decoding are described. An example method includes performing a conversion between a video comprising a video region of sub-pictures and a bitstream of the video, wherein the bitstream conforms to a format rule that specifies whether a first syntax element is signaled in the bitstream is based on whether a sub-picture is considered a picture, and wherein the first syntax element relates to an application of an in-loop filtering process across a sub-picture boundary associated with the video region.

Description

[0001] Cross-references to related applications

[0002] Pursuant to applicable patent law and / or the rules of the Paris Convention, this application promptly claims priority and benefit from U.S. Provisional Patent Application No. 62 / 954,393, filed December 27, 2019. For all legal purposes, the entire disclosure of the aforementioned application is incorporated herein by reference as part of the disclosure of this application. Technical Field

[0003] This patent document relates to image encoding and decoding as well as video encoding and decoding. Background Technology

[0004] Digital video accounts for the largest share of bandwidth usage on the Internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, the bandwidth demand for digital video is expected to continue to grow. Summary of the Invention

[0005] This document discloses methods, techniques, and systems that can be used by video encoders and decoders to control the loop filtering process across boundaries during video encoding and decoding, respectively.

[0006] In one example aspect, a video processing method is disclosed. The method includes: for a conversion between a video comprising video regions and a bitstream of the video, determining whether to apply a loop filtering process across boundaries associated with the video regions, and performing the conversion based on that determination, wherein the bitstream includes one or more syntax elements indicating whether the loop filtering process is applicable to each video region.

[0007] In another example, a different video processing method is disclosed. This method includes: performing a conversion between a video comprising a video region containing sub-images and a bitstream of the video, wherein the bitstream conforms to a format rule specifying whether a signaling notification first syntax element is included in the bitstream based on whether the sub-image is considered an image, and wherein the first syntax element relates to the application of a loop filtering process across the boundaries of the sub-images associated with the video region.

[0008] In yet another example aspect, a video encoder device is disclosed. The video encoder includes a processor configured to implement the methods described above.

[0009] In yet another example aspect, a video decoder device is disclosed. The video decoder includes a processor configured to implement the methods described above.

[0010] In yet another example aspect, a computer-readable medium having code stored thereon is disclosed. The code embodies one of the methods described herein in the form of processor-executable code.

[0011] These and other features are described throughout this document. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 An example is shown of partitioning a picture using luma coding tree unit (CTU) partitioning.

[0013] Figure 2 Another example is shown of partitioning a picture using luma CTU partitioning.

[0014] Figure 3 An example partitioning of a picture is shown.

[0015] Figure 4 Another example partitioning of a picture is shown.

[0016] Figure 5 is a block diagram of an example encoder implementation.

[0017] Figure 6 is an illustration of picture samples that can be de-blocked in parallel, as well as horizontal and vertical block boundaries.

[0018] Figure 7 An example is shown of pixels involved in filter on / off decision and filter selection.

[0019] Figure 8 Four one-dimensional (1-D) directional modes of EO sample classification are shown: horizontal (EO class = 0), vertical (EO class = 1), 135° diagonal (EO class = 2), and 45° diagonal (EO class = 3).

[0020] Figure 9 An example is shown of ALF filter shapes.

[0021] Figure 10 An example is shown of loop filter line buffer requirements for luma components.

[0022] Figure 11 An example is shown of loop filter line buffer requirements for chroma components.

[0023] Figure 12 An example is shown of modified block classification at a virtual boundary.

[0024] Figure 13 An example is shown of modified ALF filtering of luma components at a virtual boundary.

[0025] Figures 14A-14CAn example of modified luma ALF filtering at virtual boundaries is shown.

[0026] Figure 15 An example of repeated padding of luma ALF filtering at picture / subpicture / slice / tile boundaries is shown.

[0027] Figure 16 An example of horizontal wrap-around motion compensation in VVC is shown.

[0028] Figure 17 An HEC picture in 3x2 layout is shown.

[0029] Figures 18A-18B An arrangement of CC-ALF relative to other in-loop filters is shown.

[0030] Figure 19 is a block diagram of an example video processing system that can implement the disclosed technology.

[0031] Figure 20 is a block diagram of an example hardware platform for video processing.

[0032] Figure 21 is a block diagram illustrating a video coding system according to some embodiments of the disclosure.

[0033] Figure 22 is a block diagram illustrating an encoder according to some embodiments of the disclosure.

[0034] Figure 23 is a block diagram illustrating a decoder according to some embodiments of the disclosure.

[0035] Figures 24-25 is a flowchart illustrating an example method of video processing. DETAILED DESCRIPTION

[0036] The use of section headings in this document is for convenience only and does not limit the applicability of the technology and embodiments disclosed in each section to the application for which that section is presented. Also, the use of H.266 terminology in some descriptions is for convenience only and is not intended to limit the scope of the disclosed technology to the H.266 video codec design. As such, the technology described herein is applicable to other video codec protocols and designs as well.

[0037] 1. SUMMARY

[0038] This document is related to video coding technology. Specifically, it is about the control of in-loop filtering across picture region boundaries. It can be applied to any video coding standard or non-standard video codec that supports single-layer video coding and multi-layer video coding, e.g., the Versatile Video Coding (VVC) that is under development.

[0039] 2. ABBREVIATIONS

[0040] ALF adaptive loop filter

[0041] APS adaptive parameter set

[0042] AU access unit

[0043] AUD access unit delimiter

[0044] AVC advanced video coding

[0045] CLVS coded layer video sequence

[0046] CPB coded picture buffer

[0047] CRA clean random access

[0048] CTU coding tree unit

[0049] CVS coded video sequence

[0050] DPB decoded picture buffer

[0051] DPS decoding parameter set

[0052] EOB end of bitstream

[0053] EOS end of sequence

[0054] GDR gradual decoding refresh

[0055] HEVC high efficiency video coding

[0056] IDR instantaneous decoding refresh

[0057] JEM joint exploration model

[0058] MCTS motion-constrained tile set

[0059] NAL network abstraction layer

[0060] OLS output layer set

[0061] PH picture header

[0062] PPS picture parameter set

[0063] PU picture unit

[0064] RBSP raw byte sequence payload

[0065] SOA sample adaptive offset

[0066] SEI supplemental enhancement information

[0067] SPS Sequence Parameter Set

[0068] VCL Video Coding Layer

[0069] VPS Video Parameter Set

[0070] VTM VVC Test Model

[0071] VUI Video Usability Information

[0072] VVC Versatile Video Coding

[0073] 3. Preliminary Discussion

[0074] Video coding standards have evolved mainly through the development of the well-known ITU-T and ISO / IEC standards. The ITU-T standardized H.261 and H.263, ISO / IEC standardized MPEG-1 and MPEG-4 Visual, and the two organizations jointly standardized H.262 / MPEG-2 Video and H.264 / MPEG-4 Advanced Video Coding (AVC) and H.265 / HEVC. Since H.262, the video coding standards are based on the hybrid video coding structure where temporal prediction is used in combination with transform coding. To explore future video coding technologies beyond HEVC, the Joint Video Exploration Team (JVET) was founded by VCEG and MPEG jointly in 2015. Since then, many new methods have been adopted by JVET and applied to the reference software named Joint Exploration Model (JEM). Currently, the JVET meeting is held every quarter, and the goal of the new coding standard is to reduce bitrates by 50% compared to HEVC. In the April 2018 JVET meeting, the new video coding standard was officially named as Versatile Video Coding (VVC), and the first version of VVC test model (VTM) was released at that time. With continuous effort contributing to the VVC standardization, new coding techniques are adopted for the VCC standard in every JVET meeting. Then, the VVC working draft and test model VTM are updated after every meeting. The current goal of the VVC project is to achieve the Final Draft International

[0075] 3.1. Picture partitioning schemes in HEVC

[0076] HEVC includes four different picture partitioning schemes, namely regular slices, dependent slices, tiles, and Wavefront Parallel Processing (WPP), which can be applied for maximum transmission unit (MTU) size matching, parallel processing, and reduced end-to-end delay.

[0077] A regular slice is similar to a slice in H.264 / AVC. Each regular slice is encapsulated in its own NAL unit and intra-picture prediction (intra-sample prediction, motion information prediction, coding mode prediction) and entropy coding dependencies across slice boundaries are disabled. Thus, a regular slice can be reconstructed independently from other regular slices within the same picture (although there can still be interdependencies due to in-loop filtering operations).

[0078] The regular slice is the only tool available for parallelization, which is also provided in almost the same form in H.264 / AVC. Parallelization based on regular slices does not require much inter-processor or inter-kernel communication (except for inter-processor or inter-kernel data sharing for motion compensation when decoding predictable coded pictures, which is usually much more heavy than inter-processor or inter-kernel data sharing due to intra-picture prediction). However, for the same reason, using regular slices can result in a lot of coding overhead due to the bit cost of the slice header and due to the lack of prediction across slice boundaries. Furthermore, due to the intra-picture independence of regular slices and because each regular slice is encapsulated in its own NAL unit, regular slices can also act as a key mechanism for bitstream segmentation to match MTU size requirements (compared to other tools mentioned below). In many cases, the goals of parallelization and MTU size matching contradict the requirements for slice layout in a picture. The implementation of this situation led to the development of the parallelization tools mentioned below.

[0079] A dependent slice has a short slice header and allows segmentation of the bitstream at tree block boundaries without breaking any intra-picture prediction. Basically, a dependent slice provides a segment of multiple regular slices to multiple NAL units to provide a simplified end-to-end delay by allowing a part of a regular slice to be sent before the encoding of the entire regular slice is completed.

[0080] In WPP, a picture is partitioned into single-row coded tree blocks (CTBs). Entropy decoding and prediction are allowed to use data from CTBs in other partitions. Parallel processing can be achieved by decoding CTB rows in parallel, with the start of decoding of a CTB row delayed by two CTBs to ensure that data related to CTBs above and to the right of the subject CTB are available before the subject CTB is decoded. Using this staggered start (which looks like a wave front when graphically represented), parallelization can be achieved using up to as many processors / cores as the picture contains CTB rows. Because intra-picture prediction between adjacent tree block rows within a picture is allowed, the required inter-processor / core communication for implementing intra-picture prediction can be substantial. WPP partitioning does not result in the creation of additional NAL units compared to non- applied WPP partitioning, so WPP is not a tool for MTU size matching. However, regular slices can be used with WPP, but with some coding overhead, if MTU size matching is required.

[0081] A slice defines horizontal and vertical boundaries that partition a picture into slice columns and slice rows. A slice column extends from the top of the picture to the bottom of the picture. Likewise, a slice row extends from the left side of the picture to the right side of the picture. The number of slices in a picture can be simply derived by multiplying the number of slice columns by the number of slice rows.

[0082] The scan order of the CTBs is changed to be local within a slice (in the order of CTB raster scan of the slice) before the left-top CTB of the next slice is decoded in the picture's slice raster scan order. Similar to regular slices, slices break intra-picture prediction dependencies as well as entropy decoding dependencies. However, they do not need to be included in separate NAL units (same as WPP in this regard); thus, slices cannot be used for MTU size matching. Each slice can be processed by one processor / core, and the inter-processor / core communication required between processing units decoding neighboring slices for intra-picture prediction is limited to communicating the shared slice header in the case of a slice that spans more than one slice, and loop filtering related to sharing of reconstructed samples and metadata. When more than one slice or WPP segment is included in a slice, the entry point byte offset of each slice or WPP segment in the slice is signaled in the slice header, except for the first one in the slice.

[0083] For simplicity, restrictions on the application of four different picture partitioning schemes have been specified in HEVC. For most profiles specified in HEVC, a given coded video sequence cannot contain both tiles and wavefronts. For each slice and tile, either one or both of the following conditions must be met: 1) all coding tree blocks in a slice belong to the same tile; 2) all coding tree blocks in a tile belong to the same slice. Finally, a wavefront tile contains exactly one CTB row, and when WPP is used, if a slice starts from within a CTB row, it must end in the same CTB row.

[0084] A recent amendment to HEVC is specified in the JCT-VC output document (JCTVC-AC1005, J. Boyce, A. Ramasubramonian, R. Skupin, G. J. Sullivan, A. Tourapis, Y.-K. Wang (editors), “HEVC Additional Supplemental Enhancement Information (Draft 4),” 24 October 2017, available at http: / / phenix.int- evry.fr / jct / doc_end_user / documents / 29_Macau / wg11 / JCTVC-AC1005-v2.zip). After including this amendment, HEVC specifies three SEI messages related to MCTS, namely the temporal MCTS SEI message, the MCTS extraction information set SEI message, and the MCTS extraction information nesting SEI message.

[0085] The temporal MCTS SEI message indicates the presence of MCTS in the bitstream and signals the MCTS. For each MCTS, the motion vectors are restricted to point to full-sample positions within the MCTS and to fractional-sample positions that only require interpolation of full-sample positions within the MCTS and the use of motion vector candidates for temporal motion vector prediction that are derived from blocks outside the MCTS is not allowed. In this way, each MCTS can be decoded independently without the presence of tiles that are not included in the MCTS.

[0086] The MCTS extraction information set SEI message provides supplemental information that can be used for MCTS sub-bitstream extraction (specified as part of the semantics of the SEI message) to generate a conforming bitstream for an MCTS set. The information consists of multiple extraction information sets, each defining multiple MCTS sets and containing the RBSP bytes of the replacement VPS, SPS, and PPS to be used during the MCTS sub-bitstream extraction process. When extracting a sub-bitstream according to the MCTS sub-bitstream extraction process, the parameter sets (VPS, SPS, and PPS) need to be rewritten or replaced, and the slice header needs to be slightly updated because one or all of the syntax elements related to slice address (including first_slice_segment_in_pic_flag and slice_segment_address) will typically need to have different values.

[0087] 3.2. Partitioning of pictures in VVC

[0088] In VVC, a picture is partitioned into one or more tile rows and one or more tile columns. A tile is a sequence of CTUs that covers a rectangular region of a picture. The CTUs in a tile are scanned in the tile in the raster scan order.

[0089] A slice consists of an integer number of consecutive complete CTU rows within an integer number of complete tiles or tiles within a picture.

[0090] Two slice modes are supported, namely, the raster-scan slice mode and the rectangular slice mode. In the raster-scan slice mode, a slice contains a series of complete tiles in the tile raster scan of a picture. In the rectangular slice mode, a slice contains either multiple complete tiles that collectively form a rectangular region of a picture or multiple consecutive complete CTU rows of one tile that collectively form a rectangular region of a picture. The tiles within a rectangular slice are scanned in the tile raster scan order within the rectangular region corresponding to the slice.

[0091] A subpicture contains one or more slices that collectively cover a rectangular region of a picture.

[0092] Figure 1 An example of the raster-scan slice partitioning of a picture is shown, where the picture is partitioned into 12 tiles and 3 raster-scan slices.

[0093] Figure 2 An example of the rectangular slice partitioning of a picture is shown, where the picture is partitioned into 24 tiles (6 tile columns and 4 tile rows) and 9 rectangular slices.

[0094] Figure 3 An example of a picture partitioned into tiles and rectangular slices is shown, where the picture is partitioned into 4 tiles (2 tile columns and 2 tile rows) and 4 rectangular slices.

[0095] Figure 4 An example of subpicture partitioning of a picture is shown, where the picture is partitioned into 18 tiles, including 12 tiles on the left (each tile covering one slice of 4x4 CTUs) and 6 tiles on the right (each tile covering 2 vertically stacked slices of 2x2 CTUs), resulting in 24 tiles and 24 subpictures of different dimensions (each slice is a subpicture) in total.

[0096] 3.3. Signaling of subpictures, slices and tiles in VVC

[0097] In the latest VVC draft text, the information of subpictures, including the layout of subpictures (i.e., the number of subpictures per picture and the position and size of each subpicture) and other sequence-level subpicture information, are signaled in the SPS. The order of subpictures signaled in the SPS defines the subpicture index. For example, a list of subpicture IDs (each subpicture has one subpicture ID) can be explicitly signaled in the SPS or PPS.

[0098] Tiles in VVC are conceptually the same as tiles in HEVC, i.e., each picture is partitioned into tile columns and tile rows, but the syntax for signaling of tiles in the PPS is different.

[0099] In VVC, slice modes are also signaled in the PPS. When the slice mode is rectangular slice mode, the slice layout of each picture (i.e., the number of slices per picture and the position and size of each slice) is signaled in the PPS. The order of rectangular slices within a picture signaled in the PPS defines the picture-level slice index. The subpicture-level slice index is defined as the order of a slice within a subpicture in the increasing order of its picture-level slice index. The position and size of a rectangular slice are signaled / derived based on the subpicture position and size signaled in the SPS (when each subpicture contains only one slice) or the tile position and size signaled in the PPS (when a subpicture can contain more than one slice). When the slice mode is raster-scan slice mode, the layout of slices within a picture is signaled in the slices themselves with different details, similar to HEVC.

[0100] 3.4. In-loop filtering in VVC

[0101] Figure 5An example of an encoder block diagram of VVC is shown, which contains three in-loop filters: Deblocking Filter (DF), Sample Adaptive Offset (SAO), and ALF. Unlike DF which uses a pre-defined filter, SAO and ALF utilize original samples of the current picture to reduce the mean square error between original and reconstructed samples by adding offsets and applying a Finite Impulse Response (FIR) filter respectively, with side information signaling the offsets and filter coefficients coded. ALF is located at the last processing stage of each picture and can be regarded as a tool that tries to capture and fix artifacts created by previous stages.

[0102] 3.5. Deblocking Filter (DB)

[0103] The input of DB is the reconstructed samples before in-loop filters.

[0104] The vertical edges in a picture are filtered first. Then the horizontal edges in the picture are filtered with the samples modified by the vertical edge filtering process as input. The vertical and horizontal edges in each CTB of a CTU are processed separately on a coding unit basis. The vertical edges of the coding blocks in a coding unit are filtered starting from the left side edges of the coding blocks, going through the edges in their geometric order, towards the right side of the coding blocks. The horizontal edges of the coding blocks in a coding unit are filtered starting from the top side edges of the coding blocks, going through the edges in their geometric order, towards the bottom of the coding blocks.

[0105] Figure 6 is an illustration of picture samples, horizontal and vertical block boundaries on an 8x8 grid and non-overlapping blocks of 8x8 samples (which can be deblocked in parallel).

[0106] 3.5.1. Boundary decision

[0107] In HEVC, the filtering is applied to 8x8 block boundaries as shown in Figure 6 However, in VVC, a finer filtering is used, where 4x4 block boundaries are filtered. Moreover, it has to be either a transform block boundary or a coding sub-block boundary (e.g. due to the use of affine motion prediction, ATMVP). For those not belonging to such boundaries, the filter is disabled.

[0108] 3.5.2. Boundary strength calculation

[0109] For transform block boundaries / coding sub-block boundaries, if it is located in the 8x8 grid, it can be filtered, and the bS[xD i ][yD j ](where [xD i ][yD jThe settings of the coordinates (x, y) are defined in Table 3-1 and Table 3-2, respectively.

[0110] Table 3-1 Boundary strength (when SPS IBC is disabled)

[0111]

[0112] Table 3-2 Boundary strength (when SPS IBC is enabled)

[0113]

[0114] 3.5.3. Deblocking decision for luma components

[0115] The de-blocking decision process is described in this subclause.

[0116] Figure 7 An example of pixels involved in filter on / off decision and strong / weak filter selection is shown.

[0117] The wider and stronger luma filter is used only when all of condition 1, condition 2 and condition 3 are true.

[0118] Condition 1 is the "large block condition". This condition checks whether the samples on the P-side and the Q-side belong to a large block, which is denoted by the variables bSidePisLargeBlk and bSideQisLargeBlk, respectively. bSidePisLargeBlk and bSideQisLargeBlk are defined as follows.

[0119] bSidePisLargeBlk = ((edgeType is vertical and p0 belongs to a CU with width >= 32) || (edgeType is horizontal and p0 belongs to a CU with height >= 32))? TRUE : FALSE

[0120] bSideQisLargeBlk = ((edgeType is vertical and q0 belongs to a CU with width >= 32) || (edgeType is horizontal and q0 belongs to a CU with height >= 32))? TRUE : FALSE

[0121] Based on bSidePisLargeBlk and bSideQisLargeBlk, condition 1 is defined as follows.

[0122] condition 1 = (bSidePisLargeBlk || bSideQisLargeBlk)? TRUE : FALSE

[0123] Next, if condition 1 is true, condition 2 will be further checked. First, the following variables are derived:

[0124] - First dp0, dp3, dq0, dq3 are derived as in HEVC

[0125] - If (pEdge is greater than or equal to 32)

[0126] dp0 = (dp0 + Abs(p50 - 2*p40 + p30) + 1) » 1

[0127] dp3 = (dp3 + Abs(p53 - 2*p43 + p33) + 1) » 1

[0128] - If (qEdge is greater than or equal to 32)

[0129] dq0 = (dq0 + Abs(q50 - 2*q40 + q30) + 1) » 1

[0130] dq3 = (dq3 + Abs(q53 - 2*q43 + q33) + 1) » 1

[0131] Condition2 = (d < β)? True : False

[0132] Where d = dp0 + dq0 + dp3 + dq3.

[0133] If Condition1 and Condition2 are valid, further check if either block uses sub-blocks:

[0134]

[0135] Finally, if both Condition1 and Condition2 are valid, the proposed deblocking method will check Condition3 (large block strong filter condition), which is defined as follows.

[0136] In Condition3 StrongFilterCondition, the following variables are derived:

[0137] dpq is derived as in HEVC.

[0138] sp3 = Abs(p3 - p0), derived as in HEVC

[0139] If (pEdge is greater than or equal to 32)

[0140]

[0141] sq3 = Abs(q0 - q3), derived as in HEVC

[0142] If (qEdge is greater than or equal to 32)

[0143]

[0144] As in HEVC, StrongFilterCondition = (dpq < (beta » 2), (sp3 + sq3) < (3 * beta » 5), and Abs(p0 - q0) < ((5 * tc + 1) » 1))? TRUE: FALSE.

[0145] 3.5.4. Stronger deblocking filter for luma (designed for larger blocks)

[0146] When any of the samples on either side of the boundary belong to a large block, the bilinear filter is used. A sample belonging to a large block is defined as a vertical edge width >= 32 and a horizontal edge height >= 32.

[0147] The bilinear filter is listed below.

[0148] Then, in the above HEVC deblocking, the block boundary samples p i (i = 0 to Sp - 1) and q j (j = 0 to Sq - 1) (p i and q i are replaced by linear interpolation

[0149] p i ′ = (f i * Middle s,t + (64 - f i ) * P s + 32) » 6), clipped to p i ± tcPD i

[0150] q j ′ = (g j * Middle s,t + (64 - g j ) * Q s + 32) » 6), clipped to q j ± tcPD j

[0151] where the tcPD i and tcPD j terms are the position dependent clippings described in section 3.5.7, and g j , f j , Middle s,t , P s , and Q s are given below:

[0152] 3.5.5. Deblocking control for chroma

[0153] A chroma strong filter is used on both sides of the block boundary. Here, when the two sides of the chroma edge are greater than or equal to 8 (chroma position), the chroma filter is selected and the following decision with three conditions is satisfied: the first one is for the boundary strength and the large block decision. In the chroma sample domain, the proposed filter can be applied when the block width or block height of the orthogonal crossing the block edge is equal to or greater than 8. The second and third ones are basically the same as the HEVC luma deblocking decision, which are the on / off decision and the strong filter decision, respectively.

[0154] In the first decision, the boundary strength (bS) is modified for chroma filtering and the conditions are checked in turn. If the condition is satisfied, the remaining conditions with lower priority are skipped.

[0155] Chroma deblocking is performed when bS is equal to 2, or when a large block boundary is detected, bS is equal to 1.

[0156] The second and third conditions are basically the same as the HEVC luma strong filter decision, as follows.

[0157] In the second condition,

[0158] d is derived as in the HEVC luma deblocking.

[0159] The second condition will be true when d is less than β.

[0160] In the third condition, StrongFilterCondition is derived as follows:

[0161] dpq is derived as in HEVC.

[0162] sp3 = Abs(p3 - p0), derived as in HEVC

[0163] sq3 = Abs(q0 - q3), derived as in HEVC

[0164] StrongFilterCondition = (dpq is less than (β » 2), (sp3 + sq3) is less than (β » 3), and Abs(p0 - q0) is less than (5 * tc + 1) » 1) as in the HEVC design

[0165] 3.5.6. Strong deblocking filter for chroma

[0166] The following strong deblocking filter for chroma is defined:

[0167] p2' = (3 * p3 + 2 * p2 + p1 + p0 + q0 + 4) » 3

[0168] p1' = (2*p3 + p2 + 2*p1 + p0 + q0 + q1 + 4) » 3

[0169] p0' = (p3 + p2 + p1 + 2*p0 + q0 + q1 + q2 + 4) » 3

[0170] The proposed chroma filter performs de-blocking on a 4x4 chroma sample grid.

[0171] 3.5.7. Position dependent clipping

[0172] The position dependent clipping tcPD is applied to the output samples of the luma filtering process which involves strong and long filters modifying 7, 5 and 3 samples at the boundary. Assuming a quantization error distribution, it is proposed to increase the clipping values for samples which are expected to have higher quantization noise and thus are expected to deviate more from the true sample value.

[0173] For each P or Q boundary filtered with asymmetric filters, depending on the result of the decision process in section 3.5.2, a position dependent threshold table is selected from two tables (i.e. Tc7 and Tc3 listed in the tables below) which are provided as side information to the decoder:

[0174] Tc7 = {6, 5, 4, 3, 2, 1, 1}; Tc3 = {6, 4, 2};

[0175] tcPD = (Sp == 3)? Tc3 : Tc7;

[0176] tcQD = (Sq == 3)? Tc3 : Tc7;

[0177] For P or Q boundaries filtered with short symmetric filters, lower amplitude position dependent thresholds are applied:

[0178] Tc3 = {3, 2, 1};

[0179] After defining the thresholds, the filtered p' i and q' i sample values are clipped according to the tcP and tcQ clipping values:

[0180] p" i = Clip3(p' i + tcP i , p' i - tcP i , p' i );

[0181] q" j = Clip3(q' j + tcQ j , q'j –tcQ j ,q' j );

[0182] Among them, p' i and q' i These are the filtered sample values, p” i and q” j It is the output sample value after amplitude limiting, and tcP i and tcQ j The clipping threshold is derived from the VVC tc parameters, tcPD, and tcQD. The Clip3 function is the clipping function specified in VVC.

[0183] 3.5.8. Sub-block Removal and Adjustment

[0184] To achieve parallel-friendly deblocking using long filters and sub-block deblocking, the long filter is limited to modifying a maximum of 5 samples on one side when using sub-block deblocking (AFFINE, ATMVP, or DMVR), as shown in the brightness control of the long filter. Additionally, sub-block deblocking is adjusted so that sub-block boundaries on the 8×8 grid near the CU or implicit TU boundaries are limited to modifying a maximum of two samples on each side.

[0185] The following applies to sub-block boundaries that are not aligned with the CU boundary.

[0186]

[0187] Edges equal to 0 correspond to the CU boundary, and edges equal to 2 or equal to the orthogonal length -2 correspond to 8 sample points from the sub-block boundary of the CU boundary, etc. If implicit partitioning of TU is used, then implicit TU is true.

[0188] 3.6. Sample Adaptive Migration (SAO)

[0189] The input to SAO is the reconstructed samples after DB (Database Optimization). The concept of SAO is to first classify region samples into multiple categories using a selected classifier, obtaining an offset for each category, and then add the offset to each sample within that category, thereby reducing the average sample distortion of the region. The classifier index and the region offset are encoded and decoded in the bitstream. In HEVC and VVC, the region (the unit for SAO parameter signaling notification) is defined as a CTU (Center Unit).

[0190] Two SAO types are employed in HEVC that can meet the low complexity requirement. The two types are edge offset (EO) and band offset (BO), which are discussed in further detail below. The index of the SAO type is coded (in the range of [0, 2]). For EO, the sample classification is based on the comparison between the current sample and the neighboring samples according to 1-D directional models (horizontal, vertical, 135° diagonal, and 45° diagonal).

[0191] Figure 8 The four 1-D directional modes for EO sample classification are shown: horizontal (EO type = 0), vertical (EO type = 1), 135° diagonal (EO type = 2), and 45° diagonal (EO type = 3).

[0192] For a given EO type, each sample within a CTB is classified into five categories. The current sample value, denoted as “c”, is compared with its two neighboring samples along the selected 1-D mode, denoted as “a” and “b”. The classification rule for each sample is summarized in Table 3-3. Categories 1 and 4 are associated with local valleys and local peaks along the selected 1-D mode, respectively. Categories 2 and 3 are associated with concave and convex corners along the selected 1-D mode, respectively. If the current sample does not belong to EO categories 1-4, it is category 0 and no SAO is applied.

[0193] Table 3-3 Sample classification rule for edge offset

[0194] Class Condition 1 c < a and c < b 2 (c < a && c == b) || (c == a && c < b) 3 (c > a && c == b) || (c == a && c > b) 4 c > a && c > b 5 None of the above

[0195] 3.7. Adaptive loop filter (ALF)

[0196] In VVC, an adaptive loop filter (ALF) with block-based filter adaptation is applied. For the luma component, one out of 25 filters is selected for each 4x4 block based on the local gradient direction and activity.

[0197] 3.7.1 Filter shape

[0198] Two diamond filter shapes (as shown in Figure 9 ) are used. A 7x7 diamond is applied for the luma component, and a 5x5 diamond is applied for the chroma components.

[0199] Figure 9 An example of ALF filter shape (chroma: 5x5 diamond, luma: 7x7 diamond) is shown.

[0200] 3.7.2 Block classification

[0201] For the luma component, each 4x4 block is classified into one of 25 categories. The classification index C is derived based on its directionality D and activity A quantized values of the gradients in the horizontal and vertical directions as follows:

[0202]

[0203] To compute D and A, the gradients in the horizontal, vertical and two diagonal directions are first computed using a 1-D Laplacian operator:

[0204]

[0205]

[0206]

[0207]

[0208] where indices i and j refer to the coordinates of the top-left sample in the 4x4 block, and R(i,j) denotes the reconstructed sample at coordinate (i,j).

[0209] The maximum and minimum of the gradients in the horizontal and vertical directions are then set as:

[0210]

[0211] The maximum and minimum of the gradients in the two diagonal directions are set as:

[0212]

[0213] To derive the value of the directionality D, these values are compared with each other and with two thresholds t1 and t2:

[0214] Step 1. If and are both true, then D is set to 0.

[0215] Step 2. If then continue from Step 3; otherwise continue from Step 4.

[0216] Step 3. If then D is set to 2; otherwise D is set to 1.

[0217] Step 4. If then D is set to 4; otherwise D is set to 3.

[0218] The activity value A is computed as follows:

[0219] ​

[0220] A is further quantized to the range of 0 to 4, inclusive, and the quantized value is denoted as

[0221] For chroma components in a picture, no classification method is applied, i.e., a single set of ALF coefficients is applied to each chroma component.

[0222] 3.7.3. Geometric transformation of filter coefficients and clipping values

[0223] Before filtering each 4x4 luma block, a geometric transformation (e.g., rotation or diagonal and vertical flip) is applied to the filter coefficients f(k,l) and the corresponding filter clipping values c(k,l) depending on the gradient value computed for the block. This is equivalent to applying these transformations to the samples in the filter support region. The idea is to make different blocks to which ALF is applied more similar by aligning their directionality.

[0224] Three geometric transformations are introduced, including diagonal transformation, vertical flip transformation and rotation transformation:

[0225] Diagonal: f D (k,l) = f(l,k), c D (k,l) = c(l,k), (2-9)

[0226] Vertical flip: f V (k,l) = f(k,K-l-1), c V (k,l) = c(k,K-l-1) (2-10)

[0227] Rotation: f R (k,l) = f(K-l-1,k), c R (k,l) = c(K-l-1,k) (2-11)

[0228] where K is the size of the filter and 0≤k,l≤K-1 are the coefficient coordinates such that position (0,0) is at the top-left corner and position (K-1,K-1) is at the bottom-right corner. The transformation is applied to the filter coefficients f(k,l) and clipping values c(k,l) depending on the gradient value computed for the block. The relationship between the transformation and the four gradients for the four directions is summarized in the following table.

[0229] Table 3-4 Mapping between the gradient computed for a block and the transformation

[0230] Gradient value Transform g d2 g d1 and g h g v ]]> No transform g d2 g d1 and g v g h ]]> Diagonal g d1 g d2 and g h g v ]]> Vertical flip g d1 g d2 and g v g h ]]> Rotation

[0231] 3.7.4. Filter parameter signaling

[0232] ALF filter parameters are signaled in an adaptive parameter set (APS). In one APS, up to 25 sets of luma filter coefficients and clipping value indices, and up to eight sets of chroma filter coefficients and clipping value indices can be signaled. To reduce the bit overhead, different categories of filter coefficients for the luma component can be combined. In the slice header, the index of the APS used for the current slice is signaled.

[0233] The clipping value indices decoded from the APS allow to determine the clipping values using a table of clipping values for the luma component and the chroma components. These clipping values depend on the internal bit depth. More precisely, the clipping values are obtained by the following formula:

[0234] AlfClip = { round(2 B-α*n ) for n e [0..N-1]} (2-12)

[0235] In the case where B is equal to the internal bit depth, a is a predefined constant value equal to 2.35 and N is equal to 4, which is the number of clipping values allowed in VVC.

[0236] In the slice header, up to 7 APS indices can be signaled to specify the luma filter set used for the current slice. The filtering process can be further controlled at the CTB level. Always one flag is signaled to indicate whether ALF is applied to the luma CTB or not. The luma CTB can select one filter set among 16 fixed filter sets and the filter set from the APS. A filter set index is signaled for the luma CTB to indicate which filter set is applied. The 16 fixed filter sets are predefined and hard-coded in the encoder and the decoder.

[0237] For the chroma components, an APS index is signaled in the slice header to indicate the chroma filter set used for the current slice. At the CTB level, if there is more than one chroma filter set in the APS, a filter index is signaled for each chroma CTB.

[0238] The filter coefficients are quantized with a norm equal to 128. To limit the multiplication complexity, bitstream conformance is applied such that the coefficient values at non-central positions should be in the range of -2 7 to 2 7 -1, including -2 7 and 2 7 -1. The central position coefficients are not signaled in the bitstream and are considered equal to 128.

[0239] 3.7.5. Filtering process

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

[0241] R'(i,j) = R(i,j) + ((∑ k≠0 ∑ l≠0 f(k,l) x K(R(i+k,j+l)-R(i,j), c(k,l)) + 64) » 7) (2-13)

[0242] where f(k,l) denotes the decoded filter coefficients, K(x,y) denotes a clipping function, and c(k,l) denotes the decoded clipping parameters. The variables k and l vary between and where L denotes the filter length. The clipping function K(x,y) = min(y, max(-y,x)) corresponds to the function Clip3(-y,y,x).

[0243] 3.7.6. Virtual boundary filtering process for reducing line buffer

[0244] In hardware and embedded software, picture-based processing is practically unacceptable due to its high picture buffer requirement. Using on-chip picture buffers is very expensive, and using off-chip picture buffers significantly increases external memory access, power consumption, and data access latency (delay). Therefore, in real products, DF, SAO, and ALF will change from picture-based decoding to LCU-based decoding. When LCU-based processing is used for DF, SAO, and ALF, the entire decoding process can handle multiple LCUs in an LCU pipeline manner in parallel to finish one LCU by one in raster scan. In this case, DF, SAO, and ALF need line buffers because processing one LCU row needs pixels from the above LCU row. If off-chip line buffers (e.g., DRAM) are used, external memory bandwidth and power consumption will be increased; if on-chip line buffers (e.g., SRAM) are used, chip area will be increased. Therefore, although line buffers are much smaller than picture buffers, it is still desirable to reduce the line buffer.

[0245] In VTM-4.0, as Figure 10As shown, the total number of line buffers required for the luma component is 11.25 lines. The line buffer requirements are explained as follows: Since the decision and filtering need lines K, L, M, N from the first CTU and lines O, P from the bottom CTU, the deblocking of the horizontal edges overlapping with the CTU boundaries cannot be performed. Therefore, the deblocking of the horizontal edges overlapping with the CTU boundaries is postponed until the lower CTU appears. Thus, for lines K, L, M, N, the reconstructed luma samples must be stored in line buffers (4 lines). Then, SAO filtering can be performed for lines A to J. Since deblocking does not change the samples in line K, SAO filtering can be performed for line J. For SAO filtering of line K, the edge offset classification decision is only stored in line buffers (which is 0.25 luma line). ALF filtering can only be performed for lines A-F. As Figure 10 As shown, ALF classification is performed for each 4x4 block. Each 4x4 block classification requires an active window of size 8x8, which in turn requires a 9x9 window to compute the 1d Laplacian to determine the gradient.

[0246] Therefore, the block classification for 4x4 blocks overlapping with lines G, H, I, J requires SAO filtered samples below the virtual boundary. Moreover, ALF classification requires SAO filtered samples of lines D, E, F. Also, ALF filtering of line G requires selecting three SAO filtered lines D, E, F from the above lines. Therefore, the total line buffer requirements are as follows:

[0247] - Lines K-N (horizontal DF pixels): 4 lines

[0248] - Lines D-J (SAO filtered pixels): 7 lines

[0249] - SAO edge offset classifier values between line J and line K: 0.25 lines

[0250] Therefore, the total number of luma lines required is 7+4+0.25 = 11.25.

[0251] Similarly, the line buffer requirements for the chroma component are shown in Figure 11 . The line buffer requirements for the chroma component are evaluated to be 6.25 lines.

[0252] To eliminate the line buffer requirements for SAO and ALF, the concept of virtual boundary (VB) is introduced in the latest VVC to reduce the line buffer requirements for ALF. Modified block classification and filtering are adopted for the samples near the horizontal CTU boundaries. As Figure 10As shown, VB is the horizontal LCU boundary that is moved up by N pixels. For each LCU, SAO and ALF can process the pixels above VB before the lower LCU arrives, but cannot process the pixels below VB until the lower LCU arrives, which is caused by DF. Considering the hardware implementation cost, the space between the proposed VB and the horizontal LCU boundary is set to four pixels for the luma component (i.e., N = 4), and two pixels for the chroma component (i.e., N = 2). Figure 10 or Figure 12 N = 4), and two pixels for the chroma component (i.e., N = 2).

[0253] Figure 12 Modified block classification at virtual boundary is shown

[0254] Modified block classification is applied to the luma component, as Figure 13 shown. For the 1D Laplacian gradient calculation of the 4x4 block above the virtual boundary, only the samples above the virtual boundary are used. Similarly, for the 1D Laplacian gradient calculation of the 4x4 block below the virtual boundary, only the samples below the virtual boundary are used. Considering the reduced number of samples used in the 1D Laplacian gradient calculation, the quantization of the activity value A is scaled accordingly.

[0255] For the filtering process, the mirroring (symmetric) padding operation at the virtual boundary is used for both the luma and chroma components. As Figure 13 shown, when the filtered sample is located below the virtual boundary, the neighboring sample located above the virtual boundary is padded. Meanwhile, the corresponding sample on the other side is also padded symmetrically.

[0256] In another example, if one sample located at (i, j) (e.g., P0A with dashed line in Figure 14B is padded, the corresponding sample located at (m, n) (e.g., P3B with dashed line in Figure 14B ) that shares the same filter coefficient is also padded even if the sample is available, as Figures 14A-14C shown.

[0257] Figure 14A One required line above / below VB needs to be padded (per side) is shown.

[0258] Figure 14B Two required lines above / below VB need to be padded (per side) is shown.

[0259] Figure 14C Three required lines above / below VB need to be padded (per side) is shown

[0260] Unlike the mirroring (symmetric) padding method used at horizontal CTU boundaries, a repetition (unilateral) padding process is applied for slice, tile, and subpicture boundaries when cross-boundary filtering is disabled. The repetition (unilateral) padding process is also applied at picture boundaries. The padded samples are used for the classification process and the filtering process. Figure 15 An example of the repetition padding method for luma ALF filtering at picture / subpicture / slice / tile boundaries is depicted.

[0261] Figure 15 An example of the repetition padding for luma ALF filtering at picture / subpicture / slice / tile boundaries is shown.

[0262] 3.8.360-degree video coding

[0263] Horizontal wrap-around motion compensation in VTM5 is a 360-specific coding tool that aims to improve the visual quality of reconstructed 360-degree video in equirectangular (ERP) projection format. In regular motion compensation, when a motion vector points to a sample outside the picture boundary of a reference picture, repetition padding is applied to derive the value of the out-of-bound sample by copying from those nearest neighbors on the corresponding picture boundary. For 360-degree video, this repetition padding approach is not suitable and can cause visual artifacts called “seam artefacts” in the reconstructed viewport video. Because 360-degree video is captured on a sphere and intrinsically has no “boundaries”, a reference sample that is outside the reference picture boundary in the projection domain can always be obtained from the neighboring samples in the spherical domain. For general projection formats, it can be difficult to derive the corresponding neighboring samples in the spherical domain, because it involves 2D-to-3D and 3D-to-2D coordinate conversion, and sample interpolation for fractional sample positions. For the left and right boundaries of ERP projection format, this problem is much simpler, because the spherical neighborhood outside the left picture boundary can be obtained from the samples inside the right picture boundary, and vice versa.

[0264] Figure 16 An example of horizontal wrap-around motion compensation in VVC is shown.

[0265] The horizontal wrap-around motion compensation process is shown as Figure 16 When a part of the reference block is outside the left (or right) boundary of the reference picture in the projection domain, the “out-of-bound” part is not repetition padded, but obtained from the corresponding spherical neighborhood that is inside the reference picture towards the right (or left) boundary in the projection domain. Repetition padding is only used for the top and bottom picture boundaries. As Figure 16As shown, horizontal wrap-around motion compensation can be combined with the non-regular padding method commonly used in 360-degree video coding. In VVC, this is achieved by signaling a high-level syntax element to indicate a wrap-around offset (which should be set to the ERP picture width before padding); this syntax is used to adjust the position of the horizontal wrap-around accordingly. This syntax is not affected by the specific padding amount on the left and right picture boundaries, and thus naturally supports asymmetric padding of ERP pictures, i.e., when the left and right padding are different. Horizontal wrap-around motion compensation provides more meaningful information for motion compensation when the reference samples are outside the left and right boundaries of the reference picture.

[0266] For projection formats consisting of multiple faces, discontinuities between two or more adjacent faces in the frame compressed picture occur, regardless of the compact frame compression arrangement used. For example, consider the 3x2 frame compression configuration depicted in Figure 17 The three faces in the upper half are continuous in 3D geometry, the three faces in the lower half are continuous in 3D geometry, but the upper and lower halves of the frame compressed picture are discontinuous in 3D geometry. If a loop filtering operation is performed at this discontinuity, face seam artifacts can become visible in the reconstructed video.

[0267] To mitigate face seam artifacts, the loop filtering operation can be disabled at the discontinuity in the frame compressed picture. A syntax is proposed that is used to signal vertical and / or horizontal virtual boundaries at which the loop filtering operation is disabled. The proposed signaling method is more flexible compared to using two tiles (one tile per group of consecutive faces) and disabling the loop filtering operation across tile boundaries, since it does not require the face size to be a multiple of the CTU size.

[0268] Figure 17 A 3x2 layout of HEC pictures is shown

[0269] 3.9. On Cross-Component Adaptive Loop Filter, JVET-P0080

[0270] The following Figure 18A The arrangement of CC-ALF with respect to other loop filters is shown. CC-ALF operates by applying a linear diamond filter. Figure 18B For each luma channel of a chroma component, denoted as:

[0271]

[0272] where

[0273] (x,y) is the location of the chroma component i being refined

[0274] (x C ,y C ) is the luma location based on (x,y)

[0275] S i is the filter support for the luma of the chroma component i

[0276] c i (x0,y0) denotes the filter coefficient (2-14)

[0277] Figure 18A The arrangement of CC-ALF with respect to other in-loop filters is shown. (b) Diamond filter.

[0278] luma position (x C ,y C ) is computed based on the spatial scaling factor between luma and chroma planes, the support region is centered at this luma position (x C ,y C ). All filter coefficients are transmitted in APS and have 8-bit dynamic range. The APS can be referenced in slice header. CC-ALF coefficients for each chroma component of a slice are also stored in the buffer corresponding to the temporal sublayer. A slice-level flag is used to facilitate the reuse of these temporal sublayer filter coefficient sets. The application of CC-ALF filter is controlled by a variable block size (i.e., 16x16, 32x32, 64x64, 128x128) and signaled by a context-coded flag received for each block of samples. For each chroma component, the block size and the CC-ALF enabled flag are received at the slice level. The boundary padding for horizontal virtual boundaries utilizes repetition. For the remaining boundaries, the same padding types as regular ALF are used.

[0279] 3.10. Control of cross-boundary in-loop filtering in VVC

[0280] In the latest VVC draft text, the in-loop filtering across region boundaries is controlled by the following syntax elements or variables:

[0281] 1) loop_filter_across_subpic_enabled_flag[i]: for controlling the ALF across subpicture boundaries for deblocking, SAO, and each subpicture has one signaled in SPS.

[0282] 2) loop_filter_across_tiles_enabled_flag: for controlling the ALF across tile boundaries for deblocking, SAO, and there is only one signaled in PPS (thus applies to all tiles in all pictures referring to the PPS).

[0283] 3) loop_filter_across_slices_enabled_flag: used to control Deblocking, SAO and ALF across slice boundaries, signaled in PPS, there is only one (thus applicable to all slices in pictures referring to the PPS).

[0284] 4) VirtualBoundariesDisabledFlag: used to control Deblocking, SAO and ALF across specified virtual boundaries, derived based on signaling in SPS and PH (equal to 1 when SPS flag sps_virtual_boundaries_present_flag or picture header flag ph_virtual_boundaries_present_flag is equal to 1).

[0285] In the latest VVC draft text, for any particular boundary, cross-boundary filtering is turned off whenever one of the above flags indicates that cross-boundary filtering is turned off, regardless of the values of the other flags.

[0286] 4. Examples of technical problems solved by the solutions described herein

[0287] The existing VVC design for controlling loop filtering across region boundaries has the following problems:

[0288] 1) Different flags for controlling loop filtering across region boundaries can conflict with each other. For example, the encoder can choose to turn on filtering across the boundaries of some independently coded subpictures because it finds that those subpictures presented together have very annoying artifacts when filtering across those subpicture boundaries is turned off, much worse than the quality degradation in other extraction scenarios. However, in this case, if loop_filter_across_tiles_enabled_flag or loop_filter_across_slices_enabled_flag is equal to 0 for some reason, filtering across subpicture boundaries (which are also tile boundaries or slice boundaries) will be turned off anyway.

[0289] 2) The subpicture feature introduced in VVC mainly supports regions of interest and other extraction-based use cases. For AVC, such use cases are supported by using slices or slice groups. For HEVC, these use cases are supported by slices and MCTS. Therefore, the capability to turn off filtering across slice boundaries is needed in AVC and HEVC. However, in VVC, this need has disappeared.

[0290] 3) When subpic_treated_as_pic_flag[i] is equal to 0 for a subpicture, motion compensation is constrained for coding subpictures across all pictures in a CLVS, so it is not independently coded nor extractable. In this case, there is no good reason for loop_filter_across_subpic_enabled_flag[i] to be equal to 0 (i.e. to turn off loop filtering across subpicture boundaries). However, this is allowed by the current design.

[0291] 5. Example embodiments and solutions

[0292] To solve the above problems, the following methods are disclosed as summarized below. These items should be considered as examples to explain the general concepts and should not be interpreted in a narrow way. Moreover, these items can be applied individually or in any combination.

[0293] 1) To solve the first and second problems, loop_filter_across_slices_enabled_flag is removed and loop_filter_across_tiles_enabled_flag is made specific to subpictures (i.e. signaled once per subpicture), still signaled in PPS and only controls whether filtering across tile boundaries (not including those tile boundaries that are also subpicture boundaries) is turned on or off.

[0294] a. Alternatively, subpicture-specific loop_filter_across_tiles_enabled_flag is signaled in SPS. The main (if not the only) purpose of turning off filtering across tile boundaries is to reduce data exchange between different processing cores in parallel encoding. This purpose will typically not change from picture to picture, so, although it makes sense to signal tile layout in PPS for load balancing purposes, it makes sense to signal loop_filter_across_tiles_enabled_flag in SPS, especially after this flag is made specific to subpictures.

[0295] i. Alternatively, in addition, subpicture-specific loop_filter_across_tiles_enabled_flag signaled in SPS can be conditioned on "if(subpics_present_flag)".

[0296] b. Alternatively, loop_filter_across_slices_enabled_flag is kept and both loop_filter_across_tiles_enabled_flag and loop_filter_across_slices_enabled_flag are set to be sub-picture specific.

[0297] i. In an alternative to item 1 b, loop_filter_across_tiles_enabled_flag and loop_filter_across_slices_enabled_flag are signaled in the SPS instead of in the PPS, both being sub-picture specific.

[0298] c. Alternatively, it is restricted that loop_filter_across_slices_enabled_flag and loop_filter_across_tiles_enabled_flag shall have the same value.

[0299] i. Alternatively, it is restricted that loop_filter_across_slices_enabled_flag and loop_filter_across_tiles_enabled_flag for sub-pictures in the same tile shall have the same value.

[0300] d. Alternatively, loop_filter_across_slices_enabled_flag and / or loop_filter_across_tiles_enabled_flag associated with a representative sub-picture among the multiple sub-pictures in the same tile can be signaled.

[0301] i. In one example, the representative sub-picture can be the first sub-picture coded / decoded in coding / decoding order.

[0302] ii. Alternatively, in addition, loop_filter_across_slices_enabled_flag and / or loop_filter_across_tiles_enabled_flag associated with other sub-pictures in the same tile can be inferred to be equal to the signaled value.

[0303] e.Alternatively, for boundaries that are not subpicture boundaries but slice boundaries and tile boundaries, when loop_filter_across_slices_enabled_flag and loop_filter_across_tiles_enabled_flag have different values, the following applies: if the tile containing the current CTU is the same as the tile containing the CTU or is a parent (superset) of it, then the behavior is determined by using loop_filter_across_tiles_enabled_flag while ignoring loop_filter_across_slices_enabled_flag. Otherwise, the behavior is determined by using loop_filter_across_slices_enabled_flag while ignoring loop_filter_across_tiles_enabled_flag. This means that only the flag of the associated entity (slice or tile) containing the current CTU is used that is smaller than the other associated entity.

[0304] f.Alternatively, for boundaries that are subpicture boundaries, the following applies:

[0305] i.If the loop_filter_across_subpic_enabled_flag[i] of the current block is equal to 0, then the cross-boundary filtering is turned off regardless of the values of the other flags.

[0306] ii. Otherwise (the loop_filter_across_subpic_enabled_flag[i] of the current block is equal to 1), the following applies:

[0307] 1) If loop_filter_across_tiles_enabled_flag is equal to 1 or loop_filter_across_slices_enabled_flag is equal to 1, then the cross-boundary filtering is turned on.

[0308] 2) Otherwise, the cross-boundary filtering is turned off.

[0309] g. Alternatively, for a boundary that is a subpicture boundary, whether the boundary is also a slice boundary or a virtual boundary, whether the filtering across the boundary is turned on or off is determined solely by the loop_filter_across_subpic_enabled_flag[i] associated with the current block, regardless of the values of loop_filter_across_slices_enabled_flag, loop_filter_across_tiles_enabled_flag and VirtualBoundariesDisabledFlag.

[0310] h. Alternatively, both loop_filter_across_tiles_enabled_flag and loop_filter_across_slices_enabled_flag are removed.

[0311] i. Alternatively, in the above examples, those slice boundaries that are also boundaries of subpictures are also included in the slice boundaries controlled by the above flags.

[0312] i. Alternatively, in addition, a conforming bitstream shall satisfy that the control flags (e.g., loop_filter_across_tiles_enabled_flag, loop_filter_across_slices_enabled_flag) of subpictures within the same slice shall have the same value.

[0313] j. In one example, for the above bullets (including bullet 1), it can only be applied when subpic_treated_as_pic_flag[i] is true.

[0314] 2) To solve the third problem, the presence of the syntax element loop_filter_across_subpic_enabled_flag[i] is conditioned on "if (subpic_treated_as_pic_flag[i])".

[0315] a. Alternatively, in addition, when loop_filter_across_subpic_enabled_flag[i] is not present (i.e., when the subpicture is not subject to motion constraint and thus not extractable), the value of loop_filter_across_subpic_enabled_flag[i] is inferred to be equal to 1 (i.e., to allow filtering across subpicture boundaries).

[0316] b. In an alternative, the syntax element loop_filter_across_subpic_enabled_flag[i] is not conditioned on "if (subpic_treated_as_pic_flag[i])", but the constraint that when subpic_treated_as_pic_flag[i] is equal to 0, the value of loop_filter_across_subpic_enabled__flag[i] shall be equal to 1.

[0317] 3) In one example, loop_filter_across_tiles_enabled_flag is signaled per tile (i.e., signaled once for each tile). The loop_filter_across_tiles_enabled_flag signaled for the first tile only controls the filtering behavior across the boundaries of the first tile.

[0318] 4) In one example, loop_filter_across_slices_enabled_flag is signaled per slice (i.e., signaled once for each slice). The loop_filter_across_slices_enabled_flag signaled for the first slice only controls the filtering behavior across the boundaries of the first slice.

[0319] 5) In one example, how to control the filtering behavior across the boundaries shared by multiple kinds of video units is signaled (e.g., in SPS or PPS or picture header or slice header). For example, the boundary can be both a subpicture boundary and a slice boundary, or it can be both a subpicture boundary and a tile boundary, or it can be both a slice boundary and a tile boundary.

[0320] a. In one example, different control messages (e.g., flags) are signaled for different kinds of shared boundaries. For example, a first boundary that is both a subpicture boundary and a slice boundary, and a second boundary that is both a subpicture boundary and a tile boundary can be controlled by different messages.

[0321] 6) In the above examples, the filtering process can include but is not limited to the process of the following filtering methods:

[0322] a. Deblocking filter

[0323] b. Sample adaptive offset

[0324] c. Adaptive loop filter

[0325] d. Cross-component adaptive loop filter

[0326] e. Bi-directional filter

[0327] f. Transform domain filter (e.g. Hadamard filter)

[0328] g. Alternatively, in addition, in one example, all allowed filtering methods can be controlled with the same syntax element (e.g. ) to enable / disable filtering across video processing units (e.g. sub-pictures, slices / tiles / bricks).

[0329] 6. Embodiments

[0330]

[0331] 6.1. First embodiment

[0332] 7.3.2.3 Sequence parameter set RBSP syntax

[0333]

[0334]

[0335] Alternatively, the following can apply:

[0336] 7.3.2.3 Sequence parameter set RBSP syntax

[0337]

[0338]

[0339] 7.4.3.3 Sequence parameter set RBSP semantics ...

[0341] subpics_present_flag equal to 1 specifies that sub-picture parameters are present in the SPS RBSP syntax. subpics_present_flag equal to 0 specifies that sub-picture parameters are not present in the SPS RBSP syntax.

[0342] NOTE 2 - When the bitstream is the result of a sub-bitstream extraction process and contains only a subset of the sub-pictures of the input bitstream of the sub-bitstream extraction process, it can be necessary to set the value of subpics_present_flag to equal to 1 in the RBSP of the SPS.

[0343] sps_num_subpics_minus1 plus 1 specifies the number of sub-pictures.

[0344] sps num subpics minusl shall be in the range of 0 to 254. When not present, the value of sps num subpics minusl is inferred to be equal to 0.

[0345] subpic_ctu_top_left_x[ i ] specifies the horizontal position of the top-left CTU of the i-th subpicture in units of CtbSizeY. The length of the syntax element is Ceil( Log2( pic_width_max_in_luma_samples / CtbSizeY ) ) bits. When not present, the value of subpic_ctu_top_left_x[ i ] is inferred to be equal to 0.

[0346] subpic_ctu_top_left_y[ i ] specifies the vertical position of the top-left CTU of the i-th subpicture in units of CtbSizeY. The length of the syntax element is Ceil( Log2( pic_height_max_in_luma_samples / CtbSizeY ) ) bits. When not present, the value of subpic_ctu_top_left_y[ i ] is inferred to be equal to 0.

[0347] subpic_width_minusl[ i ] plus 1 specifies the width of the i-th subpicture in units of CtbSizeY. The length of the syntax element is Ceil( Log2( pic_width_max_in_luma_samples / CtbSizeY ) ) bits. When not present, the value of subpic_width_minusl[ i ] is inferred to be equal to Ceil( pic_width_max_in_luma_samples / CtbSizeY ) - 1.

[0348] subpic_height_minusl[ i ] plus 1 specifies the height of the i-th subpicture in units of CtbSizeY. The length of the syntax element is Ceil( Log2( pic_height_max_in_luma_samples / CtbSizeY ) ) bits. When not present, the value of subpic_height_minusl[ i ] is inferred to be equal to Ceil( pic_height_max_in_luma_samples / CtbSizeY ) - 1.

[0349] subpic_treated_as_pic_flag[ i ] equal to 1 specifies that the i-th subpicture of each coded picture in the CLVS is treated as a picture in the decoding process excluding the in-loop filtering operation. subpic_treated_as_pic_flag[ i ] equal to 0 specifies that the i-th subpicture of each coded picture in the CLVS is not treated as a picture in the decoding process excluding the in-loop filtering operation. When not present, the value of subpic_treated_as_pic_flag[ i ] is inferred to be equal to 0.

[0350] loop_filter_across_subpic_enabled_flag[ i ] equal to 1 specifies that the in-loop filtering operation can be performed across the boundaries of the i-th subpicture in each coded picture in the CLVS. loop_filter_across_subpic_enabled_flag[ i ] equal to 0 specifies that the in-loop filtering operation is not performed across the boundaries of the i-th subpicture in each coded picture in the CLVS. When not present, the value of loop_filter_across_subpic_enabled_pic_flag[ i ] is inferred to be equal to 1.

[0351] The following constraints apply to the requirements of bitstream conformance:

[0352] - For any two subpictures subpicA and subpicB, when the subpicture index of subpicA is less than the subpicture index of subpicB, any coded slice NAL unit of subpicA shall precede any coded slice NAL unit of subpicB in decoding order.

[0353] - The shape of a subpicture shall be such that, when decoded, each subpicture shall have its entire left and top boundaries consisting of picture boundaries or boundaries of previously decoded subpictures.

[0354] sps_subpic_id_present_flag equal to 1 specifies that subpicture ID mapping is present in the SPS. sps_subpic_id_present_flag equal to 0 specifies that subpicture ID mapping is not present in the SPS.

[0355] sps_subpic_id_signaling_present_flag equal to 1 specifies that subpicture ID mapping is signaled in the SPS. sps_subpic_id_signaling_present_flag equal to 0 specifies that subpicture ID mapping is not signaled in the SPS. When not present, the value of sps_subpic_id_signaling_present_flag is inferred to be equal to 0.

[0356] sps_subpic_id_len_minus1 plus 1 specifies the number of bits used to represent the syntax element sps_subpic_id[ i ]. The value of sps_subpic_id_len_minus1 shall be in the range of 0 to 15, inclusive.

[0357] sps_subpic_id[ i ] specifies the subpicture ID of the i-th subpicture. The sps_subpic_id[ i ] syntax element is sps_subpic_id_len_minus1 + 1 bits long. When not present and sps_subpic_id_present_flag is equal to 0, the value of sps_subpic_id[ i ] is inferred to be equal to i for each i in the range of 0 to sps_num_subpics_minus1, inclusive.

[0358] ...

[0360] 7.3.2.4 Picture parameter set RBSP syntax

[0361]

[0362]

[0363] 7.4.3.4 Picture parameter set RBSP semantics

[0364] pps_subpic_id_signalling_present_flag equal to 1 specifies that subpicture ID mapping is signaled in the PPS. pps_subpic_id_signalling_present_flag equal to 0 specifies that subpicture ID mapping is not signaled in the PPS. When sps_subpic_id_present_flag is 0 or pps_subpic_id_signalling_present_flag is equal to 1, pps_subpic_id_signalling_present_flag shall be equal to 0.

[0365] pps_num_subpics_minus1 plus 1 specifies the number of subpictures in the coded picture referring to the PPS.

[0366] It is a requirement of bitstream conformance that the value of pps_num_subpic_minus1 shall be equal to sps_num_subpics_minus1.

[0367] pps_subpic_id_len_minus1 plus 1 specifies the number of bits used to represent the syntax element pps_subpic_id[ i ]. The value of pps_subpic_id_len_minus1 shall be in the range of 0 to 15, inclusive.

[0368] It is a requirement of bitstream conformance that the value of pps_subpic_id_len_minus1 shall be the same for all PPS referred to by the coded pictures in a CLVS.

[0369] pps_subpic_id[ i ] specifies the subpicture ID of the i-th subpicture. The length of the pps_subpic_id[ i ] syntax element is pps_subpic_id_len_minus1 + 1 bits.

[0370] no_pic_partition_flag equal to 1 specifies that no picture partitioning applies to each picture referring to the PPS. no_pic_partition_flag equal to 0 specifies that each picture referring to the PPS can be partitioned into more than one slice or tile.

[0371] It is a requirement of bitstream conformance that the value of no_pic_partition_flag shall be the same for all PPS referred to by the coded pictures within a CLVS.

[0372] The requirement of bitstream conformance is that the value of no_pic_partition_flag shall not be equal to 1 when the value of sps num subpics minusl + 1 is greater than 1.

[0373] pps_log2_ctu_size_minus5 + 5 specifies the size of luma coding tree blocks per CTU. pps_log2_ctu_size_minus5 shall be equal to sps_log2_ctu_size_minus5.

[0374] num_exp_tile_columns_minusl + 1 specifies the number of explicitly provided tile column widths. The value of num_exp_tile_columns_minusl shall be in the range of 0 to PicWidthlnCtbsY - 1, inclusive. When no_pic_partition_flag is equal to 1, the value of num_exp_tile_columns_minusl is inferred to be equal to 0.

[0375] num_exp_tile_rows_minusl + 1 specifies the number of explicitly provided tile row heights. The value of num_exp_tile_rows_minusl shall be in the range of 0 to PicHeightlnCtbsY - 1, inclusive. When no_pic_partition_flag is equal to 1, the value of num_tile_rows_minusl is inferred to be equal to 0.

[0376] tile_column_width_minusl [ i ] + 1 specifies the width, in CTBs, of the i-th tile column, i in the range of 0 to num_exp_tile_columns_minusl - 1, inclusive.

[0377] tile_column_width_minusl [ num_exp_tile_columns_minusl ] is used to derive the width of tile columns with index greater than or equal to num_exp_tile_columns_minusl, as specified in Section 6.5.1. When not present, the value of tile_column_width_minusl [ 0 ] is inferred to be equal to PicWidthlnCtbsY - 1.

[0378] tile_row_height_minus1[ i ] plus 1 specifies the height, in CTBs, of the i-th tile row, i in the range of 0 to num_exp_tile_rows_minus1 - 1, inclusive.

[0379] tile_row_height_minus1[ num_exp_tile_rows_minus1 ] is used to derive the height of tile rows with index greater than or equal to num_exp_tile_rows_minus1 as specified in Section 6.5.1. When not present, the value of tile_row_height_minus1[ 0 ] is inferred to be equal to PicHeightInCtbsY - 1.

[0380] rect_slice_flag equal to 0 specifies that the tiles within each slice are in raster scan order and no slice information is signaled in the PPS. rect_slice_flag equal to 1 specifies that the tiles within each slice cover a rectangular region of the picture and slice information is signaled in the PPS.

[0381] When not present, rect_slice_flag is inferred to be equal to 1. When subpics_present_flag is equal to 1, the value of rect_slice_flag shall be equal to 1.

[0382] single_slice_per_subpic_flag equal to 1 specifies that each subpicture consists of one and only one rectangular slice. single_slice_per_subpic_flag equal to 0 specifies that each subpicture can consist of one or more rectangular slices. When subpics_present_flag is equal to 0, single_slice_per_subpic_flag shall be equal to 0. When single_slice_per_subpic_flag is equal to 1, num_slices_in_pic_minus1 is inferred to be equal to sps_num_subpics_minus1.

[0383] num_slices_in_pic_minus1 plus 1 specifies the number of rectangular slices in each picture referring to the PPS. The value of num_slices_in_pic_minus1 shall be in the range of 0 to MaxSlicesPerPicture - 1, inclusive, where MaxSlicesPerPicture is specified in Annex A. When no_pic_partition_flag is equal to 1, the value of num_slices_in_pic_minus1 is inferred to be equal to 0.

[0384] tile_idx_delta_present_flag equal to 0 specifies that tile_idx_delta values are not present in the PPS and all rectangular slices in the picture referring to the PPS are specified in raster scan order according to the process defined in section 6.5.1. tile_idx_delta_present_flag equal to 1 specifies that tile_idx_delta values can be present in the PPS and all rectangular slices in the picture referring to the PPS are specified in the order indicated by the values of tile_idx_delta.

[0385] slice_width_in_tiles_minus1[ i ] plus 1 specifies the width of the i-th rectangular slice in tile columns. The value of slice_width_in_tiles_minus1[ i ] shall be in the range of 0 to NumTileColumns - 1, inclusive. When not present, the value of slice_width_in_tiles_minus1[ i ] is inferred according to the specification in section 6.5.1.

[0386] slice_height_in_tiles_minus1[ i ] plus 1 specifies the height of the i-th rectangular slice in tiles. The value of slice_height_in_tiles_minus1[ i ] shall be in the range of 0 to NumTileRows - 1, inclusive. When not present, the value of slice_height_in_tiles_minus1[ i ] is inferred according to the specification in section 6.5.1.

[0387] num_slices_in_tile_minus1[ i ] plus 1 specifies the number of slices in the current tile in the case that the i-th slice contains a subset of CTU rows from a single tile. The value of num_slices_in_tile_minus1[ i ] shall be in the range of 0 to RowHeight[ tileY ] - 1, inclusive, where tileY is the tile row index containing the i-th slice. When not present, the value of num_slices_in_tile_minus1[ i ] is inferred to be equal to 0.

[0388] slice_height_in_ctu_minus1[ i ] plus 1 specifies the height of the i-th rectangular slice in units of CTUs in the case that the i-th slice contains a subset of CTU rows from a single tile. The value of slice_height_in_ctu_minus1[ i ] shall be in the range of 0 to RowHeight[ tileY ] - 1, inclusive, where tileY is the tile row index containing the i-th slice.

[0389] tile_idx_delta[ i ] specifies the difference in tile index between the i-th rectangular slice and the (i+1)-th rectangular slice. The value of tile_idx_delta[ i ] shall be in the range of (-NumTilesInPic+1) to (NumTilesInPic-1), inclusive. When not present, the value of tile_idx_delta[ i ] is inferred to be equal to 0. In all other cases, the value of tile_idx_delta[ i ] shall not be equal to 0.

[0390] [[ loop_filter_across_tiles_enabled_flag equal to 1 specifies that loop filter operations can be performed across tile boundaries in the picture referring to the PPS.

[0391] loop_filter_across_tiles_enabled_flag equal to 0 specifies that loop filter operations are not performed across tile boundaries in the picture referring to the PPS. Loop filter operations include the Deblocking Filter, Sample Adaptive Offset Filter, and Adaptive Loop Filter operations. When not present, the value of loop_filter_across_tiles_enabled_flag is inferred to be equal to 1.

[0392] loop_filter_across_slices_enabled_flag equal to 1 specifies that the in-loop filter operation can be performed across slice boundaries in the picture referring to the PPS.

[0393] loop_filter_across_slice_enabled_flag equal to 0 specifies that the in-loop filter operation is not performed across slice boundaries in the picture referring to the PPS. The in-loop filter operation includes the Deblocking Filter, the Sample Adaptive Offset filter and the Adaptive Loop Filter operation. When not present, the value of loop_filter_across_slices_enabled_flag is inferred to be equal to 0.

[0394] 8.8.3 Deblocking filter process

[0395] 8.8.3.1 Overview

[0396] The Deblocking Filter process is applied to all coded sub-block edges and transform block edges of a picture, except for the following types of edges:

[0397] - edges at the boundaries of the picture,

[0398] - edges coinciding with the boundaries of a subpicture for which loop_filter_across_subpic_enabled_flag[ SubPicldx ] is equal to 0,

[0399] - edges coinciding with the virtual boundaries of the picture when VirtualBoundariesDisabledFlag is equal to 1,

[0400] - edges coinciding with the boundaries of a tile for which [[when]] loop_filter_across_tiles_enabled_flag is equal to 0 - edges coinciding with the boundaries of a slice for which loop_filter_across_slices_enabled_flag is equal to 0,

[0401] - edges coinciding with the top or left boundary of a slice for which slice_deblocking_filter_disabled_flag is equal to 1,

[0402] - edges within a slice for which slice_deblocking_filter_disabled_flag is equal to 1,

[0403] - edges within a slice for which slice_deblocking_filter_disabled_flag is equal to 1,

[0404] - edges that do not correspond to a 4x4 samples grid boundary of the luma component,

[0405] - edges that do not correspond to an 8x8 samples grid boundary of the chroma component,

[0406] - edges within the luma component for which intra bdpcm luma flag on both sides of the edge is equal to 1,

[0407] - edges within the chroma component for which intra bdpcm chroma flag on both sides of the edge is equal to 1,

[0408] - edges of a chroma sub-block that are not edges of the associated transform unit.

[0409] 8.8.3.2 Deblocking filter process for one direction

[0410] For each coding unit and each coding block of each colour component of a coding unit indicated by a colour component index cldx ranging from firstCompIdx to lastCompIdx, inclusive, where the coding block width nCbW, the coding block height nCbH and the position (xCb, yCb) of the top-left sample of the coding block, when cldx is equal to 0, or when cldx is not equal to 0 and edgeType is equal to EDGE VER and xCb % 8 is equal to 0, or when cldx is not equal to 0 and edgeType is equal to EDGE HOR and yCb % 8 is equal to 0, the edges are filtered in the following ordered steps:

[0411] 1. Derive the variable filterEdgeFlag as follows:

[0412] - If edgeType is equal to EDGE VER and one or more of the following conditions are true, filterEdgeFlag is set equal to 0:

[0413] - The left boundary of the current coding block is the left boundary of the picture.

[0414] - The left boundary of the current coding block is the left or right boundary of the subpicture and loop_filter_across_subpic_enabled_flag[SubPicIdx] is equal to 0.

[0415] - The left boundary of the current coding block is the left boundary of the tile, and loop_filter_across_tiles_enabled_flag is equal to 0.

[0416] - The left boundary of the current coding block is the left boundary of the slice and loop_filter_across_slices_enabled_flag is equal to 0.

[0417] - The left boundary of the current coding block is one of the vertical virtual boundaries of the picture and VirtualBoundariesDisabledFlag is equal to 1.

[0418] - Otherwise, if edgeType is equal to EDGE HOR and one or more of the following conditions are true, the variable filterEdgeFlag is set equal to 0:

[0419] - The top boundary of the current luma coding block is the top boundary of the picture.

[0420] - The top boundary of the current coding block is the top or bottom boundary of the subpicture and loop_filter_across_subpic_enabled_flag[ SubPicldx ] is equal to 0.

[0421] - The top boundary of the current coding block is the top boundary of the tile, and loop_filter_across_tiles_enabled_flag is equal to 0.

[0422] - [[ The top boundary of the current coding block is the top boundary of the slice and loop_filter_across_slices_enabled_flag is equal to 0. ]]

[0423] - The top boundary of the current coding block is one of the horizontal virtual boundaries of the picture and VirtualBoundariesDisabledFlag is equal to 1.

[0424] - Otherwise, filterEdgeFlag is set equal to 1. 2.... ...

[0427] 8.8.4 Sample adaptive offset process

[0428] 8.8.4.2 CTB modification process ...

[0430] For all sample positions (xS i ,yS j ) and (xY i ,yY j), where i = 0..nCtbSw-1 and j = 0..nCtbSh-1. The following applies:

[0431] - If one or more of the following conditions are true, saoPicture[ xS i ][ yS j ] is not modified:

[0432] - SaoTypeIdx[ cIdx ][ rx ][ ry ] is equal to 0.

[0433] - For any n = 0..VirtualBoundariesNumVer-1, VirtualBoundariesDisabledFlag is equal to 1 and xS j is equal to ((VirtualBoundariesPosX[ n ] / scaleWidth ) - 1), and SaoTypeIdx[ cIdx ][ rx ][ ry ] is equal to 2 and SaoEoClass[ cIdx ][ rx ][ ry ] is not equal to 1.

[0434] - For any n = 0..VirtualBoundariesNumVer-1, VirtualBoundariesDisabledFlag is equal to 1 and xS j is equal to (VirtualBoundariesPosX[ n ] / scaleWidth ), and SaoTypeIdx[ cIdx ][ rx ][ ry ] is equal to 2 and SaoEoClass[ cIdx ][ rx ][ ry ] is not equal to 1.

[0435] - For any n = 0..VirtualBoundariesNumHor-1, VirtualBoundariesDisabledFlag is equal to 1 and yS j is equal to ((VirtualBoundariesPosY[ n ] / scaleHeight ) - 1), and SaoTypeIdx[ cIdx ][ rx ][ ry ] is equal to 2 and SaoEoClass[ cIdx ][ rx ][ ry ] is not equal to 0.

[0436] - For any n = 0..VirtualBoundariesNumHor-1, VirtualBoundariesDisabledFlag is equal to 1 and yS jequal to ( VirtualBoundariesPosY[ n ] / scaleHeight ), and SaoTypeIdx[ cldx ][ rx ][ ry ] is equal to 2 and SaoEoClass[ cldx ][ rx ][ ry ] is not equal to 0.

[0437] - Otherwise, if SaoTypeIdx[ cldx ][ rx ][ ry ] is equal to 2, the following ordered steps apply:

[0438] 1. The values of hPos[ k ] and vPos[ k ] (for k = 0..1 ) are specified in Table 42 based on SaoEoClass[ cldx ][ rx ][ ry ].

[0439] 2. The variable edgeIdx is derived as follows:

[0440] - The modified sample positions ( xS ik ', yS jk ') and ( xY ik ', yY jk ') are derived as follows:

[0441] ( xS ik ', yS jk ') = ( xS i + hPos[ k ], yS j + vPos[ k ]) (1404)

[0442] ( xY ik ', yY jk ') = ( cldx == 0 )? ( xS ik ', yS jk ') : ( xS ik * SubWidthC, yS jk * SubHeightC ) (1405)

[0443] - For all sample positions ( xS ik ', yS jk ') and ( xY ik ', yY jk ') (where k = 0..1 ), edgeIdx is set equal to 0 if one or more of the following conditions are true:

[0444] - The sample at position ( xS ik ', yS jk ') is located outside the picture boundaries.

[0445] - The sample at position ( xS ik ', yS jkthe sample at position (xS i ][yS j ] belongs to a different subpicture and the sample recPicture[xS i ][yS j ] belongs to a different slice. i j loop_filter_across_subpic_enabled_flag[ SubPicldx ] equal to 0.

[0446] – [[ loop_filter_across_slices_enabled_flag is equal to 0 and the sample at position (xS ik ',yS jk ) belongs to a different slice.]]

[0447] – loop_filter_across_tiles_enabled_flag is equal to 0 and the sample at position (xS ik ',yS jk ) belongs to a different tile.

[0448] – Otherwise, derive edgeIdx as follows:

[0449] – The following applies:

[0450] edgeIdx = 2 + Sign( recPicture[ xS i ][ yS j ] - recPicture[ xS i + hPos[ 0 ] ][ yS j + vPos[ 0 ] ] ) +

[0451] Sign( recPicture[ xS i ][ yS j ] - recPicture[ xS i + hPos[ 1 ] ][ yS j + vPos[ 1 ] ] ) (1406)

[0452] – When edgeIdx is equal to 0, 1 or 2, modify edgeIdx as follows:

[0453] edgeIdx = ( edgeIdx == 2 )? 0 : ( edgeIdx + 1 ) (1407)

[0454] 3. Derive the modified picture sample array saoPicture[ xS i ][ yS j ] as follows:

[0455] saoPicture[ xS i ][ yS j ] = Clip3( 0, ( 1 << BitDepth ) - 1, recPicture[ xS i ][ yS j ] + SaoOffsetVal[ cldx ][ rx ][ ry ][ edgeIdx ] ) (1408) ...

[0457] 8.8.5 Adaptive loop filter process

[0458] 8.8.5.5 ALF boundary position derivation process ...

[0460] The variable clipTopPos is modified as follows:

[0461] - If y - ( CtbSizeY - 4 ) is greater than or equal to 0, the variable clipTopPos is set equal to yCtb + CtbSizeY - 4.

[0462] - Otherwise, if VirtualBoundariesDisabledFlag is equal to 1 and yCtb + y - VirtualBoundariesPosY[ n ] is greater than or equal to 0 and less than 3 for any n = 0..VirtualBoundariesNumHor - 1, the following applies:

[0463] clipTopPos = VirtualBoundariesPosY[ n ] (1468)

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

[0465] - The top boundary of the current coding tree block is the top boundary of the tile, and loop_filter_across_tiles_enabled_flag is equal to 0.

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

[0467] - The top boundary of the current coding tree block is the top boundary of the subpicture, and loop_filter_across_subpic_enabled_flag[ SubPicldx ] is equal to 0.

[0468] The variable clipBottomPos is modified as follows:

[0469] - If 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 (for any n = 0..VirtualBoundariesNumHor - 1), the following applies:

[0470] clipBottomPos = VirtualBoundariesPosY[ n ] (1469)

[0471] - Otherwise, if CtbSizeY - 4 - y is greater than 0 and less than 5, the variable clipBottomPos is set equal to yCtb + CtbSizeY - 4.

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

[0473] - The bottom boundary of the current coding tree block is the bottom boundary of the tile, and loop_filter_across_tiles_enabled_flag is equal to 0.

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

[0475] - The bottom boundary of the current coding tree block is the bottom boundary of the subpicture, and loop_filter_across_subpic_enabled_flag[ SubPicldx ] is equal to 0.

[0476] The variable clipLeftPos is modified as follows:

[0477] - If VirtualBoundariesDisabledFlag is equal to 1, and xCtb+ x - VirtualBoundariesPosX[ n ] is greater than or equal to 0 and less than 3 (for any n = 0..VirtualBoundariesNumVer - 1), the following applies:

[0478] clipLeftPos = VirtualBoundariesPosX[ n ] (1470)

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

[0480] - The left boundary of the current coding tree block is the left boundary of the tile, and loop_filter_across_tiles_enabled_flag is equal to 0.

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

[0482] - The left boundary of the current coding tree block is the left boundary of the subpicture, and loop_filter_across_subpic_enabled_flag[ SubPicIdx ] is equal to 0.

[0483] The variable clipRightPos is modified as follows:

[0484] - If VirtualBoundariesDisabledFlag is equal to 1, and VirtualBoundariesPosX[ n ] - xCtb - x is greater than 0 and less than 5 (for any n = 0..VirtualBoundariesNumVer - 1), the following applies:

[0485] clipRightPos = VirtualBoundariesPosX[ n ] (1471)

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

[0487] - The right boundary of the current coding tree block is the right boundary of the tile, and loop_filter_across_tiles_enabled_flag is equal to 0.

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

[0489] - The right boundary of the current coding tree block is the right boundary of the subpicture, and loop_filter_across_subpic_enabled_flag[ Subpicldx ] is equal to 0.

[0490] [[The variables clipTopLeftFlag and clipBotRightFlag are modified as follows:

[0491] - If the coding tree block that covers the luma position ( xCtb, yCtb ) and the coding tree block that covers the 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.

[0492] - If the coding tree block that covers the luma position ( xCtb, yCtb ) and the coding tree block that covers the luma position ( xCtb + CtbSizeY, yCtb + CtbSizeY ) belong to different slices, and loop_filter_across_slices_enabled_flag is equal to 0, clipBotRightFlag is set equal to 1.]]

[0493] Figure 19 is a block diagram illustrating an example video processing system 1900, which can implement various techniques disclosed herein. Various implementations can include some or all of the components of system 1900. System 1900 can include an input 1902 for receiving video content. The video content can be received in a raw or uncompressed format, such as 8-bit or 10-bit multi-component pixel values, or can be received in a compressed or encoded format. Input 1902 can represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces, such as Ethernet, passive optical network (PON), etc., and wireless interfaces, such as Wi-Fi or cellular interfaces.

[0494] The system 1900 can include a coding component 1904 that can implement various coding or encoding methods described in this document. The coding component 1904 can reduce the average bitrate of a video from the input 1902 to the output of the coding component 1904 to produce a coded representation of the video. The coding techniques are thus sometimes called video compression or video transcoding techniques. The output of the coding component 1904 can be stored or transmitted via a communication connected by component 1906. The stored or transmitted bitstream (or coded) representation of the video received at the input 1902 can be used by component 1908 to generate pixel values or displayable video that is sent to a display interface 1910. The process of generating user-viewable video from the bitstream representation is sometimes called video decompression. Also, although certain video processing operations are referred to as “coding” operations or tools, it will be understood that the encoding tools or operations are used at an encoder, and corresponding decoding tools or operations that reverse the results of the encoding will be performed by a decoder.

[0495] Examples of peripheral bus interfaces or display interfaces can include Universal Serial Bus (USB) or High Definition Multimedia Interface (HDMI) or Displayport, etc. Examples of storage interfaces include SATA (Serial Advanced Technology Attachment), PCI, IDE interfaces, etc. The techniques described in this document can be embodied in various electronic devices such as mobile telephones, laptop computers, smart phones, or other devices capable of performing digital data processing and / or video display.

[0496] Figure 20 is a block diagram of a video processing device 2000. The device 2000 can be used to implement one or more of the methods described herein. The device 2000 can be included in a smart phone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. The device 2000 can include one or more processors 2002, one or more memories 2004, and video processing hardware 2006. The processor(s) 2002 can be configured to implement one or more methods described in this document. The memory or memories 2004 can be used for storing data and code used during the operation of the device 2000 as described herein. The video processing hardware 2006 can be used to implement some of the techniques described in this document in hardware circuitry.

[0497] Figure 21 is a block diagram illustrating an example video coding system 100 that can utilize the techniques of this disclosure.

[0498] As Figure 21As shown, video coding system 100 can include a source device 110 and a destination device 120. Source device 110 can generate encoded video data, and can be referred to as a video encoding device. Destination device 120 can decode the encoded video data generated by source device 110, and can be referred to as a video decoding device.

[0499] Source device 110 can include a video source 112, a video encoder 114, and an input / output (VO) interface 116.

[0500] Video source 112 can include a source such as a video capture device, an interface to receive video data from a video content provider, and / or a computer graphics system for generating video data, or a combination of such sources. Video data can comprise one or more pictures. Video encoder 114 encodes video data from video source 112 to generate a bitstream. The bitstream can include a sequence of bits that form a coded representation of the video data. The bitstream can include coded pictures and associated data. A coded picture is a coded representation of a picture. Associated data can include sequence parameter sets, picture parameter sets, and other syntax structures. VO interface 116 can include a modulator / demodulator (modem) and / or a transmitter. Encoded video data can be transmitted directly to destination device 120 by VO interface 116 through network 130a. The encoded video data can also be stored onto a storage medium / server 130b for access by destination device 120.

[0501] Destination device 120 can include VO interface 126, video decoder 124, and display device 122.

[0502] VO interface 126 can include a receiver and / or a modem. VO interface 126 can obtain encoded video data from source device 110 or storage medium / server 130b. Video decoder 124 can decode the encoded video data. Display device 122 can display the decoded video data to a user. Display device 122 can be integrated with destination device 120, or can be external to destination device 120, which is configured to interface with an external display device.

[0503] Video encoder 114 and video decoder 124 can operate according to a video compression standard, such as High Efficiency Video Coding (HEVC) standard, Versatile Video Coding (VVM) standard, and other current and / or further standards.

[0504] Figure 22 is a block diagram illustrating an example of a video encoder 200, which can be Figure 21 the video encoder 114 in the system 100 shown.

[0505] Video encoder 200 can be configured to perform any or all of the techniques of this disclosure. In Figure 22 In examples, video encoder 200 includes a number of functional components. The techniques described in this disclosure can be shared among the various components of video encoder 200. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.

[0506] The functional components of video encoder 200 can include partition unit 201, prediction unit 202 (which can include mode select unit 203, motion estimation unit 204, motion compensation unit 205, and intra-prediction unit 206), residual generation unit 207, transform unit 208, quantization unit 209, inverse quantization unit 210, inverse transform unit 211, reconstruction unit 212, buffer 213, and entropy encoding unit 214.

[0507] In other examples, video encoder 200 can include more, less, or different functional components. In examples, prediction unit 202 can include an intra-block copy (IBC) unit. The IBC unit can perform prediction in IBC mode, in which at least one reference picture is the picture in which the current video block is located.

[0508] Furthermore, some components, such as motion estimation unit 204 and motion compensation unit 205, can be highly integrated, but are represented separately in Figure 22 examples for purposes of explanation.

[0509] Partition unit 201 can partition a picture into one or more video blocks. Video encoder 200 and video decoder 300 can support various video block sizes.

[0510] Mode select unit 203 can select one of the coding modes (intra or inter), e.g., based on error results, and provide the resulting intra or inter coded block to residual generation unit 207 to generate residual block data, and to reconstruction unit 212 to reconstruct the coded block for use as a reference picture. In some examples, mode select unit 203 can select a combination of intra and inter prediction (CIIP) mode, in which prediction is based on both inter prediction signals and intra prediction signals. Mode select unit 203 can also select a resolution for motion vectors for a block (e.g., sub-pixel or integer pixel precision) in the case of inter prediction.

[0511] To perform inter prediction on a current video block, motion estimation unit 204 can generate motion information for the current video block by comparing one or more reference frames from buffer 213 to the current video block. Motion compensation unit 205 can determine a predicted video block for the current video block based on motion information and decoded samples for pictures other than the picture associated with the current video block from buffer 213.

[0512] Motion estimation unit 204 and motion compensation unit 205 can perform different operations on a current video block, e.g., depending on whether the current video block is in an I slice, a P slice, or a B slice.

[0513] In some examples, motion estimation unit 204 can perform uni-prediction on a current video block, and motion estimation unit 204 can search reference pictures in list 0 or list 1 for a reference video block for the current video block. Motion estimation unit 204 can then generate a reference index (indicating the reference picture in list 0 or list 1 containing the reference video block) and a motion vector (indicating a spatial displacement between the current video block and the reference video block). Motion estimation unit 204 can output the reference index, the prediction direction identifier, and the motion vector as motion information for the current video block. Motion compensation unit 205 can generate a predicted video block for the current block based on the reference video block indicated by the motion information for the current video block.

[0514] In other examples, motion estimation unit 204 can perform bi-prediction on a current video block, motion estimation unit 204 can search reference pictures in list 0 for a reference video block for the current video block, and also search reference pictures in list 1 for another reference video block for the current video block. Motion estimation unit 204 can then generate a reference index (indicating the reference pictures in list 0 and list 1 containing the reference video blocks) and a motion vector (indicating a spatial displacement between the reference video blocks and the current video block). Motion estimation unit 204 can output the reference index and the motion vector as motion information for the current video block. Motion compensation unit 205 can generate a predicted video block for the current video block based on the reference video blocks indicated by the motion information for the current video block.

[0515] In some examples, motion estimation unit 204 can output a full set of motion information for a decoder's decoding process.

[0516] In some examples, motion estimation unit 204 can not output a full set of motion information for a current video. Instead, motion estimation unit 204 can signal motion information for a current video block with reference to motion information for another video block. For example, motion estimation unit 204 can determine that the motion information for the current video block is sufficiently similar to the motion information for a neighboring video block.

[0517] In one example, the motion estimation unit 204 can indicate, in a syntax structure associated with the current video block, a value that indicates to the video decoder 300 that the current video block has the same motion information as another video block.

[0518] In another example, the motion estimation unit 204 can identify, in a syntax structure associated with the current video block, another video block and a motion vector difference (MVD). The motion vector difference indicates a difference between a motion vector of the current video block and a motion vector of the indicated video block. The video decoder 300 can use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.

[0519] As discussed above, the video encoder 200 can predictively signal motion vectors. Two examples of predictive signaling techniques that can be implemented by the video encoder 200 include advanced motion vector prediction (AMVP) and merge mode signaling.

[0520] The intra prediction unit 206 can perform intra prediction on the current video block. When the intra prediction unit 206 performs intra prediction on the current video block, the intra prediction unit 206 can generate prediction data for the current video block based on decoded samples of other video blocks in the same picture. The prediction data for the current video block can include a predicted video block and various syntax elements.

[0521] The residual generation unit 207 can generate residual data for the current video block by subtracting (e.g., indicated with a minus sign) the prediction video block(s) for the current video block from the current video block. The residual data for the current video block can include residual video blocks corresponding to different sample components in the current video block.

[0522] In other examples, there can be no residual data for the current video block, e.g., in skip mode, the residual generation unit 207 can not perform the subtraction operation for the current video block.

[0523] The transform processing unit 208 can generate one or more transform coefficient video blocks for the current video block by applying one or more transforms to the residual video blocks associated with the current video block.

[0524] After the transform processing unit 208 generates the transform coefficient video blocks associated with the current video block, the quantization unit 209 can quantize the transform coefficient video blocks associated with the current video block based on one or more quantization parameter (QP) values associated with the current video block.

[0525] Inverse quantization unit 210 and inverse transform unit 211 can apply inverse quantization and inverse transform, respectively, to the transform coefficient video block to reconstruct a residual video block from the transform coefficient video block. Reconstruction unit 212 can add the reconstructed residual video block to corresponding samples of one or more prediction video blocks generated from prediction unit 202 to produce a reconstructed video block associated with the current block for storage in buffer 213.

[0526] After reconstruction unit 212 reconstructs a video block, in-loop filtering operations can be performed to reduce video block artifacts in the video block.

[0527] Entropy encoding unit 214 can receive data from other functional components of video encoder 200. When entropy encoding unit 214 receives data, entropy encoding unit 214 can perform one or more entropy encoding operations to generate entropy encoded data and output a bitstream that includes the entropy encoded data.

[0528] Figure 23 FIG. 3 is a block diagram illustrating an example of a video decoder 300 that can be Figure 21 the video decoder 114 in the system 100 shown.

[0529] Video decoder 300 can be configured to perform any or all of the techniques of this disclosure. In Figure 23 examples, video decoder 300 includes a number of functional components. The techniques described in this disclosure can be shared among the various components of video decoder 300. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.

[0530] In Figure 23 examples, video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. In some examples, video decoder 300 can perform a decoding process generally reciprocal to the encoding process described with respect to video encoder 200 Figure 22 ) described above.

[0531] Entropy decoding unit 301 can retrieve an encoded bitstream. The encoded bitstream can include entropy encoded video data (e.g., encoded blocks of video data). Entropy decoding unit 301 can decode the entropy encoded video data and motion compensation unit 302 can determine motion information from the entropy decoded video data, including motion vectors, motion vector precisions, reference picture list indices, and other motion information. For example, motion compensation unit 302 can determine such information by performing AMVP and merge modes.

[0532] Motion compensation unit 302 can generate a motion compensated block, possibly performing interpolation based on an interpolation filter. An identifier of the interpolation filter used at sub-pixel precision can be included in the syntax elements.

[0533] Motion compensation unit 302 can use the interpolation filter used by video encoder 20 during encoding of the video block to calculate the interpolation of sub-integer pixels of the reference block. Motion compensation unit 302 can determine the interpolation filter used by video encoder 200 from the received syntax information and use the interpolation filter to generate the prediction block.

[0534] Motion compensation unit 302 can use some of the syntax information to determine the size of the blocks used to encode the frame(s) and / or slice(s) of the encoded video sequence, partitioning information describing how to partition each macroblock of the pictures of the encoded video sequence, modes indicating how to encode each partition, one or more reference frames (and lists of reference frames) for each inter-coded block, and other information used to decode the encoded video sequence.

[0535] Intra prediction unit 303 can use, for example, intra prediction modes received in the bitstream to form a prediction block from spatially neighboring blocks. Inverse quantization unit 303 inverse quantizes (i.e., de-quantizes) quantized video block coefficients provided in the bitstream and decoded by entropy decoding unit 301. Inverse transform unit 303 applies an inverse transform.

[0536] Reconstruction unit 306 can add the residual block to the corresponding prediction block generated by motion compensation unit 202 or intra prediction unit 303 to form a decoded block. If desired, a deblocking filter can also be applied to filter the decoded block in order to remove blocking artifacts. The decoded video blocks are then stored in buffer 307, which provides reference blocks for subsequent motion compensation / intra prediction, and also produces decoded video for presentation on a display device.

[0537] Figures 24-25 An example method in which the above-described techniques can be implemented is shown, for example, Figures 19-23 The illustrated embodiments.

[0538] Figure 24 A flowchart of an example method 2400 of video processing is shown. At operation 2410, the method 2400 includes, for a conversion between a video comprising video regions and a bitstream of the video, determining whether to apply a loop filtering process that crosses a boundary associated with the video regions, the bitstream comprising one or more syntax elements indicating whether the loop filtering process is applicable to each video region.

[0539] At operation 2420, the method 2400 includes performing the conversion based on the determining.

[0540] Figure 25 A flowchart illustrating an example method 2500 of video processing is shown. At operation 2510, the method 2500 includes performing a conversion between a video comprising a video region comprising a subpicture and a bitstream of the video, the bitstream conforming to a format rule that specifies whether a first syntax element is signaled in the bitstream is based on whether the subpicture is considered a picture and the first syntax element relates to an application of an in-loop filtering process that crosses a boundary of the subpicture associated with the video region.

[0541] A list of preferred solutions of some embodiments is provided below.

[0542] A1. A method of video processing, comprising: for a conversion between a video comprising a video region and a bitstream of the video, determining whether to apply an in-loop filtering process that crosses a boundary associated with the video region; and performing the conversion based on the determination, wherein the bitstream comprises one or more syntax elements that indicate whether the in-loop filtering process is applicable to each video region.

[0543] A2. The method of solution A1, wherein the video region is a subpicture.

[0544] A3. The method of solution A2, wherein the one or more syntax elements are signaled in a picture parameter set (PPS).

[0545] A4. The method of solution A2, wherein the one or more syntax elements control whether the in-loop filtering process that crosses a tile boundary within the subpicture is enabled.

[0546] A5. The method of solution A4, wherein the tile boundary within the subpicture excludes a tile boundary that coincides with a boundary of the subpicture.

[0547] A6. The method of solution A2, wherein the one or more syntax elements are signaled in a sequence parameter set (SPS).

[0548] A7. The method of solution A6, wherein the one or more syntax elements are signaled in response to the video comprising the subpicture.

[0549] A8. The method of any of solutions A2 to A7, wherein the one or more syntax elements comprise a first syntax element and a second syntax element.

[0550] A9. The method of solution A8, wherein the first syntax element and the second syntax element have a same value.

[0551] A10. The method of solution A8, wherein the first syntax element and the second syntax element for sub-pictures in the same tile have the same value.

[0552] A11. The method of solution A8, wherein the first syntax element and the second syntax element are associated with one representative sub-picture of the plurality of sub-pictures in the same tile.

[0553] A12. The method of solution A11, wherein the one representative sub-picture is the first sub-picture coded in coding order or decoded in decoding order, respectively.

[0554] A13. The method of solution A8, wherein the boundary is a slice boundary and a tile boundary, and wherein the first syntax element and the second syntax element have different values.

[0555] A14. The method of solution A13, wherein in determining that a slice comprising a current coding tree unit (CTU) is the same as a tile comprising the current CTU or is a parent of the tile of the current CTU, the transition is based on the first syntax element and not on the second syntax element.

[0556] A15. The method of solution A8, wherein the boundary is a sub-picture boundary, and wherein the application of the in-loop filtering process across the boundary is enabled based on the first syntax element or the second syntax element being equal to one.

[0557] A16. The method of solution A8, wherein the boundary is a sub-picture boundary and a tile boundary, and wherein the application of the in-loop filtering process across the boundary is enabled based on the first syntax element or the second syntax element being equal to one.

[0558] A17. The method of any of solutions A8 to A16, wherein the first syntax element is used to control an adaptive loop filter (ALF), a de-blocking filter (DF), and a sample adaptive offset (SAO) across a tile boundary, and wherein the second syntax element is used to control an adaptive loop filter (ALF), a de-blocking filter (DF), and a sample adaptive offset (SAO) across a slice boundary.

[0559] A18. The method of any of solutions A8 to A17, wherein the first syntax element is loop_filter_across_tiles_enabled_flag and the second syntax element is loop_filter_across_slices_enabled_flag.

[0560] A19. The method of solution Al, wherein the video region is a tile.

[0561] A20. The method of solution A1, wherein the video region is a slice.

[0562] A21. The method of solution A1, wherein the video region comprises at least a first type of video unit and a second type of video unit, and wherein the boundary is a boundary of the first type of video unit and a boundary of the second type of video unit.

[0563] A22. The method of solution A21, wherein the first type of video unit is a subpicture and the second type of video unit is a slice.

[0564] A23. The method of solution A21, wherein the first type of video unit is a subpicture and the second type of video unit is a tile.

[0565] A24. The method of solution A21, wherein the first type of video unit is a slice and the second type of video unit is a tile.

[0566] A25. A method of video processing, comprising performing a conversion between a video comprising a video region including subpictures and a bitstream of the video, wherein the bitstream conforms to a format rule that specifies whether a first syntax element is signaled in the bitstream is based on whether the subpictures are treated as pictures, and wherein the first syntax element relates to an application of an in-loop filtering process that crosses a boundary of a subpicture associated with the video region.

[0567] A26. The method of solution A25, wherein the format rule specifies that the bitstream includes a second syntax element that indicates whether the subpictures are treated as pictures.

[0568] A27. The method of solution A25, wherein, responsive to the bitstream not including the first syntax element, the first syntax element is inferred to indicate that the in-loop filtering process that crosses the boundary of the subpicture is allowed.

[0569] A28. The method of any of solutions A25 to A27, wherein the first syntax element is loop_filter_across_subpic_enabled_flag and the second syntax element is subpic_treated_as_pic_flag.

[0570] A29. The method of solution A28, wherein, responsive to the second syntax element indicating that the subpicture is not treated as the picture, the first syntax element is inferred to indicate that the in-loop filtering process that crosses the boundary of the subpicture is allowed.

[0571] A30. The method of any of solutions Al to A29, wherein the in-loop filter process comprises at least one of a deblocking filter, a sample adaptive offset (SAO) filter, an adaptive loop filter (ALF), a cross-component adaptive loop filter, a bilateral filter, and a transform domain filter.

[0572] A31. The method of any of solutions Al to A30, wherein the conversion comprises decoding the video from the bitstream representation.

[0573] A32. The method of any of solutions Al to A30, wherein the conversion comprises encoding the video into the bitstream representation.

[0574] A33. A method of writing a bitstream representing a video to a computer- readable recording medium, comprising: generating the bitstream from the video according to the method of any one or more of solutions Al to A32; and writing the bitstream to the computer-readable recording medium.

[0575] A34. A video processing device comprising a processor configured to implement the method of any one or more of solutions Al to A33.

[0576] A35. A computer-readable medium having stored thereon instructions that, when executed, cause a processor to implement the method of one or more of solutions Al to A33.

[0577] A36. A computer-readable medium storing a bitstream representation generated according to any one or more of solutions Al to A33.

[0578] A37. A video processing device for storing a bitstream representation, wherein the video processing device is configured to implement the method of any one or more of solutions Al to A33.

[0579] Another list of preferred solutions of some embodiments is provided below.

[0580] B1. A method of video processing, comprising: for a conversion between a subpicture of a video and a coded representation of the video, determining whether to apply an in-loop filter that crosses a boundary within the subpicture; and performing the conversion based on the determination; wherein a format of the coded representation allows individualized signaling of the application of the in-loop filter.

[0581] B2. The method of solution Bl, wherein a first field at a picture level indicates whether independent signaling at a subpicture level is used in the coded representation.

[0582] B3. The method of solution B1, wherein the first field at the video sequence level indicates whether independent signaling of the in-loop filter at the subpicture level is used in the coded representation.

[0583] B4. The method of any of solutions B1 to B4, wherein the independent signaling of the application of the in-loop filter comprises signaling of the application across tiles within a subpicture and / or signaling of the application across slices within a subpicture.

[0584] B5. A method of video processing, comprising: determining, based on a condition, whether to parse a field that indicates whether to apply an in-loop filter across boundaries of video parts of a video region of a video; based on the determination, performing a conversion of samples within a video part of the video and a coded representation of the video.

[0585] B6. The method of solution B5, wherein the condition corresponds to whether the video part in the video region is treated as a picture.

[0586] B7. The method of solution B6, wherein the condition corresponds to whether subpic_treated_as_pic_flag is true.

[0587] B8. The method of solution B6, further comprising, when the video part in the video region is not treated as a picture, not parsing the field for decoding.

[0588] B9. The method of solution B8, further comprising, the application of the in-loop filter across boundaries of video parts of the video region of the video is disabled.

[0589] B10. The method of solution B6, further comprising, when the video part in the video region is treated as a picture, parsing the field.

[0590] B11. The method of solution B8, further comprising, whether to apply the in-loop filter across boundaries of video parts of the video region of the video is determined by the parsed field.

[0591] B12. A method of video processing, comprising: for a conversion between a video part of a video region of a video and a coded representation of the video, performing a determination, based on a condition, whether to apply an in-loop filter across boundaries of the video part; and based on the determination, performing the conversion.

[0592] B13. The method of solution B12, wherein the condition corresponds to whether the video part is treated as a picture.

[0593] B14. The method of solution B12, wherein the condition corresponds to whether a subpic_treated_as_pic_flag in the coded representation is true.

[0594] B15. The method of any of solutions B12 to B13, wherein an indication of an application of a loop filter that crosses a boundary of the video portion is omitted in the coded representation.

[0595] B16. The method of any of the preceding claims, wherein the video portion is a subpicture and the video region is a picture.

[0596] B17. The method of any of the preceding claims, wherein the video portion is a tile and the video region is a picture.

[0597] B18. The method of solution B17, wherein a tile-specific field in the coded representation indicates whether to apply a loop filter across a boundary of the video portion.

[0598] B19. The method of any of the preceding claims, wherein the video portion is a slice and the video region is a picture.

[0599] B20. The method of solution B19, wherein a slice-specific field in the coded representation indicates whether to apply a loop filter across a boundary of the video portion.

[0600] B21. The method of any of the preceding claims, wherein the loop filter is a deblocking filter.

[0601] B22. The method of any of the preceding claims, wherein the loop filter is a sample adaptive offset (SAO) filter.

[0602] B23. The method of any of the preceding claims, wherein the loop filter is an adaptive loop filter.

[0603] B24. The method of any of the preceding claims, wherein the loop filter is a cross-component adaptive loop filter.

[0604] B25. The method of any of the preceding claims, wherein the loop filter is a bilateral filter.

[0605] B26. The method of any of the preceding claims, wherein the loop filter is a transform domain filter.

[0606] B27. The method of any of solutions B1 to B26, wherein performing the conversion comprises encoding the video to generate the coded representation.

[0607] B28. The method of any of solutions B1 to B26, wherein performing the conversion comprises parsing and decoding the coded representation to generate the video.

[0608] B29. A video decoding apparatus comprising a processor configured to implement a method recited in one or more of solutions B1 to B28.

[0609] B30. A video encoding apparatus comprising a processor configured to implement a method recited in one or more of solutions B1 to B28.

[0610] B31. A computer program product having computer code stored thereon, the code, when executed by a processor, causing the processor to implement a method recited in any of solutions B1 to B28.

[0611] In this document, the term “video processing” can refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm can be applied during a conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. For example, a bitstream representation of a current video block can correspond to bits co-located or distributed in different locations within the bitstream as defined by syntax. For example, a macroblock can be coded according to transformed and encoded error residual values, and also using bits in headers and other fields in the bitstream.

[0612] The disclosures and other solutions, examples, embodiments, modules and functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural equivalents of the disclosures disclosed herein, or in combinations of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. The propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.

[0613] A computer program, which can also be referred to or referred to as a program, software, a software application, an app, a script, or code, can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program is not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one or more computers that are located at one site or distributed across multiple sites and are interconnected by a communication network.

[0614] The processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, and / or devices that are

[0615] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0616] Although this patent document contains many details, these should not be construed as limiting the scope of any subject matter or claimed content to such details, but ought to be understood to describe features that can be particular to certain embodiments of the particular technology. Certain features described in the context of separate embodiments can also be implemented in combination with each other. Conversely, various features described in the context of a single embodiment can also be implemented separately or in any suitable subcombination. Moreover, although the features described above can be described as acting in certain combinations and even initially claimed as such, in some cases one or more features from a claimed combination can be excised from the claimed combination and the claimed combination can be directed to a subcombination or variation of a subcombination.

[0617] Similarly, although operations are described in a particular, sequential order, this should not be understood as requiring that such operations be performed in the perfect order described, or in sequential order, or that all operations be performed, to achieve desirable results. Moreover, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0618] Only a few implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

1. A method of video processing, comprising: performing a conversion between a video comprising a video region including a subpicture and a bitstream of the video, wherein the bitstream conforms to a format rule that specifies whether a first syntax element is signaled in the bitstream based on a second syntax element included in the bitstream, the second syntax element indicating whether the subpicture is treated as a picture, the first syntax element relating to an application of an in-loop filtering process across a boundary of a subpicture associated with the video region, and in response to the second syntax element indicating that the subpicture is not treated as the picture, the first syntax element is inferred to indicate that the in-loop filtering process across the boundary of the subpicture is allowed.

2. The method of claim 1, wherein, in response to the bitstream not including the first syntax element, the first syntax element is inferred to indicate that the in-loop filtering process across the boundary of the subpicture is allowed.

3. The method of claim 1, wherein, the first syntax element is loop_filter_across_subpic_enabled_flag and the second syntax element is subpic_treated_as_pic_flag.

4. The method of claim 1, further comprising: for a conversion between a video comprising a video region and a bitstream of the video, determining whether an in-loop filtering process across a boundary associated with the video region is applied; and based on the determining, performing the conversion, wherein the bitstream includes one or more syntax elements indicating whether the in-loop filtering process is applicable to each video region. the video region is a subpicture.

5. The method of claim 4, wherein, the one or more syntax elements are signaled in a picture parameter set (PPS).

6. The method of claim 5, wherein, the one or more syntax elements control whether the in-loop filtering process across a slice boundary within the subpicture is enabled.

7. The method of claim 5, wherein, the slice boundary within the subpicture does not include a slice boundary coinciding with a boundary of the subpicture.

8. The method of claim 7, wherein, the one or more syntax elements are signaled in a sequence parameter set (SPS).

9. The method of claim 5, wherein, in response to the video including the subpicture, the one or more syntax elements are signaled.

10. The method of claim 9, wherein, the one or more syntax elements include a first syntax element and a second syntax element.

11. The method of claim 5, wherein, the first syntax element and the second syntax element have a same value.

12. The method of claim 11, wherein, the first syntax element and the second syntax element for subpictures in a same slice have a same value.

13. The method of claim 11, wherein, the first syntax element and the second syntax element are associated with a representative subpicture in a plurality of subpictures in a same slice.

14. The method of claim 11, wherein, the representative subpicture is a first subpicture coded or decoded in a coding order or a decoding order, respectively.

15. The method of claim 14, wherein, the boundary is a slice boundary and a tile boundary, and wherein the first syntax element and the second syntax element have different values.

16. The method of claim 11, wherein, in determining that a slice including a current coding tree unit (CTU) is the same as a tile including the current CTU or is a parent of the tile of the current CTU, the conversion is based on the first syntax element and not based on the second syntax element.

17. The method of claim 16, wherein, ​ 18. The method of claim 11, wherein, The boundary is a subpicture boundary, and wherein application of the loop filtering process across the boundary is enabled based on the first syntax element or the second syntax element being equal to one.

19. The method of claim 11, wherein, The boundary is a subpicture boundary and a tile boundary, and wherein application of the loop filtering process across the boundary is enabled based on the first syntax element or the second syntax element being equal to one.

20. The method of claim 11, wherein, The first syntax element is for controlling adaptive loop filter (ALF), de-blocking filter (DF) and sample adaptive offset (SAO) across tile boundaries, and wherein the second syntax element is for controlling adaptive loop filter (ALF), de-blocking filter (DF) and sample adaptive offset (SAO) across slice boundaries.

21. The method of claim 11, wherein, The first syntax element is loop_filter_across_tiles_enabled_flag and the second syntax element is loop_filter_across_slices_enabled_flag.

22. The method of claim 4, wherein, The video region is a tile.

23. The method of claim 4, wherein, The video region is a slice.

24. The method of claim 4, wherein, The video region comprises at least a first type of video unit and a second type of video unit, and wherein the boundary is a boundary of the first type of video unit and a boundary of the second type of video unit.

25. The method of claim 24, wherein, The first type of video unit is a subpicture and the second type of video unit is a slice.

26. The method of claim 24, wherein, The first type of video unit is a subpicture and the second type of video unit is a tile.

27. The method of claim 24, wherein, The first type of video unit is a slice and the second type of video unit is a tile.

28. The method of claim 1, wherein, The loop filtering process comprises at least one of a de-blocking filter, a sample adaptive offset (SAO) filter, an adaptive loop filter (ALF), a cross-component adaptive loop filter, a bilateral filter and a transform domain filter.

29. The method of any one of claims 1 to 28, wherein, The conversion comprises decoding the video from the bitstream representation.

30. The method of any one of claims 1 to 28, wherein, The conversion comprises encoding the video into the bitstream representation.

31. A method of writing a bitstream representing a video to a computer readable recording medium, comprising: generating a bitstream from a video according to the method of any of claims 1 to 30; and writing the bitstream to the computer readable recording medium.

32. A video processing device comprising a processor configured to implement the method of any of claims 1 to 31.

33. A video processing device for storing a bitstream representation, wherein, The video processing device is configured to implement the method of any of claims 1 to 31. The video processing device is configured to implement the method of any of claims 1 to 31.

Images