Encoder, decoder, and corresponding method

Abstract

To provide a video coding mechanism.SOLUTION: A mechanism includes receiving a bitstream including a slice. A number of entry points (NumEntryPoints) in the slice is derived. An offset for a subset of coded slice data having subset index values ranging from 0 to NumEntryPoints is determined. The slice is decoded on the basis of the offset for the subset of coded slice data. The slice is forwarded for display as part of a decoded video sequence.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 / 832,128, entitled “Video Coding Improvements,” filed on April 10, 2019 by Ye-Kui Wang, which is incorporated herein by reference.

[0002] FIELD This disclosure relates generally to video coding, and more particularly to determining entry points for coded data within a slice of a picture in video coding. [Background technology]

[0003] The amount of video data required to depict even a relatively short video can be significant, which can pose difficulties when the data is to be streamed or otherwise conveyed over a communication network with limited bandwidth capacity. Thus, video data is generally compressed before being conveyed over modern telecommunication networks. The size of the video can also be an issue when the video is stored on a storage device, since memory resources may be limited. Often, video compression devices use software and / or hardware at the source to code the video data before transmission or storage, thereby reducing the amount of data required 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 an ever-increasing demand for higher video quality, improved compression and decompression techniques that increase compression ratios with little or no sacrifice in image quality are desirable. Summary of the Invention [Means for solving the problem]

[0004] In an embodiment, the disclosure includes a method implemented in a decoder, the method including: receiving, by a receiver of the decoder, a bitstream including a slice; deriving, by a processor of the decoder, a number of entry points (NumEntryPoints) in the slice; determining, by the processor, offsets for a subset of coded slice data having a subset index value ranging from 0 to NumEntryPoints; decoding, by the processor, the slice based on the offsets for the subset of coded slice data; and forwarding, by the processor, the slice for display as part of a decoded video sequence. In some video coding systems, an encoder signals a value of num_entry_point_offsets for each slice. The decoder then sets a value of NumEntryPoints based on the bitstream. This value is used to determine an offset for each group of coded data in the slice. These groups can then be decoded using the offsets. This example uses a mechanism for determining the value of NumEntryPoints without signaling the value in the bitstream. NumEntryPoints may then be used to obtain offsets for a subset of a slice, such as rows of a coding tree unit (CTU), before reconstructing the subset, and thus the slice. For example, a mechanism may be used to derive NumEntryPoints for a slice when the slice is coded by wavefront parallel processing (WPP). NumEntryPoints may be derived based on the size of rows of a WPP / CTU, the size of columns of a WPP / CTU, based on the number of CTUs in a slice, and / or based on CTU and / or slice addresses.This approach eliminates the signaled values ​​for each slice header and therefore for each slice in the video stream. A picture may contain multiple slices. Furthermore, a video sequence may contain thousands of pictures. Thus, removing num_entry_point_offsets from the bitstream significantly reduces the size of the video stream, increases coding efficiency, and reduces memory and network resource usage in both the encoder and decoder.

[0005] Optionally, in any of the above aspects, another implementation of the aspect provides that NumEntryPoints is derived when the slice is coded by wavefront parallel processing (WPP).

[0006] Optionally, in any of the above aspects, another implementation of the aspect provides that the bitstream includes a slice header, and the slice header does not include a value corresponding to the number of offsets of the entry points within the slice.

[0007] Optionally, in any of the above aspects, other implementations of the aspect provide that NumEntryPoints is derived based on a size of the rows in the slice.

[0008] Optionally, in any of the above aspects, other implementations of the aspect provide that NumEntryPoints is derived based on a size of the columns in the slice.

[0009] Optionally, in any of the above aspects, another implementation of the aspect provides that NumEntryPoints is derived based on a number of coding tree units (CTUs) in a slice.

[0010] Optionally, in any of the above aspects, other implementations of the aspect provide that NumEntryPoints is derived based on an address within a slice.

[0011] Optionally, in any of the above aspects, other implementations of the aspect provide that NumEntryPoints is derived based on a size of the slice.

[0012] In an embodiment, the disclosure includes a method implemented in an encoder, the method including: obtaining, by a processor of the encoder, a reference slice of a coded reference picture; deriving, by the processor, a NumEntryPoints in the reference slice; determining, by the processor, an offset for a subset of coded data in the reference slice based on the NumEntryPoints; decoding, by the processor, the reference slice of the coded reference picture based on the offset for the subset of coded data in the reference slice; encoding, by the processor, a current slice into a bitstream based on the reference slice; and storing, by a memory coupled to the processor, the bitstream for communication to a decoder. In some video coding systems, the encoder signals a value of num_entry_point_offsets for each slice. The decoder then sets a value of NumEntryPoints based on the bitstream. This value is used to determine an offset for each group of coded data in the slice. These groups can then be decoded using the offsets. This example uses a mechanism for determining the value of NumEntryPoints without signaling a value in the bitstream. NumEntryPoints may then be used to obtain offsets for a subset of a slice, such as a row of a coding tree unit (CTU), before reconstructing the subset, and thus the slice. For example, a mechanism may be used to derive NumEntryPoints for a slice when the slice is coded by wavefront parallel processing (WPP). NumEntryPoints may be derived based on the size of a row of a WPP / CTU, the size of a column of a WPP / CTU, based on the number of CTUs in the slice, and / or based on a CTU and / or slice address.This approach eliminates the signaled values ​​for each slice header and therefore for each slice in the video stream. A picture may contain multiple slices. Furthermore, a video sequence may contain thousands of pictures. Thus, removing num_entry_point_offsets from the bitstream significantly reduces the size of the video stream, increases coding efficiency, and reduces memory and network resource usage in both the encoder and decoder.

[0013] Optionally, in any of the above aspects, another implementation of the aspect provides that NumEntryPoints is derived when the reference slice is coded by WPP.

[0014] Optionally, in any of the above aspects, another implementation of the aspect provides that the bitstream includes a slice header, and the slice header does not include a value corresponding to the number of offsets of the entry point within the reference slice.

[0015] Optionally, in any of the above aspects, other implementations of the aspect provide that NumEntryPoints is derived based on a size of a row in the reference slice.

[0016] Optionally, in any of the above aspects, other implementations of the aspect provide that NumEntryPoints is derived based on a size of the columns in the reference slice.

[0017] Optionally, in any of the above aspects, another implementation of the aspect provides that NumEntryPoints is derived based on the number of CTUs in the reference slice.

[0018] Optionally, in any of the above aspects, other implementations of the aspect provide that NumEntryPoints is derived based on an address within the reference slice.

[0019] Optionally, in any of the above aspects, other implementations of the aspect provide that NumEntryPoints is derived based on a size of the reference slice.

[0020] In an embodiment, the present disclosure includes a processor, a receiver coupled to the processor, a memory coupled to the processor, and a transmitter coupled to the processor, wherein the processor, receiver, memory, and transmitter comprise a video coding device configured to perform the method of any of the above aspects.

[0021] In an embodiment, the present disclosure includes a non-transitory computer-readable medium including a computer program product for use by a video coding device, the computer program product including computer-executable instructions stored on the non-transitory computer-readable medium that, when executed by a processor, causes the video coding device to perform a method of any of the above aspects.

[0022] In an embodiment, the present disclosure includes a decoder including receiving means for receiving a bitstream including a slice, derivation means for deriving NumEntryPoints within the slice, determination means for determining an offset for a subset of coded slice data having subset index values ​​ranging from 0 to NumEntryPoints, decoding means for decoding the slice based on the offset for the subset of coded slice data, and forwarding means for forwarding the slice for display as part of a decoded video sequence.

[0023] Optionally, in any of the above aspects, another implementation of the aspect provides that the decoder is further configured to perform the method of any of the above aspects.

[0024] In an embodiment, the present disclosure includes an encoder including an obtaining means for obtaining a reference slice of a coded reference picture, a derivation means for deriving NumEntryPoints in the reference slice, a determination means for determining an offset for a subset of coded data in the reference slice based on the NumEntryPoints, a coding means for decoding the reference slice of the coded reference picture based on the offset for the subset of coded data in the reference slice and encoding a current slice based on the reference slice into a bitstream, and a storage means for storing the bitstream for transmission to a decoder.

[0025] Optionally, in any of the above aspects, another implementation of the aspect provides that the encoder is further configured to perform the method of any of the above aspects.

[0026] For purposes of clarity, any one of the above-described embodiments may be combined with any one or more of the other above-described embodiments to generate new embodiments within the scope of the present disclosure.

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

[0028] 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 description of the drawings]

[0029] [Figure 1] 1 is a flow diagram of an exemplary method for coding a video signal. [Diagram 2] 1 is a schematic diagram of an example coding and decoding (codec) system for video coding. [Diagram 3]FIG. 1 is a schematic diagram illustrating an exemplary video encoder. [Figure 4] FIG. 2 is a schematic diagram illustrating an exemplary video decoder. [Diagram 5] FIG. 1 is a schematic diagram illustrating an exemplary mechanism of wavefront parallel processing (WPP). [Figure 6] FIG. 2 is a schematic diagram illustrating an exemplary bitstream. [Figure 7] 1 is a schematic diagram of an example video coding device. [Figure 8] 1 is a flow diagram of an example method for encoding a video sequence into a bitstream without signaling the number of entry points (NumEntryPoints) for a slice. [Figure 9] 4 is a flow diagram of an example method for deriving NumEntryPoints for decoding a video sequence when NumEntryPoints is not included in the bitstream. [Figure 10] 1 is a schematic diagram of an example system for coding a video sequence into a bitstream without signaling NumEntryPoints. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] First, while an example implementation of one or more embodiments is given below, it should be understood that the disclosed system and / or method may be implemented using any number of technologies, whether currently known or in existence. The present disclosure should not be limited in any way to the example implementations, drawings, and technologies shown below, including the example designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0031] The following terms are defined as follows, unless used in the present specification in a contrary context. In particular, the following definitions are intended to provide further clarity to the present disclosure. However, terms may be explained differently in different contexts. Therefore, the following definitions should be considered as supplementary and should not be considered as limiting any other definitions of the explanations given for such terms in the present specification.

[0032] A bitstream is a sequence of bits that includes video data that is 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 the bitstream for display using a decoding process. A picture is a complete image intended for complete or partial display to a user at a corresponding instant in a video sequence. A reference picture is a picture that includes reference samples that can be used when coding other pictures by reference by inter prediction. A coded picture is a representation of a picture that is coded by inter or intra prediction and is included in a single access unit in a bitstream and includes a complete set of coding tree units (CTUs) of the picture. A slice is a partition of a picture that includes an integer number of complete tiles or an integer number of consecutive rows of complete CTUs in a tile of a picture, and the slice and all subdivisions are exclusively included in a single network abstraction layer (NAL) unit. A reference slice is a slice of a reference picture that includes reference samples or is used when coding other slices by reference by inter prediction. The slice header is the part of a coded slice that contains data elements related to all tiles represented in the slice or rows of CTUs in tiles. The entry point is the bit position in the bitstream that contains the first bit of video data for the corresponding subset of the coded slice. The offset is the distance in bits between the known bit position and the entry point. A subset is a subdivision of a set. For example, when a slice is a set, tiles, rows of CTUs / coding tree blocks (CTBs), or CTUs / CTBs are subsets of a set.A coding tree unit (CTU) is a group of samples of a predefined size that can be partitioned by a coding tree. A row of CTUs is a group of CTUs that extend horizontally between a left slice boundary and a right slice boundary. A column of CTUs is a group of CTUs that extend vertically between a top slice boundary and a bottom slice boundary. A CTB is a portion of a CTU that contains only luma samples, only red difference chroma samples, or only blue difference chroma samples. A CTB row / CTB column is a row / column of a CTU that contains only luma samples, only red difference samples, or only blue difference samples. Note that CTU and CTB may be used interchangeably in many contexts. Wavefront parallel processing (WPP) is a mechanism to delay and code rows of CTUs / CTBs of a slice to allow each row to be decoded in parallel by a different thread. A slice address is an identifiable location of a slice or a subpart thereof.

[0033] The following acronyms are used in this specification: Coded Video Sequence (CVS), Decoded Picture Buffer (DPB), Instantaneous Decoding Refresh (IDR), Intra Random Access Point (IRAP), Joint Video Experts Team (JVET), Least Significant Bit (LSB), Most Significant Bit (MSB), Network Abstraction Layer (NAL), Picture Order Count (POC), Raw Byte Sequence Payload (RBSP), Real-time Transport Protocol (RTP), Sequence Parameter Set (SPS), Versatile Video Coding (VVC), Working Draft (WD), and Wavefront Parallel Processing (WPP).

[0034] Many video compression techniques may be used to reduce the size of a video file with minimal loss of data. For example, video compression techniques may include performing spatial (e.g., intra-picture) prediction and / or temporal (inter-picture) prediction to reduce or remove data redundancy in a video sequence. For block-based video coding, a video slice (e.g., a video picture or a portion of a video picture) 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 in an intra-coded (I) slice of a picture are coded using spatial prediction with respect to reference samples in neighboring blocks in the same picture. Video blocks in an inter-coded unidirectionally predicted (P) or bidirectionally predicted (B) slice of a picture may be coded by using spatial prediction with respect to reference samples in neighboring blocks in the same picture or temporal prediction with respect to reference samples in other reference pictures. A picture may be referred to as a frame and / or an image, and a reference picture may be referred to as a reference frame and / or a reference image. Spatial or temporal prediction results in a predictive block that represents an image block. The residual data represents the pixel difference between the original image block and the predictive block. Thus, an inter-coded block is coded by a motion vector that points to a block of reference samples that form the predictive block, and the residual data that indicates the difference between the coded block and the predictive block. An intra-coded block is coded by an intra-coding mode and the residual data. For further compression, the residual data may be transformed from the pixel domain to a transform domain. These result in residual transform coefficients, which may be quantized. First, the quantized transform coefficients may 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 further compression. Such video compression techniques are discussed in more detail below.

[0035] To ensure that the encoded video can be accurately decoded, the video is encoded and decoded according to a corresponding video coding standard, including International Telecommunication Union (ITU) Standardization Sector (ITU-T) H.261, International Organization for Standardization / International Electrotechnical Commission (ISO / IEC) Moving 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). The Joint Video Experts Team (JVET) of ITU-T and ISO / IEC has begun development of a video coding standard called Versatile Video Coding (VVC). VVC is included in working drafts (WDs) including JVET-N1001-v1.

[0036] A video coding system may encode video using many different mechanisms. For example, a video coding system may partition a picture into slices. In some examples, slices are partitioned into tiles. In some examples, slices and / or tiles of slices may then be partitioned into rows of CTUs. The CTUs are then subdivided into coding blocks by a coding tree, and the coding blocks are coded by a prediction mechanism. The coded coding blocks are then included in a bitstream. In a WPP, rows of CTUs and their partitions are coded in parallel. For example, a WPP may, in some examples, code one or two CTUs of the first row using a first thread, and then start coding the CTUs of the second row with a second thread. Once one / two CTUs of the second row are coded, a third thread may start coding the CTUs of the third row, and so on. Some prediction schemes code by referencing blocks located above or to the left of the current block. By placing a CTU delay between the start of coding of the next row, WPP can ensure that blocks located above or to the left of the current block are coded before the current block is coded, which mitigates the problem of such data potentially being unavailable when the encoder starts coding the current block.

[0037] Thus, a number of bits are included in the bitstream. Furthermore, each of these bits is associated with a corresponding slice or a subpart thereof. To help the decoder interpret the bitstream and find the relevant data, an array of offsets may be included in the bitstream. Each offset indicates the location of the corresponding data in the bitstream. The offset of the first bit of video data for the corresponding subset of the coded slice is known as the entry point. In the case of WPP, the subset is a row of CTUs. Thus, in WPP, there may be as many entry points in a slice as there are rows of CTUs in the slice. In some video coding systems, num_entry_point_offsets is included in the slice header. num_entry_point_offsets is a parameter that signals the number of entry point offsets included in the slice and thus indicates to the decoder the number of offsets to be obtained from the array of offsets. The decoder can use num_entry_point_offsets from the slice header to obtain the relevant offset and start decoding the corresponding CTU. Although this approach is effective, num_entry_point_offsets contains multiple bits and is signaled in every slice header. Because each picture may contain several slices and a video sequence may contain thousands of pictures, num_entry_point_offsets may be signaled many times, which can have a significant collective impact on the amount of data in a video sequence.

[0038] Disclosed herein are mechanisms for deriving a value for the number of entry points (NumEntryPoints) at a decoder. NumEntryPoints may then be used to obtain offsets for a subset of a slice (e.g., rows of a CTU) before reconstructing the subset and therefore the slice. This allows num_entry_point_offsets to be removed from each slice header of the bitstream. These mechanisms may be used at the decoder and / or at a hypothetical reference decoder (HRD) at the encoder. Because a picture may contain multiple slices and a video may contain thousands of pictures, removing this value from the bitstream significantly reduces the size of the video stream, increases coding efficiency, and reduces memory and network resource usage at both the encoder and the decoder. For example, the mechanisms may be used to derive NumEntryPoints for a slice when the slice is coded by WPP. NumEntryPoints may be derived based on the size of a row of a WPP / CTU, the size of a column of a WPP / CTU, based on the number of CTUs in a slice, and / or based on the CTU and / or slice address.

[0039] 1 is a flow diagram of an exemplary operational method 100 of coding a video signal. Specifically, a video signal is encoded in an encoder. The encoding process compresses the video signal by reducing the video file size using various mechanisms. 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 an end user. In general, the decoding process mirrors the encoding process to allow the decoder to consistently reconstruct the video signal.

[0040] 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 audio and video components. The video component includes a series of image frames that, when viewed in sequence, give the visual impression of motion. The frames include pixels represented by light, referred to herein as luma components (or luma samples), and colors, referred to herein as chroma components (or color samples). In some examples, the frames may also include depth values ​​to support three-dimensional viewing.

[0041] In step 103, the video is partitioned into blocks. Partitioning involves subdividing the pixels of 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 units (CTUs), which are blocks of a predefined size (e.g., 64 pixels by 64 pixels). The CTUs include both luma and chroma samples. A coding tree may be used to divide the CTUs into blocks and then iteratively subdivide the blocks until a configuration that supports further encoding is achieved. For example, the luma component of a frame may be subdivided until each block contains a relatively uniform illumination value. For example, the chroma component of a frame may be subdivided until each block contains a relatively uniform color value. Thus, the partitioning mechanism varies depending on the content of the video frame.

[0042] 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 depicting an object in a reference frame does not need to be shown repeatedly in adjacent frames. Specifically, an object such as a table may remain in a constant position across multiple frames. Thus, the table may be shown once and adjacent frames may look back to the reference frame. Pattern matching mechanisms may be used to match objects across multiple frames. Furthermore, moving objects may be represented across multiple frames, for example, due to object movement or camera movement. As a particular example, a video may show a car moving across the screen for multiple frames. Motion vectors may be used to indicate such movement. A motion vector is a two-dimensional vector that gives an offset from the coordinates of an object in a frame to the coordinates of the object in a reference frame. Thus, inter-prediction may encode an image block in a current frame as a set of motion vectors that indicate an offset from a corresponding block in a reference frame.

[0043] Intra prediction encodes blocks within a common frame. Intra prediction exploits the fact that luma and chroma components tend to cluster within a frame. For example, green areas of a part of a tree tend to be located in the vicinity of similar green areas. Intra prediction uses multiple directional prediction modes (e.g., 33 in HEVC), planar mode, and direct current (DC) mode. The directional modes indicate that the current block is similar / same as the samples of neighboring blocks in the corresponding direction. The planar modes indicate that a series of blocks (e.g., a plane) along a row / column may be interpolated based on the neighboring blocks at the ends of the row. In effect, the planar modes indicate a smooth transition of light / color between rows / columns by using a relatively constant gradient of changing values. The DC mode is used for boundary smoothing and indicates that the block is similar / same as the average value associated with the samples of all neighboring blocks associated with the angular direction of the directional prediction mode. Thus, intra prediction blocks may represent the image block as the values ​​of the various related prediction modes instead of the actual values. Furthermore, inter prediction blocks may represent the image block as the values ​​of a motion vector instead of the actual values. In either case, the prediction block may not exactly represent the image block in some cases. Any differences are stored in a residual block. To further compress the file, a transform may be applied to the residual block.

[0044] In step 107, various filtering techniques may be applied. In HEVC, filters are applied according to an in-loop filtering scheme. The block-based prediction described above may result in the generation of a blocky image at the decoder. Furthermore, the block-based prediction scheme may code a block and then reconstruct the coded block for later use as a reference block. The in-loop filtering scheme iteratively applies a noise suppression filter, a deblocking filter, an adaptive loop filter, and a sample adaptive offset (SAO) filter to the block / frame. These filters mitigate such blocking artifacts so that the coded file can be accurately reconstructed. Furthermore, these filters mitigate artifacts in the reconstructed reference block so that the artifacts are less likely to cause further artifacts in subsequent blocks coded based on the reconstructed reference block.

[0045] Once the video signal has been partitioned, compressed, and filtered, the resulting data is coded into a bitstream in step 109. The bitstream includes the data described above and any signaling data desired to support reconstruction of the proper video signal at the decoder. For example, such data may include partitioning 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 the decoder upon request. The bitstream may also be broadcast and / or multicast to multiple decoders. The generation of the bitstream is an iterative process. Thus, steps 101, 103, 105, 107, and 109 may occur sequentially and / or simultaneously across many frames and blocks. The order depicted in FIG. 1 is presented for clarity and ease of discussion and is not intended to limit the video coding process to a particular order.

[0046] The decoder receives the bitstream in step 111 and starts the decoding process. 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 in step 111 to determine a partition for the frame. The partition should match the result of the block partitioning in step 103. The entropy encoding / decoding used in step 111 is described below. The encoder makes many choices during the compression process, such as selecting a block partitioning scheme from several possible options based on the spatial positioning of values ​​in the input image. Signaling the exact selection may use multiple bins. As used herein, a bin is a binary value (e.g., a bit value that can change depending on the situation) that is treated as a variable. Entropy coding allows the encoder to discard all options that obviously do not work in a particular case, leaving 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 a codeword for the selected choice. This scheme reduces the size of the codeword because the codeword is only as large as is 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 choices by determining the set of allowable choices in a similar manner as the encoder. By determining the set of allowable choices, the decoder can read the codeword and determine the choice made by the encoder.

[0047] In step 113, the decoder performs decoding of the block. Specifically, the decoder generates a residual block using an inverse transform. The decoder then uses the residual block and a corresponding prediction block to reconstruct an image block according to the partitioning. The prediction block may include both intra-prediction blocks and inter-prediction blocks generated by 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 by the entropy coding described above.

[0048] In step 115, filtering is performed on the frames of the reconstructed video signal in a manner similar to step 107 of 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 are filtered, the video signal may be output to a display in step 117 for viewing by an end user.

[0049] FIG. 2 is a schematic diagram of an exemplary coding and decoding (codec) system 200 for video coding. Specifically, the codec system 200 provides functionality to support the implementation of the operational method 100. The codec system 200 is generalized to illustrate components used in both an encoder and a decoder. The codec system 200 receives and segments a video signal as discussed for steps 101 and 103 of the operational method 100, resulting in a segmented video signal 201. The codec system 200 then compresses the segmented video signal 201 into a coded bitstream when acting as an encoder as discussed for steps 105, 107, and 109 of the method 100. When acting as a decoder, the codec system 200 generates an output video signal from the bitstream as discussed for steps 111, 113, 115, and 117 of the operational method 100. Codec system 200 includes general coder control component 211, transform, scaling and quantization component 213, intra picture estimation component 215, intra picture prediction component 217, motion compensation component 219, motion estimation component 221, scaling and inverse transform component 229, filter control analysis component 227, in-loop filter component 225, decoded picture buffer component 223, and header format and context adaptive binary arithmetic coding (CABAC) component 231. Such components are coupled as shown. In FIG. 2, the black lines indicate the movement of data to be coded / decoded, while the dashed lines indicate the movement of control data that controls the operation of the other components. The components of codec system 200 may all be present in an encoder. 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 are described below.

[0050] The partitioned video signal 201 is a captured video sequence partitioned into blocks of pixels by a coding tree. The coding tree subdivides the blocks of pixels into smaller blocks of pixels using various partitioning modes. These blocks may then be further subdivided into smaller blocks. The blocks may be referred to as nodes of 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 possibly be included in a coding unit (CU). For example, a CU may be a subpart of a CTU that includes a luma block, a red difference (Cr) block, and a blue difference (Cb) block with corresponding syntax instructions for the CU. The partitioning modes may include a binary tree (BT), a ternary tree (TT), and a quad tree (QT) that are used to partition the node into two, three, or four child nodes, each of which has a shape that varies depending on the partitioning mode used. The segmented 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.

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

[0052] 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 to select, for example, an appropriate coding mode for each block of video data.

[0053] The motion estimation component 221 and the motion compensation component 219 may be highly integrated, but are illustrated separately for conceptual purposes. Motion estimation performed by the motion estimation component 221 is a process of generating motion vectors that estimate motion for a video block. A motion vector may indicate, for example, the displacement of an object being coded relative to a predictive block. A predictive block is a block that is known to closely match a block being coded in terms of pixel difference. A predictive block may also be referred to as a reference block. Such pixel difference may be determined by sum of absolute difference (SAD), sum of squared difference (SSD), or other difference metric. 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) that includes predictive data for the CU and / or a transform unit (TU) that includes transformed residual data. The motion estimation component 221 generates the 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 the current block / frame and select the reference block, motion vector, etc. with 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 efficiency of coding (e.g., the size of the final encoding).

[0054] In some examples, the codec system 200 may calculate values ​​for sub-integer pixel locations of the reference picture stored in the decoded picture buffer component 223. For example, the video codec system 200 may interpolate values ​​for quarter pixel locations, eighth pixel locations, or other fractional pixel locations of the reference picture. Thus, the motion estimation component 221 may perform motion searches for full pixel locations and fractional pixel locations and output motion vectors with fractional pixel accuracy. The motion estimation component 221 calculates motion vectors for PUs of video blocks in an inter-coded slice by comparing the location of the PU with the location of a predictive block of the reference picture. The motion estimation component 221 outputs the calculated motion vectors as motion data to the header format and CABAC component 231 for encoding and outputs motion to the motion compensation component 219.

[0055] The motion compensation performed by the motion compensation component 219 may include retrieving or generating a predictive block based on a motion vector determined by the motion estimation component 221. Again, the motion estimation component 221 and the motion compensation component 219 may be functionally integrated in some examples. Upon receiving a motion vector for a PU of a current video block, the motion compensation component 219 may find a 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. In general, the motion estimation component 221 performs motion estimation on the luma component, and the 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 the residual block are forwarded to the transform, scaling, and quantization component 213.

[0056] The partitioned video signal 201 is also sent to an intra picture estimation component 215 and an intra picture prediction component 217. As with 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 illustrated separately for conceptual purposes. The intra picture estimation component 215 and the intra picture prediction component 217 intra predict a current block relative to blocks in a 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 an intra prediction mode to use for encoding the current block. In some examples, the intra picture estimation component 215 selects an appropriate intra prediction mode for encoding the current block from a plurality of tested intra prediction modes. The selected intra prediction mode is then forwarded to the header format and CABAC component 231 for encoding.

[0057] For example, the intra picture estimation component 215 calculates a rate-distortion value using a rate-distortion analysis for various tested intra prediction modes and selects an intra prediction mode with the best rate-distortion characteristics among the tested modes. The rate-distortion analysis generally determines the amount of distortion (or error) between an encoded block and the original uncoded block that was encoded to generate the encoded block, and the bit rate (e.g., number of bits) used to generate the encoded block. The intra picture estimation component 215 calculates a ratio from the distortion and rate for the various encoded blocks to determine which intra prediction mode exhibits the best rate-distortion value for the block. Furthermore, the intra picture estimation component 215 may be configured to code a depth block of a depth map using a depth modeling mode (DMM) based on a rate-distortion optimization (RDO).

[0058] The intra-picture prediction component 217, when implemented in an encoder, may generate a residual block from the prediction block based on a selected intra-prediction mode determined by the intra-picture estimation component 215, or, when implemented in a decoder, may read the residual block from the bitstream. The residual block includes the value difference 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 luma and chroma components.

[0059] 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 similarly conceptualized transform, to the residual block to generate a video block including 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 a pixel value domain to a transform domain, such as a frequency domain. The transform, scaling and quantization component 213 is further configured to scale the transformed residual information, for example, based on frequency. Such scaling may include applying a scale factor to the residual information such 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 further 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 modified 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 format and CABAC component 231 for encoding into the bitstream.

[0060] 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, inverse transform, and / or inverse quantization to reconstruct a residual block in the pixel domain, for example, for later use as a reference block that may become a predictive block for other current blocks. The motion estimation component 221 and / or the motion compensation component 219 may calculate a reference block by adding the residual block back to the corresponding predictive block for use in motion estimation of a later block / frame. A filter is applied to the reconstructed reference block to mitigate artifacts introduced during the scaling, quantization, and transformation. Such artifacts would otherwise result in inaccurate predictions (and cause further artifacts) when subsequent blocks are predicted.

[0061] The filter control analysis component 227 and the in-loop filter component 225 apply filters to the residual block and / or the reconstructed image block. For example, the transformed residual block from the scaling and inverse transform component 229 may be combined with the corresponding prediction block from the intra-picture prediction component 217 and / or the motion compensation component 219 to reconstruct the original image block. A filter may then be applied to the reconstructed image block. In some examples, the filter may be applied to the residual block instead. As with the other components of FIG. 2, the filter control analysis component 227 and the in-loop filter component 225 may be highly integrated and implemented together, but are illustrated separately for conceptual purposes. The filters applied to the reconstructed reference block are applied to a particular spatial region and include multiple parameters to adjust how such filters are applied. The filter control analysis component 227 analyzes the reconstructed reference block to determine where such filters should be applied and sets the corresponding parameters. Such data is forwarded as filter control data to the header format and CABAC component 231 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., to the reconstructed pixel blocks) or in the frequency domain, depending on the example.

[0062] When operating as an encoder, the filtered reconstructed image blocks, residual blocks, and / or predictive blocks are stored in a 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 and forwards the reconstructed and filtered blocks to a display as part of the output video signal. The decoded picture buffer component 223 may be any memory device capable of storing predictive blocks, residual blocks, and / or reconstructed image blocks.

[0063] The header format 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. In particular, the header format and CABAC component 231 generates various headers for encoding control data, such as general control data and filter control data. In addition, prediction data, including intra prediction and motion data, as well as residual data in the form of quantized transform coefficient data, are all encoded into the bitstream. The final bitstream contains all the information desired by the decoder to reconstruct the original partitioned video signal 201. Such information may also include an index table of intra prediction modes (also referred to as a codeword mapping table), definitions of coding contexts for various blocks, indications of the most likely intra prediction modes, indications of partitioning information, and the like. Such data may be encoded by using entropy coding. For example, the information may be coded using context adaptive variable length coding (CAVLC), CABAC, syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or other entropy coding techniques. After entropy coding, the coded bitstream may be transmitted to another device (e.g., a video decoder) or archived for later transmission or retrieval.

[0064] 3 is a block diagram illustrating an example video encoder 300. Video encoder 300 may be used to perform the encoding functions of codec system 200 and / or perform steps 101, 103, 105, 107, and / or 109 of method of operation 100. Encoder 300 segments an input video signal, resulting in a segmented video signal 301 that is substantially similar to segmented video signal 201. Segmented video signal 301 is then compressed and encoded into a bitstream by components of encoder 300.

[0065] 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 a reference block 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 block and the residual block 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 block. The transform and quantization component 313 may be substantially similar to the transform, scaling and quantization component 213. The transformed and quantized residual block and the corresponding prediction block are forwarded (together with associated control data) to an entropy coding component 331 for coding into a bitstream. The entropy coding component 331 may be substantially similar to the header format and CABAC component 231 .

[0066] The transformed and quantized residual block and / or the corresponding prediction block are also forwarded from the transform and quantization component 313 to an inverse transform and quantization component 329 for reconstruction into a reference block for use 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 of an in-loop filter component 325 is also applied to the residual block and / or the reconstructed reference block, as the case may be. 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 discussed for the in-loop filter component 225. The filtered block is then stored in a 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.

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

[0068] The bitstream is received by the entropy decoding component 433. The entropy decoding component 433 is configured to perform 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 a context for interpreting further data coded as codewords in the bitstream. The decoded information includes any desired information for decoding a video signal, such as general control data, filter control data, partitioning information, motion data, prediction data, and quantized transform coefficients from residual blocks. 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.

[0069] The reconstructed residual block and / or predictive block are forwarded to an 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 the prediction mode to find a reference block in 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 the corresponding inter prediction data are forwarded to the decoded picture buffer component 423 via an in-loop filter component 425, which 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, the residual block, and / or the 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 generates a prediction block using a motion vector from a reference block and applies a residual block to the result to reconstruct an image block. The resulting reconstructed block may also be forwarded to the decoded picture buffer component 423 via the in-loop filter component 425. The decoded picture buffer component 423 continues to store further reconstructed image blocks, which may be reconstructed into frames according to the partitioning information. Such frames may also be arranged into sequences. The sequences are output to a display as a reconstructed output video signal.

[0070] 5 is a schematic diagram illustrating an example mechanism of a WPP 500. For example, the WPP 500 may be used as part of the method 100 to encode and / or decode a slice 501. Thus, the WPP 500 may be used by the codec system 200, the encoder 300, and / or the decoder 400.

[0071] As shown, the WPP 500 is applied to a slice 501. The slice 501 is a partition of a picture. Specifically, a picture may be partitioned into one or more slices 501. The slice 501 may include an integer number of consecutive complete CTU rows 521, 522, 523, 524, and 525. Furthermore, the slice 501 and all subdivisions (e.g., CTUs 511 and 512) are exclusively contained in a single NAL unit. When the slice 501 includes an integer number of consecutive complete CTU rows 521, 522, 523, 524, and 525, the WPP 500 may be applied. Optionally, in some examples, the slice 501 may include one or more tiles, and such tiles may include an integer number of consecutive complete CTU rows 521, 522, 523, 524, and 525, respectively. Thus, a slice 501 is defined in the VVC standard as an integer number of complete tiles of a picture contained exclusively in a single NAL unit or an integer number of consecutive complete CTU rows 521-525 within a tile.

[0072] Slice 501 includes CTUs 511 and 512. CTUs 511 / 512 are groups of samples of a predefined size that may be partitioned into coding blocks by a coding tree. For example, CTUs 511 and 512 may be arranged in CTU rows 521-525 and CTU column 516. CTU rows 521-525 are groups of CTUs 511 / 512 that extend horizontally between a left boundary of slice 501 and a right boundary of slice 501. CTU column 516 is a group of CTUs 511 / 512 that extend vertically between a top boundary of slice 501 and a bottom boundary of slice 501.

[0073] WPP 500 may use multiple computational threads operating in parallel to code CTU 511 / 512. In the illustrated example, CTU 511 has already been coded and CTU 512 has not yet been coded. For example, a first thread may start coding row 521 of the CTU at a first time. Once CTU 511 is coded in row 521 of the first CTU, a second thread may start coding row 522 of the CTU. Once CTU 511 is coded in row 522 of the second CTU, a third thread may start coding row 523 of the CTU. Once CTU 511 is coded in row 523 of the third CTU, a fourth thread may start coding row 524 of the CTU. Once CTU 511 is coded in row 524 of the fourth CTU, a fifth thread may start coding row 525 of the fifth CTU. This results in the pattern shown in FIG. 5. Additional threads may be used as desired. This mechanism results in a pattern that looks similar to a wavefront, hence the name WPP 500. Some video coding techniques code the current CTU 512 based on coded CTUs 511 located above or to the left of the current CTU 512. WPP 500 leaves a CTU 511 coding delay between the start of each thread to ensure that any current CTU 512 to be coded is already coded when such CTU 511 is reached. Note that systems using the VVC standard may use one CTU 511 coding delay, while other systems such as HEVC may use two CTU 511 coding delays. Any other CTU 511 coding delay values ​​may also be used within the scope of this disclosure.

[0074] CTU 511 is coded into the bitstream in CTU rows 521-525. For example, CTU row 521 may be included in the bitstream, followed by CTU row 522, followed by CTU row 523, followed by CTU row 524, followed by CTU row 525, and so on. Each CTU row 521-525 may be an independently addressable subset of slice 501 in the bitstream. For example, each CTU row 521-525 may be addressed at entry point 517. Entry point 517 is a bit position in the bitstream that contains the first bit of video data for the corresponding subset of slice 501 after slice 501 has been coded. When WPP 500 is used, entry point 517 is a bit position that contains the first bit of the corresponding CTU row 521-525. For example, entry point 517 of CTU row 523 includes the first bit of video data for CTU row 523 and is positioned after the last bit of video data for CTU row 522. Thus, number of entry points (NumEntryPoints) 518 is the number of entry points 517 for CTU rows 521-525.

[0075] In some video coding systems, the bit offsets for the entry points 517 may be signaled in an array in a slice header associated with the slice 501. Additionally, the encoder may determine NumEntryPoints 518 and signal such data in the slice header, e.g., in a num_entry_point_offsets parameter. The decoder may then use the number of entry points 517 to determine how many bit offsets should be obtained from the array to obtain all relevant entry points 517 to begin decoding. The num_entry_point_offsets parameter includes multiple bits and is signaled in each slice header. Because each picture may include several slices 501 and a video sequence may include thousands of pictures, num_entry_point_offsets may be signaled many times and may have a significant collective impact on the amount of data in a video sequence.

[0076] This disclosure includes various mechanisms for deriving NumEntryPoints 518 at the decoder (and / or the HRD of the encoder) without signaling such data in the bitstream. Thus, num_entry_point_offsets can be omitted from the bitstream, which significantly improves overall bitstream compression. For example, mechanisms may be used to derive NumEntryPoints 518 for slice 501 when slice 501 is coded by WPP 500. NumEntryPoints 518 may be derived based on the size of CTU rows 521-525, based on the size of CTU columns 516, based on the number of CTUs 511 / 512 in slice 501, and / or based on the addresses of CTUs 511 / 512 and / or slice 501.

[0077] For example, NumEntryPoints 518 may be derived as follows: if( !entropy_coding_sync_enabled_flag ) NumEntryPoints = NumBricksInCurrSlice - 1 else { for( numBrickSpecificCtuRowsInSlice = 0, i =0; i < NumBricksInCurrSlice; i++ ) numBrickSpecificCtuRowsInSlice += BrickHeight[ SliceBrickIdx[ i ] ] NumEntryPoints = numBrickSpecificCtuRowsInSlice - 1 } where !entropy_coding_sync_enabled_flag indicates that WPP 500 is not used, NumBricksInCurrSlice is the number of tiles in slice 501, numBrickSpecificCtuRowsInSlice is the number of CTU rows 521-525 in slice 501, and BrickHeight[ SliceBrickIdx[ i ] ] is the height of CTU rows 521-525 (and thus the height of CTU column 516). Note that entropy_coding_sync_enabled_flag may be used to indicate whether WPP 500 is used to code slice 501. For example, entropy_coding_sync_enabled_flag may be set to 1 when WPP 500 is used and set to 0 when WPP 500 is not used. In some coding systems, ! indicates a negative value. Thus, !entropy_coding_sync_enabled_flag indicates that for the if clause in the pseudocode above, WPP 500 is not being used. Therefore, WPP is being used for the else clause in the pseudocode above.

[0078] The example checks whether slice 501 uses WPP 500. If WPP 500 is not used, NumEntryPoints 518 is one less than the number of tiles in slice 501. Otherwise, WPP 500 is used. In such a case, the example determines the number of rows 521-525 of the CTU by summing the height of each of the rows 521-525 of the CTU compared to the height of slice 501 (and thus the height of the columns 516 of the CTU). NumEntryPoints 518 is one less than the number of rows 521-525 of the CTU.

[0079] 6 is a schematic diagram illustrating an example bitstream 600. For example, the bitstream 600 may be generated by the codec system 200 and / or the encoder 300 for decoding by the codec system 200 and / or the decoder 400 according to the method 100. Furthermore, the bitstream 600 may include a slice 501 coded by the WPP 500.

[0080] The bitstream 600 includes an SPS 610, a number of picture parameter sets (PPS) 611, a number of slice headers 615, and image data 620. The SPS 610 includes sequence data common to all pictures in the coded video sequence included in the bitstream 600. Such data may include picture sizing, bit depth, coding tool parameters, bit rate constraints, and the like. The PPS 611 includes parameters that apply to the entire picture. Thus, each picture in the video sequence may reference the PPS 611. Note that while each picture references the PPS 611, in some examples, a single PPS 611 may include data for multiple pictures. For example, multiple similar pictures may be coded with similar parameters. In such cases, a single PPS 611 may include data for such similar pictures. The PPS 611 may indicate available coding tools, quantization parameters, offsets, and the like for slices in the corresponding picture. The slice header 615 includes parameters specific to each slice in the picture. Thus, there may be one slice header 615 for each slice in a video sequence. The slice header 615 may include slice type information, POC, reference picture list, prediction weights, tile entry points, deblocking parameters, etc. Note that the slice header 615 may also be referred to as a tile group header in some contexts.

[0081] The image data 620 includes video data coded by inter-prediction and / or intra-prediction as well as corresponding transformed and quantized residual data. For example, a video sequence includes a plurality of pictures 621. A picture 621 is a complete image intended for complete or partial display to a user at a corresponding instant in the video sequence. A picture 621 may be included in a single access unit (AU). A picture 621 includes one or more slices 623. A slice 623 may be defined as an integer number of complete tiles or an integer number of consecutive complete rows of CTUs (e.g., within a tile) of the picture 621 exclusively included in a single NAL unit. For example, a slice 623 may be substantially similar to slice 501. A slice 623 is further divided into CTUs 625 and / or coding tree blocks (CTBs). A CTU 625 is a group of samples of a predefined size that may be partitioned by a coding tree. For example, CTU 625 in bitstream 600 may be coded and therefore substantially similar to CTU 511. A CTB is a subset of CTU 625 and includes the luma or chroma components of the CTU. CTU 625 / CTB is further divided into coding blocks based on a coding tree. Then, the coding blocks may be coded / decoded by a prediction mechanism.

[0082] As mentioned above, NumEntryPoints 518 may be determined at the decoder. Thus, the slice header 615 does not include a num_entry_point_offsets parameter or other parameter that indicates the value of NumEntryPoints 518. The num_entry_point_offsets is removed from each slice header 615 and the bitstream 600 is compressed. This reduces memory and network resource usage at both the encoder and the decoder.

[0083] The above information will be described in more detail below in this specification. In the specification of a video codec, a picture should be identified for multiple purposes. These include for use as a reference picture in inter prediction, for output of a picture from the DPB, for motion vector scaling, for weighted prediction, etc. For example, a picture may be identified by a picture order count (POC). In some video coding systems, a picture in the DPB may be marked as used for short-term reference, used for long-term reference, or not used for reference. When a picture is marked as not used for reference, the picture may no longer be used for prediction. When such a picture is no longer needed for output, the picture may be deleted from the DPB.

[0084] Some video coding systems use short-term and long-term reference pictures. A reference picture may be marked as unused for reference when the picture is no longer needed for use as a prediction reference. The conversion of a picture between these three statuses (e.g., short-term, long-term, and unused for reference) may be controlled by a marking process of a decoded reference picture. For example, an implicit sliding window process and / or an explicit memory management control operation (MMCO) process may be used to mark a reference picture. The sliding window process marks a short-term reference picture as unused for reference when the number of reference frames is equal to the maximum number of reference frames (max_num_ref_frames) that can be stored in the SPS. The short-term reference pictures may be stored in a first-in-first-out manner such that the most recently decoded short-term picture is retained in the DPB. An explicit MMCO process may include multiple MMCO commands. The MMCO command may mark one or more short-term or long-term reference pictures as unused for reference, may mark all pictures as unused for reference, or may mark the current reference picture or an existing short-term reference picture as long-term and assign a long-term picture index to the long-term reference picture. In some video coding systems, the reference picture marking operation and the process for outputting and deleting pictures from the DPB are performed after the pictures are decoded.

[0085] Other video coding systems use a reference picture set (RPS) for reference picture management. One difference between the RPS process and the MMCO / sliding window process is that a complete set of reference pictures used by the current picture or any subsequent pictures is provided for each slice. Thus, the complete set of all pictures to be retained in the DPB for use by the current or future pictures is signaled. This differs from schemes that signal only relative changes to the DPB. The RPS mechanism does not need to retain information from previous pictures in the decoding order to maintain the correct status of the reference pictures in the DPB. Corresponding changes in picture decoding and DPB operation may be used to take advantage of the RPS and increase error resilience. In some video coding systems, picture marking and buffer operations, including both output and removal of decoded pictures from the DPB, may be applied after the current picture is decoded. In other video coding systems, the RPS is first decoded from the slice header of the current picture. Picture marking and buffering operations are then generally applied before decoding the current picture.

[0086] Other video coding systems manage reference pictures based on two reference picture lists, denoted as Reference Picture List 0 and Reference Picture List 1. In this approach, a reference picture list for a picture may be directly constructed without using a reference picture list initialization process and a reference picture list modification process. Furthermore, reference picture marking is performed directly based on the two reference picture lists. Syntax and semantics related to an exemplary reference picture management are as follows:

[0087] The syntax of an exemplary sequence parameter set RBSP is as follows:

[0088] [Table 1]

[0089] The syntax of an exemplary picture parameter set RBSP is as follows:

[0090] [Table 2]

[0091] An example of the syntax of a general slice header is as follows:

[0092] [Table 3A]

[0093] [Table 3B]

[0094] The syntax of an exemplary reference picture list structure is as follows:

[0095] [Table 4]

[0096] The semantics of the RBSP for an example sequence parameter set are as follows: log2_max_pic_order_cnt_lsb_minus4 specifies the value of the variable MaxPicOrderCntLsb used in the decoding process for picture order count as follows: log2_max_pic_order_cnt_lsb_minus4 specifies the value of the variable MaxPicOrderCntLsb used in the decoding process for picture order count as follows: MaxPicOrderCntLsb = 2 ( log2_max_pic_order_cnt_lsb_minus4 + 4 ) (7-7) The value of log2_max_pic_order_cnt_lsb_minus4 may range from 0 to 12, inclusive. The value of sps_max_dec_pic_buffering_minus1 plus 1 specifies the maximum required size of the decoded picture buffer for the CVS in units of the picture storage buffer. The value of sps_max_dec_pic_buffering_minus1 may range from 0 to MaxDpbSize - 1, inclusive, where MaxDpbSize is specified elsewhere. long_term_ref_pics_flag may be set equal to 0 to specify that long-term reference pictures (LTRPs) are not used for inter prediction of any coded pictures in the CVS. long_term_ref_pics_flag may be set equal to 1 to specify that LTRPs may be used for inter prediction of one or more coded pictures in the CVS. sps_idr_rpl_present_flag may be set equal to 1 to specify that the reference picture list syntax element is present in the slice header of the IDR picture. sps_idr_rpl_present_flag may be set equal to 0 to specify that the reference picture list syntax element is not present in the slice header of the IDR picture.

[0097] rpl1_same_as_rpl0_flag may be set equal to 1 to specify that the syntax structures num_ref_pic_lists_in_sps

[0001] and ref_pic_list_struct(1, rplsIdx) are not present and the following applies: The value of num_ref_pic_lists_in_sps

[0001] is inferred to be equal to the value of num_ref_pic_lists_in_sps

[0000] . The value of each syntax element of ref_pic_list_struct(1, rplsIdx) is inferred to be equal to the value of the corresponding syntax element of ref_pic_list_struct(0, rplsIdx) for rplsIdx in the range from 0 to num_ref_pic_lists_in_sps

[0000] - 1. num_ref_pic_lists_in_sps[ i ] specifies the number of ref_pic_list_struct( listIdx, rplsIdx ) syntax structures with listIdx equal to i contained in the SPS. The value of num_ref_pic_lists_in_sps[ i ] can be in the range of 0 to 64, inclusive. For each value of listIdx (equal to 0 or 1), the decoder should allocate memory for a total of num_ref_pic_lists_in_sps[ i ] + 1 ref_pic_list_struct( listIdx, rplsIdx ) syntax structures, since there can be one ref_pic_list_struct( listIdx, rplsIdx ) syntax structure directly signaled in the slice header of the current picture.

[0098] The semantics of the RBSP of an example picture parameter set are as follows: The value of num_ref_idx_default_active_minus1[ i ] plus 1 specifies the inferred value of the variable NumRefIdxActive

[0000] for a P or B slice with num_ref_idx_active_override_flag equal to 0 when i is equal to 0, and specifies the inferred value of NumRefIdxActive

[0001] for a B slice with num_ref_idx_active_override_flag equal to 0 when i is equal to 1. The value of num_ref_idx_default_active_minus1[ i ] should be in the range of 0 to 14, inclusive. rpl1_idx_present_flag may be set equal to 0 to specify that ref_pic_list_sps_flag

[0001] and ref_pic_list_idx

[0001] are not present in the slice header. rpl1_idx_present_flag may be set equal to 1 to specify that ref_pic_list_sps_flag

[0001] and ref_pic_list_idx

[0001] may be present in the slice header.

[0099] Example semantics of the general slice header are as follows: slice_pic_order_cnt_lsb specifies the picture order count remainder divided by MaxPicOrderCntLsb for the current picture. The length of the slice_pic_order_cnt_lsb syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits. The value of slice_pic_order_cnt_lsb should be in the range from 0 to MaxPicOrderCntLsb - 1, inclusive. ref_pic_list_sps_flag[ i ] may be set equal to 1 to specify that reference picture list i of the current slice is derived based on one of the ref_pic_list_struct( listIdx, rplsIdx ) syntax structures with listIdx equal to i in the active SPS. ref_pic_list_sps_flag[ i ] may be set equal to 0 to specify that the reference picture list i of the current picture is derived based on the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure with listIdx equal to i that is directly included in the slice header of the current picture. When num_ref_pic_lists_in_sps[ i ] is equal to 0, the value of ref_pic_list_sps_flag[ i ] is inferred to be equal to 0. When rpl1_idx_present_flag is equal to 0, the value of ref_pic_list_sps_flag[ 0001 ] is inferred to be equal to ref_pic_list_sps_flag[ 0000 ].

[0100] ref_pic_list_idx[ i ] specifies an index into the list of ref_pic_list_struct( listIdx, rplsIdx ) syntax structures with listIdx equal to i contained in the active SPS that are used for the derivation of reference picture list i of the current picture. The syntax element ref_pic_list_idx[ i ] is represented by Ceil( Log2( num_ref_pic_lists_in_sps[ i ] ) ) bits. When not present, the value of ref_pic_list_idx[ i ] is inferred to be equal to 0. The value of ref_pic_list_idx[ i ] is in the range of 0 to num_ref_pic_lists_in_sps[ i ] - 1, inclusive. When ref_pic_list_sps_flag[ i ] is equal to 1 and num_ref_pic_lists_in_sps[ i ] is equal to 1, the value of ref_pic_list_idx[ i ] is inferred to be equal to 0. When ref_pic_list_sps_flag[ i ] is equal to 1 and rpl1_idx_present_flag is equal to 0, the value of ref_pic_list_idx

[0001] is inferred to be equal to ref_pic_list_idx

[0000] .

[0101] The variable RplsIdx[ i ] is derived as follows. RplsIdx[ i ] = ref_pic_list_sps_flag[ i ] ? ref_pic_list_idx[ i ] : num_ref_pic_lists_in_sps[ i ] (7-40) slice_poc_lsb_lt[ i ][ j ] specifies the remainder when the picture order count value is divided by MaxPicOrderCntLsb of the jth LTRP entry of the ith reference picture list. The length of the slice_poc_lsb_lt[ i ][ j ] syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits.

[0102] The variables PocLsbLt[i][j] are derived as follows. PocLsbLt[ i ][ j ] = ltrp_in_slice_header_flag[ i ][ RplsIdx[ i ] ] ? (7-41) slice_poc_lsb_lt[ i ][ j ] : rpls_poc_lsb_lt[ listIdx ][ RplsIdx[ i ] ][ j ] delta_poc_msb_present_flag[ i ][ j ] may be set equal to 1 to specify that delta_poc_msb_cycle_lt[ i ][ j ] is present. delta_poc_msb_present_flag[ i ][ j ] may be set equal to 0 to specify that delta_poc_msb_cycle_lt[ i ][ j ] is not present. Let prevTid0Pic be the previous picture in decoding order that has TemporalId equal to 0 and is not a random access skipped leading (RASL) or random access decodable leading (RADL) picture. Let setOfPrevPocVals be the set containing the following: PicOrderCntVal of prevTid0Pic, the PicOrderCntVal of each picture referenced by the RefPicList

[0000] entry and RefPicList

[0001] entry for prevTid0Pic, and the PicOrderCntVal of each picture that follows prevTid0Pic in decoding order and precedes the current picture in decoding order. When there are two or more values ​​in setOfPrevPocVals whose value modulo MaxPicOrderCntLsb equals PocLsbLt[i][j], the value of delta_poc_msb_present_flag[i][j] shall be equal to 1.

[0103] delta_poc_msb_cycle_lt[i][j] specifies the value of the variable FullPocLt[i][j] as follows: if( j == 0 ) deltaMsbCycle[ i ][ j ] = delta_poc_msb_cycle_lt[ i ][ j ] else (7-42) deltaMsbCycle[ i ][ j ] = delta_poc_msb_cycle_lt[ i ][ j ] + deltaMsbCycle[ i ][ j - 1 ] FullPocLt[ i ][ RplsIdx[ i ] ][ j ] = PicOrderCntVal - deltaMsbCycle[ i ][ j ] * MaxPicOrderCntLsb - ( PicOrderCntVal & ( MaxPicOrderCntLsb - 1 ) ) + PocLsbLt[ i ][ j ]

[0104] The value of delta_poc_msb_cycle_lt[ i ][ j ] should be in the range of 0 to 2(32 - log2_max_pic_order_cnt_lsb_minus4 - 4), inclusive. When not present, the value of delta_poc_msb_cycle_lt[ i ][ j ] is inferred to be equal to 0. num_ref_idx_active_override_flag may be set equal to 1 to specify that the syntax element num_ref_idx_active_minus1

[0000] is present for P and B slices and that the syntax element num_ref_idx_active_minus1

[0001] is present for B slices. The num_ref_idx_active_override_flag may be set equal to 0 to specify that the syntax elements num_ref_idx_active_minus1

[0000] and num_ref_idx_active_minus1

[0001] are not present. When not present, the value of num_ref_idx_active_override_flag is inferred to be equal to 1. The num_ref_idx_active _minus1[ i ] is used to derive the variable NumRefIdxActive[ i ]. The value of num_ref_idx_active_minus1[ i ] may be in the range of 0 to 14, inclusive. For i equal to 0 or 1, when the current slice is a B slice, num_ref_idx_active_override_flag is equal to 1, and num_ref_idx_active_minus1[ i ] is not present, num_ref_idx_active_minus1[ i ] is inferred to be equal to 0. When the current slice is a P slice, num_ref_idx_active_override_flag is equal to 1, and num_ref_idx_active_minus1

[0000] is not present, num_ref_idx_active_minus1

[0000] is inferred to be equal to 0.

[0105] The variable NumRefIdxActive[ i ] is derived as follows. for( i = 0 ; i < 2 ; i++ ) { if( slice_type == B || ( slice_type == P && i == 0 ) ) { if( num_ref_idx_active_override_flag ) NumRefIdxActive[ i ] = num_ref_idx_active_minus1[ i ] + 1 (7-43) else { if( num_ref_entries[ i ][ RplsIdx[ i ] ] >= num_ref_idx_default_active_minus1[ i ] + 1 ) NumRefIdxActive[ i ] = num_ref_idx_default_active_minus1[ i ] + 1 else NumRefIdxActive[ i ] = num_ref_entries[ i ][ RplsIdx[ i ] ] } } else / / slice_type == I || ( slice_type == P && i == 1 ) NumRefIdxActive[ i ] = 0 }

[0106] The value of NumRefIdxActive[ i ] - 1 specifies the maximum reference index for reference picture list i that may be used to decode a slice. When the value of NumRefIdxActive[ i ] is equal to 0, no reference index for reference picture list i may be used to decode a slice. The variable CurrPicIsOnlyRef, which specifies that the current decoded picture is the only reference picture for the current slice, is derived as follows: CurrPicIsOnlyRef = sps_cpr_enabled_flag && ( slice_type == P ) && (7-44) ( num_ref_idx_active_minus1

[0000] == 0 )

[0107] The semantics of an exemplary reference picture list structure are as follows: The ref_pic_list_struct( listIdx, rplsIdx ) syntax structure may be present in an SPS or in a slice header. Depending on whether the syntax structure is included in a slice header or an SPS, the following applies: If present in a slice header, the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure specifies the listIdx of a reference picture list of the current picture (e.g., the picture that contains the slice). If not (e.g., present in the SPS), the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure specifies candidates for the reference picture list listIdx, and the term current picture in semantics refers to each picture that 1) has one or more slices with ref_pic_list_idx[ listIdx ] equal to an index into the list of ref_pic_list_struct( listIdx, rplsIdx ) syntax structures contained in the SPS, and 2) is in a CVS that has the SPS as its active SPS.

[0108] num_ref_entries[listIdx][rplsIdx] specifies the number of entries in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. The value of num_ref_entries[listIdx][rplsIdx] should be in the range of 0 to sps_max_dec_pic_buffering_minus1 + 14, inclusive. ltrp_in_slice_header_flag[listIdx][rplsIdx] may be set equal to 0 to specify that the POC LSB of the LTRP entry in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is present in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. ltrp_in_slice_header_flag[listIdx][rplsIdx] may be set equal to 1 to specify that the POC LSB of the LTRP entry of the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is not present in the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. st_ref_pic_flag[listIdx][rplsIdx][i] may be set equal to 1 to specify that the i-th entry of the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is a short-term reference picture (STRP) entry. st_ref_pic_flag[listIdx][rplsIdx][i] may be set equal to 0 to specify that the i-th entry of the ref_pic_list_struct(listIdx,rplsIdx) syntax structure is an LTRP entry. When not present, the value of st_ref_pic_flag[listIdx][rplsIdx][i] is inferred to be equal to 1.

[0109] The variables NumLtrpEntries[listIdx][rplsIdx] may be derived as follows: for( i = 0, NumLtrpEntries[ listIdx ][ rplsIdx ] = 0; i < num_ref_entries[ listIdx ][ rplsIdx ]; i++ ) if( !st_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] ) (7-86) NumLtrpEntries[ listIdx ][ rplsIdx ]++

[0110] abs_delta_poc_st[listIdx][rplsIdx][i] specifies the absolute difference between the value of the picture order count of the current picture and the value of the picture order count of the picture referenced by the i-th entry when the i-th entry is the first STRP entry of the ref_pic_list_struct(listIdx,rplsIdx) syntax structure, or specifies the absolute difference between the value of the picture order count of the picture referenced by the i-th entry and the value of the picture order count of the picture referenced by the previous STRP entry of the ref_pic_list_struct(listIdx,rplsIdx) syntax structure when the i-th entry is a STRP entry of the ref_pic_list_struct(listIdx,rplsIdx) syntax structure but is not the first STRP entry. The value of abs_delta_poc_st[listIdx][rplsIdx][i] may be between 0 and 2. 15 - 0 to 2, inclusive 15-1. strp_entry_sign_flag[listIdx][rplsIdx][i] may be set equal to 1 to specify that the i-th entry of the syntax structure ref_pic_list_struct(listIdx,rplsIdx) has a value greater than or equal to 0. strp_entry_sign_flag[listIdx][rplsIdx] may be set equal to 0 to specify that the i-th entry of the syntax structure ref_pic_list_struct(listIdx,rplsIdx) has a value less than 0. When not present, the value of strp_entry_sign_flag[i][j] is inferred to be equal to 1.

[0111] The list DeltaPocSt[listIdx][rplsIdx] is derived as follows. for( i = 0; i < num_ref_entries[ listIdx ][ rplsIdx ]; i++ ) { if( st_ref_pic_flag[ listIdx ][ rplsIdx ][ i ] ) { (7-87) DeltaPocSt[ listIdx ][ rplsIdx ][ i ] = ( strp_entry_sign_flag[ listIdx ][ rplsIdx ][ i ]) ? abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] : 0 - abs_delta_poc_st[ listIdx ][ rplsIdx ][ i ] } }

[0112] rpls_poc_lsb_lt[ listIdx ][ rplsIdx ][ i ] specifies the remainder of the picture order count value divided by MaxPicOrderCntLsb of the picture referenced by the i-th entry of the ref_pic_list_struct( listIdx, rplsIdx ) syntax structure. The length of the rpls_poc_lsb_lt[ listIdx ][ rplsIdx ][ i ] syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits.

[0113] To code a video image, the image is first partitioned and the partitions are coded into a bitstream. Various picture partitioning schemes are available. For example, an image may be partitioned into regular slices, dependent slices, tiles, and / or by wavefront parallel processing (WPP). For simplicity, HEVC constrains the encoder such that only regular slices, dependent slices, tiles, WPP, and combinations thereof may be used when partitioning slices into groups of CTBs for video coding. Such partitioning may be applied to support maximum transmission unit (MTU) size matching, parallel processing, and reduced end-to-end delay. The MTU represents the maximum amount of data that can be transmitted in a single packet. If the payload of a packet exceeds the MTU, the payload is split into two packets by a process called fragmentation.

[0114] A regular slice, also referred to simply as a slice, is a partitioned portion of an image that can be reconstructed independently of other regular slices in the same picture, despite some dependencies due to loop filtering operations. Each regular slice is encapsulated in its own network abstraction layer (NAL) unit for transmission. Furthermore, intra-picture prediction (intra-sample prediction, motion information prediction, coding mode prediction) and entropy coding dependencies across slice boundaries can be disabled to support independent reconstruction. Such independent reconstruction supports parallelization. For example, parallelization based on regular slices uses minimal inter-processor or inter-core communication. However, since each regular slice is independent, each slice is associated with a separate slice header. The use of regular slices can incur significant coding overhead due to the bit cost of a slice header for each slice and due to the lack of prediction across slice boundaries. Furthermore, regular slices can be used to support matching on MTU size requirements. Specifically, because regular slices are encapsulated in separate NAL units and may be coded independently, each regular slice should be smaller than the MTU of the MTU scheme to avoid splitting the slice into multiple packets. Thus, the parallelization objective and the MTU size matching objective may impose conflicting requirements on the layout of slices within a picture.

[0115] Dependent slices are similar to regular slices, but have shortened slice headers, allowing partitioning of picture treeblock boundaries without impairing intra-picture prediction. Thus, dependent slices allow regular slices to be fragmented into multiple NAL units, which results in reduced end-to-end delay by allowing parts of a regular slice to be sent before the encoding of the entire regular slice is completed.

[0116] A tile may be a partitioned portion of an image generated by horizontal and vertical boundaries that generate columns and rows of tiles. Tiles may be coded in raster scan order (right to left and top to bottom). The scan order of the CTBs is limited to within the tile. Thus, the CTBs in the first tile are coded in raster scan order before proceeding to the CTBs in the next tile. As with normal slices, tiles break intra-picture prediction dependencies and entropy decoding dependencies. However, tiles may not be included in individual NAL units, and thus tiles may not be used for MTU size matching. Each tile may be processed by one processor / core, and inter-processor / inter-core communication used for intra-picture prediction between processing units that decode neighboring tiles may be limited to carrying a shared slice header (when neighboring tiles are in the same slice) and performing sharing related to loop filtering of reconstructed samples and metadata. When more than one tile is included in a slice, the byte offset of the entry point for each tile other than the offset of the first entry point of the slice may be signaled in the slice header. For each slice and tile, at least one of the following conditions should be satisfied: 1) all coded tree blocks in a slice belong to the same tile, and 2) all coded tree blocks in a tile belong to the same slice.

[0117] In WPP, a picture is partitioned into a single row of CTBs. The entropy decoding and prediction mechanism may use data from the CTBs of other rows. Parallel processing is enabled by the parallel decoding of the rows of CTBs. For example, the current row may be decoded in parallel with the previous row. However, the decoding of the current row is delayed from the decoding process of the previous row by one or two CTBs, as the case may be. This delay ensures that data related to the CTB above the current CTB and the CTB to the right above in the current row is available before the current CTB is coded. This approach appears as a wavefront when represented graphically. This staggered start allows parallelization up to as many processors / cores as the picture contains rows of CTBs. Since intra-picture prediction between neighboring treeblock rows in a picture is allowed, the inter-processor / inter-core communication to enable intra-picture prediction can be significant. WPP partitioning does take into account the size of the NAL units. Therefore, WPP does not support MTU size matching. However, regular slices can be used in conjunction with WPP, with some coding overhead, to achieve the desired MTU size matching.

[0118] In an example, a video coding system may partition an image using slices, tiles, bricks, and WPPs. A picture may be divided into one or more rows of tiles and one or more columns of tiles. A tile may be a sequence of CTUs that encompass a rectangular region of the picture. A tile may be divided into one or more bricks, each of which includes several rows of CTUs in the tile. A tile that is not partitioned into multiple bricks may also be referred to as a brick. A brick that is a pure subset of a tile may not be referred to as a tile. A slice may include several tiles of a picture or several bricks of a tile. Two modes of slices may be supported, including a raster scan slice mode and a rectangular slice mode. In a raster scan slice mode, a slice includes a sequence of tiles of a raster scan of tiles of a picture. In a rectangular slice mode, a slice may include several bricks of a picture that collectively form a rectangular region of the picture. The bricks in a rectangular slice are in the order of the raster scan of the bricks of the slice. The single_tile_in_pic_flag may be set equal to 1 to specify that there is only one tile in the picture and that the single tile is not divided into bricks. The entropy_coding_sync_enabled_flag may be set equal to 1 to specify that WPP is being used.

[0119] The syntax of an exemplary picture parameter set RBSP is as follows:

[0120] [Table 5A]

[0121] [Table 5B]

[0122] [Table 5C]

[0123] An example of the syntax of a general slice header is as follows:

[0124] [Table 6]

[0125] The semantics of an example picture parameter set RBSP are as follows: single_tile_in_pic_flag may be set equal to 1 to specify that there is only one tile in each picture that references the PPS. single_tile_in_pic_flag may be set equal to 0 to specify that there is more than one tile in each picture that references the PPS. If there is no further brick division within the tile, the entire tile may be referred to as a brick. When a picture contains only a single tile without further brick division, the picture may be referred to as a single brick. For bitstream conformance, the value of single_tile_in_pic_flag should be the same for all PPSs activated in the CVS.

[0126] uniform_tile_spacing_flag may be set equal to 1 to specify that the tile column boundaries, and similarly the tile row boundaries, are uniformly distributed in the picture and are signaled using the syntax elements tile_cols_width_minus1 and tile_rows_height_minus1. uniform_tile_spacing_flag may be set equal to 0 to specify that the tile column boundaries, and similarly the tile row boundaries, may or may not be uniformly distributed in the picture and may or may not be signaled using the syntax elements num_tile_columns_minus1 and num_tile_rows_minus1 and the list of syntax element pairs tile_column_width_minus1[ i ] and tile_row_height_minus1[ i ]. If not present, the value of uniform_tile_spacing_flag may be inferred to be equal to 0. The value of tile_cols_width_minus1 plus 1 specifies the width of the tile columns excluding the rightmost tile column of the picture in CTBs when uniform_tile_spacing_flag is equal to 1. The value of tile_cols_width_minus1 can be in the range from 0 to PicWidthInCtbsY - 1, inclusive. When not present, the value of tile_cols_width_minus1 is inferred to be equal to PicWidthInCtbsY - 1.

[0127] The value of tile_rows_height_minus1 plus 1 specifies the height of the rows of tiles in the picture, excluding the bottom row of tiles, in CTBs when uniform_tile_spacing_flag is equal to 1. The value of tile_rows_height_minus1 is in the range of 0 to PicHeightInCtbsY - 1, inclusive. When not present, the value of tile_rows_width_minus1 is inferred to be equal to PicHeightInCtbsY - 1. The value of num_tile_columns_minus1 plus 1 specifies the number of columns of tiles into which the picture is partitioned when uniform_tile_spacing_flag is equal to 0. The value of num_tile_columns_minus1 is in the range of 0 to PicWidthInCtbsY - 1, inclusive. If single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minus1 is inferred to be equal to 0. Otherwise, the value of num_tile_columns_minus1 is inferred when uniform_tile_spacing_flag is equal to 1. The value of num_tile_rows_minus1 plus 1 specifies the number of rows of tiles to partition the picture into when uniform_tile_spacing_flag is equal to 0. The value of num_tile_rows_minus1 is in the range from 0 to PicHeightInCtbsY - 1, inclusive. If single_tile_in_pic_flag is equal to 1, the value of num_tile_rows_minus1 is inferred to be equal to 0. Otherwise, the value of num_tile_rows_minus1 is inferred when uniform_tile_spacing_flag is equal to 1. The variable NumTilesInPic may be set equal to (num_tile_columns_minus1 + 1) * (num_tile_rows_minus1 + 1).

[0128] When single_tile_in_pic_flag is equal to 0, NumTilesInPic shall be greater than 1. tile_column_width_minus1[ i ] plus 1 specifies the width of the column of the i th tile in units of CTBs. tile_row_height_minus1[ i ] plus 1 specifies the height of the row of the i th tile in units of CTBs. brick_splitting_present_flag may be set equal to 1 to specify that one or more tiles of the picture referencing the PPS may be split into two or more bricks. brick_splitting_present_flag may be set equal to 0 to specify that tiles of the picture referencing the PPS are not split into two or more bricks. brick_split_flag[ i ] may be set equal to 1 to specify that the i th tile is split into two or more bricks. brick_split_flag[ i ] may be set equal to 0 to specify that the i th tile is not split into two or more bricks. When not present, the value of brick_split_flag[ i ] is inferred to be equal to 0.

[0129] uniform_brick_spacing_flag[ i ] may be set equal to 1 to specify that the brick borders are uniformly distributed in the i th tile and may be signaled using the syntax element brick_height_minus1[ i ]. uniform_brick_spacing_flag[ i ] may be set equal to 0 to specify that the brick borders may or may not be uniformly distributed in the i th tile and may or may not be signaled using the syntax element num_brick_rows_minus1[ i ] and the list of syntax elements brick_row_height_minus1[ i ][ j ]. When not present, the value of uniform_brick_spacing_flag[ i ] is inferred to be equal to 1. The value of brick_height_minus1[ i ] plus 1 specifies the height of the rows of bricks, excluding the bottommost brick, in the ith tile in units of CTBs when uniform_brick_spacing_flag[ i ] is equal to 1. When present, the value of brick_height_minus1 is in the range from 0 to RowHeight[ i ] - 2, inclusive. When not present, the value of brick_height_minus1[ i ] is inferred to be equal to RowHeight[ i ] - 1. The value of num_brick_rows_minus1[ i ] plus 1 specifies the number of bricks that partition the ith tile when uniform_brick_spacing_flag[ i ] is equal to 0. When present, the value of num_brick_rows_minus1[ i ] can range from 0 to RowHeight[ i ] - 1, inclusive. If brick_split_flag[ i ] is equal to 0, the value of num_brick_rows_minus1[ i ] is inferred to be equal to 0.Otherwise, the value of num_brick_rows_minus1[ i ] is inferred when uniform_brick_spacing_flag[ i ] is equal to 1. The value of brick_row_height_minus1[ i ][ j ] plus 1 specifies the height of the jth brick in the ith tile in CTBs when uniform_tile_spacing_flag is equal to 0.

[0130] The following variables may be derived: the values ​​of num_tile_columns_minus1 and num_tile_rows_minus1 are inferred when uniform_tile_spacing_flag is equal to 1, and for each i in the range 0 to NumTilesInPic - 1, inclusive, the value of num_brick_rows_minus1[ i ] is inferred by the CTB raster and brick scanning conversion process when uniform_brick_spacing_flag[ i ] is equal to 1.The variables that may be derived are a list RowHeight[ j ] for j ranging from 0 to num_tile_rows_minus1, inclusive, which specifies the row height of the jth tile in units of CTBs; a list CtbAddrRsToBs[ ctbAddrRs ] for ctbAddrRs ranging from 0 to PicSizeInCtbsY - 1, inclusive, which specifies the conversion from the address of the CTB in the raster scan of the picture's CTB to the address of the CTB in the scan of the bricks; and a list CtbAddrBsToRs[ ctbAddrBs ], a list BrickId[ ctbAddrBs ] for ctbAddrBs in the range 0 to NumBricksInPic - 1, inclusive, which specifies the conversion from CTB addresses to brick IDs in a brick scan, a list NumCtusInBrick[ brickIdx ] for brickIdx in the range 0 to NumBricksInPic - 1, inclusive, which specifies the conversion from brick index to the number of CTUs in a brick, and a list FirstCtbAddrBs[ brickIdx ] for brickIdx in the range 0 to NumBricksInPic - 1, inclusive, which specifies the conversion from brick IDs to CTB addresses in a brick scan of the first CTB in a brick.

[0131] single_brick_per_slice_flag may be set equal to 1 to specify that each slice that references this PPS contains one brick. single_brick_per_slice_flag may be set equal to 0 to specify that slices that reference this PPS may contain two or more bricks. When not present, the value of single_brick_per_slice_flag is inferred to be equal to 1. rect_slice_flag may be set equal to 0 to specify that the bricks in each slice are in raster scan order and slice information is not signaled in the PPS. rect_slice_flag may be set equal to 1 to specify that the bricks in each slice cover a rectangular region of the picture and slice information is signaled in the PPS. When single_brick_per_slice_flag is equal to 1, rect_slice_flag is inferred to be equal to 1. num_slices_in_pic_minus1 plus 1 specifies the number of slices in each picture that refer to the PPS. The value of num_slices_in_pic_minus1 can range from 0 to NumBricksInPic - 1, inclusive. When not present and single_brick_per_slice_flag is equal to 1, the value of num_slices_in_pic_minus1 is inferred to be equal to NumBricksInPic - 1.

[0132] top_left_brick_idx[ i ] specifies the brick index of the brick in the top-left corner of the i-th slice. For any i not equal to j, the value of top_left_brick_idx[ i ] should not be equal to the value of top_left_brick_idx[ j ]. When not present, the value of top_left_brick_idx[ i ] is inferred to be equal to i. The length of the top_left_brick_idx[ i ] syntax element is Ceil( Log2( NumBricksInPic ) bits. bottom_right_brick_idx_delta[ i ] specifies the difference between the brick index of the brick in the bottom right corner of the i-th slice and top_left_brick_idx[ i ]. When single_brick_per_slice_flag is equal to 1, the value of bottom_right_brick_idx_delta[ i ] is inferred to be equal to 0. The length of the bottom_right_brick_idx_delta[ i ] syntax element is Ceil( Log2( NumBricksInPic - top_left_brick_idx[ i ] ) ) bits.

[0133] Bitstream conformance may require that a slice contain either several complete tiles or only a subset of a tile. The variables NumBricksInSlice[ i ] and BricksToSliceMap[ j ], which specify the number of bricks in the i th slice and the mapping of bricks to slices, may be derived as follows: NumBricksInSlice[ i ] = 0 botRightBkIdx = top_left_brick_idx[ i ] + bottom_right_brick_idx_delta[ i ] for( j = 0; j < NumBricksInPic; j++) { if( BrickColBd[ j ] >= BrickColBd[ top_left_brick_idx[ i ] ] && BrickColBd[ j ] <= BrickColBd[ botRightBkIdx ] && BrickRowBd[ j ] >= BrickRowlBd[ top_left_brick_idx[ i ] ] && (7-34) BrickRowBd[ j ] <= BrickColBd[ botRightBkIdx ] ) { NumBricksInSlice[ i ]++ BricksToSliceMap[ j ] = i } }

[0134] loop_filter_across_bricks_enabled_flag may be set equal to 1 to specify that in-loop filtering operations may be performed across brick boundaries in a picture that references the PPS. loop_filter_across_bricks_enabled_flag may be set equal to 0 to specify that in-loop filtering operations are not performed across brick boundaries in a picture that references the PPS. In-loop filtering operations include operations of a deblocking filter, a sample adaptive offset filter, and an adaptive loop filter. When not present, the value of loop_filter_across_bricks_enabled_flag is inferred to be equal to 1. loop_filter_across_slices_enabled_flag may be set equal to 1 to specify that in-loop filtering operations may be performed across slice boundaries in a picture that references the PPS. loop_filter_across_slice_enabled_flag may be set equal to 0 to specify that in-loop filtering operations are not performed across slice boundaries in a picture that references the PPS. The in-loop filtering operations include the operations of a deblocking filter, a sample adaptive offset filter, and an adaptive loop filter. When not present, the value of loop_filter_across_slices_enabled_flag is inferred to be equal to 0.

[0135] signalled_slice_id_flag may be set equal to 1 to specify that the slice ID for each slice is signaled. signalled_slice_id_flag may be set equal to 0 to specify that the slice ID is not signaled. When rect_slice_flag is equal to 0, the value of signalled_slice_id_flag is inferred to be equal to 0. The value of signalled_slice_id_length_minus1 plus 1 specifies the number of bits used to represent the syntax element slice_id[ i ], when present, and the syntax element slice_address in the slice header. signalled_slice_id_length_minus1 may be in the range of 0 to 15, inclusive. When not present, the value of signalled_slice_id_length_minus1 is inferred to be equal to Ceil( Log2( num_slices_in_pic_minus1 + 1 ) ) - 1.

[0136] slice_id[ i ] specifies the slice ID of the i-th slice. The length of the slice_id[ i ] syntax element is signalled_slice_id_length_minus1 + 1 bits. When not present, the value of slice_id[ i ] is inferred to be equal to i for each i in the range from 0 to num_slices_in_pic_minus1, inclusive. entropy_coding_sync_enabled_flag may be set equal to 1 to specify that a specific synchronization process for the context variable is invoked before decoding a CTU that includes the first CTB of a row of CTBs in each brick of each picture that references a PPS, and a specific storage process for the context variable is invoked after decoding a CTU that includes the first CTB of a row of CTBs in each brick of each picture that references a PPS. The entropy_coding_sync_enabled_flag may be set equal to 0 to specify that no specific synchronization process for the context variables needs to be invoked before decoding the CTU that includes the first CTB of a row of CTBs in each brick of each picture that references the PPS, and no specific storage process for the context variables needs to be invoked after decoding the CTU that includes the first CTB of a row of CTBs in each brick of each picture that references the PPS. Bitstream conformance may require that the value of entropy_coding_sync_enabled_flag be the same for all PPSs that are activated in the CVS.

[0137] An example of the semantics of the general slice header is: slice_address specifies the slice address of the slice. When not present, the value of slice_address is inferred to be equal to 0. If rect_slice_flag is equal to 0, the following applies: The slice address is the brick ID. The length of slice_address is Ceil( Log2 ( NumBricksInPic ) ) bits. The value of slice_address can be in the range 0 to NumBricksInPic - 1, inclusive. Otherwise (rect_slice_flag is equal to 1), the following applies: The slice address is the slice ID of the slice. The length of slice_address is signalled_slice_id_length_minus1 + 1 bits. If signalled_slice_id_flag is equal to 0, the value of slice_address is in the range from 0 to num_slices_in_pic_minus1, inclusive. Otherwise, the value of slice_address is in the range from 0 to num_slices_in_pic_minus1, inclusive. ( signalled_slice_id_length_minus1 + 1 ) - 0 to 2, inclusive ( signalled_slice_id_length_minus1 + 1 ) - in the range of 1.

[0138] Bitstream conformance may require that the following constraints apply: The value of slice_address may not be equal to the value of slice_address of any other coded slice NAL unit of the same coded picture. The slices of a picture may not be in ascending order of their slice's slice_address values. The shape of a picture's slices may be such that each brick, when decoded, has its entire left and top boundaries that include the picture boundary or that include the boundaries of already decoded bricks. num_bricks_in_slice_minus1, when present, specifies the number of bricks in the slice minus 1. The value of num_bricks_in_slice_minus1 may be in the range from 0 to NumBricksInPic - 1, inclusive. When rect_slice_flag is equal to 0 and single_brick_per_slice_flag is equal to 1, the value of num_bricks_in_slice_minus1 is inferred to be equal to 0.

[0139] The variables NumBricksInCurrSlice, which specifies the number of bricks in the current slice, and SliceBrickIdx[ i ], which specifies the brick index of the i th brick in the current slice, may be derived as follows: if( rect_slice_flag ) { sliceIdx = 0 while( slice_address != rect_slice_id[ sliceIdx ] ) sliceIdx++ NumBricksInCurrSlice = NumBricksInSlice[ sliceIdx ] brickIdx = top_left_brick_idx[ sliceIdx ] botBrickIdx = brickIdx + bottom_right_brick_idx_delta[ brickIdx ] for( bIdx = 0; brickIdx <= botBrickIdx; brickIdx++ ) (7-38) if( BricksToSliceMap[ brickIdx ] == sliceIdx ) SliceBrickIdx[ bIdx++ ] = brickIdx } else { NumBricksInCurrSlice = num_bricks_in_slice_minus1 + 1 SliceBrickIdx

[0000] = slice_address for( i = 1; i < NumBricksInCurrSlice; i++ ) SliceBrickIdx[ i ] = SliceBrickIdx[ i - 1 ] + 1 }

[0140] The num_entry_point_offsets is used to specify the variable NumEntryPoints, which specifies the number of entry points in the current slice, as follows: NumEntryPoints = entropy_coding_sync_enabled_flag ? num_entry_point_offsets : NumBricksInCurrSlice - 1 (7-60)

[0141] offset_len_minus1 plus 1 specifies the length, in bits, of the entry_point_offset_minus1[ i ] syntax element. The value of offset_len_minus1 can be in the range of 0 to 31, inclusive. entry_point_offset_minus1[ i ] plus 1 specifies the offset, in bytes, of the i th entry point, represented by offset_len_minus1 plus 1 bit. The slice data following the slice header contains NumEntryPoints + 1 subsets with subset index values ​​ranging from 0 to NumEntryPoints, inclusive. The first byte of the slice data is considered to be byte 0. When present, an emulation prevention byte appearing in the slice data portion of a NAL unit of a coded slice is considered to be part of the slice data for the purposes of identifying the subsets. Subset 0 includes bytes 0 through byte entry_point_offset_minus1

[0000] , inclusive, of the coded slice data, and subset k, where k is in the range 1 through NumEntryPoints - 1, inclusive, includes bytes firstByte[k] through byte lastByte[k], inclusive, of the coded slice data, where firstByte[k] and byte lastByte[k] are defined as follows:

[0142]

number

[0143] lastByte[ k ]=firstByte[ k ] + entry_point_offset_minus1[ k ] (7-61) The last subset (having a subset index equal to NumEntryPoints) contains the remaining bytes of the coded slice data.

[0144] When entropy_coding_sync_enabled_flag is equal to 0, each subset may contain all coded bits of all CTUs in a slice that are in the same brick, and the number of subsets (e.g., the value of NumEntryPoints + 1) should be equal to the number of bricks in the slice. When entropy_coding_sync_enabled_flag is equal to 1, each subset k, where k is in the range from 0 to NumEntryPoints, inclusive, may contain all coded bits of all CTUs in a row of CTUs in a brick, and the number of subsets (e.g., the value of NumEntryPoints + 1) may be equal to the total number of rows of luma CTUs specific to a brick in the slice.

[0145] The above example may include one or more problems. For example, the syntax element ltrp_in_slice_header_flag in ref_pic_list_struct( ) may be conditioned on long_term_ref_pics_flag being equal to 1. As a result, when long_term_ref_pics_flag is equal to 1, this flag is present in each of the potentially large number of candidate reference picture list structures. This may result in a large SPS when long_term_ref_pics_flag is equal to 1. In another example, the combination of the condition on the syntax element num_ref_idx_active_override_flag and the corresponding inference may be problematic. For example, the value of num_ref_idx_active_override_flag may be equal to 1 for an I-slice, so that the syntax element num_ref_idx_active_minus1

[0000] may be, and is not required to be, signaled for I-slices with num_ref_entries

[0000] [RplsIdx

[0000] ] greater than 1. In another example, when WPP is used (e.g., when entropy_coding_sync_enabled_flag is equal to 1), the syntax element num_entry_point_offsets may be signaled for the derivation of the variable NumEntryPoints. However, NumEntryPoints may be derived without such signaling.

[0146] Generally, this disclosure describes techniques for video coding improvements, including improvements to signaling reference picture lists and improvements related to signaling entry points when WPP is used. The technique descriptions are based on the developing VVC, but may also apply to other video / media codec specifications.

[0147] One or more of the above problems may be solved as follows. In an exemplary aspect, a method is disclosed for decoding a video bitstream, in which a flag is included in the SPS. The flag specifies whether a POC LSB of a long-term reference picture (LTRP) entry of a reference picture list structure is present in a slice header or in a reference picture list structure. For example, the flag may be ltrp_in_slice_header_flag. In another exemplary aspect, a method is disclosed for decoding a video bitstream, in which the bitstream includes a flag specifying whether a number of active entries of a reference picture list is explicitly signaled, and when the flag is not present, a value of the flag is inferred to be equal to 0 when the slice is an I slice and inferred to be equal to 1 when the slice is a B or P slice. For example, the flag may be num_ref_idx_active_override_flag. In another exemplary aspect, a method is disclosed for decoding a video bitstream, in which the bitstream includes multiple tiles in a picture, a wavefront parallel processing function is applied, and a number of entry points in a slice is inferred instead of being explicitly signaled. For example, the number of entry points may be estimated to be the sum of the number of rows of the CTUs in all bricks included in the slice. In yet another example, the number of entry points may be represented by a variable NumEntryPoints.

[0148] The syntax of an exemplary sequence parameter set RBSP is as follows:

[0149] [Table 7]

[0150] An example of the syntax of a general slice header is as follows:

[0151] [Table 8A]

[0152] [Table 8B]

[0153] Reference Picture List Structure Syntax

[0154] [Table 9]

[0155] The semantics of the RBSP of an example sequence parameter set are as follows: long_term_ref_pics_flag may be set equal to 0 to specify that the LTRP is not used for inter prediction of any coded pictures in the CVS. long_term_ref_pics_flag may be set equal to 1 to specify that the LTRP may be used for inter prediction of one or more coded pictures in the CVS. ltrp_in_slice_header_flag may be set equal to 0 to specify that the POC LSB of the LTRP entry of each ref_pic_list_struct(listIdx, rplsIdx) syntax structure is present in the ref_pic_list_struct(listIdx, rplsIdx) syntax structure. The ltrp_in_slice_header_flag may be set equal to 1 to specify that the POC LSB of the LTRP entry of each ref_pic_list_struct(listIdx, rplsIdx) syntax structure is not present within the ref_pic_list_struct(listIdx, rplsIdx) syntax structure.

[0156] An example of the semantics of the general slice header is as follows: slice_poc_lsb_lt[ i ][ j ] specifies the remainder of the picture order count value divided by MaxPicOrderCntLsb of the jth LTRP entry of the ith reference picture list. The length of the slice_poc_lsb_lt[ i ][ j ] syntax element may be log2_max_pic_order_cnt_lsb_minus4 + 4 bits. The variable PocLsbLt[ i ][ j ] may be derived as follows: PocLsbLt[ i ][ j ] = ltrp_in_slice_header_flag ? (7-41) slice_poc_lsb_lt[ i ][ j ] : rpls_poc_lsb_lt[ listIdx ][ RplsIdx[ i ] ][ j ] num_ref_idx_active_override_flag may be equal to 1 to specify that the syntax element num_ref_idx_active_minus1

[0000] is present for P and B slices and that the syntax element num_ref_idx_active_minus1

[0001] is present for B slices. num_ref_idx_active_override_flag may be set equal to 0 to specify that the syntax elements num_ref_idx_active_minus1

[0000] and num_ref_idx_active_minus1

[0001] are not present. When not present, the value of num_ref_idx_active_override_flag may be inferred as follows: If slice_type is equal to B or P, the value of num_ref_idx_active_override_flag may be inferred to be equal to 1. Otherwise (slice_type is equal to I), the value of num_ref_idx_active_override_flag may be inferred to be equal to 0.

[0157] The semantics of an example reference picture list structure are as follows: num_ref_entries[listIdx][rplsIdx] may specify the number of entries of the ref_pic_list_struct(listIdx,rplsIdx) syntax structure. The value of num_ref_entries[listIdx][rplsIdx] may be in the range from 0 to sps_max_dec_pic_buffering_minus1+14, inclusive.

[0158] Another example of the syntax of a general slice header is as follows:

[0159] [Table 10]

[0160] An example of the semantics of a general slice header is as follows: The variable NumEntryPoints, which specifies the number of entry points in the current slice, may be derived as follows: if( !entropy_coding_sync_enabled_flag ) NumEntryPoints = NumBricksInCurrSlice - 1 else { for( numBrickSpecificCtuRowsInSlice = 0, i =0; i < NumBricksInCurrSlice; i++ ) (7-60) numBrickSpecificCtuRowsInSlice += BrickHeight[ SliceBrickIdx[ i ] ] NumEntryPoints = numBrickSpecificCtuRowsInSlice - 1 } The value of offset_len_minus1 plus 1 specifies the length, in bits, of the entry_point_offset_minus1[ i ] syntax element. The value of offset_len_minus1 can be in the range 0 to 31, inclusive.

[0161] FIG. 7 is a schematic diagram of an exemplary video coding device 700. The video coding device 700 is suitable for implementing the disclosed examples / embodiments as described herein. The video coding device 700 includes a downstream port 720, an upstream port 750, and / or a transceiver unit (Tx / Rx) 710 including a transmitter and / or a receiver for communicating data upstream and / or downstream over a network. The video coding device 700 further includes a processor 730 including a logic unit and / or a central processing unit (CPU) for processing data, and a memory 732 for storing data. The video coding device 700 may also include electrical, optical-electrical (OE) components, electrical-optical (EO) components, and / or wireless communication components coupled to the upstream port 750 and / or the downstream port 720 for communication of data over an electrical, optical, or wireless communication network. The video coding device 700 may also include input and / or output (I / O) devices 760 for communicating data to and from a user. The I / O devices 760 may include output devices such as a display for displaying video data, speakers for outputting audio data, etc. The I / O devices 760 may also include input devices such as a keyboard, mouse, trackball, etc., and / or corresponding interfaces for interacting with such output devices.

[0162] The processor 730 is implemented by hardware and software. The processor 730 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 730 communicates with downstream ports 720, Tx / Rx 710, upstream ports 750, and memory 732. The processor 730 includes a coding module 714. The coding module 714 implements the disclosed embodiments described herein, such as methods 100, 800, and 900, which may include the WPP 500 and / or the bitstream 600. The coding module 714 may also implement any other method / mechanism described herein. Additionally, the coding module 714 may implement the codec system 200, the encoder 300, and / or the decoder 400. For example, coding module 714 may determine a value for NumEntryPoints 518 without receiving a num_entry_point_offsets parameter in a slice header of the bitstream. Thus, coding module 714 allows video coding device 700 to provide additional functionality and / or coding efficiencies when coding video data. Thus, coding module 714 enhances the functionality of video coding device 700 and addresses problems inherent in video coding techniques. Furthermore, coding module 714 effects transition of video coding device 700 into a different state. Alternatively, coding module 714 may be implemented as instructions stored in memory 732 and executed by processor 730 (e.g., a computer program product stored in a non-transitory medium).

[0163] Memory 732 includes one or more types of memory, such as a disk, a tape drive, a solid-state drive, read-only memory (ROM), random access memory (RAM), flash memory, ternary content-addressable memory (TCAM), static random access memory (SRAM), etc. Memory 732 may be used for storing such programs when such programs are selected for execution as well as an overflow data storage device for storing instructions and data read during the execution of programs.

[0164] 8 is a flow diagram of an example method 800 for encoding a video sequence into a bitstream, such as bitstream 600 encoded with WPP 500, without signaling NumEntryPoints for slices in the video sequence. Method 800 may be used by an encoder, such as codec system 200, encoder 300, and / or video coding device 700, when performing method 100.

[0165] The method 800 may start when an encoder receives a video sequence including a plurality of pictures and decides to encode the video sequence into a bitstream based on, for example, a user input. In step 801, the encoder may encode a picture including a slice into a bitstream. The encoder may also determine that a picture and / or slice should be used as a coded reference picture and / or a reference slice for another picture and / or slice, respectively. This picture / slice is hereafter referred to as a current picture / current slice for clarity purposes. Upon determining that a reference picture should be used as a reference picture, the reference picture may be forwarded to the HRD for decoding. It should be noted that the encoder may encode a slice header into the bitstream. In an example, a slice header (e.g., for a reference slice and / or a current slice) does not include a value corresponding to the number of offsets of entry points in the slice. For example, the slice header does not include a num_entry_point_offsets parameter. In step 803, the HRD of the encoder obtains a reference slice of the coded reference picture from either the bitstream or memory.

[0166] In step 805, the HRD of the encoder derives NumEntryPoints to the reference slice based on the size of the reference slice. For example, NumEntryPoints may be derived when the reference slice is coded by WPP. In an example, NumEntryPoints may be further derived based on the size of the rows in the reference slice. In an example, NumEntryPoints may be further derived based on the size of the columns in the reference slice. In an example, NumEntryPoints may be further derived based on the number of CTUs in the reference slice. In an example, NumEntryPoints may be further derived based on an address in the reference slice, such as an address of a CTU. Then, the HRD of the encoder can determine an offset for a subset of the coded data in the reference slice based on NumEntryPoints. For example, the HRD may obtain an array of offsets. Then, the HRD can obtain some offsets from the array based on NumEntryPoints. In an example, the subset is a row of CTUs. Thus, the obtained offsets may indicate an entry point for a row of each CTU in the slice.

[0167] For example, NumEntryPoints may be derived as follows: if( !entropy_coding_sync_enabled_flag ) NumEntryPoints = NumBricksInCurrSlice - 1 else { for( numBrickSpecificCtuRowsInSlice = 0, i =0; i < NumBricksInCurrSlice; i++ ) numBrickSpecificCtuRowsInSlice += BrickHeight[ SliceBrickIdx[ i ] ] NumEntryPoints = numBrickSpecificCtuRowsInSlice - 1} !entropy_coding_sync_enabled_flag indicates that WPP 500 is not used, NumBricksInCurrSlice is the number of tiles in slice 501, numBrickSpecificCtuRowsInSlice is the number of CTU rows 521-525 in slice 501, and BrickHeight[ SliceBrickIdx[ i ] ] is the height of CTU rows 521-525 (and therefore the height of CTU column 516).

[0168] In step 807, the HRD of the encoder may decode a reference slice of the coded reference picture based on an offset for the subset of coded data in the reference slice. For example, the HRD may obtain data for a row of each CTU starting from a bit in memory or a bitstream indicated by a corresponding offset. The HRD may then decode each of the CTUs of the reference slice based on the obtained data.

[0169] In step 809, the encoder may encode the current slice into a bitstream based on the reference slice, for example by using inter prediction, and in step 811, the encoder may store the bitstream for communication to the decoder.

[0170] 9 is a flow diagram of an example method 900 for deriving NumEntryPoints for decoding a video sequence when NumEntryPoints is not included in a bitstream, such as bitstream 600 encoded with WPP 500. Method 900 may be used by a decoder, such as codec system 200, decoder 400, and / or video coding device 700, when performing method 100.

[0171] Method 900 may begin, for example, when a decoder begins receiving a bitstream of coded data representing a video sequence as a result of method 800. In step 901, the decoder receives a bitstream including a slice. For example, the slice may be slice 501 coded by WPP 500. The bitstream also includes a slice header associated with the slice. In an example, the slice header does not include a value corresponding to an entry point within the slice. For example, the slice header does not include a num_entry_point_offsets parameter.

[0172] In step 903, the decoder derives NumEntryPoints for a slice based on a size of the slice. For example, NumEntryPoints may be derived when the slice is coded by WPP. In an example, NumEntryPoints may be further derived based on a size of a row in the slice. In an example, NumEntryPoints may be further derived based on a size of a column in the slice. In an example, NumEntryPoints may be further derived based on a number of CTUs in the slice. In an example, NumEntryPoints may be further derived based on an address in the slice, such as an address of a CTU.

[0173] For example, NumEntryPoints may be derived as follows: if( !entropy_coding_sync_enabled_flag ) NumEntryPoints = NumBricksInCurrSlice - 1 else { for( numBrickSpecificCtuRowsInSlice = 0, i =0; i < NumBricksInCurrSlice; i++ ) numBrickSpecificCtuRowsInSlice += BrickHeight[ SliceBrickIdx[ i ] ] NumEntryPoints = numBrickSpecificCtuRowsInSlice - 1 } Here, !entropy_coding_sync_enabled_flag indicates that WPP 500 is not being used, NumBricksInCurrSlice is the number of tiles in slice 501, numBrickSpecificCtuRowsInSlice is the number of CTU rows 521-525 in slice 501, and BrickHeight[ SliceBrickIdx[ i ] ] is the height of CTU rows 521-525 (and therefore the height of CTU column 516).

[0174] In step 905, the decoder may determine offsets for subsets of coded slice data included in the slice based on the NumEntryPoints derived in step 903. For example, the decoder may obtain an array of offsets. Then, the decoder may obtain several offsets from the array based on the NumEntryPoints derived in step 903. For example, each offset of the coded slice data may be associated with a subset index value, and such values ​​may range from 0 to NumEntryPoints. Then, the decoder may iteratively obtain each offset of the corresponding subset index value until NumEntryPoints is reached. In an example, the subsets are rows of CTUs. Thus, the obtained offsets may indicate entry points for rows of each CTU in the slice.

[0175] In step 907, the decoder decodes the slice based on the offset for the subset of coded slice data. For example, the decoder may obtain data for a row of each CTU starting from the bit in the bitstream indicated by the corresponding offset. The decoder may then decode each of the CTUs of the slice based on the obtained data. The decoder may then forward the slice for display as part of the decoded video sequence in step 909.

[0176] 10 is a schematic diagram of an example system 1000 for coding a video sequence into a bitstream, such as bitstream 600 coded by WPP 500 without signaling NumEntryPoints. System 1000 may be implemented by an encoder and a decoder, such as codec system 200, encoder 300, decoder 400, and / or video coding device 700. Additionally, system 1000 may be used when performing methods 100, 800, and / or 900.

[0177] The system 1000 includes a video encoder 1002. The video encoder 1002 includes an obtaining module 1001 for obtaining a reference slice of a coded reference picture. The video encoder 1002 further includes a derivation module 1003 for deriving NumEntryPoints to the reference slice based on a size of the reference slice. The video encoder 1002 further includes a determination module 1004 for determining an offset for a subset of coded data in the reference slice based on the NumEntryPoints. The video encoder 1002 further includes a coding module 1005 for decoding a reference slice of the coded reference picture based on the offset for the subset of coded data in the reference slice. Furthermore, the coding module 1005 is for encoding a current slice into a bitstream based on the reference slice. The video encoder 1002 further includes a storage module 1006 for storing a bitstream for communicating to a decoder. The video encoder 1002 further includes a transmission module 1007 for transmitting the bitstream to a video decoder 1010. The video encoder 1002 may be further configured to perform any of the steps of the method 800.

[0178] The system 1000 also includes a video decoder 1010. The video decoder 1010 includes a receiving module 1011 for receiving a bitstream including the slice. The video decoder 1010 further includes a determining module 1013 for deriving a NumEntryPoints for the slice based on a size of the slice. The video decoder 1010 further includes a determining module 1015 for determining an offset for a subset of coded slice data having a subset index value ranging from 0 to NumEntryPoints. The video decoder 1010 further includes a decoding module 1017 for decoding the slice based on the offset for the subset of coded data within the slice. The video decoder 1010 further includes a transport module 1019 for transporting the slice for display as part of a decoded video sequence. The video decoder 1010 may be further configured to perform any of the steps of the method 900.

[0179] A first component is directly coupled to a second component when there are no intervening components other than lines, traces, or other media between the first and second components. A first component is indirectly coupled to a second component when there are intervening components other than lines, traces, or other media between the first and second components. The term "coupled" and variations thereof include both directly coupled and indirectly coupled. Use of the term "about" means a range that includes ±10% of the preceding number unless otherwise stated.

[0180] It should also be understood that the steps of the exemplary methods described herein are not necessarily required to be performed in the order described, and that the order of steps of such methods is to be understood to be exemplary only. Similarly, additional steps may be included in such methods, and certain steps may be omitted or combined in methods consistent with various embodiments of the present disclosure.

[0181] Although several embodiments have been 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. These examples should be considered illustrative and not limiting, and the intention should not be limited to the details given herein. For example, various elements or components may be combined or integrated into other systems, or certain features may be omitted or not implemented.

[0182] Additionally, 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 the disclosure. Other examples of changes, substitutions, and alterations may occur to those skilled in the art and may be made without departing from the spirit and scope of what is disclosed herein. [Explanation of symbols]

[0183] 100 How it works 200 Coding and Decoding (Codec) Systems 201 Segmented Video Signal 211 General Coda Control Components 213 Transformation, Scaling and Quantization Components 215 Intra-picture Estimation Components 217 Intra-picture prediction components 219 Motion Compensation Components 221 Motion Estimation Components 223 Decoded Picture Buffer Components 225 In-loop filter components 227 Filter Control Analysis Components 229 Scaling and Inverse Transformation Components 231 Header Format and Context-Adaptive Binary Arithmetic Coding (CABAC) Components 300 Video Encoder 301 Segmented Video Signal 313 Transformation and Quantization Components 317 Intra-picture prediction components 321 Motion Compensation Components 323 Decoded Picture Buffer Components 325 In-loop filter components 329 Inverse Transformation and Quantization Components 331 Entropy Coding Components 400 Video Decoder 417 Intra-picture prediction components 421 Motion Compensation Components 423 Decoded Picture Buffer Components 425 In-loop filter components 429 Inverse Transformation and Quantization Components 433 Entropy Decoding Components 500 WPP 501 slices 511 CTU 512 CTU 516 CTU in a row 517 Entry Point 518 Number of entry points (NumEntryPoints) 521 CTU rows 522 CTU rows 523 CTU rows 524 CTU rows 525 CTU row 600 bitstream 610 SPS 611 Picture Parameter Set (PPS) 615 Slice Header 620 Image data 621 Pictures 623 Slices 625 CTU 700 Video Coding Device 710 Transceiver Unit (Tx / Rx) 714 Coding Module 720 downstream ports 730 Processor 732 Memory 750 Upstream Ports 760 Input and / or Output (I / O) Devices 800 ways 900 ways 1000 Systems 1001 Acquisition Module 1002 Video Encoder 1003 Derivation Module 1004 Decision Module 1005 Coding Module 1006 Memory module 1007 Transmitting Module 1010 Video Decoder 1011 Receiver module 1013 Decision Module 1015 Decision Module 1017 Decryption Module 1019 Transfer Module

Claims

1. A method implemented in a decoder, comprising: receiving, by a receiver of the decoder, a bitstream including slices; deriving, by a processor of the decoder, a number of entry points (NumEntryPoints) in the slice; determining, by the processor, offsets for subsets of coded slice data having subset index values ​​ranging from 0 to the NumEntryPoints; and decoding, by the processor, the slice based on the offset for the subset of the coded slice data.

2. The method of claim 1 , wherein the NumEntryPoints is derived when the slice is coded by wavefront parallel processing (WPP).

3. 3. The method of claim 1 or 2, wherein the bitstream includes a slice header, the slice header not including a value corresponding to a number of offsets of entry points within the slice.

4. The method of claim 1 , wherein the NumEntryPoints is derived based on a size of a row in the slice.

5. The method of claim 1 , wherein the NumEntryPoints is derived based on the size of columns in the slice.

6. 6. The method of claim 1, wherein the NumEntryPoints is derived based on a number of coding tree units (CTUs) in the slice.

7. The method of claim 1 , wherein the NumEntryPoints is derived based on an address within the slice.

8. The method of claim 1 , wherein the NumEntryPoints is derived based on a size of the slice.

9. 1. A method implemented in an encoder, comprising: obtaining, by a processor of the encoder, a reference slice of a coded reference picture; deriving, by the processor, a number of entry points (NumEntryPoints) in the reference slice; determining, by the processor, an offset for a subset of coded data within the reference slice based on the NumEntryPoints; decoding, by the processor, the reference slice of the coded reference picture based on the offset for the subset of the coded data within the reference slice; encoding, by the processor, a current slice based on the reference slice into a bitstream; storing, by a memory coupled to the processor, the bitstream for transmission to a decoder.

10. The method of claim 9 , wherein the NumEntryPoints is derived when the reference slice is coded by wavefront parallel processing (WPP).

11. 11. The method of claim 9 or 10, wherein the bitstream includes a slice header, the slice header not including a value corresponding to a number of offsets of entry points within the reference slice.

12. 12. The method of claim 9, wherein the NumEntryPoints is derived based on a size of a row in the reference slice.

13. 13. The method of claim 9, wherein the NumEntryPoints is derived based on a size of columns in the reference slice.

14. 14. The method of claim 9, wherein the NumEntryPoints is derived based on a number of coding tree units (CTUs) in the reference slice.

15. 15. A method according to any one of claims 9 to 14, wherein the NumEntryPoints is derived based on an address within the reference slice.

16. 16. The method of claim 9, wherein the NumEntryPoints is derived based on a size of the reference slice.

17. 17. A video coding device comprising: a processor; a receiver coupled to the processor; a memory coupled to the processor; and a transmitter coupled to the processor, wherein the processor, the receiver, the memory, and the transmitter are configured to perform the method of any one of claims 1 to 16.

18. 17. A non-transitory computer-readable medium comprising a computer program product for use by a video coding device, the computer program product comprising computer-executable instructions stored on the non-transitory computer-readable medium that, when executed by a processor, causes the video coding device to perform a method according to any one of claims 1 to 16.

19. receiving means for receiving a bitstream including the slice; means for deriving a number of entry points (NumEntryPoints) in the slice; determining means for determining an offset for a subset of the coded slice data having subset index values ​​ranging from 0 to said NumEntryPoints; and decoding means for decoding the slice based on the offset for the subset of the coded slice data.

20. A decoder according to claim 19, further configured to perform a method according to any one of claims 1 to 8.

21. obtaining means for obtaining a reference slice of a coded reference picture; means for deriving a number of entry points (NumEntryPoints) in the reference slice; determining means for determining an offset for a subset of coded data within the reference slice based on the NumEntryPoints; A coding means, comprising: decoding the reference slice of the coded reference picture based on the offset for the subset of the coded data within the reference slice; coding means for encoding a current slice based on said reference slice into a bitstream; and storage means for storing said bitstream for transmission to a decoder.

22. 22. An encoder according to claim 21, further configured to perform a method according to any one of claims 9 to 16.

Images