Segment position signaling with sub-picture tile position derivation

Abstract

A mechanism performed by a decoder is provided. The method includes receiving a coded video stream (CVS). The method includes processing the CVS, wherein: the CVS includes a first set of one or more codewords encoding a first set of one or more values ​​representing a first portion of a fragment address, the CVS includes a second set of one or more codewords encoding a second set of one or more values ​​representing a second portion of the fragment address, and the fragment address specifies a spatial location of the fragment within a picture.

Description

Technical Field

[0001] The present disclosure relates to video encoding and decoding. Background Art

[0002] 1.HEVC and VVC

[0003] High Efficiency Video Coding (HEVC) is a block-based video codec standardized by ITU-T and MPEG that utilizes both temporal and spatial prediction. Spatial prediction is achieved using intra (I) prediction within the current picture. Temporal prediction is achieved using unidirectional (P) or bidirectional inter (B) prediction on a block level based on previously decoded reference pictures. In the encoder, the difference between the original pixel data and the predicted pixel data, called the residual, is transformed into the frequency domain, quantized, and then entropy encoded before being sent along with the necessary prediction parameters, such as prediction mode and motion vectors, which are also entropy encoded. The decoder performs entropy decoding, inverse quantization, and inverse transform to obtain the residual, which is then added to the intra or inter prediction to reconstruct the picture.

[0004] MPEG and ITU-T are developing a successor to HEVC within the Joint Video Exploration Team (JVET). The name of this video codec under development is Versatile Video Coding (VVC). At the time of writing, the current version of the VVC draft specification is "Versatile Video Coding (Draft 6)", JVET-O2001-vE. When VVC is mentioned in this document, it refers to Draft 6 of the VVC specification.

[0005] 2. Quantity

[0006] A video sequence comprises a series of pictures, each of which comprises one or more components. Each component can be described as a two-dimensional rectangular array of sample values. Pictures in a video sequence typically comprise three components: a luminance component (Y), in which the sample values ​​are luminance values; and two chrominance components (Cb) and (Cr), in which the sample values ​​are chrominance values. Typically, the size of the chrominance component is 1 / 2 of the luminance component in each dimension. For example, the size of the luminance component of an HD picture will be 1920x1080, while the chrominance components will each have a size of 960x540. Components are sometimes also referred to as color components. In this document, we describe methods useful for encoding and decoding video sequences. However, it should be understood that the described techniques can also be used for encoding and decoding of still images.

[0007] 3. Blocks and Units

[0008] A block is a two-dimensional array of samples. In video coding, each component is partitioned into one or more blocks, and the coded video bitstream is a sequence of blocks.

[0009] In video coding, a picture is usually divided into units covering a specific area. Each unit includes all the blocks that make up the specific area, and each block belongs entirely to only one unit. Coding units (CUs) in HEVC and VVC are examples of such units. Coding tree units (CTUs) are logical units that can be divided into several CUs.

[0010] In HEVC, CUs are square, i.e., they have a size of N×N luma samples, where N can be 64, 32, 16, or 8. In the current H.266 Test Model Versatile Video Coding (VVC), CUs can also be rectangular, i.e., have a size of N×M luma samples, where N is different from M.

[0011] 4.NAL Unit

[0012] Both HEVC and VVC define a network abstraction layer (NAL). All data (i.e., both the video coding layer (VCL) or non-VCL data in HEVC and VVC) are encapsulated in NAL units. VCL NAL units contain data representing picture sample values. Non-VCL NAL units contain other associated data, such as parameter sets and supplementary enhancement information (SEI) messages. NAL units in HEVC and the current version of VVC start with a header called a NAL unit header. The syntax of the NAL unit header for HEVC is shown in Table 1 and starts with forbidden_zero_bit, which should always be equal to 0 to prevent start code emulation. Without it, some MPEG systems may confuse HEVC video bitstreams with other data, but the 0 bit in the NAL unit header allows all possible HEVC bitstreams to be uniquely identified as HEVC bitstreams. The nal_unit_type, nuh_layer_id, and nuh_temporal_id_plus1 codewords specify the NAL unit type of the NAL unit (which identifies which type of data is carried in the NAL unit), the layer ID to which the NAL unit belongs, and the temporal ID, respectively. The NAL unit type indicates and specifies how the NAL unit should be parsed and decoded. The NAL unit header in the current version of VVC is very similar to the NAL unit header in HEVC, but for nal_unit_type, 1 bit is used less, and the bit is reserved for future use.

[0013] The remaining bytes of the NAL unit are a payload of the type indicated by the NAL unit type. The bitstream consists of a sequence of concatenated NAL units.

[0014] Table 1 - HEVC NAL unit header syntax

[0015]

[0016] Table 2 - NAL unit header syntax for the current version of VVC

[0017]

[0018] A decoder or bitstream parser can infer how the NAL unit should be processed (e.g., parsed and decoded) after looking at the NAL unit header. The remaining bytes of the NAL unit are a payload of the type indicated by the NAL unit type. The bitstream consists of a series of concatenated NAL units.

[0019] The NAL unit type indicates and defines how the NAL unit should be parsed and decoded. The VCL NAL unit provides information about the picture type of the current picture. The NAL unit types of the current version of the VVC draft are shown in Table 3.

[0020] The decoding order is the order in which NAL units should be decoded, which is the same as the order of NAL units within the bitstream. The decoding order may be different from the output order, which is the order in which decoded pictures are to be output by a decoder (e.g., for display).

[0021] Table 3 - NAL unit types in the current version of the VVC draft

[0022]

[0023]

[0024]

[0025] 5. Intra-frame random access point (IRAP) pictures and coded video sequences (CVS)

[0026] An intra random access point (IRAP) picture in HEVC is a picture that is not predicted with reference to any picture other than itself during its decoding process. In HEVC, the first picture in the bitstream in decoding order must be an IRAP picture, but IRAP pictures may also appear later in the bitstream. HEVC specifies three types of IRAP pictures, broken link access (BLA) pictures, instantaneous decoder refresh (IDR) pictures, and clean random access (CRA) pictures.

[0027] A coded video sequence (CVS) in HEVC is a sequence of access units starting from an IRAP access unit and up to (but not including) the next IRAP access unit in decoding order.

[0028] An IDR picture always starts a new CVS. An IDR picture may have an associated Random Access Decodable Leading (RADL) picture. An IDR picture does not have an associated Random Access Skipped Leading (RASL) picture.

[0029] BLA pictures in HEVC also start a new CVS and have the same impact on the decoding process as IDR pictures. However, BLA pictures in HEVC can contain syntax elements that specify a non-empty set of reference pictures. BLA pictures can have associated RASL pictures, which are not output by the decoder and may not be decodable because they may contain references to pictures that may not be present in the bitstream. BLA pictures can also have associated RADL pictures, which are decoded. BLA pictures are not defined in the current version of VVC.

[0030] A CRA picture may have an associated RADL or RASL picture. Like a BLA picture, a CRA picture may contain syntax elements that specify a non-empty set of reference pictures. For a CRA picture, a flag may be set to specify that the associated RASL pictures are not output by the decoder, since these pictures may not be decodable because they may contain references to pictures that are not present in the bitstream. A CRA may start a CVS.

[0031] In the current version of the VVC draft, the CVS starts at a CVS start (CVSS) access unit, which may contain an IRAP picture (ie, an IDR or CRA picture) or a gradual decoding refresh (GDR) picture.

[0032] GDR pictures are essentially used for random access in coded bitstreams for low-delay coding, where a full IRAP picture would cause too much delay. GDR pictures can use a step-by-step intra refresh that updates the video picture by picture, where each picture is only partially intra-coded. Assuming the bitstream is tuned into at the GDR picture, it signals with a GDR picture when the video is fully refreshed and ready for output. GDR can start CVS.

[0033] 6. Parameter Set

[0034] HEVC and VVC specify three types of parameter sets: picture parameter set (PPS), sequence parameter set (SPS), and video parameter set (VPS). The PPS contains data common to one or more pictures, the SPS contains data common to a coded video sequence (CVS), and the VPS contains data common to multiple CVSs. In order to provide random access points in the bitstream, pictures are usually periodically encoded as IRAP or GDR pictures, where each such picture is preceded by the parameter sets (VPS, SPS, PPS) required for decoding.

[0035] The current version of VVC also specifies two additional parameter sets, the Adaptation Parameter Set (APS) and the Decoder Parameter Set (DPS).

[0036] The APS carries the parameters required by the Adaptive Loop Filter (ALF) tool and the Luma Mapping and Chroma Scaling (LMCS) tool.

[0037] The DPS contains information that may not change during a decoding session and may be useful for the decoder to know, for example, the maximum number of sub-layers allowed. The information in the DPS is not essential for the operation of the decoding process.

[0038] 7. Tiles and Bricks

[0039] The draft VVC video coding standard includes a tile tool that divides a picture into spatially independent rectangular regions, which can be called tiles. The tiles in the draft VVC coding standard are similar to the tiles used in HEVC, but with a two-step partitioning mechanism. Using the tile tool, a picture in HEVC can be divided into multiple rows and columns of samples, where a tile is the intersection of a row and a column. Fig.9A An example of a partitioning using 4 tile rows and 5 tile columns is shown, resulting in a picture with a total of 20 tiles.

[0040] The tile structure is signaled in the Picture Parameter Set (PPS) by specifying the height of the rows and the width of the columns. The individual rows and columns can have different sizes, but the divisions always span the entire picture, from left to right and from top to bottom, respectively.

[0041] There are no decoding dependencies between tiles of the same picture. This includes intra prediction, context selection for entropy coding, and motion vector prediction. An exception is that in-loop filtering dependencies are usually allowed between tiles.

[0042] The two-step tile partitioning in VVC starts with dividing the picture into tiles as in HEVC. Then, each tile can be optionally divided into bricks by horizontal boundaries, such as Fig. 9B In the current VVC draft specification, the word brick is also used for tiles that are not further divided, which means Fig. 9BThe picture on the middle right includes 9 bricks.

[0043] 8. Slices

[0044] The concept of slices in HEVC divides a picture into independently coded slices, where decoding of one slice in a picture is independent of other slices in the same picture. Different coding types can be used for slices of the same picture, i.e., a slice can be an I slice, a P slice, or a B slice. One purpose of slices is to enable resynchronization in case of data loss.

[0045] In the current version of VVC, a slice consists of multiple complete tiles, or a continuous sequence of complete tiles of just one tile. Each slice has: i) a slice header, which includes parameters that can be set for each slice; and ii) slice data. Some parameters are constrained to be the same for all slices in a picture. Each slice in CVS is carried in a separate VCL NAL unit.

[0046] In previous versions of the VVC draft specification, slices were referred to as tile groups.

[0047] The current version of VVC supports two slice modes, namely raster scan slice mode and rectangular slice mode. In raster scan slice mode, a slice contains a sequence of tiles in a tile raster scan of a picture. In rectangular slice mode, a slice contains multiple bricks of a picture, which together form a rectangular region of the picture. The bricks within a rectangular slice follow the brick raster scan order of the tile.

[0048] In the current version of the VVC draft specification, the slice_address given in the slice header (see Table 4) is used to derive the spatial position of a slice in a picture.

[0049] Table 4 - Slice address syntax in the slice header in the current version of the VVC draft specification

[0050]

[0051]

[0052] 9. Sub-image

[0053] The current version of VVC supports sub-pictures. A sub-picture is defined as a rectangular area of ​​one or more slices within a picture. This means that a sub-picture contains one or more slices that together cover a rectangular area of ​​the picture. In the current version of the VVC specification, the sub-picture position and size are signaled in the SPS. The boundaries of the sub-picture area can be regarded as picture boundaries (excluding in-loop filtering operations) conditioned on each sub-picture flag subpic_treatment_as_pic_flag[i] in the SPS. In addition, loop filtering on sub-picture boundaries is conditioned on each sub-picture flag loop_filter_across_subpic_enabled_flag[i] in the SPS. Table 5 shows the sub-picture syntax in the SPS in the current version of VVC.

[0054] Table 5 - Sub-picture syntax in SPS in the current version of the VVC draft specification

[0055]

[0056]

[0057]

[0058] Summary of the invention

[0059] There are certain challenges. For example, in the current version of the VVC draft specification, the slice_address signaled in the slice header (see Table 4) is a u(v)-encoded codeword that is used to derive the spatial position of the slice in the picture. However, when sub-picture partitioning is used, the spatial position of the slice in the sub-picture cannot be directly derived from the slice_address codeword in the slice header, and it cannot be derived from the slice header that the slice belongs to a certain sub-picture. In order to derive the spatial position of a slice in a sub-picture in the current version of the VVC specification, first, it is necessary to derive the spatial position of the slice in the picture, secondly, it is necessary to derive the spatial position in the picture belonging to a certain sub-picture, and then in the third step, the spatial position of the slice in the sub-picture can be derived therefrom. This multi-step process for deriving the spatial position of a slice in a sub-picture can be simplified, which will help the slice decoding process and the positioning of the decoded pixel values ​​in the sub-picture.

[0060] Furthermore, when extracting or merging sub-pictures (such as in sub-bitstream extraction and merging), the spatial position of the slice in the sub-picture does not change. This means that the positioning of the slice relative to the sub-picture position is fixed during the sub-bitstream extraction and merging process. This information is not currently utilized in the current version of the VVC specification, which suggests that the signaling for slice addresses in the current version of the VVC specification is suboptimal and can be improved.

[0061] In the current version of the VVC specification and when using sub-picture partitioning, it is not possible to derive from the slice header alone which sub-picture the slice is spatially located in. Although this relationship is also fixed when extracting or merging sub-pictures, this information is not utilized in the current version of the VVC specification.

[0062] The present disclosure is intended to overcome the shortcomings of the current version of the VVC specification. In one embodiment, the shortcomings are overcome by including information in the slice header indicating: i) the sub-picture to which the slice belongs; and ii) the spatial positioning of the slice relative to the position of the sub-picture to which the slice belongs. For example, in one variant, the slice header includes two values ​​of the slice address: i) a value for the sub-picture ID, where the sub-picture ID indicates the sub-picture to which the slice belongs; and ii) a value for the slice address, where the slice address indicates the spatial positioning of the slice relative to the position of the sub-picture to which the slice belongs. Using the two values ​​of the slice address, the spatial position of the slice in the picture can then be derived by, for example, the following operations: deriving the sub-picture position in the picture from the sub-picture ID (as one of the values ​​signaled in the slice header); and then deriving the position of the slice in the sub-picture from another slice address value signaled in the slice header.

[0063] In the current version of the VVC specification, where the bitstream is the result of a sub-bitstream extraction, the value of slice_address is mapped to the value of slice_id in the PPS to derive the spatial position of the slice. In this case, if the subset of slices included in the sub-bitstream does not include the upper left corner slice of the picture in the "original" bitstream, the value of the slice ID and the value of the slice address will not be the same. The slice ID provides an indirect mechanism to enable the sub-bitstream extraction and merging process. In one embodiment, the sub-picture ID can be used with an indirect mechanism instead of using an indirect mechanism for the slice address. This embodiment can be used for sub_bitstream extraction and merging situations, where the slice address relative to the sub-picture remains unchanged during the process, and the sub-picture ID uses an indirect mechanism in, for example, the SPS to map the initial sub-picture ID to the sub-picture index in the new sub-bitstream.

[0064] Certain aspects of the present disclosure and embodiments thereof may provide solutions to the aforementioned challenges.

[0065] A first aspect of the embodiments defines a method performed by a decoder. The method includes receiving a coded video stream (CVS). The method includes processing the CVS, wherein: the CVS includes a first set of one or more codewords encoding a first set of one or more values ​​representing a first portion of a fragment address, the CVS includes a second set of one or more codewords encoding a second set of one or more values ​​representing a second portion of the fragment address, and the fragment address specifies a spatial location of the fragment within a picture.

[0066] A second aspect of the embodiment defines a method performed by an encoder. The method includes generating a coded video stream (CVS), wherein: the CVS includes a first set of one or more codewords encoding a first set of one or more values ​​representing a first portion of a fragment address, the CVS includes a second set of one or more codewords encoding a second set of one or more values ​​representing a second portion of the fragment address, and the fragment address specifies a spatial location of the fragment within a picture.

[0067] A third aspect of the embodiments defines a computer program comprising instructions which, when executed by a processing circuit, cause the processing circuit to perform the method according to the first aspect or the second aspect of the embodiments.

[0068] A fourth aspect of the embodiments defines a carrier embodying the computer program according to the third aspect, wherein the carrier is one of an electric signal, an optical signal, a radio signal and a computer readable storage medium.

[0069] A fifth aspect of the embodiments defines a decoding apparatus adapted to perform the method according to the first aspect of the embodiments.

[0070] A sixth aspect of the embodiments defines an encoding device suitable for performing the method according to the second aspect of the embodiments.

[0071] advantage

[0072] An advantage of embodiments is that they simplify the multi-step process for deriving the relative position of a slice in a sub-picture by signaling two values ​​in a slice header in one embodiment, where one value is the slice address relative to the sub-picture and the other value provides information about which sub-picture the slice belongs to, such as a sub-picture ID, which uses the fixed relationship of the slice relative to the sub-picture and the spatial position of the slice in the sub-picture area for the decoding process and simplifies sub-bitstream extraction and merging. If there are multiple slices in a sub-picture, bitstream extraction using current VVC designs may require address indirection of the slice_address value in each slice. Using the proposed embodiment, instead, the address indirection is performed for each sub-picture, which means that the address indirection is only performed once for all slices in the sub-picture. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] Figure 1 A system according to an embodiment is shown.

[0074] Figure 2 is a schematic block diagram of a video encoder according to one embodiment.

[0075] Figure 3 is a schematic block diagram of a video decoder according to one embodiment.

[0076] Figure 4 An encoded video bitstream according to an embodiment is shown.

[0077] Figure 5 A hierarchical partitioning is shown.

[0078] Figure 6 is a flow chart illustrating a decoding process according to an embodiment.

[0079] Figure 7 is a flow chart illustrating an encoding process according to an embodiment.

[0080] Figure 8 is a block diagram of an apparatus according to an embodiment.

[0081] Fig.9A An example of partitioning is shown.

[0082] Fig. 9B A two-step tile partitioning is shown. DETAILED DESCRIPTION

[0083] Figure 1 A system 100 is shown according to an example embodiment. The system 100 includes an encoder 102 in communication with a decoder 104 via a network 110 (e.g., the Internet or other network). Deblocking may be performed in both the encoder 102 and the decoder 104. The embodiments described herein may be used in either the video encoder 102 or the video decoder 104.

[0084] Figure 22 is a schematic block diagram of a video encoder 202 according to one embodiment. The current pixel block is predicted by performing motion estimation from a pixel block already provided in the same frame or a previous frame using a motion estimator / compensator 250. In the case of inter-frame prediction, the result of the motion estimation is a motion or displacement vector associated with a reference block. The motion vector can be used by the motion estimator / compensator 250 to output an inter-frame prediction of the pixel block. The intra-frame predictor 249 calculates the intra-frame prediction of the current pixel block. The outputs from the motion estimator / compensator 250 and the intra-frame predictor 249 are input in a selector 251, which selects intra-frame prediction or inter-frame prediction for the current pixel block. The output from the selector 251 is input to an error calculator in the form of an adder 241, which also receives the pixel value of the current pixel block. The adder 241 calculates and outputs a residual as the difference between the pixel value of the pixel block and its prediction. The error is transformed in the transformer 242 (e.g., by discrete cosine transform), quantized by the quantizer 243, and then encoded in the encoder 244 (e.g., by an entropy encoder). In inter-frame coding, the estimated motion vector is also taken to the encoder 244 to generate an encoded representation of the current pixel block. The transformed and quantized residual of the current pixel block is also provided to the inverse quantizer 245 and the inverse transformer 246 to obtain the original residual. The difference is added by the adder 247 to the block prediction output from the motion estimator / compensator 250 or the intra-frame predictor 249 to produce a reference pixel block that can be used for prediction and encoding of the next pixel block. This new reference block is first processed by the deblocking filter 200. The processed new reference block is then temporarily stored in the frame buffer 248, and the processed new reference block can be used by the intra-frame predictor 249 and the motion estimator / compensator 250.

[0085] Figure 3304 is a block diagram of a video decoder according to some embodiments. The decoder 304 includes a decoder 361, such as an entropy decoder, to decode the encoded representation of the pixel block to obtain a set of quantized and transformed residuals. These residuals are dequantized by an inverse quantizer 362 and inversely transformed by an inverse transformer 363 to provide a set of residuals. These residuals are added to the pixel values ​​of the reference pixel block by an adder 364. Depending on whether inter-frame prediction or intra-frame prediction is performed, the reference block is determined by a motion estimator / compensator 367 or an intra-frame predictor 366. Therefore, a selector 368 is interconnected with the adder 364 and the motion estimator / compensator 367 and the intra-frame predictor 366. The resulting decoded pixel block output from the adder 364 is input to the deblocking filter 300. The filtered pixel block is output from the decoder 304 and may also be temporarily provided to a frame buffer 365 to be used as a reference pixel block for a subsequent pixel block to be decoded. The frame buffer 365 is thus connected to the motion estimator / compensator 367 to make the stored pixel blocks available to the motion estimator / compensator 367. The output of the adder 364 may also be input to the intra predictor 366 to be used as an unfiltered reference pixel block.

[0086] Figure 4 An example video bitstream 400 is shown. The bitstream 400 includes a CVS 401, which includes a parameter set (PS) 410 (e.g., a non-VCL NAL unit containing a parameter set) and multiple fragments (e.g., multiple VCL NAL units containing VVC slices). Fragments 412a and 412b are shown. A fragment is a data unit that includes fragment data (SD), which includes sample data. In addition to the fragment data (SD), a fragment may also have a fragment header (SH). VVC slices and HEVC slices are examples of fragments. A fragment may also be a picture, a tile group, or some other entity that includes a complete picture or a portion of a picture. In this example, each fragment includes a fragment header in addition to the fragment data.

[0087] Figure 5 , where picture 502 is divided into large-granularity partition blocks (e.g., VVC sub-pictures) shown with thick lines (e.g., block 511), and thin dashed lines show small-granularity partition blocks (e.g., VVC slices) within the large-granularity partition blocks (see, for example, block 512, which is spatially located in block 511). In some embodiments, in the case of such hierarchical partitioning, at least two values ​​are signaled in the header or parameter set of the small-granularity partition block (e.g., block 512): i) a value specifies in which large-granularity partition block (e.g., block 511) the small-granularity partition is spatially located, and ii) a value is used to provide an address of the location of the small-granularity partition block relative to the large-granularity partition block. VVC slices are examples of small-granularity partition blocks, and VVC sub-pictures are examples of large-granularity partition blocks.

[0088] Those skilled in the art will appreciate that the following embodiments may be combined to form solutions that are not explicitly defined but are still covered by the present disclosure. In addition, the embodiments described below may be described in terms of slices (e.g., small granularity partition blocks) and sub-pictures (e.g., large granularity partition blocks). That is, the terms slice and sub-picture are used interchangeably with small granularity partition blocks and large granularity partition blocks, respectively. In addition, although the embodiments are described with respect to slices, the present invention is not limited to slices and is intended to cover other fragments.

[0089] 1. Two values ​​signaled in the slice header for the slice address

[0090] In a first embodiment, two values ​​are signaled in a header or parameter set of a slice: i) a first value, such as an ID, indicating the large granularity partition block in which the small granularity partition block is spatially located; and ii) a second value indicating the positioning of the small granularity partition block relative to the position of the large granularity partition block. As an example of this embodiment, two values ​​are signaled in a slice header, which together form a slice address: i) a first value for a sub-picture ID indicating the sub-picture to which the slice belongs (i.e., the sub-picture in which the slice is located); and ii) a value for a local slice address indicating the spatial positioning of the slice relative to the position of the sub-picture to which the slice belongs. The following is an exemplary syntax and semantics of a slice header (note that all exemplary syntax and semantics are given as text above the current version of the VVC draft specification):

[0091] Table 6

[0092]

[0093] The subpic_id codeword (also called a syntax element) specifies the ID of the subpicture to which the slice belongs. The subpic_id codeword is conditional in the table on subpics_present_flag, which is true (equal to 1) when the subpicture is present in the picture, and false (equal to 0) when the subpicture is not present. If subpic_id is false, the local_slice_address codeword specifies the spatial positioning of the slice relative to the picture rather than the subpicture. Note that other conditions on the presence of subpic_id are possible, and there may be no condition, meaning that subpic_is is always present when local_slice_address is present. When not present, the value of subpic_id is inferred to be equal to 0. The length of the syntax element is Ceil(Log2(N)) bits. Note that in the current version of VVC, 8 bits are used in the SPS to signal max_subpics_minus_1, which can be in the range of 0 to 254. N can then be 254, for example.

[0094] The local_slice_address codeword specifies the slice address of the slice in the subpicture identified by subpic_id. When not present, the value of local_slice_address is inferred to be equal to 0. The length of the syntax element is Ceil(Log2(max_num_slices_in_picture_minus1+1)) bits, where max_num_slices_in_picture_minus1+1 is the maximum number of slices allowed by the profile, layer or level definition in use.

[0095] Alternative semantics for local_slice_address are as follows:

[0096] The local_slice_address codeword specifies the address of the slice. When not present, the value of local_slice_address is inferred to be equal to 0. If sub-pictures are not enabled (subpics_present_flag is equal to 0), the following apply: 1) the slice address is the brick ID; 2) the length of slice_address is Ceil(Log2(NumBricksInPic)) bits; and 3) the value of slice_address should be in the range of 0 to NumBricksInPic-1 (inclusive). Otherwise, if sub-pictures are enabled (subpics_present_flag is equal to 1), the following apply: 1) the slice address is the slice address of the slice in the sub-picture with subpic_id; and 2) the length of slice_address is equal to signalled_slice_id_length_minus1+1 bits.

[0097] The decoder may perform the following steps for this embodiment to decode one or more pictures from a bitstream, where the bitstream includes at least two slices:

[0098] 1) Determine from one or more syntax elements in the bitstream whether the partition structure has more than one level of hierarchy.

[0099] 2) For slices having more than one level of hierarchy, perform the following operations: 2a) decode a first value from a codeword in a slice header of the slice, wherein the first value represents a first portion of an address; 2b) decode a second value from a codeword in the slice header, wherein the second value represents a second portion of the address; 2c) derive a slice address from the first value and the second value to locate the slice within the picture; and 2d) decode the slice using the slice address.

[0100] In another version, two sets of values ​​are signaled in a header or parameter set of a slice, where each set may include one or more values, and the one or more values ​​in one set together indicate the location of the slice relative to the sub-picture location, and the one or more values ​​in the other set together indicate in which sub-picture the slice is spatially located. As an example of this version, two sets of values ​​are signaled in a slice header for a slice address, one set of values ​​includes one value for a sub-picture ID, the sub-picture ID indicates to which sub-picture the slice belongs, and one set of values ​​includes two values ​​X s and Y s , which together indicate the spatial positioning of the slice relative to the position of the sub-picture to which the slice belongs.

[0101] 2- Use indirection

[0102] In another embodiment, two values ​​are signaled in the header or parameter set of the small granularity partition block: i) one value indicates the large granularity partition block where the small granularity partition block is spatially located, and ii) another value indicates the location of the small granularity partition block relative to the location of the large granularity partition block, and at least one of the two values ​​uses an indirect mechanism, such as using an index mapping list or an address mapping list (which can be signaled in a parameter set (e.g., PPS or SPS) in the bitstream) to specify a target value. Preferably, in this embodiment, the large granularity partition block is a partition block using an indirect mechanism.

[0103] For example, assume that a picture is partitioned into four spatial quadrants, each of which is a sub-picture. Further assume that each of the four sub-pictures includes only one slice. In this example, all second values ​​(e.g., local_slice_address values) can be equal to 0 to indicate that the position of the slice is equal to the position of the sub-picture. The first ID value (e.g., subpic_id value) can be equal to 0, 1, 2, 3, respectively, to indicate the sub-picture to which each slice belongs. Now, consider extracting sub-picture 2 and sub-picture 3 from the bitstream and creating a new bitstream including these two sub-pictures. To support such operations, for example, the PPS can contain an indirect mapping or index mapping, in which ID values ​​2 and 3 are mapped to 0 and 1, respectively. A decoder decoding the new bitstream can first decode that there are two sub-pictures in the new bitstream, and therefore assign the final sub-picture IDs 0 and 1 to them. The decoder will then decode the information in the PPS to create an index mapping. Afterwards, the decoder can decode the slice with an ID value of 2. Using the index mapping, the final sub-picture ID value is derived to be equal to 0. Similarly, for a slice with an ID value of 3, the final sub-picture ID value is derived to be equal to 1. Through this indirect or index mapping mechanism, sub-picture data can be extracted and a new bitstream formed without rewriting the slice ID value in each slice but only creating an index mapping once.

[0104] 3- Signaling addresses for more than one level of hierarchy

[0105] In another embodiment, there are more than two levels of partitioning hierarchy - for example, a three-level partitioning hierarchy with small, medium, and large granularity partitioning blocks, and at least three values ​​are signaled in the header or parameter set of the small granularity partitioning block: i) a first value - for example, an ID - which indicates the medium granularity partitioning block in which the small granularity partitioning block is spatially located, ii) a second value which indicates the positioning of the small granularity partitioning block relative to the position of the medium granularity partitioning block, and iii) a third value which indicates the large granularity partitioning block in which the small granularity partitioning block is spatially located. In some embodiments, the header also includes a fourth value which indicates the positioning of the small granularity partitioning block relative to the position of the large granularity partitioning block. In this embodiment, the spatial position of the medium granularity partitioning block relative to the large granularity partitioning block is derived from the difference in the spatial positions of the small granularity partitioning block relative to the medium granularity partitioning block and the large granularity partitioning block.

[0106] 4- Signaling of the number of local slices in a sub-picture

[0107] In another embodiment that may be based on any of the previous embodiments, the number of slices in the current sub-picture is known when the slice is decoded. This information may be signaled directly in the slice header or in the parameter set of each sub-picture using, for example, the num_slices_in_subpic or num_slices_in_subpic_minus1 codewords. The following example describes the syntax and semantics on top of the current version of VVC for signaling num_slices_in_subpic_minus1 in the slice header:

[0108] Table 7

[0109]

[0110] The subpic_id codeword specifies the ID of the subpicture to which the slice belongs. When not present, the value of subpic_id is inferred to be equal to 0. The length of the syntax element is Ceil(Log2(N)) bits. Note that in the current version of VVC, 8 bits are used in the SPS to signal max_subpics_minus_1, which can be in the range of 0 to 254. N can then be 254, for example.

[0111] The num_slices_in_subpic_minus1 codeword indicates the number of slices present in the current sub-picture (ie, num_slices_in_subpic_minus1 plus 1). When not present, the value of num_slices_in_subpic_minus1 is inferred to be equal to 0.

[0112] The local_slice_address codeword specifies the slice address of a slice in the subpicture with subpic_id. When not present, the value of local_slice_address is inferred to be equal to 0. The length of the syntax element is Ceil(Log2(num_slices_in_subpic_minus1+1)) bits.

[0113] The following example describes the syntax and semantics on top of the current version of VVC for signaling num_slices_in_subpic_minus1[i] for each sub-picture in the SPS:

[0114] Table 8

[0115]

[0116] The value of max_subpics_minus1 plus 1 specifies the maximum number of sub-pictures that may be present in the CVS. max_subpics_minus1 should be in the range 0 to 254. The value 255 is reserved for future use by ITU-T | ISO / IEC.

[0117] The value of num_slices_in_subpic_minus1[i] plus 1 specifies the number of slices present in the i-th sub-picture. When not present, the value of num_slices_in_subpic_minus1[i] is inferred to be equal to 0.

[0118] Example 5 - Using max_subpic_minus1 when deriving subpic_id

[0119] In another embodiment that may be based on the first embodiment, the max_subpics_minus1 codeword signaled in the SPS in the current version of VVC is used to derive the number of bits for subpic_id. The semantics of subpic_id in the slice header may then be: subpic_id specifies the ID of the subpicture to which the slice belongs. When not present, the value of subpic_id is inferred to be equal to 0. The length of the syntax element is Ceil(Log2(max_subpics_minus1+1)) bits.

[0120] 6-Signal one slice per sub-picture

[0121] In one embodiment, the flag single_slice_in_subpicture_flag is present in a parameter set, preferably an SPS or a DPS. When the flag has one value, there should not be a sub-picture consisting of more than one slice. When the flag has another value, there can be multiple slices in a sub-picture.

[0122] The presence of the slice_address codeword may be conditional on this flag, such that the slice_address codeword is not parsed when the flag indicates that there is one slice per sub-picture.

[0123] Table 9

[0124]

[0125] When the value of single_slice_in_subpicture_flag is equal to 1, this specifies that there is only one slice in each sub-picture in the CVS involving this SPS. When the value of single_tile_in_pic_flag is equal to 0, this specifies that more than one slice can be present in the sub-picture in the CVS involving this SPS. When single_slice_in_subpicture_flag is not present, it is inferred to be equal to 0.

[0126] Table 10

[0127]

[0128]

[0129] signalled_slice_id_length_minus1 plus 1 specifies the number of bits used to represent the syntax element slice_id[i] (when present) and the syntax element slice_address in the slice header. The value of signalled_slice_id_length_minus1 shall be in the range of 0 to 15, inclusive. When not present, the value of signalled_slice_id_length_minus1 is inferred to be equal to Ceil(Log2(Max(2, num_slices_in_pic_minus1+1)))-1.

[0130] Table 11

[0131]

[0132] subpic_id specifies the ID of the sub-picture to which the slice belongs. When not present, the value of subpic_id is inferred to be equal to 0. The length of the syntax element is Ceil(Log2(max_subpics_minus1+1)) bits.

[0133] slice_address specifies the address of the slice. When not present, slice_address is inferred to be equal to 0.

[0134] If subpics is not enabled (subpics_present_flag is equal to 0), the following applies: 1) the slice address is the brick ID; 2) the length of slice_address is Ceil(Log2(NumBricksInPic)) bits; and 3) the value of slice_address shall be in the range of 0 to NumBricksInPic-1, inclusive.

[0135] Otherwise, if sub-pictures are enabled (subpics_present_flag equal to 1), the following apply: 1) the slice address is the slice address within the sub-picture with sub-picture ID equal to subpic_id; and 2) the length of slice_address is signalled_slice_id_length_minus1+1 bits.

[0136] Alternatively, the maximum number of slices per subpicture, max_number_of_slices_per_subpic_minus1 codeword, may be signaled in the parameter set. In this case, if max_number_of_slices_per_subpic_minus1 is equal to 0, the decoder does not parse the slice_address codeword, but infers that the slice_address codeword is equal to 0. In the case where max_number_of_slices_per_subpic_minus1 is greater than 0, the number of bits used for slice_address may be set equal to Ceil(Log2(max_number_of_slices_per_subpic_minus1+1)) bits.

[0137] Figure 8800 is a block diagram of an apparatus 800 for implementing the video encoder 102 or the video decoder 104 according to some embodiments. That is, the apparatus 800 is operable to perform the process 600 and / or the process 700. In embodiments where the apparatus 800 implements the video encoder 102, the apparatus 800 may be referred to as an "encoding apparatus 800," and in embodiments where the apparatus 800 implements the video decoder 104, the apparatus 800 may be referred to as a "decoding apparatus 800." Figure 8 As shown, the device 800 may include: a processing circuit (PC) 802, which may include one or more processors (P) 855 (e.g., a general-purpose microprocessor and / or one or more other processors, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc.), which may be co-located in a single housing or a single data center, or may be geographically distributed (i.e., the device 800 may be a distributed computing device); a network interface 848, including a transmitter (Tx) 845 and a receiver (Rx) 847, for enabling the device 800 to send data to and receive data from other nodes that are connected to a network 110 (e.g., an Internet Protocol (IP) network) connected (directly or indirectly) to the network interface 848 (e.g., the network interface 848 may be wirelessly connected to the network 110, in which case the network interface 848 is connected to an antenna arrangement); and a local storage unit (also referred to as a "data storage system") 808, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where the PC 802 includes a programmable processor, a computer program product (CPP) 841 may be provided. The CPP 841 includes a computer readable medium (CRM) 842 storing a computer program (CP) 843 including computer readable instructions (CRI) 844. The CRM 842 may be a non-transitory computer readable medium, such as a magnetic medium (e.g., a hard disk), an optical medium, a memory device (e.g., a random access memory, a flash memory), etc. In some embodiments, the CRI 844 of the computer program 843 is configured such that when executed by the PC 802, the CRI causes the device 800 to perform the steps described herein (e.g., the steps described herein with reference to the flowcharts). In other embodiments, the device 800 may be configured to perform the steps described herein without requiring code. That is, for example, the PC 802 may consist solely of one or more ASICs. Thus, the features of the embodiments described herein may be implemented in hardware and / or software.

[0138] Although various embodiments (including appendices) are described herein, it should be understood that they are presented only by way of example and not limitation. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above-mentioned exemplary embodiments. In addition, any combination of the above-mentioned elements with all possible variations thereof is included in the present disclosure, unless otherwise indicated or otherwise clearly conflicting with the context.

[0139] Additionally, although the processes described above and shown in the accompanying drawings are shown as a series of steps, this is for illustrative purposes only. Therefore, it is contemplated that some steps may be added, some steps may be omitted, the order of steps may be rearranged, and some steps may be performed in parallel.

[0140] Abbreviations

[0141] ATSC Advanced Television Systems Committee

[0142] AU Visiting Unit

[0143] AUD Access Unit Delimiter

[0144] ALF Adaptive Loop Filter

[0145] APS Adaptive Parameter Set

[0146] BLA Broken Link Access

[0147] CLVS Coding Layer Video Sequence

[0148] CRA Clean Random Access

[0149] CVS encoded video stream

[0150] CVSS CVS Start

[0151] CU Coding Unit

[0152] Dynamic Adaptive Streaming over DASH HTTP

[0153] DPS Decoding Parameter Set

[0154] DVB Digital Video Broadcasting

[0155] DRAP Dependent Random Access Point

[0156] GDR Gradual Decode Refresh

[0157] HEVC High Efficiency Video Coding

[0158] IDR Instantaneous Decoder Refresh

[0159] IRAP Intra-frame random access point

[0160] ISO International Organization for Standardization

[0161] ISOBMFF ISO Base Media File Format

[0162] LMCS Luma Mapping and Chroma Scaling

[0163] MPEG Moving Picture Experts Group

[0164] MMT MPEG Media Transport

[0165] NAL Network Abstraction Layer

[0166] NALU NAL unit

[0167] NUT NAL unit type

[0168] PPS Picture Parameter Set

[0169] RADL Random Access Decodable Preamble

[0170] RAP Random Access Point

[0171] RASL Random Access Skip Preamble

[0172] RBSP Raw Byte Sequence Payload

[0173] RPL Reference Image List

[0174] SEI Supplementary Enhancement Layer

[0175] SPS Sequence Parameter Set

[0176] STSA Stepwise Temporal Layer Access

[0177] VCL Video Coding Layer

[0178] VPS Video Parameter Set

[0179] VVC Versatile Video Coding.

[0180] Appendix The following text comes from contributions that propose changes to the current VVC version.

[0181] Start Text

[0182] summary

[0183] This contribution proposes the following changes to the VVC specification related to slice address signaling in the sub-picture case:

[0184] - First, it is proposed to signal a sub-picture ID in the slice header to specify to which sub-picture the current slice belongs, conditional on the existence of the sub-picture in the CVS.

[0185] - Secondly, it is proposed to signal the slice address relative to the sub-picture position in the slice header.

[0186] - Third, it is proposed to use address indirection for sub-picture ID and remove address indirection for slice address. For each sub-picture, the slice address is fixed relative to the sub-picture and can be reused in the sub-bitstream extraction and merging process.

[0187] 1. Introduction

[0188] In the current VVC specification draft of JVET-O2001-vE, sub-pictures are supported and the goal is to simplify the sub-bitstream extraction and merging process. However, the address signaling mechanism of sub-pictures related to other defined hierarchical partitions (such as pictures and slices) may need improvement.

[0189] In the current VVC draft specification, the slice address is signaled in the slice header and is used to derive the spatial position of the slice in the picture. However, when sub-pictures are used and when there is more than one slice in a sub-picture, there are some problems with the current slice address signaling scheme:

[0190] 1- The spatial location of a slice in a sub-picture cannot be derived directly from the slice_address syntax in the slice header, and it requires a multi-step process:

[0191] οYou need to first derive the spatial position of the slice in the image;

[0192] Then in the second step, it is necessary to derive which sub-image the spatial position in the image belongs to;

[0193] Then in a third step, the spatial position of the patch in the sub-image can be derived.

[0194] 2- From the slice header, it is not possible to derive which sub-picture the slice belongs to. This information will be useful for the sub-bitstream merging and extraction process.

[0195] 3- When extracting or merging sub-pictures (such as in sub-bitstream extraction and merging), the fixed relative spatial positions of slices in the sub-pictures are not utilized.

[0196] 4- The indirection mechanism for mapping slice_address to slice_id may be suboptimal for the sub-bitstream extraction and merging process, because in the case of multiple slices in a sub-picture, sub-bitstream extraction using the current VVC design may require several address indirections: one for each slice_address value in the slice.

[0197] 2. Suggestions

[0198] This contribution proposes a solution to address the above issues and simplify the multi-step process for deriving the relative positions of slices in sub-pictures. This contribution proposes the following changes related to slice address signaling in the sub-picture case:

[0199] - First, it is proposed to signal a sub-picture ID in the slice header to specify to which sub-picture the current slice belongs, conditional on the existence of the sub-picture in the CVS.

[0200] - Secondly, it is proposed to signal the slice address relative to the sub-picture position in the slice header.

[0201] - Third, it is proposed to use address indirection for sub-picture ID and remove address indirection for slice address. For each sub-picture, the slice address is fixed relative to the sub-picture and can be reused in the sub-bitstream extraction and merging process.

[0202] -

[0203] With this proposal, the four issues mentioned above are addressed in the following ways:

[0204] 1-The spatial position of the slice in the sub-picture is directly derived from the slice header;

[0205] 2- The ID of the sub-picture to which the slice belongs is signaled in the slice header;

[0206] 3-The relative spatial position of the slice in the sub-picture is signaled in the slice header;

[0207] 4- In the extraction and merging of sub-pictures, an indirect process is performed for each sub-picture (rather than each slice).

[0208] The following are the syntactic and semantic changes proposed in the header over JVET-O2001-vE:

[0209]

[0210]

[0211] max_subpics__minus1 plus 1 specifies the maximum number of subpictures that may be present in the CVS. max_subpics_minus1 should be in the range 0 to 254. The value 255 is reserved for future use by ITU-T|ISO / IEC.

[0212] subpic_grid_col_width_minus1 plus 1 specifies the width of each element of the sub-picture identifier grid in units of 4 samples. The length of the syntax element is Ceil(Log2(pic_width_max_in_luma_samples / 4)) bits.

[0213] The variable NumSubPicGridCols is derived as follows:

[0214] NumSubPicGridCols

[0215] (pic_width_max_in_luma_samples+subpic_grid_col_width_minus1*4+3) /

[0216] (subpic_grid_col_width_minus1*4+4)(7-5)

[0217] subpic_grid_row_height_minus1 plus 1 specifies the height of each element of the sub-picture identifier grid in units of 4 samples. The length of the syntax element is Ceil(Log2(pic_height_max_in_luma_samples / 4)) bits.

[0218] The variable NumSubPicGridRows is derived as follows:

[0219] NumSubPicGridRows

[0220] (pic_height_max_in_luma_samples+subpic_grid_row_height_minus1*4+3) /

[0221] (subpic_grid_row_height_minus1*4+4)(7-6)

[0222] subpic_grid_idx[i][j] specifies the sub-picture index of the grid position (i, j). The length of the syntax element is Ceil(Log2(max_subpics_minus1+1)) bits.

[0223] The variables SubPicTop[subpic_grid_idx[i][j]], SubPicLeft[subpic_grid_idx[i][j]], SubPicWidth[subpic_grid_idx[i][j]], SubPicHeight[subpic_grid_idx[i][j]], and NumSubPics are derived as follows:

[0224]

[0225]

[0226] subpic_treated_as_pic_flag[i] equal to 1 specifies that the i-th subpicture of each coded picture in the CVS is treated as a picture in the decoding process except for in-loop filtering operations. subpic_treated_as_pic_flag[i] equal to 0 specifies that the i-th subpicture of each coded picture in the CVS is not treated as a picture in the decoding process except for in-loop filtering operations. When not present, the value of subpic_treated_as_pic_flag[i] is inferred to be equal to 0.

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

[0228] Bitstream conformance is required where the following constraints apply:

[0229] For any two sub-pictures subpicA and subpicB, when the index of subpicA is less than the index of subpicB, any coded NAL unit of subPicA shall follow any coded NAL unit of subPicB in decoding order.

[0230] The shape of sub-pictures shall be such that each sub-picture, when decoded, shall have its entire left border and its entire top border including picture boundaries or including the boundaries of previously decoded sub-pictures.

[0231] signalled_subpic_id_flag equal to 1 specifies that the sub-picture ID of each sub-picture is signaled. signalled_subpic_id_flag equal to 0 specifies that the sub-picture ID is not signaled. When subpics_present_flag is equal to 0, the value of signalled_subpic_id_flag is inferred to be equal to 0.

[0232] signalled_subpic_id_length_minus1 plus 1 specifies the number of bits used to represent the syntax element subpic_id[i] (when present) and the syntax element slice_subpic_id in the slice header. The value of signalled_subpic_id_length_minus1 shall be in the range of 0 to 15, inclusive. When not present, the value of signalled_subpic_id_length_minus1 is inferred to be equal to Ceil(Log2(Max(2, max_subpics_minus1+1)))-1.

[0233] subpic_id[i] specifies the subpicture ID of the i-th subpicture. The length of the subpic_id[i] syntax element is signalled_subpic_id_length_minus1+1 bits. When not present, the value of subpicid[i] is inferred to be equal to i, where i is in the range 0 to NumSubPics-1, inclusive.

[0234] The following are the syntactic and semantic changes proposed in the header over JVET-O2001-vE:

[0235]

[0236] slice_pic_parameter_set_id specifies the value of pps_pic_parameter_set_id for the PPS used. The value of slice_pic_parameter_set_id shall be in the range of 0 to 63, inclusive.

[0237] The bitstream conformance requirement is that the TemporalId value of the current picture should be greater than or equal to the TemporalId value of the PPS whose pps_pic_parameter_set_id is equal to slice_pic_parameter_set_id.

[0238] slice_subpic_id specifies the value of subpic_id of the sub-picture in which the slice is spatially located. When not present, the value of slice_subpic_id is inferred to be equal to 0. The length of the syntax element is Ceil(Log2(max_subpics_minus1)) bits.

[0239] slice_address specifies the slice address of the slice. When not present, the value of slice_address is inferred to be equal to 0. If subpics_present_flag is equal to 0, slice_address represents the slice address of the slice relative to the picture, otherwise, if subpics_present_flag is equal to 1, slice_adress represents the slice address of the slice relative to the subpicture with subpicture ID equal to slice_subpic_id.

[0240] If rect_slice_flag is equal to 0, the following applies:

[0241] The slice address is the brick ID specified by equation (7-59)

[0242] The length of slice_address is Ceil(Log2(NumBricksInPic)) bits.

[0243] The value of slice_address should be in the range of 0 to NumBricksInPic-1 (inclusive).

[0244] Otherwise (rect_slice_flag is equal to 1), the following applies:

[0245]

[0246] The length of slice_address is Ceil(Log2(NumBricksInPic - NumSubpics)) bits.

[0247]

[0248] Bitstream conformance is required which imposes the following constraints:

[0249]

[0250] When rect_slice_flag is equal to 0, the slices of the picture shall be in increasing order of their slice_address values.

[0251] The shape of the slices of a picture shall be such that each tile, when decoded, shall have its entire left border and its entire top border either inclusive of the picture border or inclusive of the border of the previously decoded tile.

[0252] num_bricks_in_slice_minus1, when present, specifies the number of bricks in the slice minus 1. The value of num_bricks_in_slice_minus1 shall be in the range of 0 to NumBricksInPic-1, inclusive. When rect_slice_flag is equal to 0 and single_brick_per_slice_flag is equal to 1, the value of num_bricks_in_slice_minus1 is inferred to be equal to 0. When single_brick_per_slice_flag is equal to 1, the value of num_bricks_in_slice_minus1 is inferred to be equal to 0.

[0253] The variables NumBricksInCurrSlice (which specifies the number of bricks in the current slice) and SliceBrickIdx[i] (which specifies the brick index of the i-th brick in the current slice) are derived as follows:

[0254]

[0255]

[0256] End text.

Claims

1. A method (600) performed by a decoder, the method include: receiving (s602) a coded video stream CVS; as well as processing (s604) the CVS, wherein: The CVS includes a slice header, the slice header including a first codeword, the first codeword encoding a first value representing a first portion of a slice address, wherein the first value is a sub-picture ID indicating a sub-picture to which the slice belongs, The slice header comprises a second codeword encoding a second value representing a second portion of the slice address, wherein the second value is a local slice address indicating a spatial location of the slice relative to a location of a sub-picture to which the slice belongs, and The slice address specifies the spatial location of the slice within the picture. Wherein, the method further comprises: deriving the slice address using the first value and the second value; and decoding the slice using the slice address, Wherein, deriving the slice address from the first value and the second value comprises: derive a mapping list from the syntax elements in the parameter set; mapping a specific value to a mapping value different from the specific value using the mapping list, wherein the specific value is included in one of the first value or the second value; and The slice address is derived using the mapping value.

2. The method according to claim 1, in, Processing the CVS includes: decoding the first value from the first codeword; and The second value is decoded from the second codeword.

3. The method according to claim 1, in, The method further comprises: decoding a third value from a third codeword, the third value representing a third portion of the chip address, and the third portion of the chip address representing an address in a second level, the second level being lower than the first level; and The slice address is derived using the first value, the second value, and the third value.

4. The method according to claim 3, in, The method further comprises: decoding a fourth value from a fourth codeword, the fourth value representing a fourth portion of the chip address, wherein the fourth portion of the chip address represents an address in a third level, wherein the first level is higher than the second level and the second level is higher than the third level; and The slice address is derived using the first value, the second value, the third value, and the fourth value.

5. The method according to any one of claims 2 to 4, further comprising deriving a number N from a codeword in the CVS, in: The step of decoding the first value or the second value comprises decoding a fixed number N bits from the CVS.

6. The method according to claim 5, in: The number N represents the number of second-level partitions in the picture, or The number N represents the maximum number of partitions of the second level in the picture.

7. The method according to claim 1, further comprising: include: Decode a flag value from a flag in a parameter set to which the CVS refers, wherein: If the flag value is equal to the first value, there is only one slice in each sub-picture in the CVS, and If the flag value is equal to the second value, more than one slice can exist in the sub-picture in the CVS.

8. A computer program product (843) comprising instructions (844) which, when executed by a processing circuit (802), cause the processing circuit (802) to perform the method according to any one of claims 1 to 7.

9. A decoding device (800), include: Processing circuit (802); as well as A memory (842) comprising instructions executable by the processing circuit (802) to cause the decoding device to perform the method according to any one of claims 1 to 7.

Images