Method and apparatus for decoding video data from bitstream, method and apparatus for encoding video data in bitstream, computer readable storage medium and computer program product

Abstract

The invention provides a method and an apparatus for decoding video data from a bitstream, a method and an apparatus for encoding video data in a bitstream, a computer readable storage medium and a computer program product. A method of decoding video data from a bitstream is also provided, the bitstream comprising video data corresponding to one or more than one slice. The bitstream includes a picture header and a slice header, the picture header including syntactic elements to be used in decoding one or more slices, the slice header including syntactic elements to be used in decoding the slices, the decoding including parsing the syntactic elements. The method comprises: if parsing one or more syntactic elements indicating that the picture contains only one slice, omitting parsing of one or more syntactic elements for the slice related to use or availability of a decoding tool or parameter for the slice; and decoding the bitstream using the syntactic elements.

Description

[0001] (This application is a divisional application of application No. 2021800229714, filed on March 17, 2021, entitled “Method and Apparatus for Encoding and Decoding Video Data, Computer-Readable Storage Medium, and Computer Program Product.”) Technical Field

[0002] The present invention relates to video encoding and decoding, and in particular to high-level syntax for use in bitstreams. Background Art

[0003] Recently, the Joint Video Experts Team (JVET) (a collaboration between MPEG and ITU-T Study Group 16, VCEG) began work on a new video coding standard called Versatile Video Coding (VVC). The goal of VVC is to provide significant improvements in compression performance over the existing HEVC standard (i.e., typically twice as fast as before) and to be completed in 2020. Key target applications and services include, but are not limited to, 360-degree and high dynamic range (HDR) video. In total, JVET evaluated feedback from 32 organizations using formal subjective tests conducted by independent test labs. Some proposals showed compression efficiency improvements of 40% or more, typically when compared to using HEVC. Particular improvements were shown on ultra-high-definition (UHD) video test material. Therefore, we can expect compression efficiency improvements far exceeding the targeted 50% for the final standard.

[0004] The JVET Exploration Model (JEM) uses all HEVC tools and has introduced several new tools. These changes require changes to the structure of the bitstream, especially the high-level syntax, which may have an impact on the overall bitrate of the bitstream. Summary of the Invention

[0005] The present invention relates to improvements to high-level syntax structures, which enable complexity reduction and / or signaling without any significant degradation in coding performance.

[0006] According to a first aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, and the slice header including syntax elements to be used when decoding the slices, the decoding comprising: parsing the syntax elements and, if one or more syntax elements indicating that a picture contains only one slice are parsed, omitting parsing one or more syntax elements for the slice related to use or availability of decoding tools or parameters for the slice; and decoding the bitstream using the syntax elements. According to another aspect of the present invention, a method for decoding video data from a bitstream including video data corresponding to one or more slices is provided, wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, the slice header including syntax elements to be used when decoding the slices, the bitstream being constrained such that, if the bitstream includes a syntax element having a value indicating that the picture contains only one slice, the bitstream includes a syntax element indicating omission of parsing of one or more syntax elements for the slice related to the use or availability of decoding tools or parameters for the slice, the method comprising decoding the bitstream using the syntax elements. Thus, improved coding efficiency is achieved because certain syntax elements are not sent when not needed. In particular, when the current picture contains only one slice, there is no additional flexibility to signal certain parameters in the picture header and then in the slice header.

[0007] Syntax elements related to the use or availability of decoding tools or parameters may be signaled in a picture parameter set (PPS) or a sequence parameter set (SPS).

[0008] The one or more syntax elements indicating that the current picture contains only one slice may include a picture header in slice header syntax element, which indicates that the picture header is signaled in the slice header. The advantage is that coding efficiency is improved when the picture is in the slice header. In practice, for low-latency and low-bitrate applications, signaling the picture header in the slice header is efficient. In this case, the cost of overwriting multiple pictures is greater than the cost of setting up a set of reference picture lists in the SPS. In practice, for these use cases, the number of reference frames is typically limited to one or two reference frames per list.

[0009] The one or more syntax elements indicating that the current picture includes only one slice include a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the slice, and wherein the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture indicates that the current picture includes only one slice.

[0010] The syntax elements related to the use or availability of decoding tools or parameters may include a flag for indicating the use of the decoding mode or parameter at the slice level, and also include prediction of the overriding of the decoding mode or parameter at the slice level from the value of the flag at the picture header level. For example, the decoding tool or parameter may be related to the signaling of a reference frame, and the syntax element related to the use or availability of the decoding tool or parameter is a flag for overriding the use of a reference picture list. If a slice uses a reference picture list (or multiple reference picture lists) sent in the SPS, there is an advantage in overriding one or more lists to limit the number of reference pictures. However, surprisingly, in terms of coding efficiency trade-offs for practical applications, it is preferable to avoid such overriding to save bits related to its signaling. In addition, slice header parsing is simplified for some implementations.

[0011] The decoding tool or parameter may be related to LCMS, and the syntax element includes an activation flag of the LCMS.

[0012] The decoding tool or parameter may be related to a zoom list, and the syntax element includes an activation flag for the zoom list.

[0013] According to a second aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, and the slice header including syntax elements to be used when decoding the slices, the decoding comprising: parsing the syntax elements and, upon parsing one or more syntax elements indicating that a picture contains only one slice, setting values of one or more syntax elements for the slice related to overwriting of reference picture list decoding tools or parameters to indicate that a reference picture list is not to be overwritten for the slice; and decoding the bitstream using the syntax elements. This simplifies slice header parsing in terms of decoding implementation.

[0014] The one or more syntax elements indicating that the current picture contains only one slice may include a picture header in slice header syntax element indicating that the picture header is signaled in a slice header.

[0015] Each slice may include one or more blocks, and the one or more syntax elements indicating that the current picture includes only one slice may include a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the slice, wherein the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture, indicating that the current picture includes only one slice.

[0016] According to a third aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, and the slice header including syntax elements to be used when decoding the slices, the decoding comprising: parsing the syntax elements and, if the picture header indicates that the syntax elements in the slice header indicate that the picture header is signaled in the slice header, setting values of one or more syntax elements for the slice related to overwriting of reference picture list decoding tools or parameters to indicate that a reference picture list is not overwritten for the slice; and decoding the bitstream using the syntax elements.

[0017] According to a fourth aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, and the slice header including syntax elements to be used when decoding the slice, the decoding comprising: parsing the syntax elements, and if a syntax element indicating the number of blocks in a current picture and a syntax element indicating the number of blocks in a slice are parsed, and the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture, setting values of one or more syntax elements for the slice related to overwriting of reference picture list decoding tools or parameters to indicate that a reference picture list is not to be overwritten for the slice; and decoding the bitstream using the syntax elements.

[0018] In at least the second to fourth aspects, the syntax element related to overwriting of the reference picture list decoding tool may include a flag, and setting the flag to be disabled indicates that the reference picture list is not overwritten.

[0019] According to a fifth aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data, the video data including a picture sequence having one or more slices, wherein the bitstream includes one or more syntax elements, and the decoding includes: parsing the one or more syntax elements indicating whether a reference picture list of a picture to be decoded refers to a sequence parameter set (SPS) reference picture list; if the one or more syntax elements indicate that the reference picture list of the picture to be decoded does not refer to the sequence parameter set (SPS) reference picture list, omitting parsing the one or more syntax elements related to overwriting the reference picture list of the slice of the picture in the slice header; and decoding the bitstream using the syntax elements. Therefore, parsing can be simplified and unnecessary syntax elements can be avoided.

[0020] Omitting the parsing of one or more syntax elements related to overwriting the reference picture list can also require that a picture has only one slice. When a picture contains one slice, the encoder should generally not overwrite the reference picture list explicitly signaled in the slice header or picture header. However, if a reference picture list signaled in the SPS is used, it can be advantageous to overwrite it to limit the number of reference pictures. However, surprisingly, in terms of coding efficiency tradeoffs for practical applications, it is preferable to avoid such overwriting to save bits associated with its signaling. In addition, slice header parsing is simplified for some implementations.

[0021] The one or more syntax elements may include a "picture header in slice header" syntax element, the "picture header in slice header" syntax element indicating whether a picture header is signaled in a slice header, and the omission further requiring the picture header to be signaled in a slice header. An advantage is that coding efficiency is improved when the picture is in a slice header. In practice, signaling a picture header in a slice header is efficient for low-latency and low-bitrate applications, where the cost of overwriting flags for multiple pictures is greater than the cost of setting up several reference picture lists in an SPS.

[0022] Each slice may include one or more blocks, and the one or more syntax elements are a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the slice, and the omission requires that the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture. Therefore, this provides an efficient way to determine whether a picture has only one slice.

[0023] If the reference picture list is signaled in the slice header, parsing of one or more syntax elements related to overwriting the reference picture list is omitted. The advantage is that coding efficiency is improved because if the reference picture list is explicitly sent in the slice header, the reference picture list does not need to be updated.

[0024] According to a sixth aspect of the present invention, a method for decoding video data from a bitstream is provided, wherein the bitstream includes video data, the video data including a sequence of pictures having one or more slices, wherein the bitstream includes one or more syntax elements, and the decoding includes: parsing a high-level syntax element at a level higher than the slice in the bitstream, the high-level syntax element indicating whether to permit the use or availability of decoding tools or parameters at the slice level; if the high-level syntax element indicates that the use or availability of decoding tools or parameters at the slice level is not permitted, omitting parsing or inferring the one or more syntax elements indicating the use or availability of decoding tools or parameters for the slice for a slice header; and decoding the bitstream using the syntax elements. According to another aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, wherein the bitstream comprises one or more syntax elements, the bitstream being constrained such that, if the bitstream comprises a high-level syntax element at a level higher than a slice in the bitstream (the high-level syntax element indicating whether to permit indication of use or availability of decoding tools or parameters at the slice level), if the high-level syntax element indicates that indication of use or availability of the decoding tools or parameters at the slice level is not permitted, the bitstream further comprises a syntax element indicating that parsing or inference of one or more syntax elements indicating use or availability of decoding tools or parameters for the slice is to be omitted for the slice header, the method comprising decoding the bitstream using the syntax element. Thus, a more flexible implementation can be provided compared to the previous aspects, but with similar coding efficiency improvements.

[0025] High-level syntax elements may be signaled in one or more of a sequence parameter set (SPS), a picture parameter set (PPS), a video parameter set (VPS), and a picture header (PH).

[0026] If the number of reference picture lists in a sequence parameter set (SPS) is zero, the high-level syntax elements may not be decoded.

[0027] If a picture has only one slice, the high-level syntax elements may not be decoded.

[0028] Decoding tools or parameters may be related to reference picture lists. If the reference picture lists are signaled in the slice header, high-level syntax elements may not be decoded.

[0029] The syntax element indicating the use or availability of a decoding tool or parameter may include an activation flag. The decoding tool or parameter may be a luma map with chroma scaling (LMCS) tool. The decoding tool or parameter may be a scaling list. The activation flag in the slice header may depend on the (corresponding) activation flag on the picture header. For example, if a high-level syntax element indicates permission to indicate the use or availability of a decoding tool or parameter at the slice level, the value of the slice activation flag may be inferred from the value of the activation flag of the decoding tool or parameter signaled in the picture header.

[0030] According to a seventh aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, and wherein the bitstream comprises a picture header and a slice header, the picture header comprising syntax elements to be used when decoding the one or more slices, the slice header comprising syntax elements to be used when decoding the slices, the decoding comprising: parsing the syntax elements and, if a picture contains only one slice, restricting the values of the one or more syntax elements indicating use or availability of one or more decoding tools or parameters for the slices in the picture to the same values as corresponding syntax elements indicating use or availability of decoding tools or parameters signaled in a picture header of the picture containing the slices; and decoding the bitstream using the syntax elements. According to another aspect of the present invention, a method is provided for decoding video data from a bitstream, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, and the bitstream comprising a picture header and a slice header, the picture header comprising syntax elements to be used when decoding the one or more slices, the slice header comprising syntax elements to be used when decoding the slices, the bitstream being constrained such that, if the bitstream includes a syntax element having a value indicating that a picture contains only one slice, the value of the one or more syntax elements indicating use or availability of one or more decoding tools or parameters for the slices in the picture is constrained to be the same as the value of the corresponding syntax element indicating use or availability of the decoding tools or parameters signaled in a picture header of a picture containing the slices, the method comprising decoding the bitstream using the syntax elements. An advantage is improved coding efficiency because syntax elements are not sent when they are not needed. In fact, there is no additional flexibility to signal in the picture header and then in the slice header when the current picture contains only one slice.

[0031] The method may further include parsing a slice picture header in slice header syntax element, wherein if the picture header in slice header syntax element indicates that the picture header is signaled in the slice header, then the picture contains only one slice. An advantage is that coding efficiency is improved when the picture is in the slice header. In practice, the picture header in the slice header is efficient for low-latency and low-bitrate applications, in which case signaling at the slice level has a significant cost in terms of global bit rate.

[0032] Each slice may include one or more blocks, and the method may further include parsing a syntax element indicating a number of blocks in the current picture and a syntax element indicating a number of blocks in the slice, wherein the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture, indicating that the current picture contains only one slice.

[0033] According to an eighth aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, wherein the bitstream comprises a picture header and a slice header, the picture header comprising syntax elements to be used when decoding the one or more slices, the slice header comprising syntax elements to be used when decoding the slices, the decoding comprising: parsing the syntax elements and, if the picture header is signaled in the slice header, restricting the values of the one or more syntax elements indicating use or availability of one or more decoding tools or parameters for the slices in the picture to the same values as corresponding syntax elements of the use or availability of the decoding tools or parameters signaled in the picture header of the picture containing the slices. According to another aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, wherein the bitstream comprises a picture header and a slice header, the picture header comprising syntax elements to be used when decoding the one or more slices, the slice header comprising syntax elements to be used when decoding the slices, the bitstream being constrained such that, if the bitstream includes a syntax element having a value indicating that the picture header is signaled in the slice header, the value of the one or more syntax elements indicating use or availability of one or more decoding tools or parameters for the slices in the picture is restricted to the same value as a corresponding syntax element indicating use or availability of the decoding tools or parameters signaled in a picture header of a picture containing the slices, the method comprising decoding the bitstream using the syntax elements.

[0034] According to a ninth aspect of the present invention, there is provided a method for decoding video data from a bitstream, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, wherein each slice may comprise one or more tiles, and wherein the bitstream comprises a picture header and a slice header, the picture header comprising syntax elements to be used when decoding the one or more slices, the slice header comprising syntax elements to be used when decoding the slices, the decoding comprising: parsing the syntax elements and, if the number of tiles in the picture being decoded is greater than one and the number of tiles in the slice is equal to the number of tiles in the picture, restricting the value of the one or more syntax elements indicating use or availability of one or more decoding tools or parameters for the slices to the same value as a corresponding syntax element indicating use or availability of the decoding tools or parameters signaled in a picture header of a picture containing the slices; and decoding the bitstream using the syntax elements.

[0035] In at least the seventh to ninth aspects, one or more decoding tools or parameters may include a Luma Mapping with Chroma Scaling (LMCS) tool.

[0036] In at least the seventh to ninth aspects, one or more decoding tools or parameters may include a scaling list.

[0037] According to a tenth aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, and the slice header including syntax elements to be used when decoding the slices, and the encoding includes: determining the syntax elements; if one or more syntax elements indicating that a picture contains only one slice are determined, omitting encoding the one or more syntax elements for the slice related to use or availability of decoding tools or parameters for the slice; and encoding the video data using the syntax elements.

[0038] Syntax elements related to the use or availability of decoding tools or parameters may be signaled in a picture parameter set (PPS).

[0039] The one or more syntax elements indicating that the current picture contains only one slice may include a picture header in slice header syntax element indicating that the picture header is signaled in a slice header.

[0040] The one or more syntax elements indicating that the current picture includes only one slice may include a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the slice, and wherein the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture indicates that the current picture includes only one slice.

[0041] Syntax elements related to the use or availability of decoding tools or parameters may include a flag for indicating the use of the decoding mode or parameter at the slice level, and also include predicting the decoding mode or parameter at the slice level to be overridden from the value of the flag at the picture header level.

[0042] The decoding tool or parameter is a signaling of a reference frame, and the syntax elements related to the use or availability of the decoding tool or parameter may include a flag for overriding the use of a reference picture list.

[0043] The decoding tool or parameter may include luma mapping with chroma scaling (LMCS), and the syntax element is an activation flag for luma mapping with chroma scaling (LMCS).

[0044] The decoding tools or parameters may include a scaling list, and the syntax element may include an activation flag for the scaling list.

[0045] According to an eleventh aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, and the slice header including syntax elements to be used when decoding the slices, the encoding comprising: determining the syntax elements, and if one or more syntax elements indicating that a picture contains only one slice are determined, setting the values of the one or more syntax elements for the slice related to overwriting of reference picture list decoding tools or parameters to indicate that a reference picture list is not to be overwritten for the slice; and encoding the video data using the syntax elements.

[0046] The one or more syntax elements indicating that the current picture contains only one slice may include a picture header in slice header syntax element indicating that the picture header is signaled in a slice header.

[0047] Each slice may include one or more blocks, and the one or more syntax elements indicating that the current picture includes only one slice may include a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the slice, wherein the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture, indicating that the current picture includes only one slice.

[0048] According to a twelfth aspect of the present invention, a method of encoding video data into a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, the slice header including syntax elements to be used when decoding the slice, the encoding comprising: determining the syntax elements, and if the picture header is in the slice header and the syntax elements indicate that the picture header is signaled in the slice header, setting the values of one or more syntax elements for the slice related to overwriting of reference picture list decoding tools or parameters to indicate that a reference picture list is not to be overwritten for the slice; and encoding the video data using the syntax elements.

[0049] According to a thirteenth aspect of the present invention, a method for encoding video data into an encoded bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein each slice may include one or more blocks, and wherein the bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding the one or more slices, the slice header including syntax elements to be used when decoding the slices, the encoding comprising: determining syntax elements, and if a syntax element indicating the number of blocks in a current picture and a syntax element indicating the number of blocks in a slice are determined, and the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture, setting values of one or more syntax elements for the slice related to overwriting of reference picture list decoding tools or parameters to indicate that a reference picture list is not to be overwritten for the slice; and encoding the video data using the syntax elements.

[0050] In at least the eleventh to thirteenth aspects, the syntax element related to overwriting of the reference picture list decoding tool may include a flag, and setting the flag to be disabled indicates that the reference picture list is not overwritten.

[0051] According to a fourteenth aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, wherein the bitstream comprises one or more syntax elements, and the encoding comprises: determining one or more syntax elements indicating whether a reference picture list of a picture to be decoded refers to a sequence parameter set (SPS) reference picture list; if the one or more syntax elements indicate that the reference picture list of the picture to be decoded does not refer to the sequence parameter set (SPS) reference picture list, omitting encoding the one or more syntax elements related to overwriting of a reference picture list of a slice of the picture in a slice header; and encoding the video data using the syntax elements.

[0052] Omitting parsing of one or more syntax elements related to overwriting of a reference picture list may further require that a picture has only one slice, the one or more syntax elements including a picture header in slice header syntax element indicating whether a picture header is signaled in a slice header, the omission requiring the picture header to be signaled in a slice header, each slice may include one or more blocks, and the one or more syntax elements indicating that the current picture has only one slice include a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in a slice, wherein the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture.

[0053] If the reference picture list is signaled in the slice header, encoding of one or more syntax elements related to overwriting of the reference picture list may be omitted.

[0054] According to a fifteenth aspect of the present invention, a method of encoding video data into a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, and the bitstream comprising one or more syntax elements, the encoding comprising: encoding a high-level syntax element at a level higher than a slice in the bitstream, the high-level syntax element indicating whether to permit use or availability of decoding tools or parameters at the slice level; if the high-level syntax element indicates that the use or availability of decoding tools or parameters at the slice level is not permitted, omitting encoding, for a slice header, the one or more syntax elements indicating use or availability of decoding tools or parameters for the slice; and encoding the video data using the syntax elements.

[0055] High-level syntax elements may be signaled in one or more of a sequence parameter set (SPS), a picture parameter set (PPS), a video parameter set (VPS), and a picture header (PH).

[0056] Optionally, if the number of reference picture lists in the sequence parameter set (SPS) is zero, the high-level syntax element is not encoded.

[0057] Alternatively, if the picture has only one slice, the high-level syntax elements are not encoded.

[0058] Decoding tools or parameters may be related to the reference picture list.Alternatively, if the reference picture list is signaled in the slice header, the high-level syntax elements are not encoded.

[0059] Syntax elements indicating the use or availability of decoding tools or parameters may include an activation flag. The decoding tools or parameters may include a Luma Map with Chroma Scaling (LMCS) tool. The decoding tools or parameters may include a scaling list.

[0060] The activation flag in the slice header may depend on the (corresponding) activation flag in the picture header. For example, if the high-level syntax element indicates permission to indicate the use or availability of a decoding tool or parameter at the slice level, the value of the activation flag of the slice may be inferred from the value of the activation flag of the decoding tool or parameter signaled in the picture header.

[0061] According to a sixteenth aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, wherein the bitstream comprises a picture header and a slice header, the picture header comprising syntax elements to be used when decoding the one or more slices, the slice header comprising syntax elements to be used when decoding the slices, the encoding comprising: parsing the syntax elements and, if a picture contains only one slice, restricting the values of the one or more syntax elements indicating use or availability of one or more decoding tools or parameters for the slices in the picture to the same values as corresponding syntax elements indicating use or availability of decoding tools or parameters signaled in a picture header of the picture containing the slices; and encoding the video data using the syntax elements.

[0062] Optionally, the method may include encoding a picture header in slice header syntax element, wherein if the picture header in slice header syntax element indicates that the picture header is signaled in the slice header, the picture contains only one slice.

[0063] Optionally, the method may include encoding a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the slice, wherein the number of blocks in the picture is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture indicating that the current picture contains only one block.

[0064] According to a seventeenth aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, wherein the bitstream comprises a picture header and a slice header, the picture header comprising syntax elements to be used when decoding the one or more slices, the slice header comprising syntax elements to be used when decoding the slices, the encoding comprising: determining syntax elements and, if the picture header is signaled in the slice header, restricting values of the one or more syntax elements indicating use or availability of one or more decoding tools or parameters for the slices in the picture to the same values as corresponding syntax elements indicating use or availability of the decoding tools or parameters signaled in the picture header of the picture containing the slices; and encoding the video data using the syntax elements.

[0065] According to an eighteenth aspect of the present invention, a method of encoding video data into a bitstream is provided, the bitstream comprising video data, the video data comprising a sequence of pictures having one or more slices, wherein each slice may comprise one or more blocks, and wherein the bitstream comprises a picture header and a slice header, the picture header comprising syntax elements to be used when decoding the one or more slices, the slice header comprising syntax elements to be used when decoding the slices, the decoding comprising: determining the syntax elements and, if the number of blocks in the picture being encoded is greater than one and the number of blocks in the slice is equal to the number of blocks in the picture, restricting the value of the one or more syntax elements indicating use or availability of one or more decoding tools or parameters for the slices to the same value as a corresponding syntax element indicating use or availability of the decoding tools or parameters signaled in a picture header of a picture containing the slices; and encoding the video data using the syntax elements.

[0066] The one or more decoding tools or parameters may include a Luma Mapping with Chroma Scaling (LMCS) tool.

[0067] One or more decoding tools or parameters may include a scaling list.

[0068] According to a nineteenth aspect of the present invention, there is provided an apparatus for decoding video data from a bit stream, the apparatus being configured to perform the method according to any one of the first to ninth aspects.

[0069] According to a twentieth aspect of the present invention, there is provided an apparatus for encoding video data into a bit stream, the apparatus being configured to perform the method of any one of the tenth to eighteenth aspects.

[0070] According to a twenty-first aspect of the present invention, there is provided a computer program comprising executable instructions, which, when executed, cause the method of any one of the above aspects to be performed.

[0071] The program may be provided separately or may be on, carried by, or in a carrier medium. The carrier medium may be non-transitory, such as a storage medium, in particular a computer-readable storage medium. The carrier medium may also be transient, such as a signal or other transmission medium. The signal may be transmitted via any suitable network, including the Internet. Other features of the invention are characterized by the independent and dependent claims.

[0072] Any features in one aspect of the invention may be applied to other aspects of the invention in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

[0073] Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any references herein to software and hardware features should be interpreted accordingly.

[0074] Any apparatus features as described herein may also be provided as method features, and vice versa.As used herein, means-plus-function features may alternatively be expressed in terms of their corresponding structure (such as a suitably programmed processor and associated memory, etc.).

[0075] It will also be understood that specific combinations of the various features described and defined in any aspect of the present invention may be independently implemented, provided and / or used. BRIEF DESCRIPTION OF THE DRAWINGS

[0076] Reference will now be made by way of example to the accompanying drawings, in which:

[0077] Figure 1 is a diagram for explaining the coding structure used in HEVC and VVC;

[0078] Figure 2 is a block diagram schematically illustrating a data communication system in which one or more embodiments of the present invention may be implemented;

[0079] Figure 3 is a block diagram illustrating components of a processing device that may implement one or more embodiments of the present invention;

[0080] Figure 4 is a flow chart illustrating the steps of an encoding method according to an embodiment of the present invention;

[0081] Figure 5 is a flowchart illustrating the steps of a decoding method according to an embodiment of the present invention;

[0082] Figure 6 shows the structure of a bitstream in an exemplary coding system VVC;

[0083] Figure 7 Another structure of a bit stream in an exemplary coding system VVC is shown;

[0084] Figure 8 Shows Luma Modelling Chroma Scaling (LMCS);

[0085] Figure 9 Shows the sub-tools of LMCS;

[0086] Figure 10 This is a diagram of the raster scan strip mode and rectangular strip mode of the current VVC draft standard;

[0087] Figure 11 A diagram showing a system including an encoder or decoder and a communication network according to an embodiment of the present invention;

[0088] Figure 12 is a schematic block diagram of a computing device for implementing one or more embodiments of the present invention;

[0089] Figure 13 is a diagram showing a network camera system; and

[0090] Figure 14 is a diagram showing a smartphone. DETAILED DESCRIPTION

[0091] Figure 1 The present invention relates to a coding structure used in the High Efficiency Video Coding (HEVC) video standard. A video sequence 1 consists of a series of digital images i. Each of these digital images is represented by one or more matrices. The matrix coefficients represent pixels.

[0092] The images 2 of the sequence may be partitioned into slices 3. In some cases, one slice may constitute the entire image. These slices are partitioned into non-overlapping Coding Tree Units (CTUs). The Coding Tree Unit (CTU) is the basic processing unit of the High Efficiency Video Coding (HEVC) video standard and conceptually corresponds in structure to the macroblock unit used in several previous video standards. A CTU is sometimes also called a Largest Coding Unit (LCU). A CTU has luminance and chrominance component parts, each of which is called a Coding Tree Block (CTB). These different color components are not Figure 1 Shown in.

[0093] A CTU is typically 64 pixels by 64 pixels in size. Each CTU can be iteratively partitioned into smaller, variable-sized coding units (CUs) using a quadtree decomposition.

[0094] The coding unit is the basic coding element and is composed of two subunits called prediction units (PUs) and transform units (TUs). The maximum size of a PU or TU is equal to the CU size. A prediction unit corresponds to a partition of a CU used for prediction of pixel values. Various different partitions of a CU into PUs are possible, as shown in Figure 6, including a partition into four square PUs and two different partitions into two rectangular PUs. A transform unit is the basic unit for spatial transformation using DCT. A CU can be partitioned into TUs based on a quadtree representation.

[0095] Each slice is embedded in a network abstraction layer (NAL) unit. In addition, the coding parameters of the video sequence are stored in a dedicated NAL unit called a parameter set. In HEVC and H.264 / AVC, two types of parameter set NAL units are used: first, the sequence parameter set (SPS) NAL unit, which collects all parameters that do not change during the entire video sequence. Typically, it handles the coding profile, the size of the video frame, and other parameters. Second, the picture parameter set (PPS) NAL unit, which includes parameters that can change from one image (or frame) of the sequence to other images (or frames). HEVC also includes a video parameter set (VPS) NAL unit, which contains parameters that describe the overall structure of the bitstream. VPS is a new type of parameter set defined in HEVC and applies to all layers of the bitstream. A layer can contain multiple temporal sublayers, and all version 1 bitstreams are limited to a single layer. HEVC has certain layered extensions for scalability and multi-view, and these extensions will allow multiple layers with a backward-compatible version 1 base layer.

[0096] In the current definition of Versatile Video Coding (VVC), there are three high-level possibilities for partitioning pictures: sub-pictures, slices, and tiles. Each has its own characteristics and usefulness. Partitioning into sub-pictures allows for spatial extraction and / or merging of regions of the video. Partitioning into slices is based on similar concepts to previous standards and corresponds to packetization for video transmission (even though it can be used for other applications). Partitioning into tiles is conceptually an encoder parallelization tool, as it splits the picture into independently coded regions of (almost) the same size. But this tool can also be used for other applications.

[0097] Since these three high-level possible ways of using picture partitioning together exist, there are several modes for its use. As defined in the current draft specification for VVC, two modes for defining slices are defined. For raster scan slice mode, a slice contains a complete sequence of tiles in a raster scan of the tiles of a picture. This mode in the current VVC specification is in Figure 10 As shown in (a), the picture contains 18 by 12 luma CTUs shown as partitioned into 12 stripes and 3 raster scan stripes.

[0098] For the second (rectangular strip mode), the strip contains several complete blocks from a common rectangular area of the picture. Figure 10 In this example, the picture has 18 by 12 luma TUs shown partitioned into 24 blocks and 9 rectangular strips.

[0099] Figure 2 The data communication system in which one or more embodiments of the present invention may be implemented is illustrated. The data communication system includes a transmitting device (in this case, a server 201) operable to transmit data packets of a data stream to a receiving device (in this case, a client terminal 202) via a data communication network 200. The data communication network 200 may be a wide area network (WAN) or a local area network (LAN). Such a network may be, for example, a wireless network (Wifi / 802.11a, b, or g), an Ethernet network, an Internet network, or a hybrid network consisting of several different networks. In a specific embodiment of the present invention, the data communication system may be a digital television broadcast system in which the server 201 transmits the same data content to multiple clients.

[0100] The data stream 204 provided by the server 201 may be composed of multimedia data representing video and audio data. In some embodiments of the present invention, the audio and video data streams may be captured by the server 201 using a microphone and a camera, respectively. In some embodiments, the data streams may be stored on the server 201 or received by the server 201 from other data providers, or generated at the server 201. The server 201 is provided with an encoder for encoding the video and audio streams, in particular for providing a compressed bit stream for transmission, which is a more compact representation of the data presented as input to the encoder.

[0101] In order to obtain a better ratio of quality of transmitted data to the amount of transmitted data, the video data may be compressed, for example, according to the HEVC format or the H.264 / AVC format.

[0102] The client 202 receives the transmitted bitstream and decodes the reconstructed bitstream to reproduce a video image on a display device and reproduce audio data using a speaker.

[0103] Despite Figure 2 A streaming scenario is considered in the examples of FIG, but it will be appreciated that in some embodiments of the invention, data communication between the encoder and decoder may be performed using, for example, a media storage device such as an optical disc.

[0104] In one or more embodiments of the present invention, a video image is transmitted along with data representing a compensating offset to be applied to reconstructed pixels of the image to provide filtered pixels in the final image.

[0105] Figure 3 A processing device 300 configured to implement at least one embodiment of the present invention is schematically illustrated. The processing device 300 may be a device such as a microcomputer, a workstation, or a lightweight portable device. The device 300 includes a communication bus 313 connected to:

[0106] - a central processing unit 311 denoted as CPU, such as a microprocessor;

[0107] - a read-only memory 306, denoted ROM, for storing the computer program implementing the invention;

[0108] a random access memory 312, represented as a RAM, for storing executable codes of the method according to an embodiment of the present invention, and registers suitable for recording variables and parameters required for implementing the method for encoding a digital image sequence and / or the method for decoding a bit stream according to an embodiment of the present invention; and

[0109] A communication interface 302 connected to a communication network 303, via which digital data to be processed are transmitted or received.

[0110] Optionally, the device 300 may further include the following components:

[0111] - a data storage component 304, such as a hard disk, for storing a computer program for implementing the method of one or more embodiments of the present invention and data used or generated during the implementation of one or more embodiments of the present invention;

[0112] a disk drive 305 for a disk 306, which is suitable for reading data from the disk 306 or writing data to said disk;

[0113] - A screen 309 for displaying data and / or serving as a graphical interface for interaction with the user by means of a keyboard 310 or any other pointing means.

[0114] Device 300 may be connected to various peripheral devices such as digital camera 320 or microphone 308 , each of which is connected to an input / output card (not shown) to provide multimedia data to device 300 .

[0115] The communication bus provides communication and interoperability between the various elements included in or connected to device 300. The representation of a bus is not limiting, and in particular, the central processing unit is operable to communicate instructions to any element of device 300, either directly or via other elements of device 300.

[0116] The disk 306 may be replaced by any information medium, such as a rewritable or non-rewritable compact disk (CD-ROM), a ZIP disk or a memory card, and in general by an information storage element that can be read by a microcomputer or a microprocessor, the disk 306 being integrated into the device or not, possibly removable and suitable for storing one or more programs whose execution enables the implementation of the method for encoding a digital image sequence and / or the method for decoding a bit stream according to the invention.

[0117] The executable code may be stored in a read-only memory 306, on a hard disk 304 or on a removable digital medium such as, for example, the disk 306 as previously described. According to a variant, the executable code of the program may be received via the interface 302 by means of the communication network 303 to be stored in one of the storage means of the device 300 (such as the hard disk 304) before being executed.

[0118] The central processing unit 311 is adapted to control and direct the execution of instructions or portions of software code for executing one or more programs according to the present invention, instructions stored in one of the aforementioned storage means. Upon power-up, one or more programs stored in non-volatile memory (e.g., on the hard disk 304 or in the read-only memory 306) are transferred to the random access memory 312 (which then contains the executable code of the one or more programs) and registers for storing variables and parameters necessary for the implementation of the present invention.

[0119] In this embodiment, the device is a programmable device that implements the invention using software. Alternatively, however, the invention may be implemented in hardware (for example in the form of an application specific integrated circuit or ASIC).

[0120] Figure 4 A block diagram illustrating an encoder according to at least one embodiment of the present invention. The encoder is represented by connected modules, each module being adapted to implement at least one corresponding step of at least one embodiment of a method for encoding an image of a sequence of images according to one or more embodiments of the present invention, e.g., in the form of programming instructions executed by a CPU 311 of an apparatus 300.

[0121] The encoder 400 receives digital images i0 to i n The original sequence 401 of is taken as input. Each digital image is represented by a set of samples (called pixels).

[0122] After implementing the encoding process, the encoder 400 outputs a bitstream 410. The bitstream 410 includes a plurality of coding units or slices, each slice including a slice header for transmitting encoded values of encoding parameters used for slice encoding, and a slice body including encoded video data.

[0123] Module 402 inputs digital images i0 to i n 401 is divided into pixel blocks. A block corresponds to an image portion and can have a variable size (e.g., 4×4, 8×8, 16×16, 32×32, 64×64, 128×128 pixels, and several rectangular block sizes are also considered). A coding mode is selected for each input block. Two families of coding modes are provided: coding modes based on spatial prediction coding (intra-frame prediction) and coding modes based on temporal prediction (inter-frame coding, merge, skip). Possible coding modes are tested.

[0124] Module 403 implements an intra-frame prediction process in which a given block to be coded is predicted by a predictor calculated from its neighboring pixels. If intra-frame coding is selected, the selected intra-frame predictor and an indication of the difference between the given block and its predictor are encoded to provide a residual.

[0125] Temporal prediction is implemented by the motion estimation module 404 and the motion compensation module 405. First, a reference image is selected from the reference image set 416, and the motion estimation module 404 selects a portion of the reference image (also called a reference region or image portion) that is closest to the given block to be encoded. The motion compensation module 405 then uses the selected region to predict the block to be encoded. The motion compensation module 405 calculates the difference between the selected reference region and the given block (also called the residual block). The selected reference region is indicated by a motion vector.

[0126] Thus, in both cases (spatial and temporal prediction), the residual is calculated by subtracting the prediction from the original block.

[0127] In the intra-frame prediction implemented by module 403, the prediction direction is encoded. In the temporal prediction, at least one motion vector is encoded. In the inter-frame prediction implemented by modules 404, 405, 416, 418, 417, at least one motion vector or data for identifying such a motion vector is encoded for the temporal prediction.

[0128] If inter prediction is selected, information about the motion vector and the residual block is encoded. To further reduce the bit rate, the motion vector is encoded as a difference relative to the motion vector predictor, assuming that the motion is homogeneous. The motion vector predictor from the set of motion information predictors is obtained by the motion vector prediction and encoding module 417 from the motion vector field 418.

[0129] The encoder 400 further includes a selection module 406 for selecting a coding mode by applying a coding cost criterion, such as a rate-distortion criterion. To further reduce redundancy, a transform (such as DCT) is applied to the residual block by a transform module 407, and the resulting transformed data is then quantized by a quantization module 408 and entropy encoded by an entropy coding module 409. Finally, the encoded residual block of the current block being encoded is inserted into a bitstream 410.

[0130] The encoder 400 also decodes the encoded image to generate a reference image for motion estimation of subsequent images. This allows the encoder and decoder receiving the bitstream to have the same reference frame. The inverse quantization module 411 performs inverse quantization of the quantized data, followed by an inverse transform by the inverse transform module 412. The inverse intra prediction module 413 uses the prediction information to determine which predictor to use for a given block, and the inverse motion compensation module 414 actually adds the residual obtained by module 412 to the reference region obtained from the reference image set 416.

[0131] Post filtering is then applied by module 415 to filter the reconstructed pixel frame. In an embodiment of the present invention, a SAO loop filter is used, wherein a compensating offset is added to the pixel values of the reconstructed pixels of the reconstructed image.

[0132] Figure 5 A block diagram of a decoder 60 according to an embodiment of the present invention is shown, which can be used to receive data from an encoder. The decoder is represented by connected modules, each module being adapted to implement the corresponding steps of the method implemented by the decoder 60, for example in the form of programming instructions to be executed by the CPU 311 of the device 300.

[0133] The decoder 60 receives a bitstream 61 comprising coding units, each consisting of a header containing information about the coded parameters and a body containing the coded video data. Figure 6 The structure of the bitstream in VVC is described in more detail. Figure 4 As illustrated, for a given block, the coded video data is entropy coded on a predetermined number of bits and the index of the motion vector predictor is encoded. The received coded video data is entropy decoded by module 62. The residual data is then dequantized by module 63, after which an inverse transform is applied by module 64 to obtain pixel values.

[0134] Mode data indicating an encoding mode is also entropy-decoded, and based on the mode, an encoding block of image data is subjected to intra-type decoding or inter-type decoding.

[0135] In the case of intra mode, the intra inverse prediction module 65 determines the intra predictor based on the intra prediction mode specified in the bitstream.

[0136] If the mode is inter, motion prediction information is extracted from the bitstream to find the reference region used by the encoder. The motion prediction information consists of a reference frame index and a motion vector residual. The motion vector predictor is added to the motion vector residual to obtain the motion vector by the motion vector decoding module 70.

[0137] A motion vector decoding module 70 applies motion vector decoding to each current block coded by motion prediction. Once the index of the motion vector predictor for the current block has been obtained, the actual value of the motion vector associated with the current block can be decoded and used to apply inverse motion compensation by module 66. The portion of the reference image indicated by the decoded motion vector is extracted from the reference image 68 to apply inverse motion compensation 66. The decoded motion vector is used to update the motion vector field data 71 for use in inverse prediction of subsequently decoded motion vectors.

[0138] Finally, a decoded block is obtained. Post filtering is applied by a post filtering module 67. The decoder 60 finally provides a decoded video signal 69.

[0139] Figure 6 The organization of the bitstream in an exemplary coding system VVC as described in JVET_Q2001-vD is shown.

[0140] The bitstream 600 according to the VVC coding system consists of an ordered sequence of syntax elements and encoded data. The syntax elements and encoded data are placed into network abstraction layer (NAL) units 601-608. There are different NAL unit types. The network abstraction layer provides the ability to encapsulate the bitstream into different protocols (such as RTP / IP (Real Time Protocol / Internet Protocol), ISO base media file format, etc.). The network abstraction layer also provides a framework for packet loss resistance.

[0141] NAL units are divided into video coding layer (VCL) NAL units and non-VCL NAL units. VCL NAL units contain the actual coded video data. Non-VCL NAL units contain additional information. This additional information can be parameters required to decode the coded video data or supplementary data that can enhance the usability of the decoded video data. NAL units 606 correspond to slices and constitute the VCL NAL units of the bitstream.

[0142] Different NAL units 601-605 correspond to different parameter sets, which are non-VCL NAL units. The decoder parameter set (DPS) NAL unit 301 contains parameters that are constant for a given decoding process. The video parameter set (VPS) NAL unit 602 contains parameters defined for the entire video and therefore the entire bitstream. The DPS NAL unit can define parameters that are more static than those in the VPS. In other words, the parameters of the DPS change less frequently than those of the VPS.

[0143] The sequence parameter set (SPS) NAL unit 603 contains parameters defined for a video sequence. Specifically, the SPS NAL unit may define the sub-picture layout and associated parameters of the video sequence. Parameters associated with each sub-picture specify the coding constraints applied to the sub-picture. Specifically, a flag is included to indicate that temporal prediction between sub-pictures is restricted to data from the same sub-picture. Another flag may enable or disable loop filters across sub-picture boundaries.

[0144] Picture parameter set (PPS) NAL unit 604. The PPS contains parameters defined for a picture or group of pictures. Adaptation parameter set (APS) NAL unit 605 contains parameters for the loop filter, which is typically an adaptive loop filter (ALF) or a shaper model (or a luma map with chroma scaling (LMCS) model) or a scaling matrix used at the slice level.

[0145] The syntax of PPS as proposed in the current version of VVC includes syntax elements that specify the size of a picture in units of luma samples and the partitioning of each picture into blocks and slices.

[0146] The PPS contains syntax elements that allow the location of slices within a frame to be determined. Since a sub-picture forms a rectangular area within a frame, the set of slices, tile portions, or tiles belonging to a sub-picture can be determined from the parameter set NAL unit. Like the APS, the PPS has an ID mechanism to limit the number of transmissions of the same PPS.

[0147] The main difference between the PPS and the picture header is its transmission, which is usually sent for a group of pictures, compared to the PH which is systematically sent for each picture. Therefore, in contrast to the PH, the PPS contains parameters that can be constant for several pictures.

[0148] The bitstream may also contain Supplemental Enhancement Information (SEI) NAL units ( Figure 6(Not shown in the image). The periodicity of these parameter sets in the bitstream is variable. A VPS defined for the entire bitstream may appear only once in the bitstream. Conversely, an APS defined for a slice may appear once for each slice in each picture. In practice, different slices may rely on the same APS, and therefore there are typically fewer APSs than slices in each picture. Specifically, the APS is defined in the picture header. However, the ALF APS can be refined in the slice header.

[0149] The Access Unit Delimiter (AUD) NAL unit 607 separates two access units. An access unit is a collection of NAL units that may include one or more coded pictures with the same decoding timestamp. This optional NAL unit contains only one syntax element from the current VVC specification: pic_type, which indicates that the slice_type value is used for all slices of the coded pictures in the AU. If pic_type is set to 0, the AU contains only intra slices. If it is 1, it contains P and I slices. If it is 2, it contains B, P, or intra slices.

[0150] This NAL unit contains only one syntax element, pic-type.

[0151] Table 1 Syntax AUD

[0152]

[0153] In JVET-Q2001-vD, pic-type is defined as follows:

[0154] "pic_type indicates that the slice_type values of all slices of the coded pictures in the AU containing the AU delimiter NAL unit are members of the set listed in Table 2 for the given pic_type value. The value of pic_type shall be equal to 0, 1, or 2 in bitstreams conforming to this version of this specification. Other values of pic_type are reserved for future use by ITUT|ISO / IEC. Decoders conforming to this version of this specification shall ignore the reserved values of pic_type."

[0155] rbsp_trailing_bits() is a function that adds bits to align with the end of a byte. Therefore, after this function, the amount of the bit stream parsed is an integer number of bytes.

[0156] Table 2 Explanation of pic_type

[0157] pic_type Possible slice_type values in AU 0 I 1 P,I 2 B,P,I

[0158] The PH NAL unit 608 is a picture header NAL unit that groups common parameters for a set of slices of one coded picture.A picture may refer to one or more APSs to indicate the AFL parameters, shaper models, and scaling matrices used by the slices of the picture.

[0159] Each VCL NAL unit 606 contains a slice. A slice can correspond to an entire picture or a sub-picture, a single block, or multiple blocks or a fragment of a block. For example, Figure 6 A slice comprises a number of blocks 620 . A slice consists of a slice header 610 and a raw byte sequence payload RBSP 611 , which contains coded pixel data coded as coded blocks 640 .

[0160] The syntax of the PPS as proposed in the current version of VVC includes syntax elements that specify the size of a picture in units of luma samples and the partitioning of each picture in units of blocks and slices.

[0161] The PPS contains syntax elements that allow the slice positions in a frame to be determined. Since a sub-picture forms a rectangular area in a frame, the set of slices, tile parts or tiles belonging to a sub-picture can be determined from the parameter set NAL units.

[0162] NAL unit slice

[0163] The NAL unit slice layer contains a slice header and slice data, as shown in Table 3.

[0164] Table 3 Stripe layer syntax

[0165]

[0166] APS

[0167] The adaptation parameter set (APS) NAL unit 605 is defined in Table 4 showing the syntax elements.

[0168] As depicted in Table 4, there are 3 possible types of APS given by the aps_params_type syntax element:

[0169] ALF_AP: used for ALF parameters

[0170] LMCS_APS: used for LMCS parameters

[0171] SCALLING_APS: used for scaling list related parameters

[0172] Table 4 Adaptive parameter set syntax

[0173]

[0174]

[0175] The following discusses these three types of APS parameters in turn.

[0176] ALF APS

[0177] The ALF parameters are described in the adaptive loop filter data syntax element (Table 5). First, four flags are dedicated to specifying whether the ALF filter is sent for luma and / or for chroma and whether CC-ALF (cross-component adaptive loop filtering) is enabled for the Cb component and the Cr component. If the luma filter flag is enabled, another flag is decoded to know whether the clipping value (alf_luma_clip_flag) is signaled. The number of filters signaled is then decoded using the alf_luma_num_filters_signalled_minus1 syntax element. If necessary, the syntax element representing the ALF coefficient increment "alf_luma_coeff_delta_idx" is decoded for each enabled filter. The absolute value and sign of each coefficient of each filter are then decoded.

[0178] If alf_luma_clip_flag is enabled, the clipping index of each coefficient of each enabled filter is decoded.

[0179] In the same way, the ALF chroma coefficients are decoded when needed.

[0180] If CC-ALF is enabled for Cr or Cb, the number of filters is decoded (alf_cc_cb filters_signalled minus1 or alf_cc_cr filters_signalled_minus1) and the related coefficients are decoded (alf_cc_cb_mapped_coeff_abs and alf_cc_cb_coeff_sign or alf_cc_cr_mapped_coeff_abs and alf_cc_cr_coeff_sign respectively).

[0181] Table 5 Adaptive loop filter data syntax

[0182]

[0183]

[0184]

[0185] LMCS syntax elements for both luma mapping and chroma scaling

[0186] Table 6 below gives all LMCS syntax elements (LMCS_APS) encoded in the Adaptation Parameter Set (APS) syntax structure when the aps_params_type parameter is set to 1. Up to four LMCS APSs may be used in a coded video sequence, however, for a given picture only a single LMCS APS may be used.

[0187] These parameters are used to construct the forward and inverse mapping functions for luma and the scaling function for chroma.

[0188] Table 6 Luma Mapping with Chroma Scaling Data Syntax

[0189]

[0190] Zoom List APS

[0191] The scaling list provides the possibility to update the quantization matrix used for quantization. In VVC, the scaling matrix is signaled in the APS as described in the scaling list data syntax element (Table 7 Scaling list data syntax). The first syntax element specifies whether the scaling matrix is used for the LFNST (Low Frequency Non-separable Transform) tool based on the flag scaling_matrix_for_lfnst_disabled_flag. The second is specified if the scaling list is used for chroma components (scaling_list_chroma_present_flag). Then, the syntax elements required to construct the scaling matrix (scaling_list_copy_mode_flag, scaling_list_pred_mode_flag, scaling_list_pred_id_delta, scaling_list_dc_coef, scaling_list_delta_coef) are decoded.

[0192] Table 7: Scaling List Data Syntax

[0193]

[0194]

[0195] Image header

[0196] A picture header is sent at the beginning of each picture before the other slice data. This is very large compared to previous headers in previous drafts of the standard. A complete description of all these parameters can be found in JVET_Q2001-vD. Table 10 shows these parameters in the current picture header decoding syntax.

[0197] The relevant syntactic elements that can be decoded are:

[0198] Whether to use the image or reference frame

[0199] Type of image

[0200] Output frame

[0201] Number of images

[0202] Use sub-images (if needed)

[0203] List of reference images (if required)

[0204] Color plane (if needed)

[0205] Partition update (if overwrite flag is enabled)

[0206] Incremental QP parameters (if needed)

[0207] Motion information parameters (if required)

[0208] ALF parameters (if required)

[0209] SAO parameters (if needed)

[0210] Quantization parameters (if needed)

[0211] LMCS parameters (if required)

[0212] Scale list parameters (if needed)

[0213] Image header expansion (if necessary)

[0214] ·etc

[0215] Image "Type"

[0216] The first flag is grd_or_irap_pic_flag, which indicates whether the current picture is a resynchronization picture (IRAP or GDR). If this flag is true, gdr_pic_flag is decoded to know whether the current picture is an IRAP picture or a GDR picture.

[0217] The ph_inter_slice_allowed_flag is then decoded to identify that inter slices are allowed.

[0218] When they are allowed, the flag ph_infra_slice_allowed_flag is decoded to know whether intra slices are allowed for the current picture.

[0219] Then decode non_reference_picture_flag, ph_pic_parameter_set_id indicating PPS ID, and picture order count ph_pic_order_cnt_lsb. The picture order count gives the number of the current picture.

[0220] If the picture is a GDR or IRAP picture, the flag no_output_of_prior_pics_flag is decoded.

[0221] And if the picture is GDR, decode recovery_poc_cnt. Then, decode ph_poc_msb_present_flag and poc_msb_val if necessary.

[0222] ALF

[0223] After these parameters that describe important information about the current picture, a set of ALF APS ID syntax elements are decoded if ALF is enabled at the SPS level and if ALF is enabled at the picture header level. ALF is enabled at the SPS level due to the sps_alf_enabled_flag flag. ALF is signaled at the picture header level due to alf_info_in_ph_flag being 1, otherwise (alf_info_in_ph_flag being 0), ALF is signaled at the slice level.

[0224] alf_info_in_ph_flag is defined as follows:

[0225] "alf_info_in_ph_flag equal to 1 specifies that ALF information is present in the PH syntax structure and is not present in slice headers referencing PPSs that do not contain a PH syntax structure. alf_info_in_ph_flag equal to 0 specifies that ALF information is not present in the PH syntax structure and may be present in slice headers referencing PPSs that do not contain a PH syntax structure."

[0226] First, ph_alf_enabled_present_flag is decoded to determine whether ph_alf_enabled_flag should be decoded. If ph_alf_enabled_present_flag is enabled, ALF is enabled for all slices of the current picture.

[0227] If ALF is enabled, the pic_num_alf_aps_ids_luma syntax element is used to decode the amount of ALF APS ID for luma. For each APS ID, the APS ID value "ph_alf_aps_id_luma" for luma is decoded.

[0228] For chroma, the syntax element ph_alf_chroma_idc is decoded to determine whether ALF is enabled for chroma, only for Cr, or only for Cb. If enabled, the value of the APS ID for chroma is decoded using the ph_alf_aps_id_chroma syntax element.

[0229] In this way, if required by the Cb and / or Cr components, the APS ID for the CC-ALF method is decoded.

[0230] LMCS

[0231] If LMCS is enabled at the SPS level, the set of LMCS APS ID syntax elements is decoded. First, ph_lmcs_enabled_flag is decoded to determine whether LMCS is enabled for the current picture. If LMCS is enabled, the ID value ph_lmcs_aps_id is decoded. For chroma, only ph_chroma_residual_scale_flag is decoded to enable or disable the method for chroma.

[0232] Zoom List

[0233] If scaling lists are enabled at the SPS level, the set of scaling list APS IDs is decoded. The ph_scaling_list_present_flag is decoded to determine whether the scaling matrix is enabled for the current picture. And then the value of the APS ID (ph_scaling_list_aps_id) is decoded.

[0234] Sub-image

[0235] When sub-picture parameters are enabled at the SPS and if the sub-picture ID is signaled to be disabled, the sub-picture parameters are enabled. Also contains some information about the virtual boundaries. For sub-picture parameters, eight syntax elements are defined:

[0236] ·ph_virtual_boundaries_present_flag

[0237] ·ph_num_ver_virtual_boundaries

[0238] ·ph_virtual_boundaries_pos_x[i]

[0239] ·ph_num_hor_virtual_boundaries

[0240] ·ph_virtual_boundaries_pos_y[i]

[0241] Output Flag

[0242] These sub-picture parameters are followed by pic_output_flag (if present).

[0243] Reference Image List

[0244] If the reference picture list is signaled in the picture header (due to rpl_info_in_ph_flag being equal to 1), the parameter ref_pic_lists() of the reference picture list is decoded, which contains the following syntax elements:

[0245] rpl_sps_flag[]

[0246] rpl_idx[]

[0247] ·poc_lsb_lt[][]

[0248] ·delta_poc_msb_present_flag[][]

[0249] delta_poc_msb_cycle_lt[][]

[0250] and is defined in the following syntax table:

[0251] Table 8 Reference Picture List Syntax

[0252]

[0253] Partition

[0254] If required, a partition parameter set is decoded and contains the following syntax elements:

[0255] ·partition_constraints_override_flag

[0256] ·ph_log2_diff_min_qt_min_cb_intra_slice_luma

[0257] ·ph_max_mtt_hierarchy_depth_intra_slice_luma

[0258] ·ph_log2_diff_max_bt_min_qt_intra_slice_luma

[0259] ·ph_log2_diff_max_tt_min_qt_intra_slice_luma

[0260] ·ph_log2_diff_min_qt_min_cb_intra_slice_chroma

[0261] ·ph_max_mtt_hierarchy_depth_intra_slice_chroma

[0262] ·ph_log2_diff_max_bt_min_qt_intra_slice_chroma

[0263] ·ph_log2_diff_max_tt_min_qt_intra_slice_chroma

[0264] ·ph_log2_diff_min_qt_min_cb_inter_slice

[0265] ·ph_max_mtt_hierarchy_depth_inter_slice

[0266] ·ph_log2_diff_max_bt_min_qt_inter_slice

[0267] ·ph_log2_diff_max_tt_min_qt_inter_slice

[0268] Weighted prediction

[0269] If the weighted prediction method is enabled at the PPS level and if the weighted prediction parameters are signaled in the picture header (wp_info_in_ph_flag is equal to 1), the weighted prediction parameters pred_weight_table() are decoded.

[0270] When bi-predictive weighted prediction is enabled, pred_weight_table() contains weighted prediction parameters for list L0 and list L1. As depicted in the pred_weight_table() syntax table (Table 9), when weighted prediction parameters are sent in the picture header, the number of weights for each list is explicitly sent.

[0271] Table 9 Weighted prediction parameter syntax

[0272]

[0273]

[0274]

[0275] Incremental QP

[0276] When the picture is intra, ph_cu_qp_delta_subdiv_intra_slice and ph_cu_chroma_qp_offset_subdiv_intra_slice are decoded if needed. And if inter slices are allowed, ph_cu_qp_delta_subdiv_inter_slice and ph_cu_chroma_qp_offset_subdiv_inter_slice are decoded if needed. Finally, the picture header extension syntax element is decoded if needed.

[0277] All parameters alf_info_in_ph_flag, rpl_info_in_ph_flag, qp_delta_info_in_ph_flag, sao_info_in_ph_flag, dbf_info_in_ph_flag, wp_info_in_ph_flag are signaled in the PPS.

[0278] Table 10 Image header structure

[0279]

[0280]

[0281]

[0282]

[0283]

[0284]

[0285]

[0286] Strip header

[0287] A slice header is sent at the beginning of each slice. The slice header contains approximately 65 syntax elements. This is very large compared to previous slice headers in earlier video coding standards. A complete description of all slice header parameters can be found in JVET-Q2001-vD. Table 11 shows these parameters in the current slice header decoding syntax.

[0288] Table 11 Partial strip header

[0289]

[0290]

[0291]

[0292]

[0293]

[0294] First, picture_header_in_slice_header_flag is decoded to know whether picture_header_structure() exists in the slice header.

[0295] Then, if necessary, slice_subpic_id is decoded to determine the sub-picture ID of the current slice. Then, slice_address is decoded to determine the address of the current slice. If the current slice mode is rectangular slice mode (rest_slice_flag is equal to 1) and if the number of slices in the current sub-picture is greater than 1, the slice address is decoded. If the current slice mode is raster scan mode (rest_slice_flag is equal to 0) and if the number of blocks in the current picture is greater than 1 calculated based on the variables defined in the PPS, the slice address may also be decoded.

[0296] If the number of tiles in the current picture is greater than 1 and if the current slice mode is not a rectangular slice mode, num_tiles_in_slice_minus1 is decoded. In the current VVC draft specification, num_tiles_in_slice_minus1 is defined as follows:

[0297] "num_tiles_in_slice_minus1 plus 1, when present, specifies the number of tiles in a slice. The value of num_tiles_in_slice_minus1 should be in the range of 0 to NumTilesInPic - 1, inclusive."

[0298] Then decode the slice_type.

[0299] If ALF is enabled at the SPS level (sps_alf_enabled_flag) and if ALF is signaled in the slice header (alf_info_in_ph_flag is equal to 0), the ALF information is decoded. This includes a flag indicating that ALF is enabled for the current slice (slice_alf_enabled_flag). If enabled, the number of APS ALF IDs for luma (slice_num_alf_aps_ids_luma) is decoded, followed by the APS ID (slice_alf_aps_id_luma[i]). Then, slice_alf_chroma_idc is decoded to know if ALF is enabled for the chroma components and which chroma component is enabled. Then, if necessary, the APS ID for chroma (slice_alf_aps_id_chroma) is decoded. In the same way, if necessary, slice_cc_alf_cb_enabled_flag is decoded to know if the CC ALF method is enabled. If CC ALF is enabled, if CC ALF is enabled for Cr and / or Cb, decode the relevant APS ID for Cr and / or Cb.

[0300] If the colour planes are sent independently (separate_colour_plane_flag equal to 1), colour_plane_id is decoded.

[0301] When the reference picture list ref_pic_lists() is not sent in the picture header (rpl_info_in_ph_flag is equal to 0) and when the NAL unit is not IDR or if the reference picture list is sent for an IDR picture (sps_idr_rpl_present_flag is equal to 1), the reference picture list parameters are decoded; these are similar to those in the picture header.

[0302] If a reference picture list is sent in the picture header (rpl_info_in_ph_flag is equal to 1) or the NAL unit is not IDR, or if a reference picture list is sent for an IDR picture (sps_idr_rpl_present_flag is equal to 1), and if the number of references of at least one list is higher than 1, the override flag num_ref_idx_active_override_flag is decoded. This flag is defined in the VVC draft specification as follows:

[0303] "num_ref_idx_active_override_flag equal to 1 specifies that the syntax element num_ref_idx_active_minus1[0] is present for P and B slices, and that the syntax element num_ref_idx_active_minus1[1] is present for B slices. num_ref_idx_active_override_flag equal to 0 specifies that the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1] are not present. When not present, the value of num_ref_idx_active_override_flag is inferred to be equal to 1."

[0304] If num_ref_idx_active_override_flag is enabled, the number of reference indices num_ref_idx_active_minus1[i] for each list "i" is decoded when needed. The number of reference indices overridden for the current list should be lower than or equal to the number of reference frame indices signaled in ref_pic_lists(). Thus, the overriding reduces or does not reduce the maximum number of reference frames for each list.

[0305] When the slice type is not intra, and if necessary, decode cabac_init_flag. If the reference picture list is sent in the slice header and other conditions occur, decode slice_collocated_from_l0_flag and slice_collocated_ref_idx. These data are related to CABAC coding and collocated motion vectors.

[0306] In the same manner, when the slice type is not intra, parameters pred_weight_table() of weighted prediction are decoded.

[0307] If delta QP information is sent in the slice header (qp_delta_info_in_ph_flag is equal to 0), decode slice_qp_delta. If needed, decode the syntax elements slice_cb_qp_offset, slice_cr_qp_offset, slice_joint_cbcr_qp_offset, and cu_chroma_qp_offset_enabled_flag.

[0308] If SAO information is sent in the slice header (sao_info_in_ph_flag equal to 0) and if it is enabled at the SPS level (sps_sao_enabled_flag), then the SAO enablement flags are decoded for both luma and chroma: slice_sao_luma_flag, slice_sao_chroma_flag.

[0309] Then, if the deblocking filter parameters are signaled in the slice header (dbf_info_in_ph_flag equal to 0), the deblocking filter parameters are decoded.

[0310] The flag slice_ts_residual_coding_disabled_flag is system-decoded to know whether the transform skip residual coding method is enabled for the current slice.

[0311] If LMCS is enabled in the picture header (ph_lmcs_enabled_flag is equal to 1), the flag slice_lmcs_enabled_flag is decoded. In the current VVC specification, slice_lmcs_enabled_flag is defined as follows:

[0312] "slice_lmcs_enabled_flag equal to 1 specifies that luma mapping with chroma scaling is enabled for the current slice. slice_lmcs_enabled_flag equal to 0 specifies that luma mapping with chroma scaling is not enabled for the current slice. When slice_lmcs_enabled_flag is not present, it is inferred to be equal to 0."

[0313] In the same way, if the scaling list is enabled in the picture header (phpic_scaling_list_presentenabled_flag is equal to 1), the flag slice_scaling_list_present_flag is decoded. In the current VVC specification, slice_scaling_list_present_flag is defined as follows:

[0314] "slice_scaling_list_present_flag equal to 1 specifies that the scaling list data for the current slice is derived based on the scaling list data contained in the referenced scaling list APS with aps_params_type equal to SCALING_APS and adaptation_parameter_set_id equal to ph_scaling_list_aps_id. slice_scaling_list_present_flag equal to 0 specifies that the scaling list data for the current picture is the default scaling list data derived as specified in clause 7.4.3.21. When not present, the value of slice_scaling_list_present_flag is inferred to be equal to 0."

[0315] Then, if necessary, other parameters are decoded.

[0316] Image header in strip header

[0317] In a specific signal notification manner, such as Figure 7 As depicted in FIG, the picture header 708 may be signaled within the slice header 710. In this case, there is no NAL unit containing only the picture header 608. Units 701, 702, 703, 704, 705, 706, 707, 720, and 740 correspond to Figure 6 601, 602, 603, 604, 605, 606, 606, 620, and 640 of FIGURE 1 and can therefore be understood from the foregoing description. This can be enabled in the slice header due to the flag picture_header_in_slice_header_flag. Furthermore, when a picture header is signaled within the slice header, a picture should contain only one slice. Therefore, each picture always has only one picture header. Furthermore, the flag picture_header_in_slice_header_flag should have the same value for all pictures of a CLVS (Coding Layer Video Sequence). This means that all pictures between two IRAPs, including the first IRAP, have only one slice per picture.

[0318] The flag picture_header_in_slice_header_flag is defined as follows:

[0319] "picture_header_in_slice_header_flag equal to 1 specifies that the PH syntax structure is present in the slice header. picture_header_in_slice_header_flag equal to 0 specifies that the PH syntax structure is not present in the slice header.

[0320] It is a requirement for bitstream conformance that the value of picture_header_in_slice_header_flag should be the same in all coded slices in CLVS.

[0321] When picture_header_in_slice_header_flag is equal to 1 for a coded slice, it is a requirement for bitstream conformance that no VCL NAL units with nal_unit_type equal to PH_NUT shall be present in the CLVS.

[0322] When picture_header_in_slice_header_flag is equal to 0, all coded slices in the current picture shall have picture_header_in_slice_header_flag equal to 0, and the current PU shall have a PH NAL unit.

[0323] picture_header_structure() contains the syntax elements of picture_rbsp() except for the padding bits rbsp_trailing_bits(). "

[0324] Streaming applications

[0325] Some streaming applications extract only certain portions of the bitstream. These extractions can be spatial (as sub-pictures) or temporal (sub-portions of a video sequence). These extracted portions can then be merged with the rest of the bitstream. Others reduce the frame rate by extracting only some frames. Typically, the primary goal of these streaming applications is to use the maximum allowed bandwidth to produce the highest quality for the end user.

[0326] In VVC, for frame rate reduction, APS ID numbering is already restricted so that new APS ID numbers for a frame cannot be used for frames in upper layers in the temporal hierarchy. However, for streaming applications that extract portions of a bitstream, it is necessary to track APS IDs to determine which APSs should be retained for a sub-portion of the bitstream, since frames (due to IRAP) do not reset the APS ID numbering.

[0327] LMCS (Luminance Mapping with Chroma Scaling)

[0328] The Luma Mapping with Chroma Scaling (LMCS) technique is a sample value conversion method applied to a block before applying a loop filter in a video decoder such as VVC.

[0329] LMCS can be divided into two sub-tools. The first sub-tool is applied to luma blocks, while the second sub-tool is applied to chroma blocks, as described below:

[0330] 1) The first sub-tool is an in-loop mapping of the luma component based on an adaptive piecewise linear model. Luma component in-loop mapping adjusts the dynamic range of the input signal to improve compression efficiency by redistributing codewords across the dynamic range. Luma mapping utilizes a forward mapping function into the "mapping domain" and a corresponding inverse mapping function back into the "input domain."

[0331] 2) The second sub-tool is related to the chroma components, which apply luma-dependent chroma residual scaling. Chroma residual scaling is designed to compensate for the interaction between the luma signal and its corresponding chroma signal. Chroma residual scaling depends on the average of the neighboring luma samples reconstructed above and / or to the left of the current block.

[0332] Like most other tools in video encoders such as VVC, LMCS can be enabled / disabled at the sequence level using an SPS flag. Whether chroma residual scaling is enabled is also signaled at the slice level. If luma mapping is enabled, an additional flag is signaled to indicate whether luma-dependent chroma residual scaling is enabled. When luma mapping is not used, luma-dependent chroma residual scaling is completely disabled. Additionally, luma-dependent chroma residual scaling is always disabled for chroma blocks of size less than or equal to 4.

[0333] Figure 8 The principle of LMCS as described above for the Luma Mapping Sub-Tool is shown. Figure 8 The shaded blocks in the figure are the new LMCS functional blocks, which include the forward and inverse mapping of the luminance signal. It is important to note that when LMCS is used, some decoding operations are applied in the "mapping domain". These operations are performed by the Figure 8 They generally correspond to the inverse quantization, inverse transform, luma intra prediction and reconstruction steps (which consists in adding the luma prediction to the luma residual). Figure 8 The solid blocks in indicate where the decoding processes are applied in the original (ie non-mapped) domain, and this includes loop filtering such as deblocking, ALF and SAO, motion compensated prediction, and storage of decoded pictures as reference pictures (DPB).

[0334] Figure 9 Shown with Figure 8Similar diagram, but this time for the Chroma Scaling sub-tool of the LMCS tool. Figure 9 The shaded blocks in the figure are new LMCS functional blocks, which include the luma-dependent chroma scaling process. However, in terms of chroma, there are some important differences compared to the luma case. Here, for the chroma samples, only the inverse quantization and inverse transform, represented by the blocks in the dashed line, are performed in the "mapped domain". All other steps of intra chroma prediction, motion compensation, and loop filtering are performed in the original domain. Figure 9 As shown, for brightness mapping, there is only a scaling process, and no forward and inverse processes.

[0335] Brightness mapping using a piecewise linear model

[0336] The Luma Mapping sub-tool uses a piecewise linear model, which means that the piecewise linear model divides the input signal dynamic range into 16 equal sub-ranges and, for each sub-range, uses the number of codewords assigned to that range to represent its linear mapping parameters.

[0337] Semantics of brightness mapping

[0338] The syntax element lmcs_min_bin_idx specifies the minimum bin (interval) index used in the construction process of the Luma Map with Chroma Scale (LMCS). The value of lmcs_min_bin_idx shall be in the range of 0 to 15 (inclusive).

[0339] The syntax element lmcs_delta_max_bin_idx specifies the delta value between 15 and the maximum bin index LmcsMaxBinIdx used in the construction of the luma map with chroma scaling. The value of lmcs_delta_max_bin_idx shall be in the range of 0 to 15, inclusive. The value of LmcsMaxBinIdx shall be set equal to 15 - lmcs_delta_max_bin_idx. The value of LmcsMaxBinIdx shall be greater than or equal to lmcs_min_bin_idx.

[0340] The syntax element lmcs_delta_cw_prec_minus1 plus 1 specifies the number of bits used to represent the syntax lmcs_delta_abs_cw[i].

[0341] The syntax element lmcs_delta_abs_cw[i] specifies the absolute delta codeword value for the i-th bin.

[0342] The syntax element lmcs_delta_sign_cw_flag[i] specifies the sign of the variable lmcsDeltaCW[i]. When lmcs_delta_sign_cw_flag[i] is not present, it is inferred to be equal to 0.

[0343] LMCS intermediate variable calculation for brightness mapping

[0344] In order to apply the forward and inverse brightness mapping processes, some intermediate variables and data arrays are required.

[0345] First, export the variable OrgCW as follows:

[0346] OrgCW=(1< <BitDepth) / 16

[0347] Then, the variable lmcsDeltaCW[i] (where i=lmcs_min_bin_idx . . . LmcsMaxBinIdx) is calculated as follows:

[0348] lmcsDeltaCW[i]=(1-2*lmcs_delta_sign_cw_flag[i])*lmcs_delta_abs_cw[i]

[0349] The new variable lmcsCW[i] is derived as follows:

[0350] - For i=0...lmcs_min_bin_idx-1, lmcsCW[i] is set equal to 0.

[0351] - For i = lmcs_min_bin_idx ... LmcsMaxBinIdx, the following applies:

[0352] lmcsCW[i]=OrgCW+lmcsDeltaCW[i]

[0353] The value of lmcsCW[i] should be in the range of (OrgCW>>3) to (OrgCW<<3-1) (inclusive).

[0354] - For i=LmcsMaxBinIdx+1...15, lmcsCW[i] is set equal to 0.

[0355] The variable InputPivot[i] (where i=0...16) is derived as follows:

[0356] InputPivot[i]=i*OrgCW

[0357] The variables LmcsPivot[i] (where i=0...16), ScaleCoeff[i] and InvScaleCoeff[i] (where i=0...15) are calculated as follows:

[0358] LmcsPivot[0]=0;

[0359] for(i=0;i<=15;i++){

[0360] LmcsPivot[i+1]=LmcsPivot[i]+lmcsCW[i]

[0361] ScaleCoeff[i]=(lmcsCW[i]*(1<<11)+(1<<(Log2(OrgCW)-1)))>>(Log2(OrgCW))

[0362] if(lmcsCW[i] == 0)

[0363] InvScaleCoeff[i]=0

[0364] else

[0365] InvScaleCoeff[i]=OrgCW*(1<<11) / lmcsCW[i]

[0366] Forward Luminance Map

[0367] like Figure 8 As shown, when LMCS is applied to luma, luma remap samples called predMapSamples[i][j] are obtained from the prediction samples predSamples[i][j].

[0368] predMapSamples[i][j] is calculated as follows:

[0369] First, the index idxY is calculated from the predicted sample predSamples[i][j] at position (i, j).

[0370] idxY=predSamples[i][j]>>Log2(OrgCW)

[0371] Then, predMapSamples[i][j] is derived as follows by using the intermediate variables idxY, LmcsPivot[idxY], and InputPivot[idxY] of part 0:

[0372] predMapSamples[i][j]=LmcsPivot[idxY]

[0373] +(ScaleCoeff[idxY] * (predSamples[i][j] - InputPivot[idxY]) + (1 << 10)) >> 11

[0374] Luminance reconstruction sample

[0375] Obtain the reconstruction process from the predicted luminance sample predMapSample[i][j] and the residual luminance sample resiSamples[i][j].

[0376] Simply obtain the reconstructed luminance picture sample recSamples[i][j] by adding predMapSample[i][j] to resiSamplei[i][j] as follows:

[0377] recSamples[i][j] = Clip1(predMapSamples[i][j] + resiSamples[i][j]])

[0378] In the above relationship, the Clip 1 function is a clipping function to ensure that the reconstructed samples are between 0 and 1 << BitDepth - 1.

[0379] Inverse luminance mapping

[0380] When applying the inverse luminance mapping according to Figure 8 the following operations are applied to each sample recSample[i][j] of the current block being processed:

[0381] First, calculate the index idxY from the reconstructed sample recSamples[i][j] at position (i, j).

[0382] idxY = recSamples[i][j] >> Log2(OrgCW)

[0383] The inverse - mapped luminance sample invLumaSample[i][j] is derived based on the following:

[0384] invLumaSample[i][j] =

[0385] InputPivot[idxYInv] + (InvScaleCoeff[idxYInv] *

[0386] (recSample[i][j] - LmcsPivot[idxYInv]) + (1 << 10)) >> 11

[0387] Then perform a clipping operation to obtain the final sample:

[0388] finalSample[i][j]=Clip1(invLumaSample[i][j])

[0389] Chroma Scaling

[0390] LMCS semantics for chroma scaling

[0391] The syntax element lmcs_delta_abs_crs in Table 6 specifies the absolute codeword value of the variable lmcsDeltaCrs. The value of lmcs_delta_abs_crs shall be in the range of 0 to 7 (inclusive). When not present, lmcs_delta_abs_crs is inferred to be equal to 0.

[0392] The syntax element lmcs_delta_sign_crs_flag specifies the sign of the variable lmcsDeltaCrs. When not present, lmcs_delta_sign_crs_flag is inferred to be equal to 0.

[0393] LMCS intermediate variable calculation for chroma scaling

[0394] In order to apply the chroma scaling process, some intermediate variables are needed.

[0395] The variable lmcsDeltaCrs is derived as follows:

[0396] lmcsDeltaCrs=(1-2*lmcs_delta_sign_crs_flag)*lmcs_delta_abs_crs

[0397] The variable ChromaScaleCoeff[i] (where i=0...15) is derived as follows:

[0398] if(lmcsCW[i] == 0)

[0399] ChromaScaleCoeff[i]=(1<<11)

[0400] else

[0401] ChromaScaleCoeff[i]=OrgCW*(1<<11) / (lmcsCW[i]+lmcsDeltaCrs)

[0402] Chroma scaling

[0403] In the first step, the variable invAvgLuma is derived to calculate the average luma value of the reconstructed luma samples around the current corresponding chroma block. The average luma is calculated from the left and top luma blocks surrounding the corresponding chroma block.

[0404] If no samples are available, the variable invAvgLuma is set as follows:

[0405] invAvgLuma=1<<(BitDepth-1)

[0406] Based on the intermediate array LmcsPivot[] of part 0, the variable idxYInv is then derived as follows:

[0407] For(idxYInv=lmcs_min_bin_idx; idxYInv<=LmcsMaxBinIdx; idxYInv++){

[0408] if(invAvgLuma <LmcsPivot[idxYInv+1])break

[0409] }

[0410] IdxYInv=Min(idxYInv,15)

[0411] The variable varScale is exported as follows:

[0412] varScale=ChromaScaleCoeff[idxYInv]

[0413] When the transform is applied to the current chroma block, the reconstructed chroma picture sample array recSamples is derived as follows:

[0414] recSamples[i][j]=Clip1(predSamples[i][j]+

[0415] Sign(resiSamples[i][j])*((Abs(resiSamples[i][j])*varScale+(1<<10))>>11))

[0416] If no transform has been applied to the current block, the following is applied:

[0417] recSamples[i][j]=Clip1(predSamples[i][j])

[0418] Encoder Considerations

[0419] The basic principle of the LMCS encoder is to first allocate more codewords to those dynamic range segments with codewords with lower variance than the average. In an alternative concept, the main goal of LMCS is to allocate fewer codewords to those dynamic range segments with codewords with higher variance than the average. In this way, smooth areas of the picture will be encoded with more codewords than the average, and vice versa.

[0420] All parameters of the LMCS tool stored in the APS are determined on the encoder side (see Table 6). The LMCS encoder algorithm is based on the evaluation of local luminance variance and optimizes the determination of LMCS parameters according to the basic principles described above. The optimization is then performed to obtain the best PSNR metric for the final reconstructed samples of a given block.

[0421] Example

[0422] Reference frame signaling

[0423] Avoid signaling of additional reference frames when there is only one slice

[0424] In an embodiment, when at least one syntax element indicates that the current picture contains only one slice, overwriting of the reference picture list is not signaled in the slice header. In fact, when a picture contains one slice, the encoder should not overwrite the reference picture list, because the reference picture list should only be written once. Similarly, when the current picture contains only one slice, the decoder should not seek to parse syntax elements for overwriting the reference picture list. If the slice uses a reference picture list (or multiple reference picture lists) signaled in the SPS, there is an advantage in overwriting one or more lists to limit the number of reference pictures. However, surprisingly, in terms of coding efficiency trade-offs for practical applications, it is preferable to avoid such overwriting to save bits associated with its signaling. In addition, slice header parsing is simplified for some implementations.

[0425] Avoid signaling of additional reference frames when PH is in SH

[0426] In an embodiment, when the picture header is in the slice header, the syntax elements related to the overriding of the reference frame are not signaled in the slice header. More specifically, as depicted in Table 12, when the flag picture_header_in_slice_header_flag is set to 1, the syntax elements "num_ref_idx_active_override_flag" and "num_ref_idx_active_minus1[i]" are not sent.

[0427] Additionally, the definition of "num_ref_idx_active_override_flag" should be modified as follows:

[0428] "num_ref_idx_active_override_flag equal to 1 specifies that the syntax element num_ref_idx_active_minus1[0] is present for P and B slices and that the syntax element num_ref_idx_active_minus1[1] is present for B slices. num_ref_idx_active_override_flag equal to 0 specifies that the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1] are not present. When not present, And when referring to the PPS strip When the header does not contain PH syntax structure , it is inferred that the value of num_ref_idx_active_override_flag is equal to 1. Otherwise, when When not present, and when the slice header of the referenced PPS contains a PH syntax structure, num_ref_idx_active_ The value of override_flag is equal to 0 .”

[0429] The advantage is that coding efficiency improves when the picture is in the slice header. In practice, for low-latency and low-bitrate applications, it is efficient to signal the picture header in the slice header. In this case, the cost of overwriting multiple pictures is greater than the cost of setting up a set of reference picture lists in the SPS. In practice, for these use cases, the number of reference frames is usually limited to one or two reference frames per list.

[0430] Table 12 shows the modified portion of the slice header

[0431]

[0432]

[0433] Avoid signaling of additional reference frames when the number of blocks in a slice is equal to the number of blocks in a picture and the number of blocks in a picture is greater than 1

[0434] In one embodiment, when the number of blocks in the current picture is greater than one and when the number of blocks in a slice is equal to the number of blocks in the current picture, overwriting of a reference frame is not signaled in the slice header. In this case, it is ensured that the current picture contains only one slice. Table 13 illustrates this embodiment. Furthermore, in an embodiment, the syntax for overwriting a reference frame that is not signaled (i.e., encoded or decoded) does not require that raster scan slice mode be enabled. That is, even when raster scan slice mode is not enabled, the syntax for overwriting a reference frame may not be signaled.

[0435] Additionally, the definition of "num_ref_idx_active_override_flag" should be modified as follows:

[0436] "num_ref_idx_active_override_flag equal to 1 specifies that the syntax element num_ref_idx_active_minus1[0] is present for P and B slices and that the syntax element num_ref_idx_active_minus1[1] is present for B slices. num_ref_idx_active_override_flag equal to 0 specifies that the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1] are not present. When not present, And when raster scanning is not enabled When the number of blocks in the current image is not higher than 1, or when the number of blocks in the stripe is not equal to the current The number of blocks in the previous image , it is inferred that the value of num_ref_idx_active_override_flag is equal to 1. Otherwise, when When not present, and when raster scan striping mode is enabled, and the number of tiles in the current picture is higher than 1, and when striping When the number of blocks in the image is equal to the number of blocks in the current image, num_ref_idx_active_override_ The value of flag is equal to 0 .”

[0437] Table 13 shows the modified portion of the slice header

[0438]

[0439] In another embodiment, as depicted in Table 14, when the picture header is in the slice header, or when the raster scan slice mode is enabled, the number of blocks in the current picture is higher than 1, and when the number of blocks in the slice is equal to the number of blocks in the current picture, the overwriting of the reference frame is not signaled in the slice header.

[0440] Additionally, the definition of "num_ref_idx_active_override_flag" should be modified as follows:

[0441] "num_ref_idx_active_override_flag equal to 1 specifies that the syntax element num_ref_idx_active_minus1[0] is present for P and B slices and that the syntax element num_ref_idx_active_minus1[1] is present for B slices. num_ref_idx_active_override_flag equal to 0 specifies that the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1] are not present. When not present, And when raster scanning is not enabled When the stripe mode is selected, or the number of blocks in the current image is not greater than 1, or the number of blocks in the stripe is not equal to The number of blocks in the current picture, or when the slice header of the reference PPS does not contain the PH syntax structure , it is inferred that the value of num_ref_idx_active_override_flag is equal to 1. Otherwise, when not present, and when raster scan striping is enabled mode, the number of blocks in the current picture is higher than 1, and when the number of blocks in the slice is equal to the number of blocks in the current picture num_ref_idx_active_ The value of override_flag is equal to 0 .

[0442] Table 14 shows the modified portion of the slice header

[0443]

[0444] Force num_ref_idx_active_override_flag to be 0 when there is only one slice

[0445] In an embodiment, it is a bitstream requirement to set the flag num_ref_idx_active_override_flag to 0 when a picture contains only one slice. In practice, the encoder should not overwrite the reference picture list when a picture contains only one slice, because the reference picture list should only be written once. In terms of implementation, this simplifies slice header parsing.

[0446] Force num_ref_idx_active_override_flag to be 0 when PH is in SH

[0447] In one embodiment, when the picture header is in a slice header, it is a bitstream requirement to set the flag num_ref_idx_active_override_flag equal to 0. More precisely, when the flag picture_header_in_slice_header_flag is set equal to 1, the picture header is in a slice header.

[0448] When the number of blocks in a slice is equal to the number of blocks in a picture and the number of blocks in a picture is greater than 1, force num_ref_idx_active_override_flag to be equal to 0

[0449] In one embodiment, when raster scan stripe mode is enabled and the number of tiles in the current picture is higher than 1, and when the number of tiles in a slice is equal to the number of tiles in the current picture, setting the flag num_ref_idx_active_override_flag equal to 0 is a bitstream requirement.

[0450] In another embodiment, it is a bitstream requirement to set the flag num_ref_idx_active_override_flag equal to 0 when the picture header is in the slice header, or when raster scan slice mode is enabled, the number of blocks in the current picture is higher than 1, and when the number of blocks in the slice is equal to the number of blocks in the current picture. More precisely, when the flag picture_header_in_slice_header_flag is set equal to 1.

[0451] Avoid signaling of additional reference picture lists when the current picture list refers to an SPS reference picture list

[0452] In an embodiment, signaling of an additional reference picture list is allowed only when the reference picture list of each list refers to the reference picture list signaled in the SPS. In the current VVC specification, the reference picture list signaled in the SPS can be identified due to the variable rpl_sps_flag[0] for list L0 and the variable rpl_sps_flag[1] for list L1. Table 15 shows this embodiment, where the syntax element num_ref_idx_active_override_flag is extracted from the bitstream if the slice type is P or B and the number of reference frames of L0 is higher than 1 and if the reference picture list of L0 is signaled in the SPS, or if the slice type is B and the number of reference frames of L1 is higher than 1 and if the reference picture list of L1 is signaled in the SPS. In the same way, if this flag is true, the number of reference activations for L0 decoding is decremented by 1 if the slice type is P or B and the number of reference frames for L0 is higher than 1 and if the reference picture list for L0 is signaled in the SPS, or if the slice type is B and the number of reference frames for L1 is higher than 1 and if the reference picture list for L1 is signaled in the SPS.

[0453] Table 15 shows the modified portion of the slice header

[0454]

[0455] In one embodiment, the reference picture lists signaled in the SPS can be identified by the variable num_ref_pic_lists_in_sps[0] for list L0 and the variable num_ref_pic_lists_in_sps[1] for list L1. This variable gives the number of lists signaled in the SPS. When it is equal to 0, it means that no reference picture lists exist in the SPS. Therefore, this variable does not provide information about the current reference picture list signaled, but rather provides information about all reference picture lists using the same SPS. Table 16 shows this embodiment.

[0456] Table 16 shows the modified partial slice header

[0457]

[0458] In the same way, num_ref_pic_lists_in_sps[1] can be replaced by the variable rpl1_idx_present_flag.

[0459] In an embodiment, the reference picture list signaled in the SPS can be identified by comparing RplsIdx[i] with num_ref_pic_lists_in_sps[i]. For list i, when the reference picture list index RplsIdx[i] is equal to the number of reference picture lists sent in the SPS (num_ref_pic_lists_in_sps[i]), it is determined that the reference picture list has been sent in the current picture or slice and does not refer to the reference picture list sent in the SPS. This embodiment provides better accuracy than the previous embodiment.

[0460] Additional conditions for only one stripe

[0461] In another embodiment, signaling of additional reference picture lists is permitted only when the reference picture lists of the respective lists refer to the reference picture lists signaled in the SPS and when at least one syntax element indicates that the current picture may contain more than one slice. In practice, when a picture contains one slice, the encoder should not overwrite the reference picture list explicitly signaled in the slice header or picture header. However, if a reference picture list signaled in the SPS is used, it may be advantageous to overwrite it to limit the number of reference pictures. However, in terms of coding efficiency tradeoffs for practical applications, it is preferable to avoid such overwriting to save bits associated with its signaling. Furthermore, this simplifies slice header parsing for some implementations.

[0462] Other conditions of pH in SH

[0463] In another embodiment, signaling of an additional reference picture list is allowed only when the reference picture list of each list refers to the reference picture list signaled in the SPS and when the picture header is not in the slice header. More specifically, as depicted in Table 17, when the flag picture_header_in_slice_header_flag is set to 1, the syntax elements "num_ref_idx_active_override_flag" and "num_ref_idx_active_minus1[i]" are not sent.

[0464] Table 17 shows the modified partial slice header

[0465]

[0466]

[0467] The advantage is that coding efficiency is improved when the picture is in the slice header. In fact, signaling the picture header in the slice header is efficient for low-delay and low-bitrate applications, in which case the cost of overwriting the flags for multiple pictures is greater than the cost of setting up several reference picture lists in the SPS.

[0468] Other conditions where the number of blocks in a stripe is equal to the number of blocks in the picture and the number of blocks in the picture is greater than 1

[0469] In an additional embodiment, signaling of additional reference frames is allowed only when the reference frame lists of the respective lists refer to the reference picture lists signaled in the SPS and when raster scan slice mode is disabled or the number of tiles in the current picture is equal to 1 or the number of tiles in a slice is not equal to the number of tiles in the current picture. In this case, the current picture is determined to contain only one slice. This can be achieved by changing !picture_header_in_slice_header_flag to (!(!rect_slice_flag && NumTilesInPic > 1 && num_tiles_in_slice_minus1 == ) in Table 17.

[0470] NumTilesInPic-1) to achieve this.

[0471] Signaling conditional on the reference picture list (RPL) sent in the slice header

[0472] In an embodiment, signaling of an additional reference picture list is allowed only when the reference picture list of each list refers to the reference picture list signaled in the SPS and when the reference picture list is not sent in the slice header. The advantage is that coding efficiency is improved because if the reference picture list is explicitly sent in the slice header, there is no need to update the reference picture list.

[0473] Avoid signaling of additional reference picture lists using syntax elements sent in higher levels

[0474] In one embodiment, signaling of an additional reference picture list is allowed only when the advanced flag indicates that the reference picture list may be overwritten in the slice header.

[0475] Table 18 shows a possible implementation of this embodiment, where the flag high_level_slice_rpl_override_enabled_flag specifies that num_ref_idx_active_override_flag can be decoded to overwrite the current reference picture list if necessary when it is equal to 1. Otherwise, num_ref_idx_active_override_flag is not decoded.

[0476] Table 18 shows the modified partial slice header

[0477]

[0478]

[0479] The semantics of this flag shall be defined as follows:

[0480] “ high_level_slice_rpl_override_enabled_flag is equal to 1 to specify that the slice header can be Override reference picture list syntax element. high_level_slice_rpl_override_enabled_flag equal to 0 specifies The reference picture list syntax element cannot be overwritten in the slice header. When it is not present, it is inferred to be equal to 0 .”

[0481] An advantage of this embodiment is greater flexibility compared to previous embodiments with similar coding efficiency improvements.

[0482] Signaling in SPS

[0483] In an embodiment, high_level_slice_rpl_override_enabled_flag is sent in the SPS. In this embodiment, the name of the flag is sps_slice_rpl_override_enabled_flag.

[0484] Decoding conditional on num_ref_pic_lists_in_sps[i]

[0485] In an embodiment, the decoding of sps_slice_rpl_override_enabled_flag depends on the number of reference picture lists for each list. When both are equal to 0, sps_slice_rpl_override_enabled_flag is not decoded. In practice, when there are no reference picture lists in the SPS, the reference picture lists are sent for each picture or each slice. Therefore, there is no need to overwrite this information.

[0486] Do not decode or infer flags when there is only one slice

[0487] In an embodiment, when there is more than one slice in a picture referencing the current SPS, sps_slice_rpl_override_enabled_flag is not decoded and / or inferred to be equal to 1. The use of only one slice may depend on signaling syntax elements in the picture header or when the number of blocks in the picture is the same as the number of blocks in the slice.

[0488] Do not decode or infer flags when rpl is in SH

[0489] In an additional embodiment, when the reference picture list is sent in the slice header, the sps_slice_rpl_override_enabled_flag is not decoded. In this case, the flag rpl_info_in_ph_flag is set to 0. In fact, if the reference picture list is sent in the slice header (rpl_info_in_ph_flag is equal to 0) and the reference picture list is not sent in the SPS, it is guaranteed that the reference picture list is sent for each slice. Therefore, there is no need to overwrite this information. Table 19 shows this embodiment.

[0490] Table 19 shows the modified partial SPS

[0491]

[0492] Signaling in PPS

[0493] In one embodiment, high_level_slice_rpl_override_enabled_flag is sent in the PPS. In this embodiment, the name of the flag is pps_slice_rpl_override_enabled_flag.

[0494] Decoding conditional on num_ref_pic_lists_in_sps[i]

[0495] In an embodiment, the decoding of pps_slice_rpl_override_enabled_flag depends on the number of reference picture lists for each list. When both are equal to 0, pps_slice_rpl_override_enabled_flag is not decoded. In practice, when there are no reference picture lists in the SPS, the reference picture lists are sent for each picture or each slice. Therefore, there is no need to overwrite this information.

[0496] Do not decode or infer flags when there is only one slice

[0497] In an additional embodiment, when more than one slice is present in a picture referencing the current PPS, pps_slice_rpl_override_enabled_flag is not decoded and / or inferred to be equal to 1. The use of only one slice may depend on syntax elements signaling the sending of a picture header in a slice header or when the number of blocks in a picture is the same as the number of blocks in a slice.

[0498] Do not decode or infer flag when reference picture list (RPL) is in slice header (SH)

[0499] In an additional embodiment, when the reference picture lists are sent in the slice header, the pps_slice_rpl_override_enabled_flag is not decoded. In this case, the flag rpl_info_in_ph_flag is set to 0. In fact, if the reference picture lists are sent in the slice header (rpl_info_in_ph_flag is equal to 0) and they are not the reference picture lists sent in the SPS, then the reference picture lists are guaranteed to be sent for each slice. Therefore, there is no need to overwrite this information. Table 20 shows this embodiment.

[0500] Table 20 shows the modified partial PPS

[0501]

[0502] Signaling in Video Parameter Set (VPS)

[0503] In an additional embodiment, a high_level_slice_rpl_override_enabled_flag is sent in the VPS. In this embodiment, the name of the flag is vps_slice_rpl_override_enabled_flag.

[0504] Signaling in the Picture Header (PH)

[0505] In an additional embodiment, the high_level_slice_rpl_override_enabled_flag is sent in the picture header. In this embodiment, the name of the flag is ph_slice_rpl_override_enabled_flag.

[0506] Decoding conditional on num_ref_pic_lists_in_sps[i]

[0507] In an additional embodiment, the decoding of the ph_slice_rpl_override_enabled_flag depends on the number of reference picture lists for each list. When both of these numbers are equal to 0, the ph_slice_rpl_override_enabled_flag is not decoded. In practice, when there are no reference picture lists in the SPS, the reference picture lists are sent for each picture or each slice. Therefore, there is no need to overwrite this information.

[0508] Do not decode or infer flags when there is only one slice

[0509] In an additional embodiment, when more than one slice is present in the picture referencing the current picture header, ph_slice_rpl_override_enabled_flag is not decoded and / or inferred to be equal to 1. The use of only one slice may depend on syntax elements signaling the sending of the picture header in the slice header or when the number of blocks in the picture is the same as the number of blocks in the slice.

[0510] Do not decode or infer flags when rpl is in slice header (SH)

[0511] In an additional embodiment, when the reference picture lists are sent in the slice header, the ph_slice_rpl_override_enabled_flag is not decoded. In this case, the flag rpl_info_in_ph_flag is set to 0. In practice, if the reference picture lists are sent in the slice header (rpl_info_in_ph_flag is equal to 0) and they are not the reference picture lists sent in the picture header, then the reference picture lists are guaranteed to be sent for each slice, so there is no need to overwrite this information. Table 21 shows an implementation of this embodiment.

[0512] Table 21 shows the modified part of the picture header

[0513]

[0514] Examples related to LMC and zoom lists

[0515] Avoid signaling of XXX active flag when only one stripe

[0516] In one embodiment, when the current picture contains only one slice, the following syntax element sent in the slice header, which enables or specifies the presence of tool (or parameter) XXX and depends on at least one variable in the picture header that enables or specifies the presence of the tool (or parameter) XXX, is not sent in the slice header.

[0517] An advantage of this embodiment is that coding efficiency is improved since syntax elements are not sent when not needed.In fact, when the current picture contains only one slice, there is no additional flexibility to signal in the picture header and then in the slice header.

[0518] Avoid signaling of XXX activation flag when PH is in SH

[0519] In an embodiment, when a picture header is in a slice header, a syntax element sent in a slice header that enables or specifies the presence of a tool (or parameter) and depends on at least one variable in the picture header that enables or specifies the presence of the tool is not sent in the slice header.

[0520] An advantage of this additional embodiment is that coding efficiency is improved when the picture is in the slice header. In fact, picture headers in the slice header are efficient for low-delay and low-bitrate applications, where signaling at the slice level has a significant cost in terms of global bitrate.

[0521] Table 22 shows the implementation of this embodiment.

[0522] Avoid signaling of XXX flag when blocks in slice equal blocks in picture and number of blocks in picture is greater than 1

[0523] In an embodiment, when raster scan strip mode is enabled and the number of tiles in the current picture is higher than 1, and when the number of tiles in the slice is equal to the number of tiles in the current picture, a syntax element sent in the slice header that enables or specifies the presence of a tool and depends on at least one variable in the picture header that enables or specifies the presence of the tool is not sent in the slice.

[0524] This embodiment can be implemented by changing the two conditions “&&!picture_header_in_slice_header_flag” in Table 22 to “&&(!(!rect_slice_flag&&NumTilesInPic>1&&num_tiles_in_slice_minus1==NumTilesInPic-1)))”.

[0525] Predict slice_XXX_flag from the value ph_XXX_flag

[0526] In an embodiment, when the following syntax element sent in the slice header is not sent due to the conditions defined above, where the value of the syntax element is predicted by the value of the variable sent or obtained in the picture header, the syntax element enables or specifies the presence of a tool (or parameter) and depends on at least one variable in the picture header that enables or specifies the presence of the tool (or parameter).

[0527] XXX is LMCS

[0528] In an embodiment, due to the conditions defined above, the syntax element slice_lmcs_enabled_flag to enable LMCS at the slice level is not sent.

[0529] Table 22 shows this embodiment when the condition is that the picture header is in the slice header.

[0530] In addition, when the conditions defined above are met, the variable slice_lmcs_enabled_flag is predicted by the value of ph_lmcs_enabled_flag. For example, for the condition that the picture header is in the slice header, slice_lmcs_enabled_flag is defined as follows:

[0531] "slice_lmcs_enabled_flag equal to 1 specifies that luma mapping with chroma scaling is enabled for the current slice. slice_lmcs_enabled_flag equal to 0 specifies that luma mapping with chroma scaling is not enabled for the current slice. When slice_lmcs_enabled_flag is not present, And when the slice header of the reference PPS does not contain the PH syntax structure , inferring it to be equal to 0. When the slice header of the reference PPS contains the PH syntax structure, slice_lmcs_enabled_flag, etc. are inferred ph_lmcs_enabled_flag .”

[0532] Table 22 shows the modified partial slice header

[0533]

[0534] XXX is the zoom list

[0535] In one embodiment, due to the conditions defined above, the syntax element slice_scaling_list_present_flag specifying that a scaling list is present for the current slice is not sent.

[0536] Table 23 shows the implementation of this embodiment when the condition is that the picture header is in the slice header.

[0537] In addition, when the conditions defined above are met, the variable slice_scaling_list_present_flag is predicted by the value of ph_scaling_list_present_flag. For example, for the condition "picture header is in slice header", slice_lmcs_enabled_flag is defined as follows:

[0538] "slice_scaling_list_present_flag equal to 1 specifies that the scaling list data for the current slice is derived based on the scaling list data contained in the referenced scaling list APS (where aps_params_type is equal to SCALING_APS and adaptation_parameter_set_id is equal to ph_scaling_list_aps_id). slice_scaling_list_present_flag equal to 0 specifies that the scaling list data for the current picture is the default scaling list data derived as specified in clause 7.4.3.21. When not present, And when the slice header of the reference PPS does not contain PH syntactic structure , it is inferred that the value of slice_scaling_list_present_flag is equal to 0. When referring to the PPS slice header When PH syntax structures are included, slice_lmcs_enabled_flag is inferred to be equal to ph_scaling_list_present_ flag .”

[0539] In an embodiment, the proposed restriction on the variable XXX is applied to both slice_lmcs_enabled_flag and slice_scaling_list_present_flag.

[0540] In an embodiment, when a picture header is in a slice header, or when raster scan slice mode is disabled or the number of blocks in the current picture is equal to 1 or the number of blocks in the slice is not equal to the number of blocks in the current picture, a syntax element sent in a slice header that enables or specifies the presence of a tool and depends on at least one variable in the picture header that enables or specifies the presence of the tool is not sent in the slice header. Table 23 shows an implementation of this embodiment.

[0541] In another embodiment, slice_lmcs_enabled_flag and slice_scaling_list_present_flag are sent in the slice header, which enable LMCS and specify the presence of scaling lists, respectively, and depend on ph_lmcs_enabled_flag and ph_scaling_list_present_flag in the picture header, respectively. When the picture header is in the slice header or when the raster scan slice mode is disabled or the number of blocks in the current picture is equal to 1 or the number of blocks in the slice is not equal to the number of blocks in the current picture, slice_lmcs_enabled_flag and slice_scaling_list_present_flag are not sent in the slice header.

[0542] Table 23 shows the modified partial slice header

[0543]

[0544]

[0545] Bitstream constraint when slice_XXX_flag is equal to ph_XXX_flag when there is only one slice

[0546] In an embodiment, when the current picture contains only one slice, a syntax element is sent in the slice header that enables or specifies the presence of a tool or parameter XX and depends on at least one variable in the picture header that enables or specifies the presence of the tool. When there is only one slice, bitstream conformance requirements may appropriately cause the syntax element in the slice header to have the same value as the syntax element in the picture header that enables or specifies the presence of the same tool or parameter.

[0547] Bitstream constraint that slice_XXX_flag is equal to ph_XXX_flag when PH is in SH

[0548] In one embodiment, when a picture header is in a slice header, a syntax element is sent in the slice header that enables or specifies the presence of a tool or parameter XXX and depends on at least one variable that enables or specifies the presence of the tool in the picture header. That is, when the picture header is in a slice header, bitstream conformance requires that the syntax element in the slice header has the same value as the syntax element in the picture header that enables or specifies the presence of the same tool or parameter, as appropriate.

[0549] When the blocks in the slice are equal to the blocks in the picture and the number of blocks in the picture is greater than 1, the bitstream constraint that slice_XXX_flag is equal to ph_XXX_flag

[0550] In one embodiment, when raster scan slice mode is enabled and the number of blocks in the current picture is higher than 1, and when the number of blocks in a slice is equal to the number of blocks in the current picture, a syntax element is sent in the slice header that enables or specifies the presence of a tool or parameter XXX and depends on at least one variable in the picture header that enables or specifies the presence of the tool. When the number of blocks in a slice is equal to the number of blocks in a picture and the number of blocks in a picture is greater than 1, bitstream conformance requires that the syntax element in the slice header have the same value as the syntax element in the picture header, as appropriate.

[0551] XXX is LMCS

[0552] In one embodiment, the syntax element slice_lmcs_enabled_flag that enables LMCS at the slice level is systematically equal to ph_lmcs_enabled_flag when one of the conditions defined above is true.

[0553] For example, when the condition is "the picture header is in the slice header", slice_lmcs_enabled_flag is defined as follows:

[0554] "slice_lmcs_enabled_flag equal to 1 specifies that luma mapping with chroma scaling is enabled for the current slice. slice_lmcs_enabled_flag equal to 0 specifies that luma mapping with chroma scaling is not enabled for the current slice. When slice_lmcs_enabled_flag is not present, it is inferred to be equal to 0. When the slice header of the reference PPS contains the PH syntax structure When constructing, slice_lmcs_enabled_flag shall be equal to ph_lmcs_enabled_flag as a requirement for bitstream consistency. .”

[0555] XXX is the zoom list

[0556] In one embodiment, the syntax element slice_scaling_list_present_flag specifying the presence of a scaling list for the current slice is systematically equal to ph_scaling_list_present_flag when one of the conditions defined above is true.

[0557] For example, when the condition is "the picture header is in the slice header", slice_scaling_list_present_flag is defined as follows:

[0558] "slice_scaling_list_present_flag equal to 1 specifies that the scaling list data for the current slice is derived based on the scaling list data contained in the referenced scaling list APS with aps_params_type equal to SCALING_APS and adaptation_parameter_set_id equal to ph_scaling_list_aps_id. slice_scaling_list_present_flag equal to 0 specifies that the scaling list data for the current picture is the default scaling list data derived as specified in clause 7.4.3.21. When not present, the value of slice_scaling_list_present_flag is inferred to be equal to 0. When the slice header of the reference PPS contains the PH syntax structure, slice_scaling_ list_present_flag is equal to ph_scaling_list_present_flag. When the slice header of the reference PPS contains the PH sentence When using the lmcs_enabled_flag structure, slice_lmcs_enabled_flag shall be equal to ph_lmcs_enabled_flag. This is a requirement for bitstream consistency. beg .”

[0559] In an embodiment, this restriction is applied to LMCS and zoom lists.

[0560] In an embodiment, when a picture header is in a slice header, or when raster scan strip mode is enabled and the number of tiles in the current picture is higher than 1, and when the number of tiles in the slice is equal to the number of tiles in the current picture, a syntax element is sent in the slice header that enables or specifies the presence of a tool (or parameter) and depends on at least one variable enabling or specifying the presence of the tool (or parameter) in the picture header.

[0561] In an embodiment, when the picture header is in the slice header, or when the raster scan slice mode is enabled and the number of blocks in the current picture is higher than 1, and when the number of blocks in the slice is equal to the number of blocks in the current picture, slice_lmcs_enabled_flag and slice_scaling_list_present_flag are set, where slice_lmcs_enabled_flag and slice_scaling_list_present_flag respectively enable the LMCS and specify the presence of the scaling list and depend on ph_lmcs_enabled_flag and ph_scaling_list_present_flag, respectively, where ph_lmcs_enabled_flag and ph_scaling_list_present_flag respectively enable and specify the presence of the LMCS and the scaling list in the picture header.

[0562] Avoid signaling of XXX activation flags when due to flags sent in higher levels

[0563] In an embodiment, a syntax element sent in a slice header that enables or specifies the presence of a tool or parameter XXX is only sent if the high-level flag indicates that the syntax element is present.

[0564] Signal notifications in SPS, PPS, VPS, and PH

[0565] In an embodiment, the advanced flag is sent in the SPS or PPS or VPS or picture header. It is best to send the flag at the highest possible level.

[0566] Predict slice_XXX_flag from the value ph_XXX_flag

[0567] In an embodiment, a syntax element sent in a slice header is sent only if the advanced flag indicates that the syntax element is present and its value is predicted by the value of a variable sent or obtained in a picture header, wherein the syntax element enables or specifies the presence of a tool and depends on at least one variable in the picture header that enables or specifies the presence of the tool.

[0568] XXX is LMCS

[0569] In an embodiment, the syntax element slice_lmcs_enabled_flag to enable LMCS at the slice level is sent only if the advanced flags indicate that slice_lmcs_enabled_flag is present.

[0570] Table 24 shows this embodiment of the advanced flag sent in the SPS sps_override_slice_lmcs_enabled_flag.

[0571] Table 24 shows the modified partial slice header

[0572]

[0573] XXX is the zoom list

[0574] In an embodiment, when the advanced flags indicate that slice_scaling_list_present_flag is present, the syntax element slice_scaling_list_present_flag specifies that a scaling list is present for the current slice.

[0575] Table 24 shows this embodiment of the advanced flag sent in the SPS sps_override_slice_scaling_list_present_flag.

[0576] In an embodiment, the proposed restriction on the variable XXX is applied to both slice_lmcs_enabled_flag and slice_scaling_list_present_flag.

[0577] accomplish

[0578] Figure 11Systems 191 and 195 according to embodiments of the present invention are shown, comprising at least one of encoder 150 or decoder 100 and a communication network 199. According to embodiments, system 195 is configured to process and provide content (e.g., video and audio content for display / output or streaming) to a user, who accesses decoder 100, for example, via a user terminal including decoder 100 or a user interface of a user terminal capable of communicating with decoder 100. Such a user terminal may be a computer, mobile phone, tablet computer, or any other type of device capable of providing / displaying (provided / streamed) content to a user. System 195 obtains / receives bitstream 101 (in the form of a continuous stream or signal (e.g., when displaying / outputting earlier video / audio)) via communication network 199. According to embodiments, system 191 is configured to process content and store processed content, such as video and audio content processed for display / output / streaming at a later time. System 191 obtains / receives content comprising a raw image sequence 151, which is received and processed by encoder 150 (including filtering using a deblocking filter according to the present invention), and encoder 150 generates a bitstream 101 to be transmitted to decoder 100 via communication network 199. Bitstream 101 is then transmitted to decoder 100 in a variety of ways. For example, it can be pre-generated by encoder 150 and stored as data in a storage device in communication network 199 (e.g., on a server or cloud storage device) until a user requests content (i.e., bitstream data) from the storage device, at which point the data is transmitted / streamed from the storage device to decoder 100. System 191 may also include a content providing device for providing / streaming content information (e.g., the title of the content and other metadata / storage location data used to identify, select, and request the content) of the content stored in the storage device to the user (e.g., by transmitting data for a user interface to be displayed on a user terminal), and for receiving and processing user requests for content so that the requested content can be transmitted / streamed from the storage device to the user terminal. Alternatively, the encoder 150 generates the bitstream 101 and transmits / streams it directly to the decoder 100 when the user requests content. The decoder 100 then receives the bitstream 101 (or signal) and filters it using the deblocking filter according to the present invention to obtain / generate a video signal 109 and / or an audio signal, which the user terminal then uses to provide the requested content to the user.

[0579] Any step of the method / process according to the present invention or the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the step / function may be stored as one or more instructions or codes or programs or computer-readable media on one or more hardware-based processing units or sent via one or more hardware-based processing units and executed by one or more hardware-based processing units, such as a programmable computing machine, which may be a PC ("personal computer"), a DSP ("digital signal processor"), a circuit, a circuit system, a processor and memory, a general-purpose microprocessor or central processing unit, a microcontroller, an ASIC ("application-specific integrated circuit"), a field programmable logic array (FPGA), or other equivalent integrated or discrete logic circuit system. Thus, the term "processor" as used herein may refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein.

[0580] Embodiments of the present invention may also be implemented by various devices or apparatuses, including wireless handsets, integrated circuits (ICs), or JC collections (e.g., chipsets). Various components, modules, or units are described herein to illustrate functional aspects of apparatuses / devices configured to perform these embodiments, but they do not necessarily need to be implemented by different hardware units. Instead, the various modules / units may be combined in a codec hardware unit or provided by a collection of interoperable hardware units, including one or more processors in conjunction with appropriate software / firmware.

[0581] The embodiments of the present invention can be implemented by a computer of a system or device that reads and executes computer-executable instructions (e.g., one or more programs) recorded on a storage medium to perform one or more modules / units / functions in the above-described embodiments and / or includes one or more processing units or circuits for performing one or more functions in the above-described embodiments, and can be implemented by a method performed by a computer of the system or device, for example, reading and executing computer-executable instructions from a storage medium to perform one or more functions in the above-described embodiments and / or controlling one or more processing units or circuits to perform one or more functions in the above-described embodiments. The computer may include a network of separate computers or separate processing units to read and execute computer-executable instructions. The computer-executable instructions may be provided to the computer from a computer-readable medium such as a communication medium, for example, via a network or a tangible storage medium. The communication medium may be a signal / bit stream / carrier. Tangible storage media are “non-transitory computer-readable storage media” and may include, for example, a hard disk, random access memory (RAM), read-only memory (ROM), a storage device of a distributed computing system, an optical disk (such as a compact disk (CD), a digital versatile disk (DVD), or a Blu-ray disk (BD)). TM ), one or more of a flash memory device, a memory card, etc. At least some steps / functions may also be implemented in hardware by a machine or dedicated components such as an FPGA (“field programmable gate array”) or an ASIC (“application-specific integrated circuit”).

[0582] Figure 122 is a schematic block diagram of a computing device 2000 for implementing one or more embodiments of the present invention. The computing device 2000 may be a device such as a microcomputer, a workstation, or a lightweight portable device. The computing device 2000 includes a communication bus connected to the following: - a central processing unit (CPU) 2001, such as a microprocessor; - a random access memory (RAM) 2002 for storing executable code of the method of the embodiment of the present invention and registers suitable for recording variables and parameters required to implement the method for encoding or decoding at least a portion of an image according to the embodiment of the present invention, the storage capacity of which may be expanded, for example, by an optional RAM connected to an expansion port; - a read-only memory (ROM) 2003 for storing computer programs for implementing the embodiment of the present invention; - a network interface (NET) 2004, which is typically connected to a communication network through which digital data to be processed is transmitted or received. The network interface (NET) 2004 may be a single network interface, or may be composed of a group of different network interfaces (e.g., wired and wireless interfaces, or different kinds of wired or wireless interfaces). Under the control of a software application in 2001, data packets are written to a network interface for transmission or read from the network interface for reception; a user interface (UI) 2005, which can be used to receive input from a user or display information to a user; a hard disk (HD) 2006, which can be configured as a mass storage device; and an input / output module (IO) 2007, which can be used to receive and send data from and to external devices (such as a video source or display). Executable code can be stored in ROM 2003, on HD 2006, or on a removable digital medium such as a disk. According to a variation, the executable code of a program can be received via NET 2004 via a communications network for storage in one of the storage components of computing device 2000 (such as HD 2006) prior to execution. CPU 2001 is adapted to control and direct the execution of instructions or portions of software code of one or more programs according to embodiments of the present invention, the instructions being stored in one of the aforementioned storage components. For example, after power-up, CPU 2001 is capable of executing those instructions relating to a software application from main RAM memory 2002 after loading instructions from program ROM 2003 or HD 2006. Such a software application, when executed by CPU 2001, causes the steps of the method according to the invention to be performed.

[0583] It will also be appreciated that, according to other embodiments of the present invention, a decoder according to the above-described embodiments is provided in a user terminal such as a computer, a mobile phone (cellular phone), a tablet, or any other type of apparatus capable of providing / displaying content to a user (e.g., a display device). According to yet another embodiment, an encoder according to the above-described embodiments is provided in an image capture device that also includes a camera, a video camera, or a webcam (e.g., a closed-circuit television or video surveillance camera) for capturing and providing content for encoding by the encoder. See below. Figure 13 and 14 Two such examples are provided.

[0584] Web camera

[0585] Figure 13 21 is a diagram illustrating a network camera system 2100 including a network camera 2102 and a client device 2104 .

[0586] The network camera 2102 includes an imaging unit 2106 , an encoding section 2108 , a communication unit 2110 , and a control unit 2112 .

[0587] The network camera 2102 and the client device 2104 are connected to each other via the network 200 so as to be able to communicate with each other.

[0588] The camera unit 2106 includes a lens and an image sensor (eg, a charge coupled device (CCD) or a complementary metal oxide semiconductor (CMOS)), and captures an image of a subject and generates image data based on the image. The image may be a still image or a video image.

[0589] The encoding section 2108 encodes the image data by using the encoding method described above.

[0590] The communication unit 2110 of the network camera 2102 transmits the encoded image data encoded by the encoding section 2108 to the client device 2104 .

[0591] Furthermore, the communication unit 2110 receives commands from the client device 2104. The commands include commands for setting parameters for encoding by the encoding section 2108.

[0592] The control unit 2112 controls other units in the network camera 2102 according to the commands received by the communication unit 2110 .

[0593] The client device 2104 includes a communication unit 2114 , a decoding section 2116 , and a control unit 2118 .

[0594] The communication unit 2114 of the client device 2104 transmits a command to the network camera 2102 .

[0595] Furthermore, the communication unit 2114 of the client device 2104 receives the encoded image data from the network camera 2102 .

[0596] The decoding section 2116 decodes the encoded image data by using the decoding method described above.

[0597] The control unit 2118 of the client device 2104 controls other units in the client device 2104 according to user operations or commands received by the communication unit 2114 .

[0598] The control unit 2118 of the client device 2104 controls the display device 2120 to display the image decoded by the decoding section 2116 .

[0599] The control unit 2118 of the client device 2104 also controls the display device 2120 to display a GUI (Graphical User Interface) for specifying values of parameters of the network camera 2102 (including parameters used for encoding by the encoding section 2108 ).

[0600] The control unit 2118 of the client device 2104 also controls other units in the client device 2104 according to user operation input to the GUI displayed by the display device 2120 .

[0601] The control unit 2118 of the client device 2104 controls the communication unit 2114 of the client device 2104 according to user operation input to the GUI displayed by the display device 2120 to transmit a command for specifying the value of the parameter of the network camera 2102 to the network camera 2102 .

[0602] smartphone

[0603] Figure 14 2 is a diagram illustrating a smartphone 2200 .

[0604] The smartphone 2200 includes a communication unit 2202 , a decoding section 2204 , a control unit 2206 , a display unit 2208 , an image recording device 2210 , and a sensor 2212 .

[0605] The communication unit 2202 receives the encoded image data via the network 200 .

[0606] The decoding section 2204 decodes the encoded image data received by the communication unit 2202 .

[0607] The decoding section 2204 decodes the encoded image data by using the decoding method described above.

[0608] The control unit 2206 controls other units in the smartphone 2200 according to user operations or commands received by the communication unit 2202 .

[0609] For example, the control unit 2206 controls the display unit 2208 to display the image decoded by the decoding section 2204 .

[0610] Although the present invention has been described with reference to the embodiments, it will be understood that the present invention is not limited to the disclosed embodiments. It will be understood by those skilled in the art that various changes and modifications may be made without departing from the scope of the invention as defined in the appended claims. All features disclosed in this specification (including any appended claims, abstracts and drawings), and / or all steps of any method or process disclosed, may be combined in any combination, except for at least some mutually exclusive combinations of such features and / or steps. Unless expressly stated otherwise, each feature disclosed in this specification (including any appended claims, abstracts and drawings) may be replaced by alternative features for the same, equivalent or similar purposes. Therefore, unless expressly stated otherwise, each feature disclosed is merely an example of a general series of equivalent or similar features.

[0611] It should also be understood that any results of the above-described comparisons, determinations, evaluations, selections, performance, performance, or considerations (e.g., selections made during an encoding or filtering process) may be indicated in data in the bitstream (e.g., a flag or data indicating the results) or may be determined / inferred from data in the bitstream, such that the indicated or determined / inferred results may be used in processing rather than actually being compared, determined, evaluated, selected, performed, performed, or considered, for example, during a decoding process.

[0612] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

[0613] Reference signs appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

1. A method of decoding video data from a bit stream, in, The bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding one or more slices, the slice header including syntax elements to be used when decoding a slice, The method comprises: Parsing syntactic elements; and decoding video data from the bitstream, wherein, according to a value of a second flag indicating whether the picture header is present in the slice header, a first flag related to use of a scaling list for a slice is parsed from the slice header, and if the second flag indicates that the picture header is present in the slice header, parsing of the first flag is omitted; wherein, in a case where the second flag indicates that the picture header is present in the slice header, the value of the first flag is inferred from the value of a third flag related to a scaling list in the picture header, and Each slice includes multiple coding tree units, and each coding tree unit can have a size of 64×64.

2. The method according to claim 1, wherein The bitstream includes video data corresponding to one or more slices.

3. The method according to claim 1 or 2, wherein: According to the value of the second flag, a fourth flag related to the availability of luma mapping with chroma scaling, i.e., LMCS, is parsed from the slice header, and if the second flag indicates that the picture header is present in the slice header, parsing of the fourth flag is omitted.

4. A method according to any one of the preceding claims, wherein In the case that the number of blocks in a picture is greater than 1 and the number of blocks in the slice is equal to the number of blocks in the picture, the picture contains only one slice.

5. A method according to any one of the preceding claims, wherein The first flag indicates whether scaling list data obtained from the bitstream is used for the slice.

6. A method according to any one of the preceding claims, wherein In case the value of the first flag is 1, scaling list data obtained from the bitstream is used for the slice.

7. A method according to any one of the preceding claims, wherein The second flag is included in the slice header.

8. A method according to any one of the preceding claims, wherein The picture header is picture_header_structure().

9. An apparatus for decoding video data from a bit stream, wherein: The bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding one or more slices, the slice header including syntax elements to be used when decoding the slices, the apparatus comprising: Components for parsing syntactic elements; and means for decoding video data from said bitstream, wherein, according to a value of a second flag indicating whether the picture header is present in the slice header, a first flag related to use of a scaling list for a slice is parsed from the slice header, and if the second flag indicates that the picture header is present in the slice header, parsing of the first flag is omitted; wherein, in a case where the second flag indicates that the picture header is present in the slice header, the value of the first flag is inferred from the value of a third flag related to a scaling list in the picture header, and Each slice includes multiple coding tree units, and each coding tree unit can have a size of 64×64.

10. A method of encoding video data into a bit stream, in, The bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding one or more slices, the slice header including syntax elements to be used when decoding the slices, the method comprising: Encode syntactic elements; and encoding video data into said bitstream, wherein a first flag related to use of a scaling list for a slice is encoded into the slice header according to a value of a second flag indicating whether the picture header is present in the slice header, and the first flag is not encoded if the second flag indicates that the picture header is present in the slice header. wherein, in a case where the second flag indicates that the picture header is present in the slice header, the value of the first flag is inferred from the value of a third flag related to a scaling list in the picture header, and Each slice includes multiple coding tree units, and each coding tree unit can have a size of 64×64.

11. An apparatus for encoding video data into a bitstream, wherein: The bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding one or more slices, the slice header including syntax elements to be used when decoding the slices, the apparatus comprising: means for encoding syntactic elements; and means for encoding video data into said bitstream, wherein a first flag related to use of a scaling list for a slice is encoded into the slice header according to a value of a second flag indicating whether the picture header is present in the slice header, and the first flag is not encoded if the second flag indicates that the picture header is present in the slice header. wherein, in a case where the second flag indicates that the picture header is present in the slice header, the value of the first flag is inferred from the value of a third flag related to a scaling list in the picture header, and Each slice includes multiple coding tree units, and each coding tree unit can have a size of 64×64.

12. A computer-readable storage medium storing a computer program comprising executable instructions which, when executed by a processor, cause the method according to any one of claims 1 to 8 and 10 to be performed.

13. A computer program product comprising a computer program comprising executable instructions which, when executed by a processor, cause the method according to any one of claims 1 to 8 and 10 to be performed.

Images