JP7354241B2 - Video encoder, video decoder, and corresponding method - Google Patents

Description

TECHNICAL FIELD This disclosure relates generally to video coding, and specifically to efficient signaling of coding tool parameters used to compress video data in video coding.

The amount of video data required to represent even a relatively short video can be substantial, and this makes it difficult for data to be streamed or otherwise communicated over communication networks with limited bandwidth capacity. It can cause difficulties when it should. Accordingly, video data is typically compressed before being communicated across modern telecommunications networks. The size of the video can also be an issue when the video is stored on a storage device since memory resources can be limited. Video compression devices often use software and/or hardware at the source to code video data before transmission or storage, thereby reducing the amount of data needed to represent a digital video image. do. The compressed data is then received at the destination by a video decompression device that decodes the video data. With limited network resources and ever-increasing demands for higher video quality, improved compression and decompression techniques that improve compression ratios with no or little sacrifice in picture quality are desirable.

In embodiments, the disclosure provides a method implemented in a decoder, the method comprising: determining, by a receiver of the decoder, a first Header Parameter Set ( HPS) comprising a first type of coding tool parameters; receiving a bitstream having a second HPS including coding tool parameters, a slice header, and a slice associated with the slice header; using the first type of coding tool parameters and the second type of coding tool parameters based on determining that the slice header includes the first reference and the second type of coding tool parameter based on the determination that the slice header includes the first reference and the second reference. A method includes decoding a slice and transmitting the slice for display by a processor as part of a decoded video sequence. HPS, also known as Adaptive Parameter Set ( APS), is used to describe video data at a lower granularity than a Picture Parameter Set (PPS) and a higher granularity than a slice header. It's fine. The disclosed aspects allow a single slice header to reference multiple types of HPS. By providing a mechanism that allows a single slice header to reference multiple types of HPS, various coding tool parameters may be signaled at the HPS level. This allows coding tool parameters to change between slices within the same picture/frame without loading extra data into the slice header. Therefore, coding tool parameters that change between slices within the same picture do not have to be loaded in any slice header, allowing the encoder to update them when performing Rate Distortion Optimization ( RDO). It has flexibility. Furthermore, the average coding efficiency is increased because the encoder may have access to more encoding options when finding the optimal coding solution. This, in turn, reduces the utilization of memory resources and the utilization of network resources, both at the encoder and decoder, when storing video data and when transmitting video data.

Optionally, in any of the above aspects, another implementation of the aspect provides that the first HPS and the second HPS are an Adaptive Loop Filter (ALF) HPS, Luma Mapping with Chroma Scaling ( LMCS). HPS, a scaling list parameter HPS, or a combination thereof.

Optionally, in any of the above aspects, another implementation of the aspect is that the bitstream further comprises a plurality of HPSs, including a first HPS and a second HPS, each of the plurality of HPSs being different from others in the plurality of HPSs. coding tool parameters from the HPS. In some systems, the current HPS may inherit coding parameters by reference to a previous HPS. In theory, this allows the current HPS to only contain the differences between the current HPS and the previous HPS. However, in practice, this approach often creates long inheritance chains and in turn forces the decoder to keep a large number of old HPSs in its buffer as long as subsequent HPSs may refer back to them. ask you to do so. This causes both buffer memory problems and increases the possibility of coding errors if the HPS is lost during transfer. Some aspects of the present disclosure address this challenge by requiring each HPS to include all relevant coding parameters without reference to other HPSs.

Optionally, in any of the above aspects, another implementation of the aspect provides that the first HPS is included in an access unit associated with a temporal identifier (ID), and the first HPS is included in an access unit that includes the first HPS. including the associated temporal ID. In one example, each HPS may be required to maintain the same temporal ID as the access unit containing the HPS.

Optionally, in any of the aspects above, another implementation of the aspect provides that the slice is a portion of a picture, the picture is associated with a temporal identifier (ID), and the first HPS is a temporal identifier (ID) associated with the picture . Provide information, including ID. In some examples, each HPS may be required to maintain the same temporal ID as the picture associated with the first slice that references that HPS.

Optionally, in any of the above aspects, another implementation of the aspect provides that the bitstream includes a plurality of pictures each including one or more slices including a slice, and the bitstream includes a first HPS and a first HPS. 2HPS, each of the plurality of HPS and each of the one or more slices is associated with one of the plurality of temporal IDs, each slice having a first temporal ID; , is restricted from referencing any HPS with a second temporal ID greater than the first temporal ID. In some examples, a bitstream of pictures and slices may be associated with one of a plurality of temporal IDs (eg, one of three). Each temporal ID is associated with a corresponding frame rate. Data items with higher frame rates may be ignored if lower frame rates are rendered. In this example, slices are prevented from referencing HPSs with higher temporal IDs and thus higher frame rates. This approach ensures that the slice does not reference higher frame rate HPSs that are ignored when the slice's lower frame rate is rendered. This may ensure that the HPS is actually available for the slice and is not ignored due to frame rate mismatch.

In embodiments, the disclosure is a method implemented in an encoder, comprising: partitioning a plurality of pictures into a plurality of slices by a processor of the encoder; and encoding the plurality of slices into a bitstream by a processor. and the plurality of slices are encoded by at least a first type of coding tool based on the first type of coding tool parameters and a second type of coding tool based on the second type of coding tool parameters; encoding a first HPS and a second HPS into a bitstream, the first HPS including a first type of coding tool parameter and the second HPS including a second type of coding tool parameter; encoding a first slice header in the bitstream that describes the encoding of a first slice of the plurality of slices, wherein the first slice header includes a first reference to a first HPS and a second reference to a second HPS. and storing the bitstream for communication to a decoder by a memory coupled to the processor. HPS, also known as APS, may be used to describe video data with lower granularity than PPS and higher granularity than slice headers. The disclosed aspects allow a single slice header to reference multiple types of HPS. By providing a mechanism that allows a single slice header to reference multiple types of HPS, various coding tool parameters may be signaled at the HPS level. This allows coding tool parameters to change between slices within the same picture/frame without loading extra data into the slice header. Therefore, the encoder has additional flexibility when performing RDO in that coding tool parameters that vary between slices within the same picture do not have to be loaded into any slice header. Furthermore, the average coding efficiency is increased because the encoder may have access to more encoding options when finding the optimal coding solution. This, in turn, reduces the utilization of memory resources and the utilization of network resources, both at the encoder and decoder, when storing video data and when transmitting video data.

Optionally, in any of the above aspects, other implementations of the aspect provide that the first HPS and the second HPS include an ALF HPS, a LMCS HPS, a scaling list parameter HPS, or a combination thereof.

Optionally, in any of the above aspects, another implementation of the aspect further comprises encoding, by the processor, a plurality of HPS into the bitstream, the plurality of HPS including a first HPS and a second HPS; Provided is that each of the plurality of HPSs is restricted from referencing coding tool parameters from other HPSs within the plurality of HPSs. In some systems, the current HPS may inherit coding parameters by reference to a previous HPS. In theory, this allows the current HPS to only contain the differences between the current HPS and the previous HPS. However, in practice, this approach often creates long inheritance chains and in turn forces the decoder to keep a large number of old HPSs in its buffer as long as subsequent HPSs may refer back to them. ask you to do so. This causes both buffer memory problems and increases the possibility of coding errors if the HPS is lost during transfer. Some aspects of the present disclosure address this challenge by requiring each HPS to include all relevant coding parameters without reference to other HPSs.

Optionally, in any of the above aspects, another implementation of the aspect provides that the first HPS is included in an access unit associated with a temporal ID, and the first HPS is included in a temporal ID associated with an access unit that includes the first HPS. including, providing that. In one example, each HPS may be required to maintain the same temporal ID as the access unit containing the HPS.

Optionally, in any of the above aspects, another implementation of the aspect provides that the first slice is partitioned from a first picture, the first picture is associated with a temporal ID, and the first HPS is partitioned from a first picture. including a temporal ID associated with the . In some examples, each HPS may be required to maintain the same temporal ID as the picture associated with the first slice that references that HPS.

Optionally, in any of the above aspects, another implementation of the aspect provides that a plurality of HPSs including a first HPS and a second HPS are encoded, and each of the plurality of HPSs and each of the plurality of slices is encoded with a plurality of temporal IDs. each slice associated with one of the HPSs having a first temporal ID is restricted from referencing any HPS having a second temporal ID greater than the first temporal ID. . In some examples, a bitstream of pictures and slices may be associated with one of a plurality of temporal IDs (eg, one of three). Each temporal ID is associated with a corresponding frame rate. Data items with higher frame rates may be ignored if lower frame rates are rendered. In this example, slices are prevented from referencing HPSs with higher temporal IDs and thus higher frame rates. This approach ensures that the slice does not reference higher frame rate HPSs that are ignored when the slice's lower frame rate is rendered. This may ensure that the HPS is actually available for the slice and is not ignored due to frame rate mismatch.

In embodiments, the disclosure includes a processor, a receiver coupled to the processor, a memory coupled to the processor, and a transmitter coupled to the processor, the processor, the receiver, the memory, and the transmitter coupled to the processor. A transmitter includes a video coding device configured to perform the method of any of the above aspects.

In embodiments, the disclosure provides a non-transitory computer-readable medium having a computer program product for use by a video coding device, wherein the computer program product, when executed by a processor, provides the video coding device with the A non-transitory computer-readable medium having computer-executable instructions stored on the non-transitory computer-readable medium to cause the method of any of the aspects to be performed.

In embodiments, the disclosure provides a bitstream having a first HPS including a first type of coding tool parameters, a second HPS including a second type of coding tool parameters, a slice header, and a slice associated with the slice header. receiving means for receiving; determining means for determining that the slice header includes a first reference to the first HPS and a second reference to the second HPS; and determining means for determining that the slice header includes the first reference and the second reference. , decoding means for decoding the slices using the first type of coding tool parameters and the second type of coding tool parameters, and transfer means for transferring the slices for display as part of the decoded video sequence. including a decoder with

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.

In embodiments, the disclosure provides a partitioning means for partitioning a plurality of pictures into a plurality of slices, and encoding the plurality of slices into a bitstream, the slices having at least a first type of coding tool parameter based on a first type of coding tool parameter. encoded by a second type of coding tool based on the type of coding tool and the second type of coding tool parameters; encoding the first HPS and the second HPS into the bitstream, the first HPS including the first type of coding tool parameters; , the second HPS includes a second type of coding tool parameters; encodes a first slice header in the bitstream that describes the encoding of a first slice of the plurality of slices; 1 reference and a second reference to a second HPS, an encoder having encoding means and storage means for storing the bitstream for communication to a decoder.

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.

For clarity, any one of the embodiments described above may be combined with any one or more of the other embodiments described above to yield new embodiments within the scope of this disclosure.

These and other features will be more clearly understood from the following detailed description, read in conjunction with the accompanying drawings and claims.

For a more complete understanding of the present disclosure, reference is now made to the following brief description, read in conjunction with the accompanying drawings and detailed description. Like reference numbers refer to like parts.

1 is a flowchart of an example method of coding a video signal. 1 is a schematic diagram of an example coding and decoding (CODEC) system for video coding; FIG. 1 is a schematic diagram representing an example of a video encoder; FIG. 1 is a schematic diagram representing an example of a video decoder; FIG. 1 is a schematic diagram representing an example of a bitstream containing an encoded video sequence with a header parameter set (HPS); FIG. 1 is a schematic diagram representing an example of a mechanism for time scaling; FIG. 1 is a schematic diagram of an example video coding device; FIG. 1 is a flowchart of an example method of encoding a video sequence into a bitstream by using HPS. 1 is a flowchart of an example method of decoding a video sequence from a bitstream by using HPS. 1 is a schematic diagram of an example system for coding a video sequence of images in a bitstream by using HPS. FIG.

Although example implementations of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether or not currently known or existing. It should first be understood that it may be implemented in any manner. The disclosure is in no way to be limited to the example implementations, drawings, and techniques described below, including the example designs and implementations shown and described herein, but is to be construed in accordance with the appended claims and claims. Variations may be made within the full range of equivalence thereof.

The following acronyms: Adaptive Loop Filter (ALF), Coding Tree Block (CTB), Coding Tree Unit (CTU), Coding Unit (CU), Coded Video Sequence (CVS), Dynamic Adaptive Streaming over Hypertext transfer protocol (DASH), Joint Video Experts Team (JVET), Motion-Constrained Tile Set (MCTS), Maximum Transfer Unit (MTU), Network Abstraction Layer (NAL), Picture Order Count (POC), Raw Byte Sequence Payload (RBSP), Sample Adaptive Offset ( Sequence Parameter Set (SPS), Versatile Video Coding (VVC), and Working Draft (WD) are used here.

Many video compression techniques can be used to reduce the size of video files with minimal data loss. For example, video compression techniques can include performing spatial (eg, intra-picture) prediction and/or temporal (eg, inter-picture) prediction to reduce or eliminate data redundancy within a video sequence. For block-based video coding, a video slice (e.g., a video picture or a portion of a video picture) can be a tree block, a coding tree block (CTB), a coding tree unit (CTU), a coding unit (CU), and/or a coding It may be partitioned into video blocks, which may also be called nodes. Video blocks within an intra-coded (I) slice of a picture are coded using spatial prediction with respect to reference samples in adjacent blocks within the same picture. Video blocks within an inter-coded unidirectionally predicted (P) or bidirectionally predicted (B) slice of a picture are spatially predicted with respect to reference pictures in adjacent blocks within the same picture, or with respect to reference samples in other reference pictures. may be coded by using temporal prediction. 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 reference image. Spatial or temporal prediction results in a predicted block representing an image block. Residual data represents pixel differences between the original image block and the predicted block. Thus, inter-coded blocks are encoded accordingly with motion vectors pointing to the blocks of reference samples forming the predictive block and residual data indicating the difference between the coded block and the predictive block. Intra-coded blocks are encoded according to the intra-coding mode and residual data. For further compression, the residual data may be transformed from the pixel domain to the transform domain. These yield residual transform coefficients, which may be quantized. The quantized transform coefficients may be arranged first 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.

To ensure that the encoded video can be decoded accurately, the video is encoded and decoded according to the corresponding video coding standard. The video coding standard is developed by the International Telecommunication Union (ITU) Standardization Sector (ITU-T) H. 261, International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) Motion Picture Expert Group (MPEG)-1 Part 2, ITU-T H. 262 or ISO/IEC MPEG-2 Part 2, ITU-T H.262 or ISO/IEC MPEG-2 Part 2, ITU-T H. 263, ISO/IEC MPEG-4 Part 2, ITU-T H. Advanced Video Coding (AVC), also known as H.264 or ISO/IEC MPEG-4 Part 10, and ITU-T H.264 or ISO/IEC MPEG-4 Part 10. High Efficiency Video Coding (HEVC), also known as H.265 or MPEG-H Part 2. AVC includes scalable video coding (SVC), multi-view video coding (MVC), multi-view video coding plus depth (MVC+D), and three-dimensional (3D) AVC (3D-AVC). Including extensions. HEVC includes extensions such as scalable HEVC (SHVC), multi-view HEVC (MV-HEVC), and 3D HEVC (3D-HEVC). The Joint Video Expert Group (JVET) of ITU-T and ISO/IEC has begun developing a video coding standard called Versatile Video Coding (VVC). VVC is included in a working draft (WD) that includes JVET-L1001-v1 and JVET-K1002-v3, and provides an algorithm description, an encoder-side description of the VVC WD, and reference software.

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 according to wavefront parallel processing (WPP). For simplicity, HEVC allows only regular slices, dependent slices, tiles, WPP, and combinations thereof to be used when partitioning slices into groups of CTBs for video coding. , limit the encoder. Such partitioning may be applied to support maximum transform unit (MTU) size matching, parallelism, and reduced end-to-end delay. MTU represents the maximum amount of data that can be transmitted in a single packet. If a packet payload exceeds the MTU, the payload is split into two packets through a process called fragmentation.

A regular slice, also simply called a slice, is a partitioned part of an image that can be reconstructed independently from other regular slices in the same picture, despite some interdependence due to loop filtering operations. be. 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 may be overridden to support independent reconstruction. Such independent reconfiguration supports parallelization. For example, regular slice-based parallelization 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 the slice header for each slice and the lack of prediction across slice boundaries. Additionally, regular slices may be used to support MTU size matching requirements. Specifically, regular slices can be encapsulated in separate NAL units and coded independently, so that each regular slice can be In other words, it must be smaller than the MTU in the MTU scheme. As such, parallelization goals and MTU size matching goals can place contradictory demands on the slice layout within a picture.

Dependent slices are similar to regular slices, but have a shortened slice header, allowing partitioning of image treeblock boundaries without interrupting intra-picture prediction. Therefore, dependent slices allow a regular slice to be fragmented into multiple NAL units, which means that a portion of a regular slice is fragmented before encoding of the entire regular slice is completed. This results in reduced end-to-end delay.

Tiles are partitioned portions of an image created by horizontal and vertical boundaries that create columns and rows of tiles. Tiles may be coded in raster scan order (right to left and top to bottom). The CTB scan order is local within a tile. Therefore, the CTBs in a first tile are coded in raster scan order before processing for CTBs in the next tile. Similar to regular slices, tiles also break intra-picture prediction dependencies in addition to 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 the inter-processor/inter-core communication used for intra-picture prediction between processing units decoding adjacent tiles is may be limited to carrying shared slice headers (in some cases) and performing sharing associated with loop filtering of reconstructed samples and metadata. If more than one tile is included in a slice, the entry point byte offset for each tile other than the first entry point offset within the slice may be signaled in the slice header. For each slice and tile, the following conditions: 1) all coded treeblocks within a slice belong to the same tile; and 2) all coded treeblocks within a tile belong to the same slice. At least one of the following should be satisfied.

In WPP, images are partitioned into a single row of CTBs. Entropy decoding and prediction mechanisms may use data from CTBs in other rows. Parallel processing is enabled through parallel decoding of CTB rows. For example, the current row may be decoded in parallel with previous rows. However, the decoding of the current row is delayed by two CTBs from the decoding process of the previous row. This delay ensures that data for the CTB above and to the right of the current CTB 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 with no more than the same number of processors/cores as there are CTB rows included in the image. Since intra-picture prediction between adjacent treeblock rows within a picture is allowed, inter-processor/inter-core communication to enable intra-picture prediction can be significant. WPP partitioning does not consider NAL unit size. Therefore, WPP does not support MTU size matching. However, regular slices may be used with WPP, with certain coding overhead, to implement MTU size matching as desired.

Tiles define horizontal and vertical boundaries that partition the picture into columns and rows of tiles. The scan order of the CTBs may be changed locally within a tile before decoding the top left CTB of the next tile in the tile raster scan order of the picture. The local scan order indicates the CTB raster scan order of the tile. Similar to regular tiles, tiles also break intra-picture prediction dependencies in addition to entropy decoding dependencies. However, tiles may not be included in individual NAL units. Therefore, tiles may not be used for MTU size matching. Each tile may be processed by one processor/core. Inter-processor/inter-core communication used for intra-picture prediction between processing units decoding adjacent tiles is limited to carrying shared slice headers when the slice spans more than one tile. good. Inter-processor/inter-core communication may also be used for loop filtering-related sharing of reconstructed samples and metadata. If more than one tile or WPP segment is included in a slice, the entry point byte offset for each tile or WPP other than the first one in the slice may be signaled in the slice header. A restriction on applying four different picture partitioning schemes may be used to support simplicity. For example, coded video sequences (CVS) may not include both tiles and wavefronts for most of the profiles defined in HEVC. For each slice and tile, one or both of the following conditions may be satisfied: All coded treeblocks within a slice may belong to the same tile, and all coded treeblocks within a tile may belong to the same slice. Furthermore, a wavefront segment may include exactly one CTB row. Also, when WPP is in use, slices that start within a CTB row should end in the same CTB row.

VVC may include a tile and tile group picture partitioning scheme. Tiles in VVC may be the same as tiles in HEVC. VVC may use tile groups instead of slices. A slice is defined as containing a group of CTUs, while a tile group is defined as containing a group of tiles. A coded picture may be composed of one or more slices (or tile groups). Each slice/tile group has a slice header that contains syntax elements representing information used to decode the slice. Each slice header may include information for decoding only that slice. However, the information from the slice header may be the same for other slices within the same picture. This is because the coding tool may operate at the picture level and the parameters for all slices within a picture may be the same. This situation can cause redundant information in the slice header.

Header Parameter Set (HPS), also known as APS, may be used to solve problems with redundant slice header information. The HPS may include slice level information shared by multiple slices. The HPS may be generated by the encoder and may include coding tool parameters used when decoding the corresponding slice at the decoder. Some systems implement the HPS scheme by using an HPS and a reference HPS. In this scheme, the first HPS in the coding order contains all of the relevant coding tool parameters for the corresponding slice. If such parameters change for subsequent slices, subsequent HPSs only include the changed parameters. Subsequent HPSs then reference the first HPS. Therefore, the first HPS serves as a reference HPS for subsequent HPSs. Further HPSs can then be used to reference previous HPSs, and so on.

Such HPS references involve several problems. For example, allowing HPSs to reference other HPSs results in complex mechanisms. As a specific example, this mechanism can lead to a series of HPS references. In some cases, this approach can lead to long chains of HPS in that there may not be an explicit limit on the number of HPS references used in the bitstream containing the video data. . To manage such a scheme, the decoder may need to maintain an arbitrary number of HPS in the decoding picture buffer in preparation for possible subsequent references. To address this issue, an HPS reset mechanism may be added to break any such extended HPS reference chain, which adds further complexity. Furthermore, this approach is potentially error-prone. For example, if a previous HPS is lost due to a transmission error, the subsequent reference HPS will not contain enough data to code the corresponding slice . Also, this approach can lead to a large number of HPS in the bitstream. However, the number of HPS identifiers (IDs) may be limited to avoid coding large HPS ID values. As such, the HPS ID may be reused within the bitstream. This may result in ambiguity, for example, if an HPS references an HPS ID used by more than one reference HPS. Additionally, HPS may be signaled within the coded bitstream, which is referred to as in-band signaling. The HPS may also be informed by external mechanisms, eg, in metadata information. Such signaling is called out-of-band signaling. Such a dual signaling mechanism further increases the complexity of the HPS scheme.

Various mechanisms are disclosed herein to reduce the complexity of HPS signaling. HPS is called HPS in the latest standards document. Accordingly, the following disclosure generally refers to HPS for clarity of discussion. However, the terms HPS and APS may be used interchangeably in most aspects. The present disclosure removes the complexity and error-prone nature of HPSs by preventing them from referencing other HPSs. Loss of a single HPS only causes a local error since the HPS does not have to refer to other HPSs. Additionally, the decoder may not be required to maintain HPSs in memory, with later HPSs replacing earlier ones. As a specific example, multiple types of HPS may be used, where HPS type indicates the type of coding tool parameters included in the HPS. Such HPS types may include adaptive loop filter (ALF) HPS, luma mapping with chroma scaling (LMCS) HPS, and/or scaling list parameter HPS. In such an example, when a current HPS of the first type is obtained by the decoder, a previous HPS of the first type is discarded such that the current HPS replaces such previous HPS. It can be done. Additionally, to allow for multiple types of HPS, a single slice header may reference more than one HPS to reference all coding tool parameters for the corresponding slice. This is in contrast to other schemes that allow the slice header to refer to a single HPS which in turn refers to other HPSs. Therefore, allowing a single slice header to reference multiple HPSs provides an implementation that avoids HPS reference chains. This disclosure also describes mechanisms that allow HPS to operate with time scaling. With temporal scaling, the bitstream is configured to allow the decoder and/or user to select from multiple frame rates. To implement such a scheme, each picture/frame is assigned a temporal ID. Frames with lower temporal IDs are displayed at each frame rate. Frames with higher temporal IDs are skipped for lower frame rates and displayed only for higher frame rates. To support such temporal scaling, the HPS is assigned a temporal ID. The HPS may receive the temporal ID of the picture containing the first slice that references the HPS. In other examples, the HPS may receive the temporal ID of the access unit that includes the HPS. An access unit is a bitstream data grouping that contains enough video data to decode a corresponding picture. To further support temporal scaling, slices associated with lower temporal IDs may be restricted from referencing HPSs containing higher temporal IDs. This ensures that lower frame rate settings do not cause slices to reference HPS that are ignored due to temporal scaling, and therefore make coding tool parameters unavailable when decoding a particular slice at lower frame rates. Prevent it from being possible.

FIG. 1 is a flowchart of an example method of operation 100 for coding a video signal. Specifically, the video signal is encoded by an encoder. The encoding process compresses the video signal by using various mechanisms to reduce the video file size. Smaller file sizes allow compressed video files to be transmitted toward users while reducing associated bandwidth overhead. A decoder then decodes the compressed video file to reconstruct the original video signal for display to an end user. The decoding process generally mirrors the encoding process to allow the decoder to consistently reconstruct the video signal.

At 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, a video file may be captured by a video capture device, such as a video camera, and encoded to support live streaming of the video. A video file may include both an audio component and a video component. A video component includes a series of image frames that, when viewed in succession, give a visual impression of movement. A frame includes pixels that are expressed in terms of light, referred to herein as a luma component (or luma sample), and color, referred to herein as a chroma component (or color sample). In some examples, frames may also include depth values to support three-dimensional display.

At step 103, the video is partitioned into blocks. Partitioning involves subdividing pixels within each frame into square and/or rectangular blocks for compression. For example, in High Efficiency Video Coding (HEVC) (known as H.265 and MPEG-H Part 2), a frame is first coded by a coding tree unit (which is a block of predefined size (e.g., 64x64 pixels)). CTU). A CTU includes both luma and chroma samples. The coding tree may be used to divide the CTU into blocks and then recursively subdivide the blocks until a configuration that supports further encoding is achieved. For example, the luma component of a frame may be subdivided until individual blocks contain relatively uniform brightness values. Additionally, the chroma components of the frame may be subdivided until individual blocks contain relatively uniform color values. Therefore, the partitioning mechanism changes depending on the content of the video frame.

At step 105, various compression mechanisms are used to compress the image blocks partitioned at 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. Therefore, blocks representing objects in the reference frame do not need to be repeatedly described in adjacent frames. Specifically, an object, such as a table, may remain in place over multiple frames. Therefore, the table is written once and adjacent frames can refer back to the reference frame. A pattern matching mechanism may be used to match objects across multiple frames. Furthermore, moving objects may be represented over multiple frames, for example due to object motion or camera motion. As a specific example, a video may show a car moving across the screen over multiple frames. Motion vectors can be used to describe such motion. A motion vector is a two-dimensional vector that provides an offset from the object's coordinates in one frame to the object's coordinates in a reference frame. As such, inter prediction may encode image blocks in a current frame as a set of motion vectors that indicate offsets from corresponding blocks in a reference frame.

Intra prediction encodes blocks within a common frame. Intra prediction takes advantage of the fact that luma and chroma components tend to cluster in frames. For example, patches of green in a portion of a tree tend to be located adjacent to similar patches of green. Intra prediction uses multiple directional prediction modes (eg, 33 in HEVC), planar mode, and direct current (DC) mode. Directional mode indicates that the current block is similar/same as samples of neighboring blocks in the corresponding direction. Planar mode indicates that a series of blocks along a row/column (eg, a plane) can be interpolated based on neighboring blocks at the ends of the row. Planar mode effectively exhibits smooth transitions of light/color across rows/columns by using a relatively constant slope of changing values. The DC mode is used for boundary smoothing and indicates that a block is similar/same as the average value associated with the samples of all neighboring blocks related to the angular direction in the directional prediction mode. Therefore, an intra-prediction block can represent an image block as various associated prediction mode values instead of actual values. Additionally, inter-predicted blocks can represent image blocks as motion vectors instead of actual values. In either case, the predictive block may not accurately represent the image block in some cases. Any differences are saved in the residual block. Transforms may be applied to the residual blocks to further compress the file.

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

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

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

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

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

FIG. 2 is a schematic diagram of an example coding and decoding (CODEC) system 200 for video coding. Specifically, codec system 200 provides functionality to support implementation of method of operation 100. Codec system 200 is generalized to represent components used in both encoders and decoders. Codec system 200 receives and partitions a video signal as described with respect to steps 101 and 103 of method of operation 100, resulting in a partitioned video signal 201. Codec system 200 then compresses partitioned video signal 201 into a coded bitstream when operating as an encoder as described with respect to steps 105, 107, and 109 of method 100. When operating as a decoder, codec system 200 generates an output video signal from the bitstream as described with respect to steps 111, 113, 115, and 117 of method of operation 100. Codec system 200 includes a general coder control component 211, a transform scaling and quantization component 213, an intra picture estimation component 215, an intra picture prediction component 217, a motion compensation component 219, a motion estimation component 221, a scaling and inverse transform component 229, and a filter control component. It includes an analysis component 227, an in-loop filter component 225, a decoding picture buffer component 223, and a header formatting and Context Adaptive Binary Arithmetic Coding ( CABAC) component 231. Such components are coupled as shown. In FIG. 2, black lines indicate the movement of data to be encoded/decoded, and white dashed lines indicate the movement of control data that controls the operation of other components. All components of codec system 200 may be present in the encoder. The 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 decoding picture buffer component 223. These components will now be described.

Partitioned video signal 201 is a captured video sequence that is partitioned into blocks of pixels by a coding tree. Coding trees use various splitting modes to subdivide blocks of pixels into smaller blocks of pixels. These blocks may then be further subdivided into smaller blocks. A block may be called a node on a coding tree. Larger parent nodes are split into smaller child nodes. The number of times a node is subdivided is called the depth of the node/coding tree. The partitioned blocks may be included in coding units (CUs) in some cases. For example, a CU can be a sub-portion of a CTU that includes a luma block, a red differential chroma (Cr) block, and a blue differential chroma (Cb) block, along with the CU's corresponding syntax instructions. The splitting mode is a binary tree (BT), a ternary tree ( TT), and quadtrees (QT). Partitioned video signal 201 is forwarded to general coder control component 211, transform scaling and quantization component 213, intra picture estimation component 215, filter control analysis component 227, and motion estimation component 221 for compression.

The general coder control component 211 is configured to make decisions regarding the 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 for reconstruction quality. Such decisions may be made based on storage space/bandwidth availability and image resolution requirements. General purpose coder control component 211 also manages buffer utilization in light of transmission rate to alleviate buffer underrun and overrun problems. To manage these issues, general coder control component 211 manages partitioning, prediction, and filtering by other components. For example, the general purpose coder control component 211 may dynamically increase compression complexity to increase resolution and increase bandwidth utilization, or reduce compression complexity to decrease resolution and bandwidth utilization. . Accordingly, general coder control component 211 controls other components of codec system 200 to balance video signal reconstruction quality and bit rate concerns. General purpose coder control component 211 generates control data that controls the operation of other components. Control data is also transferred to the header formatting and CABAC component 231 to be encoded in the bitstream to inform the parameters for decoding at the decoder.

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

Motion estimation component 221 and motion compensation component 219 may be highly integrated, but are represented separately for conceptual purposes. Motion estimation performed by motion estimation component 221 is the process of generating motion vectors, thereby estimating the motion of a video block. A motion vector may, for example, indicate a displacement of a coded object with respect to a predictive block. A predicted block is a block that is found to closely match the block to be coded in terms of pixel differences. A predictive block may also be called a reference block. Such pixel differences may be determined by a Sum of Absolute Difference (SAD), a Sum of Square Difference ( SSD), or other difference metrics. HEVC uses several coded objects including CTUs, coding tree blocks (CTBs), and CUs. For example, a CTU may be partitioned into CTBs, which may then be partitioned into CBs for inclusion in a CU. A CU may be encoded as a prediction unit (PU) containing prediction data and/or a transform unit (TU) containing transformed residual data for the CU. Motion estimation component 221 generates motion vectors, PUs, and TUs by using rate-distortion analysis as part of a rate-distortion optimization process. For example, motion estimation component 221 may determine a number of reference blocks, a number of motion vectors, etc. for the current block/frame, and select the reference block, motion vector, etc. that has the best rate-distortion characteristics. You may choose. The best rate-distortion characteristics balance both video reconstruction quality (e.g., amount of data loss due to compression) and coding efficiency (e.g., size of final encoding).

In some examples, codec system 200 may calculate values for sub-integer pixel positions of reference pictures stored in decoding picture buffer component 223. For example, video codec system 200 may interpolate values at quarter pixel positions, eighth pixel positions, or other fractional pixel positions of a reference picture. Accordingly, motion estimation component 221 may perform motion estimation for full pixel locations and fractional pixel locations and output motion vectors with fractional pixel precision. Motion estimation component 221 calculates a motion vector for a PU of a video block within an inter-coded slice by comparing the position of the PU to the position of a predictive block of a reference pixel. Motion estimation component 221 outputs the calculated motion vectors as motion data to header formatting and CABAC component 231 for encoding, and motion data to motion compensation component 219.

Motion compensation performed by motion compensation component 219 may include fetching or generating predictive blocks based on motion vectors determined by motion estimation component 221. As before, motion estimation component 221 and motion compensation component 219 may be functionally integrated in some examples. Upon receiving the motion vector for the PU of the current video block, motion compensation component 219 may find the location of the predictive block pointed to by the motion vector. 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, motion estimation component 221 performs motion estimation on the luma component, and motion compensation component 219 uses motion vectors computed based on the luma component, for both chroma and luma components. The prediction block and residual block are transferred to transform scaling and quantization component 213.

Partitioned video signal 201 is also sent to intra picture estimation component 215 and intra picture prediction component 217. Like motion estimation component 221 and motion compensation component 219, intra picture estimation component 215 and intra picture prediction component 217 may be highly integrated, but are represented separately for conceptual purposes. Intra picture estimation component 215 and intra picture prediction component 217 are used for blocks within the current frame as an alternative to the inter prediction performed by motion estimation component 221 and motion compensation component 219 between frames as described above. Intra predict the current block. In particular, intra picture estimation component 215 determines the intra prediction mode to use to encode the current block. In some examples, 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 header formatting and CABAC component 231 for encoding.

For example, intra picture estimation component 215 calculates rate-distortion values using rate-distortion analysis for various tested intra-prediction modes, and determines which intra-prediction has the best rate-distortion characteristics among the tested modes. Select mode. Rate-distortion analysis generally includes the bitrate (e.g., number of bits) used to produce the encoded block, as well as the encoded block and the source code that was encoded to produce the encoded block. The amount of distortion (or error) between the encoded blocks and the unencoded blocks is also determined. Intra picture estimation component 215 calculates a ratio from the distortion and rate for various encoded blocks to determine which intra prediction mode exhibits the best rate distortion value for that block. Moreover, the intra-picture estimation component 215 may be configured to code the depth blocks of the depth map using a Depth Modeling Mode (DMM) based on rate-distortion optimization (RDO).

Intra picture prediction component 217, if implemented in an encoder, generates a residual block from the prediction block based on the selected intra prediction mode determined by intra picture estimation component 215, or if implemented in a decoder. If so, the residual block may be read from the bitstream. The residual block contains the difference in values between the predicted block and the original block, represented as a matrix. The residual block is then transferred to transform scaling and quantization component 213. Intra picture estimation component 215 and intra picture prediction component 217 may operate on both luma and chroma components.

Transform scaling and quantization component 213 is configured to further compress the residual block. The transform scaling and quantization component 213 applies a transform, such as a Discrete Cosine Transform ( DCT), a Discrete Sine Transform ( DST), or a conceptually similar transform, to the residual block to reduce the residual size. A video block having difference transform coefficient values is generated. Wavelet transforms, integer transforms, subband transforms, or other types of transforms may also be used. The transformation may transform the residual information from a pixel value domain to a transform domain, such as a frequency domain. Transform scaling and quantization component 213 is also configured to scale the transformed residual information, eg, based on frequency. Such scaling involves applying a scale factor to the residual information such that different frequency information is quantized with different granularity, which affects the final visual quality of the reconstructed video. can be affected. Transform scaling and quantization component 213 is also configured to quantize the transform coefficients to further reduce the bit rate. The quantization process may reduce the bit depth associated with some or all coefficients. The degree of quantization can be changed by adjusting the quantization parameter. In some examples, transform scaling and quantization component 213 may then perform a scan of the matrix containing the quantized transform coefficients. The quantized transform coefficients are transferred to header formatting and CABAC component 231 for encoding in the bitstream.

Scaling and inverse transform component 229 applies the inverse operation of transform scaling and quantization component 213 to support motion estimation. The scaling and inverse transform component 229 inversely scales, transforms, and so on to reconstruct the residual block in the pixel domain for later use as a reference block that can be a predictive block for other current blocks, for example. , and/or apply quantization. Motion estimation component 221 and/or motion compensation component 219 may compute reference blocks by adding the residual blocks back to the corresponding predictive blocks for use in motion estimation of subsequent blocks/frames. Filters are applied to the reconstructed reference blocks to reduce artifacts introduced during scaling, quantization, and transformation. Such artifacts may otherwise cause incorrect predictions (and cause further artifacts) when subsequent blocks are predicted.

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

When operating as an encoder, the filtered reconstructed image blocks, residual blocks, and/or prediction blocks are sent to the decoding picture buffer component 223 for later use in motion estimation as described above. is memorized. When operating as a decoder, the decoding picture buffer component 223 stores and forwards the reconstructed and filtered blocks toward the display as part of the output video signal. Decoding picture buffer component 223 may be any memory device capable of storing predictive blocks, residual blocks, and/or reconstructed image blocks.

Header formatting and CABAC component 231 receives data from various components of codec system 200 and encodes such data into a coded bitstream for transmission to a decoder. Specifically, header formatting and CABAC component 231 generates various headers for encoding control data, such as general purpose control data and filter control data. Furthermore, in addition to residual data in the form of quantized transform coefficient data, prediction data, including intra-prediction and motion data, are all encoded in 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 intra-prediction mode index table (also called a codeword mapping table), definitions of encoding contexts for various blocks, an indication of the most likely intra-prediction mode, an indication of partition information, etc. Such data may be encoded by using entropy coding. For example, the information can be stored in Context Adaptive Variable Length Coding (CAVLC), CABAC, Syntax-based context-adaptive Binary Arithmetic Coding ( SBAC), Stochastic Interval Partitioned Entropy It may be encoded by using Probability Interval Partitioning Entropy ( PIPE) coding or other entropy coding techniques. Following entropy coding, the coded bitstream may be transmitted to another device (eg, a video decoder) or archived for later transmission or retrieval.

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

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

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

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

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

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

FIG. 5 is a schematic diagram representing an example bitstream 500 that includes an encoded video sequence along with an HPS 513. For example, bitstream 500 may be generated by codec system 200 and/or encoder 300 for decoding by codec system 200 and/or decoder 400. As another example, bitstream 500 may be generated by an encoder at step 109 of method 100 for use by a decoder at step 111.

Bitstream 500 includes a sequence parameter set (SPS) 510, a plurality of picture parameter sets (PPS) 512, a plurality of HPS 513 , a plurality of slice headers 514, and image data 520. SPS 510 contains sequence data that is common to all pictures in the video sequence included in bitstream 500. Such data may include picture sizing, bit depth, coding tool parameters, bit rate limits, etc. PPS 512 includes parameters that apply to the entire picture. Accordingly, each picture within a video sequence may reference PPS 512. It should be noted that while each picture references a PPS 512, a single PPS 512 may contain data for multiple pictures in some examples. For example, multiple similar pictures may be coded according to similar parameters. In such cases, a single PPS 512 may contain data for such similar pictures. PPS 512 may indicate coding tools, quantization parameters, offsets, etc. available for slices within the corresponding picture. Slice header 514 includes parameters that are specific to each slice within the picture. Thus, there may be one slice header 514 for each slice in the video sequence. Slice header 514 may include slice type information, picture order counts (POC), reference picture list, prediction weights, tile entry points, deblocking parameters, and the like.

HPS 513 is a syntax structure that includes syntax elements that apply to zero or more slices as determined by zero or more syntax elements found in the slice header. Accordingly, HPS 513 includes syntax elements for coding tool parameters associated with multiple slices. HPS 513 may also be referred to as HPS in some systems. For example, one or more slices may reference HPS 513 . Accordingly, the decoder can obtain the HPS 513 based on such reference, obtain coding tool parameters from the HPS 513, and use the coding tool parameters to decode the corresponding slice. HPS 513 conceptually occupies a hierarchical position between PPS 512 and slice header 514. For example, particular data may relate to multiple slices rather than an entire picture. Such data may not be stored in PPS 512 because the data is not related to the entire picture. However, such data would otherwise be included in multiple slice headers 514. HPS 513 can accept such data to avoid redundant signaling across multiple slice headers 514. The HPS513 coding structure was introduced in VVC and there is no similar structure in HEVC or previous coding standards. Various implementations of HPS 513 are described below.

Image data 520 includes video data encoded according to inter-prediction and/or intra-prediction, along with corresponding transformed and quantized residual data. For example, a video sequence includes a plurality of pictures 521 coded as image data. Picture 521 is a single frame of a video sequence, and thus is generally displayed as a single unit when displaying a video sequence. However, partial pictures may be displayed implementing certain technologies such as virtual reality, picture-in-picture, etc. Pictures 521 each refer to PPS 512. Picture 521 is divided into slices 523. Slice 523 may be defined as a horizontal cross section of picture 521. For example, slice 523 may include a portion of the height of picture 521 and the entire width of picture 521. In some systems, slice 523 is subdivided into tiles 525. In other systems, slice 523 is replaced by a tile group that includes tile 525. Slices 523 and/or groups of tiles 525 reference slice headers 514 and/or HPSs 513. Tile 525 may include a rectangular portion of picture 521 and/or a portion of picture 521 defined by columns and rows. Tiles 525 are further divided into coding tree units (CTUs). The CTU is further divided into coding blocks based on the coding tree. The coding block may then be encoded/decoded according to a prediction mechanism.

Bitstream 500 is coded into VCL NAL units 533 and non-VCL NAL units 531. A NAL unit is a coded data unit sized to be placed as the payload for a single packet for transmission over a network. VCL NAL unit 533 is a NAL unit that contains coded video data. For example, each VCL NAL unit 533 may include a tile group of data, a CTU, and/or a coding block, including one slice 523 and/or a corresponding tile 525. Non-VCL NAL units 531 are NAL units that include supporting syntax but do not include coded video data. For example, non-VCL NAL unit 531 may include SPS 510, PPS 512, HPS 513, slice header 514, and so on. As such, the decoder receives the bitstream 500 in separate VCL NAL units 533 and non-VCL NAL units 531. An access unit 535 is a group of VCL NAL units 533 and/or non-VCL NAL units 531 that includes sufficient data to code a single picture 521.

In some examples, HPS 513 may be implemented as follows. HPS 513 may be available in-band and/or out-of-band, where in-band signaling is included in bitstream 500 and out-of-band is included in supporting metadata. HPS 513 is included in a NAL unit, such as non-VCL NAL unit 531, where HPS 513 is identified by a NAL unit type. The HPS 513 includes coding tools such as, but not limited to, ALF, SAO, deblocking, quantization matrices, inter prediction parameters, parameters related to reference picture set configuration, and/or parameters related to reference picture list configuration. may contain parameters for HPS 513 may include a type. The type defines which coding tool parameters are included in the HPS 513. Each HPS 513 may include only one type of coding tool parameter. Different types of HPS 513 may be grouped together into a group of parameter sets (GPS). Rather than referencing a single HPS 513, slice 523 may refer to GPS. HPS 513 may be made available to the decoder before being referenced by the corresponding slice 523 and/or tile group. Different slices 523 of coded picture 521 may reference different HPSs 513. HPS 513 may be placed at the boundary of any slice 523 in bitstream 500. This allows reuse of parameters (eg, ALF parameters) in HPS 513 even for all slices 523 of current picture 521 following HPS 513.

References from slice header 514 to HPS 513 may be arbitrary. For example, slice 523 may reference HPS 513 if any of the following are true: First, such a reference may indicate in the corresponding PPS 512 that the HPS 513 is available for the bitstream 500. Second, slice 523 may reference HPS 513 if at least one of the coding tools whose parameters are included in HPS 513 is enabled for bitstream 500. Each HPS 513 may be associated with an HPS ID. Slices 523 that reference HPS 513 should include the HPS ID of the referenced HPS 513. The HPS ID may be coded with an unsigned integer zero-order Exp-Golomb coded syntax element starting from the left bit (eg, ue(v)). The value of the HPS ID may be limited to a range of 0 to 63, for example. For each parameter of the coding tool, a flag may exist in HPS 513 to indicate whether that parameter is present in HPS 513. If a coding tool is enabled for slice 523 and parameters for that coding tool exist in HPS 513 referenced by slice 523, the parameters may not be signaled in the corresponding slice header 514. HPS 513 may be fragmented into one or more NAL units, and each fragment of HPS 513 may be independently parsed and applied. A slice 523 may reference a single HPS 513 or multiple HPSs 513. If references to multiple HPSs 513 are allowed, each reference to an HPS 513 may be used to determine the parameters of a particular coding tool.

The following implementation allows HPSs 513 to reference other HPSs 513 and inherit coding tool parameters through such references. HPS 513 may include one or more references to other HPS 513. In such an example, an HPS 513 may be referred to as an intra-HPS if the HPS 513 does not reference any other HPS 513. If an HPS 513 references another HPS 513, the referencing HPS 513 may copy one or more parameters from the reference HPS 513. HPS 513 may have multiple references to other HPS 513, one reference HPS 513 per parameter group. In some examples, a linked list of HPSs 513 may be formed in which a series of HPSs 513 are connected by a reference mechanism. If a parameter of the coding tool is identified as not present in the HPS 513 (e.g., the value of the present flag is equal to 0), an additional flag is present to indicate whether the parameter can be inherited from the reference HPS 513. It's okay. References from HPS 513 to other HPS 513 are implicitly made such that if a coding tool parameter is not present in HPS 513, such parameter is inherited to be the same as the coding tool parameter for the previous HPS 513. can be specified.

In some cases, HPS 513 may no longer be present when invoking Instantaneous Decoder Refresh ( IDR) and/or Clean Random Access ( CRA) random access to pictures. Therefore, two HPS buffers may be used to store the HPS 513, each buffer being alternatively active at the beginning of each Intra Random Access Point ( IRAP) picture. be made into In such case, the received HPS 513 is stored in the active HPS buffer. To improve error resiliency, a range of HPS IDs may be defined to indicate HPS IDs that are currently in use. If an HPS 513 has an HPS ID outside of the HPS ID range in use, the additional HPS 513 may use that HPS ID. The HPS ID in use may then be updated according to a sliding window approach. When this technique is used, HPS 513 may only refer to other HPS 513 whose HPS ID is within the range in use. A limit on the number of active HPSs 513 may be defined to limit the storage requirements of HPSs 513 in the decoder memory. If the limit is reached and a new HPS 513 is received, the oldest (eg, earliest received) HPS 513 in the buffer may be deleted and a new HPS 513 inserted.

In some cases, all HPS 513 references may be resolved as soon as the HPS 513 is received by the decoder. For example, the coding tool parameters may be copied as soon as the decoder receives the HPS 513, where the coding tool parameters are not available in the current HPS 513 but are available in the reference HPS 513. Other approaches to improving error resiliency may require that intra-HPS 513 be present during certain periods of time. If an intra-HPS 513 is received, all available HPS 513 of the same type in the buffer may be discarded. A flag may be present to indicate whether the coding tool is disabled for the slice 523 that references the HPS 513 if the coding tool's parameters are not present in the HPS 513. Additionally, a flag in the NAL unit header (eg, nal_ref_flag) may define whether the HPS 513 included in the NAL unit can be referenced by a slice 523 from a picture 521 used as a reference. For example, HPS 513 may only be referenced by slice 523 of non-reference picture 521 if the nal_ref_flag of the NAL unit containing HPS 513 is equal to 0. This flag may also be used to determine which HPS 513 may be used as a reference for other HPS 513. For example, an HPS 513 may not reference other HPSs 513 that are included in a NAL unit with nal_ref_flag equal to 0. A reset period for the HPS buffer may be defined in SPS 510. The buffer of HPS 513 may be reset upon generation of an IRAP picture.

As can be seen from reviewing the above implementation, allowing HPSs 513 to reference other HPSs 513 can be quite complex. Accordingly, in the disclosed example, HPSs 513 may be restricted from referencing other HPSs 513. Alternatively, multiple types of HPS 513 may be used. The type of HPS 513 indicates the type of coding tool parameters included in HPS 513. Types of such HPS 513 may include ALF HPS, LMCS HPS, and/or scaling list parameter HPS. ALF HPS is an HPS that contains coding tool parameters used as part of the adaptive loop filtering of the corresponding slice. The LMCS HPS includes the coding tool parameters used for the LMCS mechanism. LMCS is a filtering technique that reshapes the luma component based on its mapping to the corresponding chroma component to reduce rate distortion. The scaling list parameters HPS include coding tool parameters related to the quantization matrices used by a particular filter. In such an example, when a current HPS 513 of the first type is obtained by the decoder, a previous HPS 513 of the first type is discarded such that the current HPS 513 replaces such previous HPS 513. It can be done. Additionally, to allow for multiple types of HPS 513, a single slice header 514 may reference more than one HPS 513 to reference all coding tool parameters for the corresponding slice 523 and/or tile group. You may do so. This is in contrast to other schemes that allow the slice header 514 to reference a single HPS 513 which in turn references other HPSs 513. Therefore, allowing a single slice header 514 to reference multiple HPSs 513 provides an implementation that avoids reference chains of HPSs 513. This approach greatly reduces complexity and thus reduces processing resource utilization at both the encoder and decoder. Additionally, this process reduces the number of HPSs 513 buffered at the decoder. For example, only one HPS 513 of each type may be buffered at the decoder. This reduces memory usage in the decoder. Furthermore, by avoiding the reference chain of HPS 513, potential errors are detected and thus reduced. This is because losing HPS 513 during a transmission error can only affect slices 523 that directly reference HPS 513. As such, the disclosed mechanism produces improvements at both the encoder and decoder when using HPS 513 in bitstream 500.

FIG. 6 is a schematic diagram representing an example mechanism 600 for temporal scaling. For example, mechanism 600 may be used by codec system 200 and/or a decoder, such as decoder 400, when displaying a decoded bitstream, such as bitstream 500. Additionally, mechanism 600 may be used as part of step 117 of method 100 when outputting video for display. Also, an encoder, such as codec system 200 and/or encoder 300, may encode data within the bitstream to enable mechanism 600 to occur at the decoder.

Mechanism 600 operates on multiple decoded pictures 601, 603, and 605. Pictures 601, 603, and 605 are part of an ordered video sequence and have been decoded from the bitstream, eg, by using the mechanisms described above. The bitstream causes the decoder to display the video sequence at one of a plurality of frame rates, including a first frame rate (FR0) 610, a second frame rate (FR1) 611, and a third frame rate (FR2) 612. is encoded to make it possible. Frame rate is a measure of the frequency at which frames/pictures of a video sequence are displayed. Frame rate may be measured in frames over time. Differences in frame rate allow different decoders to display the same video sequence with different quality to account for variations in decoder capabilities. For example, a decoder with reduced hardware capabilities and/or a decoder streaming from a poor quality network connection may be indicated as FR0 610. As another example, a high quality decoder with access to a high speed network connection may be designated as FR2 612. As yet another example, a decoder with a particular functional impairment may be able to display on FR1 611 but not on FR2 612. Accordingly, temporal scaling (e.g., mechanism 600) is used to enable each decoder to display video at the highest possible frame rate for the best user experience based on varying decoder-side capabilities and constraints. used for. In most systems, each frame rate is twice the frequency of the previous frame rate. For example, FR0 610, FR1 611, and FR2 612 may be set to 15 frames per second (FPS), 30FPS, and 60FPS, respectively.

To implement temporal scaling, pictures 601, 603, and 605 are coded into the bitstream by an encoder at the highest possible frame rate, in this case FR2 612. The encoder also assigns each picture 601, 603, and 605 a temporal identifier (TID). Pictures 601, 603, and 605 have received TIDs of 0, 1, and 2, respectively. When displaying the resulting decoded video, the decoder selects a frame rate, determines a corresponding frame rate TID, and displays all frames with TIDs that are less than or equal to that frame rate TID. Pictures with TIDs greater than the frame rate TID of the selected frame rate are ignored. For example, a decoder that selects FR2 612 would display all pictures with a TID less than or equal to 2, and thus display all pictures 601, 603, and 605. As another example, a decoder that selects FR1 611 would display all pictures with a TID of 1 or less, thus displaying pictures 601 and 603 while ignoring picture 605. As another example, a decoder that selects FR0 610 would display all pictures with a TID less than or equal to 0, thus displaying picture 601 while ignoring pictures 603 and 605. By using this mechanism 600, a video sequence can be temporally scaled by a decoder to a selected frame rate.

HPS 513 described in FIG. 5 may be implemented to support temporal scaling of mechanism 600. This may be accomplished by assigning a TID, such as TID0, TID1, or TID2, to each HPS. When temporal scaling is performed, HPSs with TIDs less than or equal to the selected frame rate TID are decoded and HPSs with TIDs greater than the selected frame rate TID are discarded. A TID may be assigned to an HPS according to various embodiments.

Referring to FIG. 5, in one example, HPS 513 may receive the temporal ID of picture 521 that includes first slice 523 that references HPS 513. In other examples, HPS 513 may receive the temporal ID of access unit 535 that includes HPS 513. To further support temporal scaling, slices 523 associated with lower temporal IDs may be restricted from referencing HPSs 513 containing higher temporal IDs. This ensures that lower frame rate settings do not make slices 523 reference HPS 513, which is ignored by the time scaling of mechanism 600, and therefore coding tool parameters lower such as FR0 610 and/or FR1 611. Prevents unavailability when decoding a particular slice 523 at the frame rate.

The above mechanism may be implemented as follows. The following aspects may be applied individually and/or in combination. Adaptive Parameter Set (APS) is another name for HPS. HPS availability for bitstreams may be all available in-band, all available out-of-band, and/or some available in-band, and some available in-band. portion is available out-of-band. When provided out-of-band, the HPS may reside in: In ISO-based media file formats, the HPS may be present in the sample entry (eg, sample description box). In ISO-based media file formats, the HPS may reside in time-synchronized tracks, such as parameter set tracks or timed metadata tracks.

In certain implementations, when provided out of band, the HPS may be carried as follows. In ISO-based media file formats, HPS may only be present in sample entries (eg, sample description boxes) if no HPS updates are present. HPS updates may not exist if the HPS identifier (ID) is reused while other HPS parameters are different from the previously sent HPS with the same HPS ID. In media file formats based on the International Organization for Standardization (ISO), if an HPS update is present, e.g. if the HPS includes adaptive loop filter (ALF) parameters, the HPS is a parameter set track or timed metadata. - May be transported by time-synchronized trucks such as trucks. In this way, slices each containing a complete group of tiles may be carried in their own file format tracks. Furthermore, the HPS may be transported in time-synchronized trucks. As a result, each of these tracks may be carried in a Dynamic Adaptive Streaming of Hypertext transfer protocol ( DASH) representation. For decoding and rendering of the slice/tile track subset, a DASH representation containing the slice/tile track subset and a DASH representation containing the HPS may be requested by the client for each segment.

In other examples, HPS may be defined as always being provided in-band. HPS may also be carried in time-synchronized tracks, such as parameter set tracks or timed metadata tracks. As a result, HPS can be provided as described above. Furthermore, in the file format specifications for video codecs, the bitstream reconstruction process requires that the HPS be part of the output bitstream from a subset of the slice/tile tracks and the time-synchronized tracks containing the HPS. , may configure the output bitstream.

The HPS should be present and/or available to the decoder before the first slice that references the HPS in the decoding order. For example, if an HPS is available in-band, the HPS may precede the first slice that references the HPS in decoder order. Otherwise, the HPS decoding time should be less than or equal to the decoding time of the first slice that references the HPS.

The HPS may include the ID of a sequence level parameter set such as SPS. If the SPS ID does not exist in the HPS, the following constraints may apply. The HPS may be present in an IRAP access unit if the first slice that references the HPS is part of an intra random access point (IRAP) picture and the HPS is carried in-band. If the first slice that references the HPS is part of an IRAP picture and the HPS is carried out-of-band, the decoding time of the HPS may be the same as that of the IRAP picture. If the first slice that refers to the HPS is not part of an IRAP picture and the HPS is carried in-band, the HPS is transmitted between the IRAP access unit that starts the coded video sequence and the access unit that contains that slice. may exist in one of the access units inclusively present in the access unit. If the first slice that references the HPS is not part of an IRAP picture and the HPS is carried out-of-band, the decoding time of the HPS is equal to the decoding time of the IRAP access unit that starts the coded video sequence and its It may exist inclusively between the decoding time of the access unit including the slice.

If the SPS ID is present in the HPS, the following may apply: When provided in-band, the HPS is present at the beginning of the bitstream or in any coded sequence as long as the HPS precedes the first slice that references it in the decoding order. It's fine. Otherwise, the HPS may be present in the same entry or in time-synchronized tracks as long as the decoding time of the HPS is less than the decoding time of the first slice that references the HPS.

For slice references to HPS, the following may apply. If the SPS ID exists in the HPS, each slice and the HPS it references may reference the same SPS. Otherwise, the slice may not refer to HPSs present in access units that precede the IRAP access unit with which the slice is associated. A slice may also be restricted from referencing HPSs that have a decoding time that is less than the decoding time of the IRAP access unit with which the slice is associated.

As an alternative to using flags to identify the presence of coding tool parameters in the HPS, a 2-bit indicator may be used (eg, coded as u(2)). The semantics of the indicator is defined as follows. A value of one of the indicators (eg, a value of 0) defines that the parameter does not exist in the HPS and that no references to other HPSs exist to derive the parameter. Other values of the indicator (eg, a value of 1) define that the parameter does not exist in the HPS and that references to other HPSs exist to derive the parameter. Other values of the indicator (eg, value 2) define that the parameter exists in the HPS and there are no references to other HPSs. Other values of the indicator may be reserved. In other examples, other values of the indicator (eg, value 3) define that the parameter exists in the HPS and that references to other HPSs exist to derive the parameter. In this case, the final parameters are derived by input from the parameters explicitly signaled in the HPS and the parameters present in the reference HPS.

If the coding tool is defined to be disabled for the coded video sequence by some indicating means (e.g. an enable flag in the sequence parameter set specifies that the coding tool is disabled), then Constraints may be applied individually or in combination. A flag or indication of the presence of parameters for the coding tool and the parameters for the coding tool may not be present in the HPS associated with the coded video sequence. A flag or indication of the presence of a parameter for the coding tool is present, but the value specifies that the parameter for the coding tool is not present and there is no reference HPS for deriving and/or inferring the parameter. There may be restrictions.

The following constraints may be applied individually or in combination when a slice references an HPS that may include coding tool parameters. If a coding tool is enabled for a slice and the coding tool parameters are available in the HPS, the coding tool parameters may not be present in the slice header. This may occur if the coding tool parameters are communicated directly and/or are present in the HPS or available through a reference HPS. The coding tool parameters may be present in the slice header if the coding tool is enabled for a slice and the coding tool parameters are not available in the HPS. This may occur if the coding tool parameters are not directly communicated and/or are not present at the HPS or available through the reference HPS. The coding tool parameters may also be present in the slice header if the coding tool is enabled for the slice and the coding tool parameters are available in the HPS. This may occur if the coding tool parameters are communicated directly and/or are present in the HPS or available through a reference HPS. In this case, the parameters used to invoke the coding tool during slice decoding are those present in the slice header.

If both in-band and out-of-band transport of HPS are used, the following may apply. If an HPS is carried in-band, the HPS may not reference other HPSs carried out-of-band. Otherwise, the HPS may not reference other HPSs carried within the band.

If both in-band and out-of-band transport of HPS are used, the following constraints may also be applied individually or in combination. HPS carried out of band may only be carried in time-synchronized trucks. HPS may be carried out-of-band only when there are HPS updates.

Instead of coding the HPS ID as an unsigned integer zero-order Exp-Golomb coded syntax element (ue(v)) starting with the left bit first, the HPS ID is coded as u(v). may be done. The number of bits for reporting the HPS ID may be specified in the SPS.

Two HPSs within the same coded video sequence may have the same HPS ID, in which case the following may apply. When HPS A and HPS B have the same HPS ID, HPS B follows HPS A in decoding order, and SPS contains an ID that references the HPS ID, then HPS B replaces HPS A. . When HPS A and HPS B have the same HPS ID, HPS B's decoding time is longer than HPS A's decoding time, and SPS contains an ID that references the HPS ID, then HPS B Replaces A. HPS A, HPS B, HPS C, and HPS D must be the same, either by having the same SPS ID (e.g., if the SPS ID is present in the HPS) or by association of the access unit containing the HPS. Let it be the HPS contained within the coded video sequence. When the HPS IDs of HPS A and HPS D are the same, and the HPS IDs of HPS A, HPS B, and HPS C are unique, the values of the HPS IDs of HPS A, HPS B, and HPS D monotonically increase. You may be restricted in what you do. A flag may be present in the SPS to specify whether the HPS may refer to other reference HPSs.

If cross-HPS references are not allowed, a slice header may have multiple references to the same HPS or different HPSs. In this case the following may apply: A HPS reference may exist for each coding tool that is enabled for a slice, and the parameters of the coding tool may be inferred from the HPS. If a slice references an HPS to infer coding tool parameters, the coding tool parameters should be present in that HPS.

If a parameter of a coding tool is not present in the HPS and a reference to another HPS exists for that parameter, then the parameter should be present in that reference HPS. HPSs may not reference other HPSs from different coded video sequences. If the SPS ID exists in the HPS, the value of the SPS ID in both the current HPS and the corresponding reference HPS must be the same. Otherwise, the HPS may not refer to other HPSs present in access units that precede the last IRAP access unit that precedes the HPS in decoding order. The HPS also has a decoding time that is less than the decoding time of the last IRAP access unit that precedes the HPS in the decoding order, or the last IRAP access unit that is closest to and has a decoding time that is less than the decoding time of the HPS. There is no need to refer to other HPSs that have time.

When an HPS references another HPS, the HPS ID of the reference HPS must be smaller than the HPS ID of that HPS. HPS A, HPS B, HPS C, and HPS D may all have the same SPS ID if the SPS ID exists in either HPS. The following constraints apply individually or in combination if HPS B follows HPS A in decoding order, HPS C follows HPS B in decoding order, and HPS D follows HPS C in decoding order. It's okay to be. If HPS C references HPS A, HPS B's HPS ID may not be the same as HPS A's HPS ID. When HPS B references HPS A and HPS C has the same HPS ID as HPS A, then HPS D need not reference either HPS A or HPS B. If HPS B and HPS A have the same HPS ID, there may be no slice following HPS B in decoding order that references HPS A. If HPS B references HPS A and HPS C has the same HPS ID as HPS A, even if there is no slice following HPS C in decoding order that references either HPS A or HPS B. good.

If temporal scalability is used, the temporal ID of the HPS may be specified as follows. The temporal ID of an HPS may be set to be the same as the temporal ID of the access unit containing the HPS. In one example, the temporal ID of an HPS may be set to be the same as the temporal ID of the picture of the first slice that references that HPS.

A slice in a picture with temporal ID (Tid) A may not reference the HPS with ID TidB if TidB is greater than TidA. The HPS with TidA may not refer to the reference HPS with TidB if TidB is greater than TidA. An HPS with TidA may not replace another HPS with TidB if TidA is greater than TidB.

A flag in the sequence level parameter (eg, SPS) may be present to specify whether a slice has a reference to HPS. The value of the flag, when set equal to 1, may define that the slice references an HPS and that the HPS ID is present in the header of the slice. The value of the flag, when set equal to 0, may define that the slice does not reference an HPS and that the HPS ID is not present in the slice's header.

The above aspects may be implemented according to the following syntax.

hps_present_flag may be set equal to 1 to define that hps_id is present in the slice header. hps_present_flag may be set equal to 0 to define that hps_id is not present in the slice header.

header_parameter_set_id may identify the HPS for reference by other syntax elements. The value of hdr_parameter_set_id may be in the range of 0 to 63. hps_seq_parameter_set_id specifies the value of sps_seq_parameter_set_id for the active SPS. The value of pps_seq_parameter_set_id may be in the range of 0 to 15. alf_parameters_idc[header_parameter_set_id] may be set equal to 2 to define that alf_data( ) exists in the HPS. alf_parameters_idc[header_parameter_set_id] is the alf_data( ) that does not exist in the HPS, but exists in the reference HPS specified by alf_ref_hps_id[header_parameter_set_id] set equal to 1 to specify that it is assumed to be the same as ta( ) good. alf_parameters_idc[header_parameter_set_id] may be set equal to 0 to define that neither alf_data( ) nor alf_ref_hps_id[header_parameter_set_id] is present in the HPS. The value of alf_parameters_idc[header_parameter_set_id] equal to 3 may be reserved. alf_ref_hps_id[header_parameter_set_id] may specify the header_parameter_set_id of the reference HPS for inferring the value of alf_data( ).

An example bitstream conformance check may require the following constraints to be applied. If present, the value of alf_ref_hps_id[header_parameter_set_id] may be smaller than the value of header_parameter_set_id. The value of hps_seq_parameter_set_id in the current HPS and in the HPS specified by alf_ref_hps_id[header_parameter_set_id] may be the same. The value of alf_parameters_idc[alf_ref_hps_id[header_parameter_set_id]] may be equal to 2.

Given HPS A with header_parameter_set_id equal to hpsA, HPS B with header_parameter_set_id equal to hpsB, HPS C with header_parameter_set_id equal to hpsC, and the current HPS: alf_ref_hps_id[header_parameter_set_id] if the following conditions are true: The value need not be equal to hpsA or hpsB. Such conditions are that HPS A precedes HPS B in decoding order, HPS B precedes HPS C in decoding order, and HPS C precedes the current HPS in decoding order. Such conditions also include that the value of alf_ref_id[hpsB] is equal to hpsA and the value of hpsC is equal to hpsA.

slice_hps_id specifies the header_parameter_set_id of the HPS that the slice refers to. If slice_hps_id does not exist, alf_parameters_idc[slice_hps_id] is assumed to be equal to 0. An example bitstream conformance check may require the following constraints to be applied. The HPS with header_parameter_set_id equal to slice_hps_id must be available prior to parsing of the slice header. If a HPS with header_parameter_set_id equal to slice_hps_id is available in-band, header_parameter_set_id should be present in one of the next access units. The IRAP access unit associated with the picture of the current slice, or any access unit that follows the IRAP access unit but precedes the current access unit in decoding order, or the current access unit. Given HPS A with header_parameter_set_id equal to hpsA, HPS B with header_parameter_set_id equal to hpsB, HPS C with header_parameter_set_id equal to hpsC, and the current slice, When both conditions are true, then The value of slice_hps_id must be equal to hpsA or hpsB. The conditions include that HPS A precedes HPS B in decoding order, HPS B precedes HPS C in decoding order, and HPS C precedes the current slice in decoding order. The conditions also include that the value of alf_ref_id[hpsB] is equal to hpsA and the value of hpsC is equal to hpsA.

Other example implementations are described below.

alf_parameters_idc[header_parameter_set_id] may be set equal to 2 to define that alf_data( ) exists in the HPS. alf_parameters_idc[header_parameter_set_id] is the alf_data( ) that does not exist in the HPS, but exists in the reference HPS specified by alf_ref_hps_id[header_parameter_set_id] set equal to 1 to specify that it is assumed to be the same as ta( ) good. alf_parameters_idc[header_parameter_set_id] may be set equal to 0 to define that neither alf_data( ) nor alf_ref_hps_id[header_parameter_set_id] is present in the HPS. If absent, lf_parameters_idc[header_parameter_set_id] may be assumed to be equal to 0. The value of alf_parameters_idc[header_parameter_set_id] equal to 3 may be reserved.

Other example implementations are described below.

A slice header may reference multiple HPSs. A slice of a picture may refer to the HPS for ALF parameters (e.g., pic_alf_HPS_id_luma[i]), the HPS for LMCS parameters (e.g., pic_lmcs_aps_id), and the HPS for scaling list parameters (e.g., pic_scaling_list_aps_id). can. pic_alf_aps_id_luma[i] specifies the adaptation_parameter_set_id of the i-th ALF HPS referenced by the luma component of the slice associated with the PH. slice_alf_aps_id_luma[i] specifies the adaptation_parameter_set_id of the i-th ALF HPS referenced by the luma component of the slice. The temporal ID of an HPS NAL unit with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_alf_aps_id_luma[i] must be less than or equal to the temporal ID of the coded slice NAL unit. The value of slice_alf_aps_id_luma[i] is inferred to be equal to the value of pic_alf_aps_id_luma[i] if slice_alf_enabled_flag is equal to 1 and slice_alf_aps_id_luma[i] is not present. pic_lmcs_aps_id specifies the adaptation_parameter_set_id of the LMCS HPS referenced by the slice associated with the PH. The temporal ID of an HPS NAL unit with aps_params_type equal to LMCS_APS and adaptation_parameter_set_id equal to pic_lmcs_aps_id must be less than or equal to the temporal ID of the picture associated with the PH. pic_scaling_list_aps_id specifies adaptation_parameter_set_id of scaling list HPS. The temporal ID of an HPS NAL unit with aps_params_type equal to SCALING_APS and adaptation_parameter_set_id equal to pic_scaling_list_aps_id must be less than or equal to the temporal ID of the picture associated with the PH.

The temporal ID of the HPS NAL unit must be the same as the access unit (AU) containing the HPS. The temporal ID of the HPS NAL unit must be less than or equal to the temporal ID of the coded slice NAL unit that references the HPS. In a specific example, the value of the temporal ID of a non-VCL NAL unit is constrained as follows. If nal_unit_type is equal to DPS_NUT, VPS_NUT, or SPS_NUT, the temporal ID must be equal to 0, and the temporal ID of the AU containing the NAL unit must be equal to 0. Otherwise, if nal_unit_type is equal to PH_NUT, then the temporal ID must be equal to the temporal ID of the PU containing the NAL unit. Otherwise, the temporal ID must be equal to 0 if nal_unit_type is equal to EOS_NUT or EOB_NUT. Otherwise, if nal_unit_type is equal to AUD_NUT, FD_NUT, PREFIX_SEI_NUT, or SUFFIX_SEI_NUT, then the temporal ID must be equal to the temporal ID of the AU containing the NAL unit. Otherwise, if nal_unit_type is equal to PPS_NUT, PREFIX_APS_NUT, or SUFFIX_APS_NUT, then the temporal ID must be greater than or equal to the temporal ID of the PU containing the NAL unit. If the NAL unit is a non-VCL NAL unit, the value of the temporal ID is equal to the minimum value of the temporal ID values of all AUs to which the non-VCL NAL unit applies. If nal_unit_type is equal to PPS_NUT, PREFIX_APS_NUT, or SUFFIX_APS_NUT, the temporal ID means that all PPSs and HPSs may be included at the beginning of the bitstream (e.g., if they are transported out-of-band and the receiver at the beginning of the bitstream), it may be greater than or equal to the temporal ID of the containing AU, in which case the first coded picture has a temporal ID equal to 0.

FIG. 7 is a schematic diagram of an example video coding device 700. Video coding device 700 is suitable for implementing the disclosed examples/embodiments described herein. Video coding device 700 has a downstream port 720, an upstream port 750, and/or a transceiver unit (Tx/Rx) 710 that includes a transmitter and/or receiver to communicate data upstream and/or downstream on the network. . Video coding device 700 also includes a processor 730 that includes a logic unit and/or a central processing unit (CPU) for processing data, and memory 732 for storing data. Video coding device 700 also includes an electrical opto-electrical (OE) component coupled to upstream port 750 and/or downstream port 720 for communication of data via an electrical, optical, or wireless communication network. EO) component and/or a wireless communication component. Video coding device 700 may also include input and/or output (I/O) devices 760 that communicate data to and from users. I/O devices 760 may include output devices such as a display to display video data, speakers to output audio data, and the like. I/O devices 760 may also include input devices such as a keyboard, mouse, trackball, and/or corresponding interfaces for interacting with such output devices.

Processor 730 is implemented by hardware and software. Processor 730 may include one or more CPU chips, cores (eg, as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc. , and digital signal processors (DSPs). Processor 730 communicates with downstream port 720, Tx/Rx 710, upstream port 750, and memory 732. Processor 730 has a coding module 714. Coding module 714 implements the disclosed embodiments described above, such as methods 100, 800, and 900 that may use bitstream 500 and/or mechanism 600. Coding module 714 may also implement any other methods/mechanisms described herein. Further, coding module 714 may implement codec system 200, encoder 300, and/or decoder 400. For example, coding module 714 can encode/decode pictures in a bitstream and encode/decode parameters associated with slices of pictures in multiple HPSs. Various types of HPS may be included with corresponding types of coding tool parameters. The slice header may then reference various types of HPS to obtain coding tool parameters for the corresponding slice. Such a HPS may also be assigned a temporal ID to function with a temporal scaling algorithm. Utilization of HPS allows coding tool parameters used by multiple slices to be collected in a single location (eg, with additional HPS if the parameters change). Therefore, redundant signaling is eliminated, which increases coding efficiency, reduces memory resource usage when storing the bitstream, and reduces network resource usage when communicating the bitstream. Accordingly, coding module 714 allows video coding device 700 to provide additional functionality and/or coding efficiency when coding video data. As such, coding module 714, in addition to addressing issues inherent in video coding techniques, also improves the functionality of video coding device 700. Additionally, coding module 714 accomplishes transformation of video coding device 700 into different states. Alternatively, coding module 714 may be executed as instructions stored in memory 732 and executed by processor 730 (eg, as a computer program product stored on a non-transitory medium).

The memory 732 includes a disk, tape drive, solid state drive, read only memory ( ROM), random access memory ( RAM), flash memory, and ternary content addressable memory ( Ternary Content- Associative Memory). One or more memory types, such as Addressable Memory ( TCAM), Static Random-Access Memory ( SRAM), etc. Memory 732 is used as an overflow data storage device to store programs when they are selected for execution and to store instructions and data that are read during program execution. good.

FIG. 8 is a flowchart of an example method 800 for encoding a video sequence into a bitstream, such as bitstream 500, by using HPS. 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. Method 800 may also encode the bitstream to support temporal scaling according to mechanism 600 at a decoder, such as decoder 400.

Method 800 may begin when an encoder receives a video sequence that includes multiple images and determines to encode the video sequence into a bitstream, eg, based on user input. The video sequence is partitioned into pictures/images/frames for further partitioning before encoding. At step 801, pictures are partitioned into slices, including a first slice.

At step 803, the plurality of slices, including the first slice, are encoded into a bitstream. A slice may be encoded by multiple coding tool parameters. In some examples, the slice is encoded by at least a first type of coding tool and a second type of coding tool. Specifically, the slices are encoded by a first type of coding tool based on first type of coding tool parameters. The slices are also encoded by a second type of coding tool based on second type of coding tool parameters. For example, such coding tools may include ALF coding tools, LMCS coding tools, and/or scaling list parameter coding tools.

At step 805, multiple HPSs are encoded into the bitstream. The plurality of HPSs may include at least a first HPS and a second HPS. The first HPS and the second HPS each include a first type of coding tool parameter and a second type of coding tool parameter used to encode the slice in step 803.

At step 807, a first slice header is encoded into the bitstream. The first slice header describes the encoding of the first slice among the plurality of slices to support decoding at the decoder. For example, the first slice header may include a first reference to a first HPS and a second reference to a second HPS. Thus, a slice header may inherit coding tool parameters from multiple HPSs of different types. This allows such coding tool parameters to be omitted from the slice header, improving bitstream coding efficiency by reducing redundant coding tool parameter signaling. As a specific example, the first HPS and the second HPS may include an ALF HPS, a LMCS HPS, a scaling list parameter HPS, or a combination thereof.

To reduce the complexity of coding methods associated with HPSs, HPSs may be restricted from referencing coding tool parameters stored in other HPSs. Accordingly, the HPSs encoded in step 805, including the first HPS and the second HPS, are restricted from referencing coding tool parameters from other HPSs among the HPSs. HPSs may also be encoded to support temporal scaling by including a temporal ID in each HPS. In one example, the first HPS is included in the access unit associated with the temporal ID. Additionally, the first HPS includes the same temporal ID associated with the access unit that includes the first HPS. In other examples, the first slice is partitioned from a first picture, and the first picture is associated with a temporal ID. In this example, the first HPS includes a temporal ID associated with the picture. Further, to support temporal scaling, each of the plurality of HPSs and each of the slices is associated with one of a plurality of temporal IDs. Additionally, each slice with a first temporal ID is restricted from referencing any HPS with a second temporal ID that is larger (e.g., associated with a higher frame rate) than the first temporal ID. Ru. This means that slices associated with lower frame rates will have HPS associated with higher frame rates, such HPS will be ignored if lower frame rates are used according to the temporal scaling mechanism. , make sure you don't reference it.

At step 809, the bitstream is stored in memory. Upon request, the bitstream may then be sent to a decoder, eg, by a transmitter.

FIG. 9 is a flowchart of an example method 900 for decoding a video sequence from a bitstream, such as bitstream 500, by using HPS. 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. The results of method 900 may also be used in a decoder to support temporal scaling according to mechanism 600. Method 900 may be used in response to receiving a bitstream from an encoder, such as encoder 300, and thus method 900 may be used in response to method 800.

Method 900 may begin when a decoder begins to receive a bitstream of coded data representing a video sequence, eg, as a result of method 800. At step 910, a bitstream is received at a decoder. The bitstream has multiple HPS including a first HPS and a second HPS. The first HPS is a first type of HPS and includes a first type of coding tool parameters. The second HPS is a second type of HPS and includes a second type of coding tool parameters. The bitstream also includes a slice header and slices associated with the slice header.

At step 903, the decoder determines that the slice header includes a first reference to a first HPS and a second reference to a second HPS. Thus, a slice header may inherit coding tool parameters from multiple HPSs of different types. This allows such coding tool parameters to be omitted from the slice header, improving bitstream coding efficiency by reducing redundant coding tool parameter signaling. As a specific example, the first HPS and the second HPS may include an ALF HPS, a LMCS HPS, a scaling list parameter HPS, or a combination thereof.

At step 905, the decoder decodes the slice using the first type of coding tool parameter and the second type of coding tool parameter based on the determination that the slice header includes the first reference and the second reference. I can do it. To reduce the complexity of coding methods associated with HPSs, HPSs may be restricted from referencing coding tool parameters stored in other HPSs. Accordingly, the HPSs received in the bitstream at step 901, including the first HPS and the second HPS, are restricted from referencing coding tool parameters from other HPSs among the HPSs. HPSs may also be coded to support temporal scaling by including a temporal ID in each HPS. In one example, the first HPS is included in the access unit associated with the temporal ID. Additionally, the first HPS includes the same temporal ID associated with the access unit that includes the first HPS. In other examples, the first slice is partitioned from a first picture, and the first picture is associated with a temporal ID. In this example, the first HPS includes a temporal ID associated with the picture. Further, to support temporal scaling, each of the plurality of HPSs and each of the slices is associated with one of a plurality of temporal IDs. Additionally, each slice with a first temporal ID is restricted from referencing any HPS with a second temporal ID that is larger (e.g., associated with a higher frame rate) than the first temporal ID. Ru. This means that slices associated with lower frame rates will have HPS associated with higher frame rates, such HPS will be ignored if lower frame rates are used according to the temporal scaling mechanism. , make sure you don't reference it.

At step 907, the decoder may forward the slices for display as part of the decoded video sequence.

FIG. 10 is a schematic diagram of an example system 1000 for coding a video sequence of images in a bitstream, such as bitstream 500, by using HPS. System 1000 may be implemented by encoders and decoders, such as codec system 200, encoder 300, decoder 400, and/or video coding device 700. Additionally, system 1000 may be used in implementing methods 100, 800, and/or 900. Additionally, system 1000 may be used to support temporal scaling as described in connection with mechanism 600.

System 1000 includes a video encoder 1002. Video encoder 1002 has a partitioning module 1001 that partitions pictures into slices. The video encoder 1002 further comprises an encoding module 1003 for encoding a plurality of slices into the bitstream, wherein the slices are encoded by at least a first type of coding tool based on the first type of coding tool parameters and a second type of coding tool based on the first type of coding tool parameters. and a second type of coding tool based on the type of coding tool parameters. The encoding module 1003 is further for encoding a first HPS and a second HPS into the bitstream, where the first HPS includes a first type of coding tool parameters and the second HPS includes a second type of coding tool parameters. The encoding module 1003 is further for encoding into the bitstream a first slice header that describes the encoding of a first slice of the plurality of slices, where the first slice header is a first slice header for a first HPS. 1 reference and a second reference to a second HPS. Video encoder 1002 further includes a storage module 1005 that stores the bitstream for communication to the decoder. The video encoder 1002 includes a transmitting module 1007 that transmits a bitstream including a first HPS and a second HPS to support decoding the slice at a decoder based on a first type of coding tool and a second type of coding tool. Furthermore, it has Video encoder 1002 may be further configured to perform any of the steps of method 800.

System 1000 also includes a video decoder 1010. The video decoder 1010 includes a receiving module 1011 that receives a bitstream having a first HPS including coding tool parameters of a first type, a second HPS including coding tool parameters of a second type, a slice header, and a slice associated with the slice header. has. Video decoder 1010 further comprises a determination module 1013 that determines that the slice header includes a first reference to a first HPS and a second reference to a second HPS. Video decoder 1010 includes a decoding module that decodes the slice using a first type of coding tool parameter and a second type of coding tool parameter based on determining that the slice header includes a first reference and a second reference. 1015. Video decoder 1010 further includes a transfer module 1017 for transferring slices for display as part of a decoded video sequence. Video decoder 1010 may be further configured to perform any of the steps of method 900.

The first component is coupled directly to the second component in the absence of intervening components, except for lines, traces, or other media between the first and second components. A first component is indirectly coupled to a second component when there is another intervening component other than a line, trace, or other medium between the first component and the second component. The term "coupled" and variations thereof include both directly coupled and indirectly coupled. The use of the term "about", unless stated otherwise, means a range that includes ±10% of the number that follows.

It should be understood that the steps of the example methods described herein do not necessarily have to be performed in the order presented, and the order of the steps of such methods is for illustrative purposes only. It should be understood that it is not too much. Similarly, such methods may include additional steps, and certain steps may be deleted or combined in methods according to various embodiments of this disclosure.

Although several embodiments are provided in this disclosure, the disclosed systems and methods may be embodied in numerous other specific forms without departing from the spirit or scope of this disclosure. can be understood. This example is to be regarded as illustrative rather than limiting, and there is no intent to be limited to the details provided herein. For example, various elements or components may be combined or integrated with other systems, or certain features may be omitted or not implemented.

Moreover, the techniques, systems, subsystems, and methods described and illustrated in various embodiments as separate or separate may be combined with other systems, components, techniques, or methods without departing from the scope of this disclosure. May be combined or integrated. Other examples of changes, substitutions, and substitutions will be ascertained by those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

Claims (22)

A method implemented in a decoder, the method comprising:
a first parameter set comprising a first type of coding tool parameters, a second parameter set comprising a second type of coding tool parameters, a slice header, and a slice associated with the slice header; receiving a bitstream having data;
determining, by a processor of the decoder, that the slice header includes a first reference to the first parameter set and a second reference to the second parameter set;
the data representing the slice, the first type of coding tool parameters and the second type of coding tool based on the determination by the processor that the slice header includes the first reference and the second reference; decoding the slice using parameters;
The bitstream has a plurality of parameter sets including the first parameter set and the second parameter set, and the slice having a first temporal ID has a second temporal ID larger than the first temporal ID. A method that is restricted from referencing any parameter set that has an ID. The method further comprises transmitting, by the processor, the slice for display as part of a decoded video sequence.
The method according to claim 1. The first parameter set includes an adaptive loop filter (ALF) parameter set, a luma mapping with chroma scaling (LMCS) parameter set, a scaling list parameter parameter set, or a combination thereof.
The method according to claim 1 or 2. The second parameter set includes an adaptive loop filter (ALF) parameter set, a luma mapping with chroma scaling (LMCS) parameter set, a scaling list parameter parameter set, or a combination thereof.
A method according to any one of claims 1 to 3. The bitstream has a plurality of parameter sets including the first parameter set and the second parameter set, and each of the plurality of parameter sets includes a coding tool from another parameter set within the plurality of parameter sets. be restricted from viewing parameters,
A method according to any one of claims 1 to 4. the first parameter set is included in an access unit associated with a temporal identifier (ID), the first parameter set includes the temporal ID associated with the access unit including the first parameter set;
A method according to any one of claims 1 to 5. The slice is a portion of a picture, the picture is associated with a temporal identifier (ID), and the first parameter set includes the temporal ID associated with the picture.
A method according to any one of claims 1 to 6. A method implemented in an encoder, the method comprising:
partitioning a plurality of pictures into a plurality of slices by a processor of the encoder;
encoding, by the processor, the plurality of slices into a bitstream, the plurality of slices comprising at least a first type of coding tool based on a first type of coding tool parameter and a second type of coding tool parameter. encoded by a second type of coding tool based on
encoding, by the processor, a first parameter set and a second parameter set into the bitstream, the first parameter set including the first type of coding tool parameters, and the second parameter set comprising: comprising the second type of coding tool parameters;
encoding, by the processor, into the bitstream a slice header describing an encoding of a first slice of the plurality of slices, the slice header including a first reference to the first parameter set and a first reference to the first parameter set; 2, comprising a second reference to the set of parameters; and
The bitstream has a plurality of parameter sets including the first parameter set and the second parameter set, and the slice having a first temporal ID has a second temporal ID larger than the first temporal ID. A method that is restricted from referencing any parameter set that has an ID. The method further comprises storing the bitstream for communication to a decoder by a memory coupled to the processor.
The method according to claim 8. The first parameter set includes an adaptive loop filter (ALF) parameter set, a luma mapping with chroma scaling (LMCS) parameter set, a scaling list parameter parameter set, or a combination thereof.
The method according to claim 8 or 9. The second parameter set includes an adaptive loop filter (ALF) parameter set, a luma mapping with chroma scaling (LMCS) parameter set, a scaling list parameter parameter set, or a combination thereof.
A method according to any one of claims 8 to 10. encoding a plurality of parameter sets into the bitstream by the processor;
The plurality of parameter sets include the first parameter set and the second parameter set, and each of the plurality of parameter sets references coding tool parameters from other parameter sets within the plurality of parameter sets. be restricted,
A method according to any one of claims 8 to 11. the first parameter set is included in an access unit associated with a temporal identifier (ID), the first parameter set includes the temporal ID associated with the access unit including the first parameter set;
13. A method according to any one of claims 8 to 12. The first slice is partitioned from a first picture, the first picture is associated with a temporal identifier (ID), and the first parameter set includes the temporal ID associated with the picture.
14. A method according to any one of claims 8 to 13. a processor;
a receiver coupled to the processor;
a memory coupled to the processor;
a transmitter coupled to the processor;
The processor, receiver, memory and transmitter are configured to perform a method according to any one of claims 1 to 14,
video coding device. 15. A computer program product which, when executed by a processor, causes the processor to perform the method according to any one of claims 1 to 14. A bitstream having a first parameter set including a first type of coding tool parameters, a second parameter set including a second type of coding tool parameters, a slice header, and data representing a slice associated with the slice header. a receiving unit configured to receive;
a determining unit configured to determine that the slice header includes a first reference to the first parameter set and a second reference to the second parameter set;
based on the determination that the slice header includes the first reference and the second reference, using the data representing the slice, the first type of coding tool parameter and the second type of coding tool parameter. a decoding unit configured to decode the slice;
The bitstream has a plurality of parameter sets including the first parameter set and the second parameter set, and the slice having a first temporal ID has a second temporal ID larger than the first temporal ID. A decoder restricted to refer to any parameter set with an ID. The decoder further comprises a transfer unit configured to transfer the slices for display as part of a decoded video sequence.
A decoder according to claim 17. a partitioning unit configured to partition a plurality of pictures into a plurality of slices;
encoding the plurality of slices into a bitstream, the plurality of slices being encoded with at least a first type of coding tool based on a first type of coding tool parameter and a second type of coding based on a second type of coding tool parameter. encoded by the tool,
encoding a first parameter set and a second parameter set into the bitstream, the first parameter set including the first type of coding tool parameters, and the second parameter set including the second type of coding tool parameters; contains parameters,
Encoding a slice header in the bitstream that describes an encoding of a first slice of the plurality of slices, the slice header having a first reference to the first parameter set and a second reference to the second parameter set. an encoding unit configured to include and
The bitstream has a plurality of parameter sets including the first parameter set and the second parameter set, and the slice having a first temporal ID has a second temporal ID larger than the first temporal ID. An encoder that is restricted from referencing any parameter set that has an ID. The encoder further comprises a storage unit configured to store the bitstream for communication to a decoder.
Encoder according to claim 19. Video coding device comprising a processing circuit for performing the method according to any one of claims 1 to 14. 17. A non-transitory computer readable medium storing a computer program according to claim 16.

Images