Indication of one slice per subpicture in subpicture-based video coding

Abstract

To provide an improved compression and decompression method, system, encoding device, terminal, and data structure that increase compression ratios with little or no sacrifice in image quality.SOLUTION: A method for video decoding includes receiving a bitstream including a picture parameter set (PPS) including a single slice per subpicture flag, and determining whether the single slice per subpicture flag has a first value or a second value. The first value specifies that each subpicture referring to the PPS includes only one rectangular slice, and the second value specifies that each subpicture referring to the PPS may include one or more rectangular slices. The method also includes decoding the only one rectangular slice when the single slice per subpicture flag has the first value, or the one or more rectangular slices when the single slice per subpicture flag has the second value.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This patent application claims the benefit of U.S. Provisional Patent Application No. 62 / 904,481, filed September 23, 2019, by Ye-Kui Wang., et al., entitled "Indication of One Slice Per Subpicture in Subpicture-Based Video Coding," and U.S. Provisional Patent Application No. 62 / 905,122, filed September 24, 2019, by Ye-Kui Wang., et al., entitled "Indication of One Slice Per Subpicture in Subpicture-Based Video Coding," both of which are incorporated herein by reference.

[0002] [Technical field] FIELD This disclosure relates generally to video coding, and more particularly to signaling instructions in sub-picture-based video coding. [Background technology]

[0003] The amount of video data required to represent even a relatively short video can be considerable, and as a result, problems can arise when the data is to be streamed or otherwise communicated over communication networks with limited bandwidth capacity. Thus, video data is typically compressed before being communicated over today's telecommunications networks. Video size can also be an issue when the video is stored on a storage device, as memory resources may be limited. Video compression devices often use software and / or hardware at the source to code the video data before transmission or storage, thereby reducing the amount of data needed to represent a digital video image. The compressed data is then received at the destination by a video decompression device, which decodes the video data. Due to limited network resources and increasing demands for higher video quality, improved compression and decompression techniques are desired that increase compression ratios with little to no sacrifice in image quality. Summary of the Invention

[0004] A first aspect relates to a method implemented by a decoder, the method comprising: receiving, by the decoder, a bitstream including a picture parameter set (PPS) including a single slice per sub-picture flag; determining, by the decoder, whether the single slice per sub-picture flag has a first value or a second value, where the first value specifies that each sub-picture that references the PPS includes only one rectangular slice and the second value specifies that each sub-picture that references the PPS may include one or more rectangular slices; and decoding, by the decoder, the only rectangular slice if the single slice per sub-picture flag has the first value, or the one or more rectangular slices if the single slice per sub-picture flag has the second value, to obtain a decoded picture.

[0005] The method provides a technique that uses a flag in a bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements that signal the number and layout of subpictures (e.g., the position and size of each subpicture) can be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, thereby reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or displayed.

[0006] Optionally, in any of the above aspects, another implementation of the aspect provides that the single slice per subpicture flag is specified as pps_single_slice_per_subpic_flag.

[0007] Optionally, in any of the above embodiments, another implementation of the embodiment provides that the first value is one (1) and the second value is zero (0).

[0008] Optionally, in any of the above aspects, another implementation of the aspect provides that the PPS further includes a number of slices in picture flag, and the value of the number of slices in picture flag plus 1 specifies the number of slices in each picture that references the PPS.

[0009] Optionally, in any of the above aspects, another implementation of the aspect provides that the number of slices in picture flag is specified as pps_num_slices_in_pic_minus1.

[0010] Optionally, in any of the above aspects, another implementation of the aspect provides that each sub-picture comprises a rectangular region of one or more slices within the picture.

[0011] Optionally, in any of the above aspects, another implementation of the aspect provides generating an image for display based on only one rectangular slice if the single slice per sub-picture flag has a first value, and based on one or more rectangular slices if the single slice per sub-picture flag has a second value.

[0012] A second aspect relates to a method implemented by an encoder, the method comprising: setting, by the encoder, a single slice per sub-picture flag to a first value if each sub-picture referencing a picture parameter set (PPS) contains only one rectangular slice, and to a second value if each sub-picture referencing the PPS may contain one or more rectangular slices; encoding, by the encoder, the PPS containing the single slice per sub-picture flag into a bitstream; and storing, by the encoder, the bitstream for communication to a decoder.

[0013] The method provides a technique that uses a flag in a bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements that signal the number and layout of subpictures (e.g., the position and size of each subpicture) can be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, thereby reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or displayed.

[0014] Optionally, in any of the above aspects, another implementation of the aspect provides that the single slice per subpicture flag is specified as pps_single_slice_per_subpic_flag.

[0015] Optionally, in any of the above embodiments, another implementation of the embodiment provides that the first value is one (1) and the second value is zero (0).

[0016] Optionally, in any of the above aspects, another implementation of the aspect provides that the PPS further includes a number of slices in picture flag, and the value of the number of slices in picture flag plus 1 specifies the number of slices in each picture that references the PPS.

[0017] Optionally, in any of the above aspects, another implementation of the aspect provides that the number of slices in picture flag is specified as pps_num_slices_in_pic_minus1.

[0018] Optionally, in any of the above aspects, another implementation of the aspect provides that each sub-picture comprises a rectangular region of one or more slices within the picture.

[0019] Optionally, in any of the above aspects, another implementation of the aspect provides transmitting the bitstream to a video decoder.

[0020] A third aspect relates to a decoding device having: a receiver configured to receive a bitstream including a picture parameter set (PPS) including a single slice per sub-picture flag; a memory coupled to the receiver and storing instructions; and a processor coupled to the memory, wherein the processor executes the instructions to cause the decoding device to determine whether the single slice per sub-picture flag has a first value or a second value, where the first value specifies that each sub-picture that references the PPS includes only one rectangular slice and the second value specifies that each sub-picture that references the PPS may include one or more rectangular slices; and decoding the only rectangular slice if the single slice per sub-picture flag has the first value, or one or more rectangular slices if the single slice per sub-picture flag has the second value, to obtain a decoded picture.

[0021] A decoding device provides a technique that uses a flag in a bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements that signal the number and layout of subpictures (e.g., the position and size of each subpicture) can be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, thereby reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or displayed.

[0022] Optionally, in any of the above embodiments, another implementation of the embodiment provides that the first value is one (1) and the second value is zero (0).

[0023] Optionally, in any of the above aspects, another implementation of the aspect provides that the PPS further includes a number of slices in picture flag, and the value of the number of slices in picture flag plus 1 specifies the number of slices in each picture that references the PPS.

[0024] Optionally, in any of the above aspects, another implementation of the aspect provides that the number of slices in picture flag is specified as pps_num_slices_in_pic_minus1.

[0025] Optionally, in any of the above aspects, another implementation of the aspect provides that the processor is further configured to generate an image for display based on only one rectangular slice if the single slice per sub-picture flag has a first value, and based on one or more rectangular slices if the single slice per sub-picture flag has a second value.

[0026] A fourth aspect relates to an encoding device having a memory including instructions; a processor coupled to the memory, the processor configured to execute the instructions to cause the encoding device to encode a bitstream including a picture parameter set (PPS) including a single slice per subpicture flag, and to set the single slice per subpicture flag to a first value if each subpicture referencing the PPS includes only one rectangular slice, and to a second value if each subpicture referencing the PPS may include one or more rectangular slices; and a transmitter coupled to the processor and configured to transmit the bitstream to a video decoder.

[0027] A coding device provides a technique that uses a flag in a bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements that signal the number and layout of subpictures (e.g., the position and size of each subpicture) can be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or displayed.

[0028] Optionally, in any of the above embodiments, another implementation of the embodiment provides that the first value is one (1) and the second value is zero (0).

[0029] Optionally, in any of the above aspects, another implementation of the aspect provides that the PPS further includes a number of slices in picture flag, and the value of the number of slices in picture flag plus 1 specifies the number of slices in each picture that references the PPS.

[0030] Optionally, in any of the above aspects, another implementation of the aspect provides that the number of slices in picture flag is specified as pps_num_slices_in_pic_minus1.

[0031] Optionally, in any of the above aspects, other implementations of the aspect provide for storing the bitstream in a memory before transmitting the bitstream to the decoder.

[0032] A fifth aspect relates to a coding apparatus including: a receiver configured to receive pictures to be encoded or to receive a bitstream to be decoded, a transmitter coupled to the receiver and configured to transmit the bitstream to a decoder or to transmit decoded images to a display, a memory coupled to at least one of the receiver or the transmitter and configured to store instructions, and a processor coupled to the memory and configured to execute the instructions stored in the memory to perform any of the methods disclosed herein.

[0033] The coding device provides a technique that uses a flag in the bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements that signal the number and layout of subpictures (e.g., the position and size of each subpicture) can be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, reducing the utilization of memory, processor, and network resources and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practice, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or displayed.

[0034] Optionally, in any of the above aspects, another implementation of the aspect provides a display configured to display the decoded picture.

[0035] A sixth aspect relates to a system including an encoder and a decoder in communication with the encoder, the encoder or decoder including a decoding device, encoding device, or coding apparatus disclosed herein.

[0036] The system provides a technique that uses a flag in the bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements that signal the number and layout of subpictures (e.g., the position and size of each subpicture) can be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or displayed.

[0037] A seventh aspect relates to a means for coding, the means for coding including receiving means configured to receive a picture to be encoded or to receive a bitstream to be decoded, transmitting means coupled to the receiving means and configured to transmit the bitstream to the decoding means or to transmit a decoded image to the display means, storage means coupled to at least one of the receiving means or the transmitting means and configured to store instructions, and processing means coupled to the storage means and configured to execute the instructions stored in the storage means to perform any of the methods disclosed herein.

[0038] The coding means provides a technique that uses a flag in a bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements that signal the number and layout of subpictures (e.g., the position and size of each subpicture) can be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practice, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or displayed.

[0039] For clarity, any one of the above embodiments may be combined with any one or more of the other above embodiments to create new embodiments within the scope of the present disclosure.

[0040] These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

[0041] For a more complete understanding of the present disclosure, reference is now made to the following brief description taken in conjunction with the accompanying drawings and detailed description, in which like reference numerals represent like parts. [Brief explanation of the drawings]

[0042] [Figure 1] 1 is a flowchart of an example method for coding a video signal. [Figure 2]1 is a schematic diagram of an example encoding and decoding (codec) system for video coding. [Figure 3] FIG. 1 is a schematic diagram illustrating an example video encoder. [Figure 4] FIG. 1 is a schematic diagram illustrating an example video decoder. [Figure 5] 1 is a schematic diagram illustrating an example of a bitstream containing an encoded video sequence. [Figure 6] 1 is an embodiment of a method for decoding a coded video bitstream. [Figure 7] 1 is an embodiment of a method for encoding a coded video bitstream. [Figure 8] 1 is a schematic diagram of a video coding device. [Figure 9] FIG. 1 is a schematic diagram of an embodiment of a means for coding. DETAILED DESCRIPTION OF THE INVENTION

[0043] It should be understood at the outset that, although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods may be implemented using any number of technologies, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and technologies described below, including the exemplary designs and implementations shown and described herein, but may vary within the scope of the appended claims along with their full range of equivalents.

[0044] The following terms are defined as follows, unless used herein in a contrary context. Specifically, the following definitions are intended to bring further clarity to the present disclosure. However, terms may be described differently in different contexts. Therefore, the following definitions should be considered supplemental and not limiting of any other definitions given for such terms herein.

[0045] A bitstream is a sequence of bits containing video data that has been compressed for transmission between an encoder and a decoder. An encoder is a device configured to compress video data into a bitstream using an encoding process. A decoder is a device configured to reconstruct video data from a bitstream for display using a decoding process. A picture is an array of luma samples and / or chroma samples that generate a frame or a field thereof. A picture being encoded or decoded may be referred to as a current picture for clarity of discussion. A reference picture is a picture containing reference samples that may be used when coding other pictures by reference according to inter-prediction and / or inter-layer prediction. A reference picture list is a reference picture list used for inter-prediction and / or inter-layer prediction. Some video coding systems utilize two reference picture lists, which may be referred to as Reference Picture List 1 and Reference Picture List 0. A reference picture list structure is an addressable syntax structure that contains multiple reference picture lists. Inter-prediction is a mechanism for coding a sample of a current picture by referencing an indicated sample in a reference picture different from the current picture when the reference picture and the current picture are in the same layer. A reference picture list structure entry is an addressable location in a reference picture list structure that indicates a reference picture associated with the reference picture list. A slice header is a portion of a coded slice that contains data elements related to all video data within a tile represented by the slice. A slice includes four sides connected at right angles. The four sides include two pairs of parallel sides. Furthermore, the sides of a pair of parallel sides are equal in length. As such, a slice can be any rectangular shape, and a square is a special case of a rectangle in which all four sides are equal in length. A rectangular slice is a slice with two pairs of parallel sides, each of which is equal in length, but one pair of parallel sides is longer than the other pair of parallel sides.A sequence parameter set (SPS) is a parameter set that contains data about a sequence of pictures. A picture parameter set (PPS) is a syntax structure that contains syntax elements that apply across zero or more coded pictures as determined by the syntax elements included in each picture header.

[0046] A flag is a variable or single-bit syntax element that can take one of two possible values, 0 and 1. A subpicture is a rectangular region of one or more slices within a picture. A subpicture identifier (ID) is a number, letter, or other indicia that uniquely identifies a subpicture. A subpicture ID (also known as a tile identifier) ​​is used to identify a specific subpicture with a subpicture index, which may be referred to herein as subpicture ID mapping.

[0047] An access unit (AU) is a set of one or more coded pictures associated with the same latency (e.g., the same picture order count) for output from the decoded picture buffer (DPB) (e.g., for display to a user). An access unit delimiter (AUD) is an indicator or data structure used to mark the start of an AU or the boundary between AUs. A decoded video sequence is a series of pictures reconstructed by a decoder for display to a user.

[0048] A coded video sequence (CVS) is a series of access units (AUs) that includes, in decoding order, a coded video sequence start (CVSS) AU followed by zero or more AUs that are not CVSS AUs, including all subsequent AUs up to but not including any subsequent AUs that are CVSS AUs. A CVSS AU is an AU in which a prediction unit (PU) exists for each layer specified by a video parameter set (VPS), and the coded picture in each PU is a coded layer video sequence start (CLVSS) picture. In an embodiment, each picture is within an AU. A PU is a set of network abstraction layer (NAL) units that are related to each other according to specified classification rules, are consecutive in decoding order, and contain exactly one coded picture.

[0049] The following acronyms are used herein: Adaptive Loop Filter (ALF), Coding Tree Block (CTB), Coding Tree Unit (CTU), Coding Unit (CU), Coded Video Sequence (CVS), Joint Video Experts Team (JVET), Motion-Costrained Tile Set (MCTS), Maximum Transfer Unit (MTU), Network Abstraction Layer (NAL), Picture Order Count (POC), Picture Parameter Set (PPS), Raw Byte Sequence Payload (RBSP), Sample Adaptive Offset (SAO), Sequence Parameter Set (SPS), Temporal Motion Vector Prediction (TMVP), Versatile Video Coding (VVC), and Working Draft (WD).

[0050] Many video compression techniques may be used to reduce the size of video files with minimal data loss. For example, video compression techniques may include performing spatial (e.g., intra-picture) prediction and / or temporal (e.g., inter-picture) prediction to reduce or remove data redundancy within a video sequence. For block-based video coding, video slices (e.g., video pictures or portions of video pictures) may be partitioned into video blocks, which may also be referred to as tree blocks, coding tree blocks (CTBs), coding tree units (CTUs), coding units (CUs), and / or coding nodes. Video blocks within an intra-coded (I) slice of a picture are coded using spatial prediction with respect to reference samples in neighboring blocks within the same picture. Video blocks within an inter-coded unidirectionally predicted (P) or bidirectionally predicted (B) slice of a picture may be coded using spatial prediction with respect to reference samples in neighboring blocks within the same picture or temporal prediction with respect to reference samples in other reference pictures. A picture may also be referred to as a frame and / or an image, and may also be referred to as a reference picture, reference frame, and / or reference image. Spatial or temporal prediction results in a predictive block representing an image block. Residual data represents pixel differences between the original image block and the predictive block. Thus, inter-coded blocks are coded according to a motion vector pointing to a block of reference samples forming the predictive block and residual data indicating the difference between the coded block and the predictive block. Intra-coded blocks are coded according to an intra-coding mode and the residual data. For further compression, the residual data may be transformed from the picture domain to a transform domain, resulting in residual transform coefficients, which may be quantized. The quantized transform coefficients may initially be arranged in a two-dimensional array. The quantized transform coefficients may be scanned to generate a one-dimensional vector of transform coefficients. Entropy coding may be applied to achieve even greater compression.Such video compression techniques are discussed in further detail below.

[0051] To ensure that the encoded video can be accurately decoded, the video is encoded and decoded according to a corresponding video coding standard, such as International Telecommunication Union (ITU) Standardization Sector (ITU-T) H.261, International Organization for Standardization / International Electrotechnical Commission (ISO / IEC) Motion Picture Experts Group (MPEG)-1 Part 2, Advanced Video Coding (AVC), also known as ITU-T H.262 or ISO / IEC MPEG-2 Part 2, ITU-T H.263, ISO / IEC MPEG-4 Part 2, ITU-T H.264 or ISO / IEC MPEG-4 Part 10, and High Efficiency Video Coding (HEVC), also known as ITU-T H.265 or MPEG-H Part 2. AVC includes extensions such as Scalable Video Coding (SVC), Multiview Video Coding (MVC), and Multiview Video Coding plus Depth (MVC+D), as well as three-dimensional (3D) AVC (3D-AVC). HEVC includes extensions such as Scalable HEVC (SHVC), Multiview HEVC (MV-HEVC), and 3D HEVC (3D-HEVC).

[0052] There is also a new video coding standard named Versatile Video Coding (VVC) being developed by the Joint Video Experts Team (JVET) of ITU-T and ISO / IEC. The VVC standard has several working drafts, but one working draft (WD) of VVC in particular, namely, B. Bross, J. Chen, and S. Liu, “Versatile Video Coding (Draft 5)”, JVET-N1001-v3, 13th JVET Meeting, March 27, 2019 (VVC Draft 5), is referenced here.

[0053] HEVC includes four different picture partitioning schemes: regular slice, dependent slice, tile, and Wavefront Parallel Processing (WPP), which can be applied for Maximum Transfer Unit (MTU) size matching, parallel processing, and end-to-end delay reduction.

[0054] Regular slices are similar to those 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, regular slices can be reconstructed independently of other regular slices in the same picture (although interdependencies may still exist due to loop filtering operations).

[0055] Regular slices are the only tool available for parallelization that can be applied in virtually the same way in H.264 / AVC. Parallelization based on regular slices does not require much inter-processor or inter-core communication (except for inter-processor or inter-core data sharing for motion compensation when decoding predictively coded pictures, which is usually much heavier than inter-processor or inter-core data sharing with intra-picture prediction). However, for the same reason, using regular slices can incur significant coding overhead due to the bit cost of slice headers and the lack of prediction across slice boundaries. Furthermore, regular slices (in contrast to other tools described below) also serve as an important mechanism for bitstream partitioning to match MTU size requirements, due to their intra-picture independence and the fact that each regular slice is encapsulated in its own NAL unit. In many cases, the goals of parallelization and MTU size matching pose conflicting requirements on the slice layout within a picture. The realization of this situation led to the development of the parallelization tools described below.

[0056] Dependent slices have short slice headers and allow for bitstream partitioning at treeblock boundaries without breaking any intra-picture prediction. Essentially, dependent slices provide fragmentation of regular slices into multiple NAL units to provide end-to-end delay reduction by allowing portions of a regular slice to be transmitted before the coding of the entire regular slice is finished.

[0057] In WPP, a picture is partitioned into single rows of coding treeblocks (CTBs). Entropy decoding and prediction can use data from CTBs in other partitions. Parallel processing is possible through parallel decoding of CTB rows; the start of decoding of a CTB row is delayed by two CTBs to ensure that data for the CTB above and to the left of the target CTB is available before the target CTB is decoded. This staggered start (graphically represented as a wavefront) allows parallelization using up to as many processors / cores as there are CTB rows in the picture. Because intra-picture prediction is possible between adjacent treeblock rows within a picture, the amount of inter-processor / inter-core communication required to enable intra-picture prediction can be significant. Because WPP partitioning does not result in the generation of additional NAL units compared to when it is not applied, WPP is not a tool for MTU size matching. However, if MTU size matching is required, regular slicing can be used with WPP, with certain coding overhead.

[0058] Tiles define horizontal and vertical boundaries that partition a picture into tile columns and rows. The scan order of the CTBs is changed to be local within a tile (in the tile's CTB raster scan order) before decoding the top-left CTB of the next tile in the picture's tile raster scan order. Like regular slices, tiles break intra-picture prediction dependencies in addition to entropy decoding dependencies. However, they do not need to be included in individual NAL units (similar to WPP in this respect), and therefore tiles cannot be used for MTU size matching. Each tile can be processed by one processor / core, and the inter-processor / inter-core communication required for intra-picture prediction between processing units decoding adjacent tiles is limited to the transmission of a shared slice header if the slice spans more than one tile and the sharing of reconstructed samples and metadata related to loop filtering. When more than one tile or WPP segment is included in a slice, the entry point byte offset for each tile or WPP segment in the slice except the first one is signaled in the slice header.

[0059] For simplicity, HEVC specifies restrictions on the application of four different picture partitioning schemes. A given coded video sequence cannot contain both tiles and wavefronts for most of the profiles specified in HEVC. For each slice and tile, one or both of the following conditions should be satisfied: 1) all coded treeblocks in a slice belong to the same tile; 2) all coded treeblocks in a tile belong to the same slice. Finally, a wavefront segment contains only one CTB row, and when WPP is used, if a slice starts in a CTB row, it should end in the same CTB row.

[0060] A recent amendment to HEVC is specified in 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),” Oct. 24, 2017, available at http: / / phenix.int-evry.fr / jct / doc_end_user / documents / 29_Macau / wg11 / JCTVC-AC1005-v2.zip. With the inclusion of this amendment, HEVC specifies three MCTS-related Supplemental Enhancement Information (SEI) messages: the Temporal MCTS SEI message, the MCTS Extraction Information Set SEI message, and the MCTS Extraction Information Nest SEI message.

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

[0062] The MCTS Extraction Information Set SEI message provides supplemental information that can be used in 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, where each extraction information set defines the number of an MCTS set and includes the RBSP bytes of the replacement video parameter set (VPS), SPS, and PPS 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, since one or all of the syntax elements related to slice addresses (including first_slice_segment_in_pic_flag and slice_segment_address) usually need to have different values.

[0063] In the latest VVC draft specification, a picture can be partitioned into multiple sub-pictures. Each sub-picture covers a rectangular area and contains an integer number of complete slices. The sub-picture partitioning persists across all pictures in a coded video sequence, and the partitioning information (i.e., the location and size of the sub-pictures) is signaled in the SPS. A sub-picture can be indicated as being coded without using sample values ​​from any other sub-picture for motion compensation.

[0064] In JVET contribution JVET-O0141, publicly available at http: / / phenix.it-sudparis.eu / jvet / doc_end_user / documents / 13_Marrakech / wg11 / JVET-M0261-v1.zip, the subpicture design is similar to that in the latest VVC draft specification, with some differences. One difference is the signaling of subpicture IDs in each slice header to enable subpicture-based subbitstream extraction without the need to modify the coded slice NAL, in addition to the explicit signaling of subpicture IDs per subpicture in the SPS. In this approach, the subpicture ID of each subpicture remains constant across all pictures in the CVS.

[0065] In a common use case, each subpicture contains only one slice. However, the ability to indicate the common use case is lacking or missing. This is unfortunate. In fact, knowing that each subpicture contains only one slice can be useful. For example, if the layout of the slices in a picture is known, the bits to signal the subpicture layout can be omitted entirely from the bitstream if the subpicture layout is to be exactly the same as the slice layout.

[0066] Disclosed herein is a technique that uses a flag in a bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements that signal the number and layout of subpictures (e.g., the position and size of each subpicture) can be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, thereby reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practice, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or displayed.

[0067] 1 is a flowchart of an exemplary operational method 100 for coding a video signal. Specifically, a video signal is encoded by an encoder. The encoding process compresses the video signal by using various mechanisms to reduce the video file size. The smaller file size allows the compressed video file to be transmitted to a user while reducing the associated bandwidth overhead. A decoder then decodes the compressed video file to reconstruct the original video signal for display to the end user. The decoding process generally mirrors the encoding process to allow the decoder to consistently reconstruct the video signal.

[0068] In step 101, a video signal is input to an encoder. For example, the video signal may be an uncompressed video file stored in memory. As another example, the video file may be captured by a video capture device such as a video camera and encoded to support live streaming of the video. The video file may include both an audio component and a video component. The video component includes a series of image frames that, when viewed sequentially, create the effect of visual movement. A frame includes pixels represented in terms of light, referred to herein as luma components (or luma samples), and pixels represented in terms of color, referred to herein as chroma components (or color samples). In some examples, the frame may also include depth values ​​to support three-dimensional viewing.

[0069] In step 103, the video is partitioned into blocks. Partitioning involves subdividing pixels within each frame into square and / or rectangular blocks for compression. For example, in High Efficiency Video Coding (HEVC) (also known as H.265 and MPEG-H Part 2), a frame may first be divided into coding tree blocks (CTUs), which are blocks of a predefined size (64 pixels by 64 pixels). CTUs contain both luma and chroma samples. The coding tree may be used to divide the CUT into blocks and then recursively subdivide the blocks until a structure that supports further encoding is achieved. For example, the luma component of a frame may be subdivided until each block contains relatively homogeneous luminance values. Furthermore, the chroma component of a frame may be subdivided until each block contains relatively homogeneous color values. Thus, the partitioning mechanism varies depending on the content of the video frame.

[0070] In step 105, various compression mechanisms are used to compress the image blocks partitioned in step 103. For example, inter-prediction and / or intra-prediction may be used. Inter-prediction is designed to take advantage of the fact that objects in a common scene tend to appear in consecutive frames. Thus, a block representing an object in a reference frame need not be repeatedly described in adjacent frames. Specifically, an object such as a table may remain in a constant position across multiple frames. Thus, the table may be described once, and adjacent frames may reference the reference frame. A pattern matching mechanism may be used to match objects across multiple frames. Furthermore, a moving object may be represented across multiple frames, for example, due to object motion or camera motion. As a specific example, a video may show a car moving across the screen across multiple frames. Motion vectors may be used to describe such motion. A motion vector is a two-dimensional vector that provides an offset from the coordinates of an object in one frame to the coordinates of the object in the reference frame. As such, inter-prediction may encode an image block in a current frame as a set of motion vectors indicating an offset from a corresponding block in a reference frame.

[0071] Intra prediction encodes blocks within a common frame. Intra prediction takes advantage of the fact that luma and chroma components tend to cluster within a frame. For example, a green patch in a part of a tree tends to be located adjacent to similar patches of green. Intra prediction uses multiple directional prediction modes (e.g., 33 in HEVC), planar mode, and direct current (DC) mode. Directional mode indicates that the current block is similar / the same as samples of neighboring blocks in the corresponding direction. Planar mode indicates that a series of blocks along a row / column (e.g., a plane) can be interpolated based on neighboring blocks at the end of the row. Planar mode effectively indicates a smooth transition of light / color across the row / column by using a relatively constant slope of changing values. DC mode is used for boundary smoothing and indicates that the block is similar / the same as the average value associated with samples of all neighboring blocks associated with the angular direction of the directional prediction mode. Thus, intra prediction blocks can represent image blocks as various associated prediction mode values ​​instead of their actual values. Furthermore, inter-predicted blocks can represent image blocks as motion vector values ​​instead of actual values. In either case, the predicted blocks may not accurately represent the image blocks in some cases. Any differences are stored in the residual blocks. Transforms may be applied to the residual blocks to further compress the file.

[0072] Various filtering techniques may be applied in step 107. In HEVC, filters are applied according to an in-loop filtering scheme. The block-based prediction described above can cause blocky images to be generated at the decoder. Furthermore, block-based prediction schemes may encode blocks and then reconstruct the encoded blocks for later use as reference blocks. In-loop filtering schemes iteratively apply noise suppression filters, deblocking filters, adaptive loop filters, and sample adaptive offset (SAO) filters to blocks / frames. These filters mitigate such blocking artifacts so that the encoded file can be accurately reconstructed. Furthermore, these filters mitigate artifacts in the reconstructed reference blocks so that the artifacts are less likely to cause further artifacts in subsequent blocks that are coded based on the reconstructed reference blocks.

[0073] Once the video signal has been partitioned, compressed, and filtered, the resulting data is encoded into a bitstream at step 109. The bitstream includes the above data in addition to any signaling data desired to support proper video signal reconstruction at the decoder. For example, such data may include partition data, prediction data, residual blocks, and various flags that provide coding instructions to the decoder. The bitstream may be stored in memory for transmission to decoders upon request. The bitstream may also be broadcast and / or multicast to multiple decoders. Generating the bitstream is an iterative process. Thus, steps 101, 103, 105, 107, and 109 may occur sequentially and / or simultaneously across multiple frames and blocks. The order shown in FIG. 1 is presented for clarity and ease of discussion and is not intended to limit the video coding process to any particular order.

[0074] The decoder receives the bitstream and begins the decoding process at step 111. Specifically, the decoder uses an entropy decoding scheme to convert the bitstream into corresponding syntax and video data. The decoder uses syntax data from the bitstream to determine the frame partitions at step 111. The partitioning should match the results of the block partitioning at step 103. The entropy encoding / decoding used at step 111 will now be described. The encoder makes many choices during the compression process, such as selecting a block partitioning scheme from several possible choices based on the spatial location of values ​​within the input image. Signaling the exact choice may use a number of bins. As used herein, a bin is a binary value treated as a variable (e.g., a bit value that can change depending on the situation). Entropy coding allows the encoder to discard any options that are clearly not feasible for a particular case, while retaining a set of acceptable options. Each acceptable option is then assigned a codeword. The length of the codeword is based on the number of allowable choices (e.g., one bin for two choices, two bins for three to four choices, etc.). The encoder then encodes the codeword for the selected choice. This scheme reduces the size of the codeword in that the codeword is as large as desired to uniquely indicate a choice from a small subset of allowable choices, as opposed to uniquely indicating a choice from a potentially large set of all possible choices. The decoder then decodes the choice by determining the set of allowable choices in a similar manner to the encoder. By determining the set of allowable choices, the decoder can read the codeword and determine the choice made by the encoder.

[0075] In step 113, the decoder performs block decoding. Specifically, the decoder uses an inverse transform to generate a residual block. The decoder then uses the residual block and the corresponding prediction block to reconstruct an image block according to the partitioning. The prediction block may include both intra-predicted blocks and inter-predicted blocks generated in the encoder in step 105. The reconstructed image block is then positioned within a frame of the reconstructed video signal according to the partitioning data determined in step 111. The syntax for step 113 may also be signaled in the bitstream via entropy coding, as described above.

[0076] At step 115, filtering is performed on the frames of the reconstructed video signal in a manner similar to step 107 in the encoder. For example, a noise suppression filter, a deblocking filter, an adaptive loop filter, and an SAO filter may be applied to the frames to remove blocking artifacts. Once the frames have been filtered, the video signal may be output to a display at step 117 for viewing by an end user.

[0077] 2 is a schematic diagram of an exemplary encoding and decoding (codec) system 200 for video coding. Specifically, codec system 200 provides functionality to support the implementation of operational method 100. Codec system 200 is generalized to represent components used in both encoders and decoders. Codec system 200 receives and partitions a video signal, as described with respect to steps 101 and 103 of operational method 100, resulting in a partitioned video signal 201. Codec system 200 then compresses partitioned video signal 201 into a coded bitstream when operating as an encoder, as described with respect to steps 105, 107, and 109 of method 100. When operating as a decoder, codec system 200 generates an output video signal from the bitstream, as described with respect to steps 111, 113, 115, and 117 of operational method 100. Codec system 200 includes a general coder control component 211, a transform scaling and quantization component 213, an intra-picture estimation component 215, an intra-picture prediction component 217, a motion compensation component 219, a motion estimation component 221, a scaling and inverse transform component 229, a filter control analysis component 227, an in-loop filter component 225, a decoded picture buffer component 223, and a header formatting and context-adaptive binary arithmetic coding (CABAC) component 231. These components are coupled as shown. In FIG. 2, black lines indicate the movement of data to be encoded / decoded, while dashed lines indicate the movement of control data that controls the operation of other components. An encoder may include all of the components of codec system 200. A decoder may include a subset of the components of codec system 200.For example, the decoder may include an intra-picture prediction component 217, a motion compensation component 219, a scaling and inverse transform component 229, an in-loop filter component 225, and a decoded picture buffer component 223. These components will now be described.

[0078] The partitioned video signal 201 is a captured video sequence that has been partitioned into blocks of pixels by a coding tree. The coding tree uses various partitioning modes to subdivide the blocks of pixels into smaller blocks of pixels. These blocks may then be further subdivided into smaller blocks. Blocks are sometimes referred to as nodes on the coding tree. Larger parent nodes are partitioned into smaller child nodes. The number of times a node is subdivided is referred to as the depth of the node / coding tree. The partitioned blocks may be included in a coding unit (CU) in some cases. For example, a CU can be a subpart of a CTU that includes a luma block, a red differential chroma (Cr) block, and a blue differential chroma (Cb) block, along with the CU's corresponding syntax instructions. Partitioning modes may include a binary tree (BT), a ternary tree (TT), and a quad tree (QT), which are used to partition a node into two, three, or four child nodes, respectively, whose shape varies depending on the partitioning mode used. The partitioned video signal 201 is forwarded to a general coder control component 211, a transform scaling and quantization component 213, an intra-picture estimation component 215, a filter control analysis component 227, and a motion estimation component 221 for compression.

[0079] The generic coder control component 211 is configured to make decisions regarding the coding of images of a video sequence into a bitstream according to applicable constraints. For example, the generic coder control component 211 manages the optimization of bitrate / bitstream size versus reconstruction quality. Such decisions may be based on storage space / bandwidth availability and image resolution requirements. The generic coder control component 211 also manages buffer utilization in relation to transmission rate to mitigate buffer underrun and overrun issues. To manage these issues, the generic coder control component 211 manages partitioning, prediction, and filtering by other components. For example, the generic coder control component 211 may dynamically increase compression complexity to increase resolution and increase bandwidth utilization, or decrease compression complexity to decrease resolution and bandwidth utilization. Thus, the generic coder control component 211 controls other components of the codec system 200 to balance video signal reconstruction quality and bitrate concerns. The generic coder control component 211 generates control data that controls the operation of other components. The control data is also forwarded to the header formatting and CABAC component 231 to be encoded into the bitstream for signaling parameters for decoding at the decoder.

[0080] The partitioned video signal 201 is also sent to a motion estimation component 221 and a motion compensation component 219 for inter prediction. A frame or slice of the partitioned video signal 201 may be divided into multiple video blocks. The motion estimation component 221 and the motion compensation component 219 perform inter predictive coding of the received video blocks relative to one or more blocks in one or more reference frames to provide temporal prediction. The codec system 200 may perform multiple coding passes, for example, to select an appropriate coding mode for each block of video data.

[0081] The motion estimation component 221 and the motion compensation component 219 may be highly integrated but are depicted separately for conceptual purposes. Motion estimation, performed by the motion estimation component 221, is the process of generating motion vectors, which estimate the motion of video blocks. A motion vector may indicate, for example, the displacement of a coded object relative to a predictive block. A predictive block is a block that is found to closely match a block to be coded in terms of pixel differences. A predictive block is sometimes referred to as a reference block. Such pixel differences may be determined by sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. HEVC uses several coded objects, including CTUs, coding tree blocks (CTBs), and CUs. For example, a CTU may be divided into CTBs, which may then be divided into CBs for inclusion in a CU. A CU may be coded as a prediction unit (PU), which contains predictive data for the CU, and / or a transform unit (TU), which contains transformed residual data for the CU. The motion estimation component 221 generates motion vectors, PUs, and TUs by using rate-distortion analysis as part of a rate-distortion optimization process. For example, the motion estimation component 221 may determine multiple reference blocks, multiple motion vectors, etc. for a current block / frame and select the reference block, motion vector, etc. that has the best rate-distortion characteristics. The best rate-distortion characteristics balance both the quality of the video reconstruction (e.g., the amount of data loss due to compression) and the coding efficiency (e.g., the size of the final encoding).

[0082] In some examples, the codec system 200 may calculate values ​​for sub-integer pixel positions of reference pictures stored in the decoded picture buffer component 223. For example, the video codec system 200 may interpolate values ​​for quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference pictures. Accordingly, the motion estimation component 221 may perform motion search for full-pixel and fractional pixel positions and output motion vectors with fractional pixel accuracy. The motion estimation component 221 calculates motion vectors for PUs of video blocks in inter-coded slices by comparing the positions of the PUs with the positions of predictive blocks of the reference pictures. The motion estimation component 221 outputs the calculated motion vectors as motion data to the header formatting and CABAC component 231 and to the motion compensation component 219 for encoding.

[0083] The motion compensation performed by motion compensation component 219 may include fetching or generating a predictive block based on a motion vector determined by motion estimation component 221. Again, motion estimation component 221 and motion compensation component 219 may be functionally integrated in some examples. Upon receiving a motion vector for the PU of a current video block, motion compensation component 219 may find the location of the predictive block to which the motion vector points. A residual video block is then formed by subtracting pixel values ​​of the predictive block from pixel values ​​of the current video block being coded to form pixel difference values. Generally, motion estimation component 221 performs motion estimation on the luma component, and motion compensation component 219 uses the motion vector calculated based on the luma component for both the chroma and luma components. The predictive block and residual block are forwarded to transform scaling and quantization component 213.

[0084] The partitioned video signal 201 is also sent to an intra-picture estimation component 215 and an intra-picture prediction component 217. Like the motion estimation component 221 and the motion compensation component 219, the intra-picture estimation component 215 and the intra-picture prediction component 217 may be highly integrated but are represented separately for conceptual purposes. The intra-picture estimation component 215 and the intra-picture prediction component 217 intra-predict the current block relative to blocks within the current frame as an alternative to the inter-prediction performed by the motion estimation component 221 and the motion compensation component 219 between frames as described above. In particular, the intra-picture estimation component 215 determines the intra-prediction mode to use to encode the current block. In some examples, the intra-picture estimation component 215 selects an appropriate intra-prediction mode for encoding the current block from multiple tested intra-prediction modes. The selected intra-prediction mode is then forwarded to the header formatting and CABAC component 231 for encoding.

[0085] For example, the intra picture estimation component 215 may calculate rate-distortion values ​​for various tested intra prediction modes using a rate-distortion analysis and select the intra prediction mode with the best rate-distortion characteristics among the tested modes. The rate-distortion analysis typically determines the bit rate (e.g., number of bits) used to generate the coded block as well as the amount of distortion (or error) between the coded block and the original uncoded block coded to generate the coded block. The intra picture estimation component 215 may calculate a ratio from the distortion and rate for the various coded blocks to determine which intra prediction mode exhibits the best rate-distortion value for that block. Additionally, the intra picture estimation component 215 may be configured to code the depth blocks of the depth map using a depth modeling mode (DMM) based on rate-distortion optimization (RDO).

[0086] The intra-picture prediction component 217 may generate a residual block from the prediction block based on the selected intra-prediction mode determined by the intra-picture estimation component 215 if implemented in an encoder, or may read the residual block from the bitstream if implemented in a decoder. The residual block contains the value differences between the prediction block and the original block, represented as a matrix. The residual block is then forwarded to the transform scaling and quantization component 213. The intra-picture estimation component 215 and the intra-picture prediction component 217 may operate on both the luma and chroma components.

[0087] The transform scaling and quantization component 213 is configured to further compress the residual block. The transform scaling and quantization component 213 applies a transform, such as a discrete cosine transform (DCT), a discrete sine transform (DST), or a conceptually similar transform, to the residual block to generate a video block containing residual transform coefficient values. A wavelet transform, an integer transform, a subband transform, or other types of transforms may also be used. The transform may convert the residual information from the pixel value domain to a transform domain, such as the frequency domain. The transform scaling and quantization component 213 is also configured to scale the transformed residual information, for example, based on frequency. Such scaling may include applying a scale factor to the residual information so that different frequency information is quantized with different granularity, which may affect the final visual quality of the reconstructed video. The transform scaling and quantization component 213 is also configured to quantize the transform coefficients to further reduce the bit rate. The quantization process may reduce the bit depth associated with some or all of the coefficients. The degree of quantization may be changed by adjusting a quantization parameter. In some examples, the transform scaling and quantization component 213 may then perform a scan of the matrix containing the quantized transform coefficients, which are forwarded to the header formatting and CABAC component 231 to be encoded into the bitstream.

[0088] The scaling and inverse transform component 229 applies the inverse operations of the transform scaling and quantization component 213 to support motion estimation. The scaling and inverse transform component 229 applies inverse scaling, transform, and / or quantization to reconstruct residual blocks in the pixel domain, for example, for later use as reference blocks that can become predictive blocks for other current blocks. The motion estimation component 221 and / or motion compensation component 219 may calculate reference blocks by adding the residual blocks back to the corresponding predictive blocks for use in motion estimation of later blocks / frames. Filters are applied to the reconstructed reference blocks to mitigate artifacts introduced during scaling, quantization, and transform. Such artifacts could otherwise cause erroneous predictions (and further artifacts) when subsequent blocks are predicted.

[0089] The filter control analysis component 227 and the in-loop filter component 225 apply filters to residual blocks and / or to reconstructed image blocks. For example, a transformed residual block from the scaling and inverse transform component 229 may be combined with a corresponding prediction block from the intra-picture prediction component 217 and / or the motion compensation component 219 to reconstruct the original image block. The filter may then be applied to the reconstructed image block. In some examples, the filter may instead be applied to the residual block. Like the other components in FIG. 2, the filter control analysis component 227 and the in-loop filter component 225 are highly integrated and may be implemented together, but are depicted separately for conceptual purposes. The filters applied to reconstructed reference blocks are applied to specific spatial regions and include multiple parameters for adjusting how such filters are applied. The filter control analysis component 227 analyzes the reconstructed reference blocks to determine where such filters should be applied and sets the corresponding parameters. Such data is forwarded to the header formatting and CABAC component 231 as filter control data for encoding. The in-loop filter component 225 applies such filters based on the filter control data. The filters may include deblocking filters, noise suppression filters, SAO filters, and adaptive loop filters. Such filters may be applied in the spatial / pixel domain (e.g., on reconstructed pixel blocks) or in the frequency domain, depending on the example.

[0090] When operating as an encoder, the filtered reconstructed image blocks, residual blocks, and / or prediction blocks are stored in the decoded picture buffer component 223 for later use in motion estimation, as described above. When operating as a decoder, the decoded picture buffer component 223 stores the reconstructed and filtered blocks and forwards them to a display as part of an output video signal. The decoded picture buffer component 223 may be any memory device capable of storing prediction blocks, residual blocks, and / or reconstructed image blocks.

[0091] The header formatting and CABAC component 231 receives data from various components of the codec system 200 and encodes such data into a coded bitstream for transmission to a decoder. Specifically, the header formatting and CABAC component 231 generates various headers for encoding control data, such as general control data and filter control data. Furthermore, residual data in the form of quantized transform coefficient data, as well as prediction data, including intra-prediction and motion data, are all encoded into the bitstream. The final bitstream contains all information required by a decoder to reconstruct the original partitioned video signal 201. Such information may also include an intra-prediction mode index table (also called a codeword mapping table), definitions of the coding contexts of various blocks, indications of the most likely intra-prediction mode, indications of partition information, etc. Such data may be encoded using entropy coding. For example, the information may be encoded using context-adaptive variable length coding (CAVLC), CABAC, syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioned entropy (PIPE) coding, or other entropy coding techniques. Following entropy coding, the coded bitstream may be transmitted to another device (e.g., a video decoder) or archived for later transmission or retrieval.

[0092] 3 is a block diagram illustrating an exemplary video encoder 300. Video encoder 300 may be used to implement the encoding functionality of codec system 200 and / or to implement steps 101, 103, 105, 107, and / or 109 of method of operation 100. Encoder 300 partitions an input video signal to result in a partitioned video signal 301 that is substantially similar to partitioned video signal 201. Partitioned video signal 301 is then compressed and encoded into a bitstream by components of encoder 300.

[0093] Specifically, the partitioned video signal 301 is forwarded to an intra-picture prediction component 317 for intra prediction. The intra-picture prediction component 317 may be substantially similar to the intra-picture estimation component 215 and the intra-picture prediction component 217. The partitioned video signal 301 is also forwarded to a motion compensation component 321 for inter prediction based on reference blocks in a decoded picture buffer component 323. The motion compensation component 321 may be substantially similar to the motion estimation component 221 and the motion compensation component 219. The prediction blocks and residual blocks from the intra-picture prediction component 317 and the motion compensation component 321 are forwarded to a transform and quantization component 313 for transforming and quantizing the residual blocks. The transform and quantization component 313 may be substantially similar to the transform scaling and quantization component 213. The transformed and quantized residual blocks and corresponding prediction blocks (along with associated control data) are forwarded to an entropy coding component 331 for coding into a bitstream. The entropy coding component 331 may be substantially similar to the header formatting and CABAC component 231 .

[0094] The transformed and quantized residual block and / or the corresponding prediction block are also forwarded from the transform and quantization component 313 to the inverse transform and quantization component 329 for reconstruction into a reference block used by the motion compensation component 321. The inverse transform and quantization component 329 may be substantially similar to the scaling and inverse transform component 229. An in-loop filter in the in-loop filter component 325 is also applied to the residual block and / or the reconstructed reference block, depending on the example. The in-loop filter component 325 may be substantially similar to the filter control analysis component 227 and the in-loop filter component 225. The in-loop filter component 325 may include multiple filters as described with respect to the in-loop filter component 225. The filtered block is then stored in the decoded picture buffer component 323 for use as a reference block by the motion compensation component 321. The decoded picture buffer component 323 may be substantially similar to the decoded picture buffer component 223.

[0095] 4 is a block diagram illustrating an exemplary video decoder 400. Video decoder 400 may be used to implement the decoding functionality of codec system 200 and / or to implement steps 111, 113, 115, and / or 117 of method of operation 100. Decoder 400 receives a bitstream, for example, from encoder 300, and generates a reconstructed output video signal based on the bitstream for display to an end user.

[0096] The bitstream is received by the entropy decoding component 433. The entropy decoding component 433 is configured to implement an entropy decoding scheme such as CAVLC, CABAC, SBAC, PIPE coding, or other entropy coding techniques. For example, the entropy decoding component 433 may use header information to provide context for interpreting additional data encoded as codewords in the bitstream. The decoded information includes any desired information for decoding the video signal from the residual blocks, such as general control data, filter control data, partition information, motion data, prediction data, and quantized transform coefficients. The quantized transform coefficients are forwarded to the inverse transform and quantization component 429 for reconstruction into residual blocks. The inverse transform and quantization component 429 may be similar to the inverse transform and quantization component 329.

[0097] The reconstructed residual block and / or predictive block are forwarded to the intra-picture prediction component 417 for reconstruction into an image block based on an intra-prediction operation. The intra-picture prediction component 417 may be similar to the intra-picture estimation component 215 and the intra-picture prediction component 217. Specifically, the intra-picture prediction component 417 uses a prediction mode to locate a reference block within a frame and applies the residual block to the result to reconstruct an intra-predicted image block. The reconstructed intra-predicted image block and / or residual block and corresponding inter-prediction data are forwarded to the decoded picture buffer component 423 via an in-loop filter component 425. These may be substantially similar to the decoded picture buffer component 223 and the in-loop filter component 225, respectively. The in-loop filter component 425 filters the reconstructed image block, residual block, and / or predictive block, and such information is stored in the decoded picture buffer component 423. The reconstructed image blocks from the decoded picture buffer component 423 are forwarded to the motion compensation component 421 for inter-prediction. The motion compensation component 421 may be substantially similar to the motion estimation component 221 and / or the motion compensation component 219. Specifically, the motion compensation component 421 uses motion vectors from reference blocks to generate prediction blocks and applies a residual block to the result to reconstruct an image block. The resulting reconstructed blocks may also be forwarded to the decoded picture buffer component 423 via an in-loop filter component 425. The decoded picture buffer component 423 continues to store additional reconstructed image blocks that may be reconstructed within frames according to the partition information. Such frames may also be arranged in a sequence. The sequence is output to a display as a reconstructed output video signal.

[0098] 5 is a schematic diagram illustrating an exemplary bitstream 500 including an encoded video sequence. For example, bitstream 500 may be generated by codec system 200 and / or encoder 300 for decoding by codec system 200 and / or decoder 400. As another example, bitstream 500 may be generated by an encoder at step 109 of method 100 for use by a decoder at step 111.

[0099] The bitstream 500 includes a sequence parameter set (SPS) 510, multiple picture parameter sets (PPSs) 512, a slice header 514, and image data 520. The SPS 510 includes sequence data common to all pictures in the video sequence included in the bitstream 500. Such data may include picture sizing, bit depth, coding tool parameters, bit rate limits, etc. The PPS 512 includes parameters specific to one or more corresponding pictures. Thus, each picture in the video sequence may reference one PPS 512. The PPS 512 may indicate coding tools, quantization parameters, offsets, picture-specific coding tool parameters (e.g., filter control), etc. available for slices (or tiles) in the corresponding picture. The slice header 514 includes parameters specific to each slice in the picture. Thus, there may be one slice header 514 per slice in the video sequence. The slice header 514 may include slice information, a picture order count (POC), a reference picture list, prediction weights, tile entry points, deblocking parameters, etc. It should be noted that some systems refer to the slice header 514 as a tile group header and use such information to support tile groups instead of slices.

[0100] The image data 520 includes video data coded according to inter-prediction and / or intra-prediction and corresponding transformed and quantized residual data. Such image data 520 is sorted according to the partitioning used to partition the images before encoding. For example, an image in the image data 520 includes one or more pictures 521. A sequence or succession of pictures 521 may be referred to as a CVS 527. As used herein, a CVS 527 is a series of access units (AUs) including, in decoding order, a coded video sequence start (CVSS) AU followed by zero or more AUs that are not CVSS AUs, including all subsequent AUs up to but not including any subsequent AUs that are CVSS AUs. A CVSS AU is an AU in which a prediction unit (PU) exists for each layer specified by a video parameter set (VPS), and the coded picture within each PU is a coded layer video sequence start (CLVSS) picture. In an embodiment, each picture 521 is arranged within an AU. A PU is a set of NAL units that are related to each other according to specified classification rules, are consecutive in decoding order, and contain exactly one coded picture.

[0101] A CVS is a coded video sequence for all coded layer video sequences (CLVS) in a video bitstream. In particular, a CVS and a CLVS are the same if the video bitstream contains one layer. A CVS and a CLVS are different only if the video bitstream contains multiple layers.

[0102] Each of the pictures 521 can be divided into sub-pictures 523. A sub-picture 523 is a partitioned portion of a picture defined by horizontal and vertical boundaries. The sub-pictures 523 can be rectangular and / or square. Specifically, a sub-picture 523 includes four sides connected at right angles. The four sides include two pairs of parallel sides. Furthermore, the sides of each pair of parallel sides are equal in length. As such, the sub-pictures 523 can be any rectangular shape, with a square being a special case of a rectangle where all four sides are equal in length.

[0103] Each subpicture 523 may be partitioned into slices 529. It should be noted that in some applications, slices 529 may be referred to as tiles and / or tile groups. Slices 529 may be rectangular and / or square, i.e., slices have a rectangular or square shape (as opposed to, for example, raster scan slices, which may not have a rectangular or square shape). Specifically, slices 529 include four sides connected at right angles. The four sides include two pairs of parallel sides. Furthermore, the sides of each pair of parallel sides are equal in length. As such, slices 529 can be any rectangular shape, with a square being a special case of a rectangle in which all four sides are equal in length.

[0104] In an embodiment, each sub-picture 523 comprises a rectangular region of one or more slices 529 within a picture 521. That is, each sub-picture 523 is divided into one or more slices 529, and each picture 521 is divided into one or more sub-pictures 523.

[0105] Slices 529 may or may not allow prediction based on other slices 529, depending on the example. Each slice 529 may have a unique slice index in the subpicture 523. A slice index is a procedurally selected numeric identifier that may be used to distinguish one slice 529 from another. For example, slice indices may increase numerically from top to bottom or left to right.

[0106] It should be noted that in some examples, a slice 529 may be assigned a slice identifier (ID). A slice ID is an assigned identifier that can be used to distinguish one slice 529 from another. Calculations may use the slice ID instead of a slice index in some examples. Furthermore, a slice ID may be assigned to have the same value as a slice index in some examples. The slice index and / or ID may be signaled to indicate a slice group that includes the slice 529. For example, the slice index and / or ID may be used to map picture data associated with the slice 529 to an appropriate location for display. Multiple slices 529 may be referred to as a tile set. A tile set is a related set of slices 529 that can be extracted and coded separately, for example, to support display of a region of interest and / or to support parallel processing. Each slice 529 may be assigned to a corresponding tile set, such that a picture 521 may include multiple tile sets.

[0107] The slice 529 is further divided into coding tree units (CTUs). The CTUs are further divided into coding blocks based on the coding tree. The coding blocks can then be encoded / decoded according to a prediction mechanism.

[0108] In an embodiment, PPS 512 includes a single-slice-per-subpicture flag 532. In an embodiment, single-slice-per-subpicture flag 532 has a first value (e.g., 1). The first value specifies that each subpicture (e.g., subpicture 523) that references PPS 512 (as opposed to other PPSs in bitstream 500) may include only one rectangular slice (e.g., slice 529). That is, each subpicture includes a single rectangular slice. Thus, the dimensions of the subpicture and the rectangular slice are the same.

[0109] In an embodiment, the single slice per subpicture flag 532 has a second value (e.g., 0). The second value specifies that each subpicture (e.g., 523) that references the PPS 512 (as opposed to other PPSs in the bitstream 500) may contain one or more rectangular slices (e.g., slice 529). That is, each subpicture may contain a single rectangular slice, or it may contain multiple slices. When a subpicture contains multiple slices, the dimensions of the subpicture differ from the dimensions of the individual slices. In an embodiment, the single slice per subpicture flag 532 is specified as pps_single_slice_per_subpic_flag.

[0110] In an embodiment, the PPS 512 further includes a number of slices in picture flag 534. The number of slices in picture flag 534 is used to determine the number of rectangular slices (e.g., slice 529) in each picture (e.g., 521) that references the PPS 512. In an embodiment, the number of slices in picture flag 534 is used to signal the number of rectangular slices in each picture that references the PPS when the single slice per picture flag 532 has a second value.

[0111] In an embodiment, the value of the number of slices in picture flag 534 plus 1 specifies the number of slices in each picture that references the PPS. For example, if the value of the number of slices in picture flag 534 is 3, then the total number of slices in the picture is 4 (e.g., 3+1). In an embodiment, the number of slices in picture flag 534 is specified as pps_num_slices_in_pic_minus1.

[0112] FIG. 6 illustrates an embodiment of a decoding method 600 implemented by a video decoder (e.g., video decoder 400). Method 600 may be executed after a decoded bitstream is received directly or indirectly from a video encoder (e.g., video encoder 300). Method 600 improves the decoding process by using a flag in the bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements signaling the number and layout of subpictures (e.g., the position and size of each subpicture) may be omitted from the bitstream, since subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, a coder / decoder (also known as a "codec") in video coding is improved over current codecs. In practice, improved video coding processes provide users with a better user experience when video is transmitted, received, and / or displayed.

[0113] At block 602, a video decoder receives a bitstream (e.g., bitstream 500) that includes a PPS (e.g., PPS 512) that includes a single slice per subpicture flag (e.g., single slice per subpicture flag 532). In an embodiment, the single slice per subpicture flag is specified as pps_single_slice_per_subpic_flag.

[0114] In an embodiment, the PPS further includes a number of slices in picture flag (e.g., number of slices in picture flag 534). The value of the number of slices in picture flag plus 1 specifies the number of slices in each picture that references the PPS. In an embodiment, the number of slices in picture flag is specified as pps_num_slices_in_pic_minus1.

[0115] In block 604, the video decoder determines whether the single slice per subpicture flag has a first value or a second value. The first value specifies that each subpicture that references a PPS includes only one rectangular slice. The second value specifies that each subpicture that references a PPS may include one or more rectangular slices (e.g., one or more rectangular slices). In an embodiment, the first value is one (1) and the second value is zero (0). In an embodiment, each subpicture includes rectangular regions of one or more slices within a picture.

[0116] At block 606, the video decoder decodes the unique rectangular slice if the single slice per sub-picture flag has a first value, or one or more rectangular slices if the single slice per sub-picture flag has a second value. Once decoded, the unique rectangular slice or the one or more rectangular slices are used to generate or generate an image or video sequence, as the case may be, for presentation to a user on a display or screen of an electronic device (e.g., a smartphone, tablet, laptop, personal computer, etc.).

[0117] 7 is an embodiment of a method 700 of video bitstream encoding implemented by a video encoder (e.g., video encoder 300). Method 700 may be performed when a picture (e.g., from a video) is to be encoded into a video bitstream and then transmitted to a video decoder (e.g., video decoder 400). Method 700 improves the encoding process by using a flag in the bitstream to indicate whether each subpicture of a picture contains only one rectangular slice. If the flag indicates that each subpicture contains only one rectangular slice, syntax elements signaling the number and layout of subpictures (e.g., the position and size of each subpicture) may be omitted from the bitstream because subpictures are the same as slices. That is, if the flag indicates that each subpicture contains only one rectangular slice, only syntax elements for slices need to be included in the bitstream. This reduces the amount of information carried in the bitstream, reducing memory, processor, and network resource utilization and increasing coding efficiency. Thus, coders / decoders (also known as "codecs") in video coding are improved over current codecs. In practice, improved video coding processes provide users with a better user experience when video is transmitted, received, and / or displayed.

[0118] In block 702, the video encoder sets a single slice per subpicture flag (e.g., single slice per subpicture flag 532) to a first value if each subpicture (e.g., subpicture 523) that references a PPS (e.g., PPS 512) contains only one rectangular slice, and to a second value if each subpicture that references a PPS may contain one or more rectangular slices.

[0119] In an embodiment, the single slice per subpicture flag is specified as pps_single_slice_per_subpic_flag. In an embodiment, the first value is one (1) and the second value is zero (0).

[0120] In an embodiment, the PPS further includes a number of slices in picture flag (e.g., number of slices in picture flag 534). In an embodiment, the video encoder sets the number of slices in picture flag to a value. The value of the number of slices in picture flag plus 1 specifies the number of slices in each picture that references the PPS. In an embodiment, the number of slices in picture flag is specified as pps_num_slices_in_pic_minus1. In an embodiment, each sub-picture has a rectangular region of one or more slices in a picture.

[0121] At block 704, the video encoder encodes the PPS, including the single-slice-per-subpicture flag, into a bitstream (e.g., bitstream 500). At block 706, the video encoder stores the bitstream for communication to a decoder. The bitstream may be stored in memory until the video bitstream is transmitted to the video decoder. Once received by the video decoder, the encoded video bitstream may be decoded (e.g., as described above) to generate or produce images or video sequences for presentation to a user on a display or screen of an electronic device (e.g., a smartphone, tablet, laptop, personal computer, etc.).

[0122] The following syntax and semantics may be used to implement the embodiments disclosed herein. The following description is relative to the latest VVC draft specification, the basic text, assuming that the signaling of sub-picture information is signaled based on the slice layout. In other words, only the differences are described, while the text in the basic text that is not mentioned below applies as is.

[0123] The PPS syntax is as follows: [Table 1]

[0124] The PPS semantics are as follows:

[0125] brick_idx_delta_sign_flag[i] equal to 1 indicates a positive sign for bottom_right_brick_idx_delta[i]. brick_idx_delta_sign_flag[i] equal to 0 indicates a negative sign for bottom_right_brick_idx_delta[i].

[0126] A bitstream conformance requirement is that a slice should contain either a number of complete tiles or a contiguous sequence of complete bricks of one tile.

[0127] The variables TopLeftBrickIdx[i], BottomRightBrickIdx[i], NumBricksInSlice[i], BrickToSliceMap[j], SliceColBd[i], SliceRowBd[i], SliceWidth[i], and SliceHeight[i], which specify the brick index of the brick located in the top-left corner of the i-th slice, the brick index of the brick located in the bottom-right corner of the i-th slice, the number of bricks in the i-th slice, and the slice index of the slice containing the j-th brick, the position of the left boundary of the i-th slice in CTB units, the position of the right boundary of the i-th slice in CTB units, the width of the i-th slice in CTB units, and the height of the i-th slice in CTB units, respectively, are derived as follows:

number

[0128] subpics_prsent_flag equal to 1 indicates that subpicture parameters are present in the PPS RBSP syntax. subpics_prsent_flag equal to 0 indicates that subpicture parameters are not present in the PPS RBSP syntax. If not present, the value of subpics_prsent_flag is inferred to be equal to 0.

[0129] NOTE - If the bitstream is the result of a subpicture-based sub-bitstream extraction process where the input bitstream contains multiple subpictures per picture and VCL NAL units are only extracted or discarded, not modified, during extraction, and the bitstream contains only a true subset of the subpictures of the input bitstream, then the value of subpics_prsent_flag MUST be equal to 1 in the RBSP of the PPS in the bitstream, even if there is only one subpicture per picture.

[0130] single_slice_per_subpic_flag equal to 1 specifies that each subpicture in each subpicture that references this PPS contains one rectangular slice. single_slice_per_subpic_flag equal to 0 specifies that subpictures in pictures that reference this PPS may contain more than one rectangular slice. The value of single_slice_per_subpic_flag is inferred to be equal to 1 if rect_slice_flag is equal to 1 and num_slices_in_pic_minus1 is equal to 0.

[0131] num_subpics_minus1 plus 1 specifies the number of subpictures in each picture that reference the PPS. num_subpics_minus1 should be in the range 0 to num_slices_in_pic_minus1, inclusive. If subpics_prsent_flag is equal to 0, the value of num_subpics_minus1 is inferred to be 0. If not present and single_slice_per_subpic_flag is equal to 1, the value of num_subpics_minus1 is inferred to be equal to num_slices_in_pic_minus1. The variable NumSubPics is derived to be equal to num_subpics_minus1 + 1.

[0132] bottom_right_slice_idx_length_minus1 plus 1 specifies the number of bits used to represent the syntax element bottom_right_slice_idx_delta[i]. The value of bottom_right_slice_idx_length_minus1 should be in the range 0 to Ceil(Log2(num_slices_in_pic_minus1+1))-1 inclusive.

[0133] bottom_right_slice_idx_delta[i], if i is greater than 0, specifies the difference between the slice index of the slice located in the bottom-right corner of the ith subpicture and the slice index of the bottom-right corner of the (i-1)th subpicture. bottom_right_slice_idx_delta[0] specifies the slice index of the bottom-right corner of the 0th subpicture. If single_slice_per_subpic_flag is equal to 1, the value of bottom_right_slice_idx_delta[i] is inferred to be equal to 1. The value of BottomRightSliceIdx[num_subpics_minus1] is inferred to be equal to num_slices_in_pic_minus1. The length of the bottom_right_slice_idx_delta[i] syntax element is bottom_right_slice_idx_length_minus1 + 1 bits.

[0134] slice_idx_delta_sign_flag[i] equal to 1 indicates the positive sign of bottom_right_slice_idx_delta[i]. slice_idx_delta_sign_flag[i] equal to 0 indicates the negative sign of bottom_right_slice_idx_delta[i].

[0135] The variables TopLeftSliceIdx[i], BottomRightSliceIdx[i], NumSlicesInSubpic[i], SliceToSubpicMap[j], and SliceSubpicToPicIdx[i][k], which specify the slice index of the slice located in the top-left corner of the i-th subpicture, the slice index of the slice located in the bottom-right corner of the i-th subpicture, the number of slices in the i-th subpicture, the subpicture index of the subpicture containing the j-th slice, and the picture-level slice index of the k-th slice in the i-th subpicture, respectively, are derived as follows:

number

[0136] The variables SubpicLeft[i], SubpicTop[i], SubpicWidth[i], and SubpicHeight[i], which specify the left border position, top border position, width, and height, respectively, of the ith subpicture in CTB units, are derived as follows for each value of i in the range 0 to NumbSubPics-1, inclusive:

number

[0137] 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 excluding 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 excluding in-loop filtering operations. If not present, the value of subpic_treated_as_pic_flag[i] is inferred to be equal to 0.

[0138] loop_filter_across_subpic_enabled_flag[i] equal to 1 specifies that in-loop filtering operations may be performed across the i-th subpicture boundary at 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 i-th subpicture boundary at each coded picture in the CVS. If not present, the value of loop_filter_across_subpic_enabled_flag[i] is inferred to be equal to 1.

[0139] The bitstream conformance requirement is that the following constraints apply:

[0140] For any two subpictures subpicA and subpicB, if the index of subpicA is smaller than the index of subpicB, then any coded NAL unit of subPicA should follow any coded NAL unit of subPicB in decoding order.

[0141] The shape of the subpictures should be such that each subpicture, when decoded, should have its entire left and top boundaries consisting of the picture boundary or the boundary of a previously decoded subpicture.

[0142] The values ​​of SubpicLeft[i], SubpicTop[i], SubpicWidth[i], and SubpicHeight[i] should be the same for each value of i from 0 to NumSubPics-1, inclusive, regardless of which PPS RBSP they are derived from referenced by the CLVS coded slice NAL unit.

[0143] The values ​​of subpic_treated_as_pic_flag[i] and loop_filter_across_subpic_enabled_flag[i] shall remain the same in all PPS RBSPs referenced by the CLVS coded slice NAL unit for each value of i in the range 0 to NumSubPics-1, inclusive.

[0144] subpic_ids_constant_in_clvs_flag equal to 1 indicates that the values ​​of subpic_id_len_minus1 and pps_subpic_id[i] remain the same in all PPS RBSPs referenced by CLVS coded slice NAL units for each value of i in the range from 0 to num_subpics_minus1, inclusive. subpic_ids_constant_in_clvs_flag equal to 0 indicates that the values ​​of subpic_id_len_minus1 and pps_subpic_id[i] may or may not be constrained.

[0145] subpic_id_len_minus1 plus 1 specifies the length of the pps_subpic_id[i] and slice_subpic_id syntax elements in bits. The value of subpic_id_len_minus1 should be in the range 3 to 31 inclusive. Values ​​of subpic_id_len_minus1 in the range 0 to 2 inclusive are reserved for future use by ITU-T|ISO / IEC.

[0146] pps_subpic_id[i] specifies the identifier of the ith subpicture.

[0147] 8 is a schematic diagram of a video coding device 800 (e.g., video encoder 300 or video decoder 400) according to an embodiment of the present disclosure. The video coding device 800 is suitable for implementing the disclosed embodiments described herein. The video coding device 800 includes an ingress port 810 and a receiver unit (Rx) 820 for receiving data, a processor, logic unit, or central processing unit (CPU) 830 for processing the data, a transmitter unit (Tx) 840 and an egress port 850 for transmitting the data, and a memory 860 for storing the data. The video coding device 800 may also include optical-electrical (OE) and electro-optical (EO) components coupled to the ingress port 810, the receiver unit 820, the transmitter unit 840, and the egress port 850 for the egress or ingress of optical or electrical signals.

[0148] The processor 830 is implemented in hardware and software. The processor 830 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 830 communicates with the ingress port 810, the receiver unit 820, the transmitter unit 840, the egress port 850, and the memory 860. The coding module 870 implements the above-disclosed embodiments. For example, the coding module 870 implements, processes, prepares, or provides various codec functions. The inclusion of the coding module 870 thus substantially improves the functionality of the video coding device 800 and achieves transformation of the video coding device 800 into different states. Alternatively, the coding module 870 is implemented as instructions stored in the memory 860 and executed by the processor 830.

[0149] Video coding device 800 may also include input and / or output (I / O) devices 880 for communicating data to and from a user. I / O devices 880 may include a display for displaying video data, speakers for outputting audio data, etc. I / O devices 880 may include input devices such as a keyboard, mouse, trackball, etc., and / or corresponding interfaces for interacting with such output devices.

[0150] Memory 860 may include one or more disks, tape drives, and solid-state drives, and may be used to store programs when such programs are selected for execution, and as an overflow data storage device to store instructions and data read during program execution. Memory 860 may be volatile and / or nonvolatile, and may be read-only memory (ROM), random access memory (RAM), ternary content addressable memory (TCAM), and / or static random access memory (SRAM).

[0151] 9 is a schematic diagram of an embodiment of a means for coding 900. In an embodiment, the means for coding 900 is implemented in a video coding device 902 (e.g., video encoder 300 or a video decoder). The video coding device 902 includes a means for receiving 901. The means for receiving 901 is configured to receive a picture to be encoded or to receive a bitstream to be decoded. The video coding device 902 includes a means for transmitting 907 coupled to the means for receiving 901. The means for transmitting 907 is configured to transmit the bitstream to a decoder or to transmit a decoded image to a display means (e.g., one of I / O devices 880).

[0152] The video coding device 902 includes a storage means 903. The storage means 903 is coupled to at least one of the receiving means 901 or the transmitting means 907. The storage means 903 is configured to store instructions. The video coding device 902 also includes a processing means 905. The processing means 905 is coupled to the storage means 903. The processing means 905 is configured to execute the instructions stored in the storage means 903 to perform the methods disclosed herein.

[0153] While several embodiments are provided in this disclosure, it will be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the disclosure. The examples should be considered illustrative rather than limiting, and the intention should not be limited to the details provided herein. For example, various elements or components may be combined or integrated into other systems, or certain features may be omitted or not implemented.

[0154] Furthermore, the techniques, systems, subsystems, and methods described and illustrated in various embodiments as separate or distinct may be combined or integrated with other systems, components, techniques, or methods without departing from the scope of this disclosure. Other examples of changes, substitutions, and alterations will be ascertainable by those skilled in the art and may be made without departing from the spirit and scope of what is disclosed herein.

Claims

1. 1. A method implemented by an encoder, comprising: setting, by the encoder, a single-slice-per-subpicture flag to a first value if each subpicture referencing a Picture Parameter Set (PPS) contains only one rectangular slice, and to a second value if each subpicture referencing the PPS may contain one or more rectangular slices; encoding, by the encoder, the PPS including the single slice per sub-picture flag into a bitstream if rect_slice_flag is true; and the rect_slice_flag is in the PPS; method.

2. The single slice per subpicture flag is specified as pps_single_slice_per_subpic_flag, The method of claim 1.

3. the first value is 1 and the second value is 0; 3. The method according to claim 1 or 2.

4. The PPS further includes a flag indicating the number of slices in a picture, and a value of the flag indicating the number of slices in a picture plus 1 specifies the number of slices in each picture that refers to the PPS.

3. The method according to claim 1 or 2.

5. The flag for the number of slices in the picture is specified as the pps_num_slices_in_pic_minus1 flag. The method of claim 4.

6. Each subpicture comprises a rectangular region of one or more slices within a picture.

3. The method according to claim 1 or 2.

7. transmitting the bitstream to a video decoder.

3. The method according to claim 1 or 2.

8. 1. A coding device, comprising: a memory containing instructions; a processor coupled to the memory; The processor executes the instructions to cause the encoding device to: encoding a bitstream including a picture parameter set (PPS) including a single slice per sub-picture flag if rect_slice_flag is true, wherein the rect_slice_flag is in the PPS; setting the single slice per sub-picture flag to a first value if each sub-picture that references the PPS contains only one rectangular slice, and to a second value if each sub-picture that references the PPS may contain one or more rectangular slices; configured to cause the Encoding device.

9. a receiver configured to receive pictures to encode; a transmitter coupled to the receiver and configured to transmit a bitstream including the encoded pictures to a decoder; a memory coupled to at least one of the receiver or the transmitter and configured to store instructions; a processor coupled to said memory and configured to execute said instructions stored in said memory to perform the method of any one of claims 1 to 7; An encoding device having:

10. An encoding device according to claim 9; a decoding device in communication with the encoding device, the decoding device is configured to receive the bitstream from the encoding device and decode the received bitstream. system.

11. receiving means configured to receive pictures to encode; transmitting means coupled to said receiving means and configured to transmit a bitstream containing said encoded pictures to a decoding means; a storage means coupled to at least one of the receiving means or the transmitting means and configured to store instructions; processing means coupled to said storage means and configured to execute the instructions stored in said storage means to perform the method of any one of claims 1 to 7; The means for encoding comprises:

12. An encoder having processing circuitry for carrying out the method of any one of claims 1 to 7.

13. A terminal having one or more processors, a memory, and a communication interface, the memory and the communication interface being connected to the one or more processors, the terminal communicates with other devices via the communication interface; the memory configured to store a set of instructions; 8. When the one or more processors execute the set of instructions, the terminal performs the method of any one of claims 1 to 7. Terminal.

14. 1. An apparatus for storing a bitstream, comprising: a receiver configured to receive one or more bitstreams; one or more storage media configured to store the one or more bitstreams; each of the one or more bitstreams includes a single-slice-per-subpicture flag if rect_slice_flag is true, the rect_slice_flag being in a picture parameter set (PPS), the single-slice-per-subpicture flag being set to a first value if each subpicture referencing the PPS includes only one rectangular slice, and being set to a second value if each subpicture referencing the PPS may include one or more rectangular slices; Device.

15. 1. A method for storing a bitstream, comprising: obtaining and storing the bitstream; the bitstream includes a single-slice-per-subpicture flag if rect_slice_flag is true, the rect_slice_flag is in a picture parameter set (PPS), and the single-slice-per-subpicture flag is set to a first value if each subpicture that references the PPS contains only one rectangular slice, and is set to a second value if each subpicture that references the PPS may contain one or more rectangular slices; method.

16. A bitstream data structure comprising: the data structure includes a single-slice-per-subpicture flag if rect_slice_flag is true, the rect_slice_flag is in a picture parameter set (PPS), and the single-slice-per-subpicture flag is set to a first value if each subpicture that references the PPS contains only one rectangular slice, and is set to a second value if each subpicture that references the PPS may contain one or more rectangular slices; Data structure.

Images