Methods and apparatuses for encoding and decoding video data, computer-readable storage media, and computer program products

Abstract

A method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to one or more than one slice. The bitstream includes a picture header and a slice header, the picture header including syntax elements to be used when decoding one or more than one slice, and the slice header including syntax elements to be used when decoding the slice. Decoding includes parsing the syntax elements. The method includes: if one or more than one syntax elements indicating that the picture contains only one slice are parsed, omitting the parsing of one or more than one syntax elements for the slice related to the use or availability of decoding tools or parameters for the slice; and decoding the bitstream using the syntax elements.

Description

Technical Field

[0001] The present invention relates to video encoding and decoding, and more particularly to advanced syntax in a bitstream. Background Art

[0002] Recently, the Joint Video Exploration Team (JVET) (a collaborative team consisting of MPEG and ITU-T Study Group 16 VCEG) has started to study a new video coding standard called Versatile Video Coding (VVC). The goal of VVC is to provide a significant improvement in compression performance (i.e., typically twice that of the previous) over the existing HEVC standard and to be completed in 2020. The main target applications and services include, but are not limited to, 360-degree and high dynamic range (HDR) video. In summary, JVET has evaluated feedback from 32 organizations using formal subjective tests conducted by independent test laboratories. Some suggestions indicate that the compression efficiency is typically increased by 40% or more when compared with using HEVC. Specific effects have been shown on ultra-high definition (UHD) video test materials. Therefore, for the final standard, we can expect the improvement in compression efficiency to far exceed the targeted 50%.

[0003] The JVET Exploration Model (JEM) uses all HEVC tools and has introduced several new tools. These changes require a change in the structure of the bitstream, especially the advanced syntax that may affect the total bit rate of the bitstream. Summary of the Invention

[0004] The present invention relates to an improvement in an advanced syntax structure, which achieves a reduction in complexity and / or signaling without any significant degradation in coding performance.

[0005] In a first aspect according to the present invention, there is provided a method for decoding video data from a bitstream, 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 one or more slices, the slice header including syntax elements to be used when decoding a slice, the decoding including: parsing the syntax elements, and if one or more syntax elements indicating that the picture contains only one slice are parsed, omitting the parsing of one or more syntax elements for the slice related to the use or availability of decoding tools or parameters for the slice; and decoding the bitstream using the syntax elements. In another aspect according to the present invention, there is provided a method for decoding video data from a bitstream, 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 one or more slices, the slice header including syntax elements to be used when decoding a slice, the bitstream being constrained such that in the case where the bitstream includes a syntax element having a value indicating that the picture contains only one slice, the bitstream includes a syntax element indicating the omission of the 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 including decoding the bitstream using the syntax elements. Thus, an encoding efficiency improvement 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.

[0006] Syntax elements related to the use or availability of decoding tools or parameters can be signaled in a Picture Parameter Set (PPS) or a Sequence Parameter Set (SPS).

[0007] 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 an encoding efficiency improvement when the picture is in the slice header. In fact, for low-latency and low-bitrate applications, signaling the picture header in the slice header is efficient. In this case, the cost of the overwrite flag for multiple pictures is greater than the setup cost of a set of several reference picture lists in the SPS. In fact, typically for these use cases, the amount of reference frames is limited to one or two reference frames per list.

[0008] One or more syntax elements indicating that the current picture contains only one strip include a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the strip, and wherein the number of blocks in the picture is greater than one and the number of blocks in the strip is equal to the number of blocks in the picture indicates that the current picture contains only one strip.

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

[0010] The decoding tools or parameters may be related to LCMS, and the syntax element includes an activation flag for LCMS.

[0011] The decoding tools or parameters may be related to the scaling list, and the syntax element includes an activation flag for the scaling list.

[0012] In 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 strips, wherein the bitstream includes a picture header and a strip header, the picture header includes syntax elements to be used when decoding one or more strips, the strip header includes syntax elements to be used when decoding a strip, and the decoding includes: parsing the syntax elements, and in the case where one or more syntax elements indicating that the picture contains only one strip are parsed, setting the values of one or more syntax elements for the strip related to the overriding of the reference picture list decoding tools or parameters to indicate no overriding of the reference picture list for the strip; and decoding the bitstream using the syntax elements. In terms of the implementation of decoding, this simplifies the strip header parsing.

[0013] One or more syntax elements indicating that the current picture contains only one strip may include a syntax element of the picture header in the strip header, and the syntax element of the picture header in the strip header indicates signaling the picture header in the strip header.

[0014] Each strip may include one or more blocks, and the syntactic elements indicating that the current picture contains only one strip may include the syntactic elements indicating the number of blocks in the current picture and the syntactic elements indicating the number of blocks in the strip, where the number of blocks in the picture is greater than one and the number of blocks in the strip being equal to the number of blocks in the picture indicates that the current picture contains only one strip.

[0015] In a third aspect according to the present invention, there is provided a method for decoding video data from a bitstream, the bitstream including video data corresponding to one or more strips, wherein the bitstream includes a picture header and a strip header, the picture header including syntactic elements to be used when decoding one or more strips, the strip header including syntactic elements to be used when decoding a strip, the decoding including: parsing the syntactic elements, and if the syntactic elements in the picture header indicate that the picture header is signaled in the strip header, setting values of one or more syntactic elements for the strip related to overriding of reference picture list decoding tools or parameters to indicate no overriding of the reference picture list for the strip; and decoding the bitstream using the syntactic elements.

[0016] In a fourth aspect according to the present invention, there is provided a method for decoding video data from a bitstream, the bitstream including video data corresponding to one or more strips, wherein the bitstream includes a picture header and a strip header, the picture header including syntactic elements to be used when decoding one or more strips, the strip header including syntactic elements to be used when decoding a strip, the decoding including: parsing the syntactic elements, and if the syntactic elements indicating the number of blocks in the current picture and the syntactic elements indicating the number of blocks in the strip are parsed, and the number of blocks in the picture is greater than one and the number of blocks in the strip is equal to the number of blocks in the picture, setting values of one or more syntactic elements for the strip related to overriding of reference picture list decoding tools or parameters to indicate no overriding of the reference picture list for the strip; and decoding the bitstream using the syntactic elements.

[0017] In at least the second to fourth aspects, the syntactic elements related to overriding of the reference picture list decoding tool may include flags, and setting the flag to not enabled indicates no overriding of the reference picture list.

[0018] In a fifth aspect according to the present invention, a method for decoding video data from a bitstream is provided. The bitstream includes video data, and the video data includes a picture sequence having one or more than one strip. Wherein the bitstream includes one or more than one syntax element, and the decoding includes: parsing one or more than one syntax element indicating whether the reference picture list of the picture to be decoded refers to the reference picture list of the sequence parameter set (SPS); if one or more than one syntax element indicates that the reference picture list of the picture to be decoded does not refer to the reference picture list of the sequence parameter set (SPS), omitting one or more than one syntax element related to the overwrite of the reference picture list of the strip of the picture during parsing in the strip header; and decoding the bitstream using the syntax element. Therefore, parsing can be simplified and unnecessary syntax elements can be avoided.

[0019] Omitting the parsing of one or more than one syntax element related to the overwrite of the reference picture list may also require that the picture has only one strip. When a picture contains one strip, the encoder generally should not overwrite the reference picture list explicitly sent in the strip header or picture header. However, if the reference picture list sent in the SPS is used, it is beneficial to overwrite the list to limit the number of reference pictures. However, surprisingly, in terms of the coding efficiency trade-off in practical applications, it is preferred to avoid such overwriting to save the bits related to its signaling. In addition, the strip header parsing of some implementations is simplified.

[0020] The one or more than one syntax element may include a syntax element of the picture header in the strip header, and this syntax element of the picture header in the strip header indicates whether the picture header is signaled in the strip header, and the omission also requires that the picture header is signaled in the strip header. The advantage is that the coding efficiency is improved when the picture is in the strip header. In fact, signaling the picture header in the strip header is efficient for low-latency and low-bitrate applications, in which case the cost of the overwrite flag for multiple pictures is greater than the cost of setting several reference picture lists in the SPS.

[0021] Each strip may include one or more than one block, and the one or more than one syntax element is a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the strip, and the omission requires that the number of blocks in the picture is greater than one and the number of blocks in the strip is equal to the number of blocks in the picture. Therefore, this gives an effective way to determine whether a picture has only one strip.

[0022] If the reference picture list is signaled in the strip header, the parsing of one or more than one syntax element related to the overwrite of the reference picture list is omitted. The advantage is that the coding efficiency is improved because if the reference picture list is explicitly sent in the strip header, there is no need to update the reference picture list.

[0023] In a sixth aspect according to the present invention, there is provided a method for decoding video data from a bitstream, the bitstream including video data, the video data including a picture sequence having one or more than one strip, wherein the bitstream includes one or more than one syntax element, and the decoding includes: parsing a high-level syntax element at a level above the strip in the bitstream, the high-level syntax element indicating whether to permit the use or availability of a decoding tool or parameter at the strip level; if the high-level syntax element indicates that the use or availability of a decoding tool or parameter at the strip level is not permitted, omitting parsing or inferring one or more than one syntax element for the strip header that indicates the use or availability of a decoding tool or parameter for the strip; and decoding the bitstream using the syntax element. In another aspect according to the present invention, there is provided a method for decoding video data from a bitstream, the bitstream including video data, the video data including a picture sequence having one or more than one strip, wherein the bitstream includes one or more than one syntax element, and the bitstream is constrained such that in the case where the bitstream includes a high-level syntax element (the high-level syntax element indicating whether to permit the use or availability of a decoding tool or parameter at the strip level) at a level above the strip in the bitstream, if the high-level syntax element indicates that the use or availability of the decoding tool or parameter at the strip level is not permitted, the bitstream further includes a syntax element indicating that parsing or inferring one or more than one syntax element for the strip header that indicates the use or availability of a decoding tool or parameter for the strip is to be omitted, and the method includes decoding the bitstream using the syntax element. Thus, a more flexible implementation can be provided compared to the previous aspect, but with a similar improvement in coding efficiency.

[0024] The high-level syntax element may be signaled in one or more than one of a sequence parameter set (SPS), a picture parameter set (PPS), a video parameter set (VPS), and a picture header (PH).

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

[0026] If a picture has only one strip, the high-level syntax element may not be decoded.

[0027] The decoding tool or parameter may be related to a reference picture list. If a reference picture list is signaled in the strip header, the high-level syntax element may not be decoded.

[0028] Syntactic elements indicating the use or availability of decoding tools or parameters may include activation flags. The decoding tools or parameters may be a luminance mapping (LMCS) tool with chroma scaling. The decoding tools or parameters 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 syntactic element indicates permission to indicate the use or availability of decoding tools or parameters 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 tools or parameters signaled in the picture header.

[0029] In a seventh aspect of the present invention, there is provided a method of decoding video data from a bitstream, the bitstream including video data, the video data including a picture sequence having one or more slices, and wherein the bitstream includes a picture header and a slice header, the picture header including syntactic elements to be used when decoding one or more slices, the slice header including syntactic elements to be used when decoding a slice, the decoding including: parsing the syntactic elements, and if the picture contains only one slice, restricting the value of one or more syntactic elements indicating the use or availability of one or more decoding tools or parameters for the slice in the picture to the same value as the corresponding syntactic elements indicating the use or availability of decoding tools or parameters signaled in the picture header of the picture containing the slice; and decoding the bitstream using the syntactic elements. In a further aspect of the present invention, there is provided a method of decoding video data from a bitstream, the bitstream including video data, the video data including a picture sequence having one or more slices, and wherein the bitstream includes a picture header and a slice header, the picture header including syntactic elements to be used when decoding one or more slices, the slice header including syntactic elements to be used when decoding a slice, the bitstream being constrained such that in the case where the bitstream includes a syntactic element having a value indicating that the picture contains only one slice, the value of one or more syntactic elements indicating the use or availability of one or more decoding tools or parameters for the slice in the picture is restricted to the same value as the corresponding syntactic elements indicating the use or availability of decoding tools or parameters signaled in the picture header of the picture containing the slice, the method including decoding the bitstream using the syntactic elements. The advantage is an improvement in coding efficiency because syntactic elements are not sent when they are not required. 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.

[0030] The method may further include parsing syntax elements of a picture header in a slice header, wherein if the syntax elements of the picture header in the slice header indicate that the picture header is signaled in the slice header, the picture contains only one slice. The advantage is an improved coding efficiency when the picture is in the slice header. In fact, having 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 the global bitrate.

[0031] Each slice may include one or more than one block, and the method may further include parsing 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 being greater than one and the number of blocks in the slice being equal to the number of blocks in the picture indicates that the current picture contains only one slice.

[0032] In an eighth aspect according to the present invention, a method of decoding video data from a bitstream is provided, the bitstream including video data, the video data including a picture sequence having one or more than one slice, 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 than one slice, the slice header including syntax elements to be used when decoding a slice, the decoding including: parsing the syntax elements, and if the picture header is signaled in the slice header, restricting the value of one or more than one syntax element indicating the use or availability of one or more than one decoding tool or parameter for the slice in the picture to the same value as the corresponding syntax element indicating the use or availability of the decoding tool or parameter signaled in the picture header of the picture containing the slice. In another aspect according to the present invention, a method of decoding video data from a bitstream is provided, the bitstream including video data, the video data including a picture sequence having one or more than one slice, 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 than one slice, the slice header including syntax elements to be used when decoding a slice, the bitstream being constrained such that in the case where the bitstream includes a syntax element having a value indicating that the picture header is signaled in the slice header, restricting the value of one or more than one syntax element indicating the use or availability of one or more than one decoding tool or parameter for the slice in the picture to the same value as the corresponding syntax element indicating the use or availability of the decoding tool or parameter signaled in the picture header of the picture containing the slice, the method including decoding the bitstream using the syntax elements.

[0033] In a ninth aspect according to 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 than one strip, wherein each strip may include one or more than one block, and wherein the bitstream includes a picture header and a strip header, the picture header including syntax elements to be used when decoding one or more than one strip, the strip header including syntax elements to be used when decoding a strip, the decoding including: parsing the syntax elements, and if the number of blocks in the picture being decoded is greater than one and the number of blocks in the strip is equal to the number of blocks in the picture, limiting the value of one or more than one syntax element indicating the use or availability of one or more than one decoding tool or parameter for the strip to the same value as the corresponding syntax element indicating the use or availability of the decoding tool or parameter signaled in the picture header of the picture containing the strip; and decoding the bitstream using the syntax elements.

[0034] In at least the seventh to ninth aspects, one or more than one decoding tool or parameter may include a Luminance Mapping with Chroma Scaling (LMCS) tool.

[0035] In at least the seventh to ninth aspects, one or more than one decoding tool or parameter may include a scaling list.

[0036] In a tenth aspect according to the present invention, a method for encoding video data into a bitstream is provided, the bitstream including video data corresponding to one or more than one strip, wherein the bitstream includes a picture header and a strip header, the picture header including syntax elements to be used when decoding one or more than one strip, the strip header including syntax elements to be used when decoding a strip, the encoding including: determining the syntax elements; if one or more than one syntax element indicating that the picture contains only one strip is determined, omitting encoding of one or more than one syntax element for the strip related to the use or availability of a decoding tool or parameter; and encoding the video data using the syntax elements.

[0037] Syntax elements related to the use or availability of a decoding tool or parameter may be signaled in a Picture Parameter Set (PPS).

[0038] One or more than one syntax element indicating that the current picture contains only one strip may include a syntax element in the picture header in the strip header, the syntax element in the picture header in the strip header indicating that the picture header is signaled in the strip header.

[0039] One or more syntax elements indicating that the current picture contains 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 contains only one slice.

[0040] Syntax elements related to the use or availability of decoding tools or parameters may include a flag for indicating the use of a decoding mode or parameter at the slice level, and may also include overriding the decoding mode or parameter at the slice level based on the value of a flag at the picture header level.

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

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

[0043] The decoding tool or parameter may include a scaling list, and the syntax element may include an activation flag for the scaling list.

[0044] In an eleventh aspect according to the present invention, there is provided a method of encoding video data into a bitstream, 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 includes syntax elements to be used when decoding one or more slices, the slice header includes syntax elements to be used when decoding a slice, and the encoding includes: determining syntax elements, and if one or more syntax elements indicating that the picture contains only one slice are determined, setting the values of one or more syntax elements for the slice related to overriding the decoding tool or parameter of the reference picture list to indicate that the reference picture list will not be overridden for the slice; and encoding the video data using the syntax elements.

[0045] One or more syntax elements indicating that the current picture contains only one slice may include a syntax element in the picture header within the slice header that indicates signaling of the picture header within the slice header.

[0046] Each strip may include one or more tiles, and a syntactic element indicating that the current picture contains only one strip may include a syntactic element indicating the number of tiles in the current picture and a syntactic element indicating the number of tiles in the strip, where the number of tiles in the picture is greater than one and the number of tiles in the strip being equal to the number of tiles in the picture indicates that the current picture contains only one strip.

[0047] In a twelfth aspect according to the present invention, there is provided a method of encoding video data into a bitstream, the bitstream including video data corresponding to one or more strips, wherein the bitstream includes a picture header and a strip header, the picture header including syntactic elements to be used when decoding one or more strips, the strip header including syntactic elements to be used when decoding a strip, the encoding including: determining syntactic elements, and if a syntactic element in the picture header indicates that the picture header is signaled in the strip header, setting values of one or more syntactic elements for the strip related to overriding of reference picture list decoding tools or parameters to indicate that the reference picture list will not be overridden for that strip; and encoding the video data using the syntactic elements.

[0048] In a thirteenth aspect according to the present invention, there is provided a method of encoding video data into an encoded bitstream, the bitstream including video data corresponding to one or more strips, wherein each strip may include one or more tiles, and wherein the bitstream includes a picture header and a strip header, the picture header including syntactic elements to be used when decoding one or more strips, the strip header including syntactic elements to be used when decoding a strip, the encoding including: determining syntactic elements, and if a syntactic element indicating the number of tiles in the current picture and a syntactic element indicating the number of tiles in the strip are determined, and the number of tiles in the picture is greater than one and the number of tiles in the strip is equal to the number of tiles in the picture, setting values of one or more syntactic elements for the strip related to overriding of reference picture list decoding tools or parameters to indicate that the reference picture list will not be overridden for that strip; and encoding the video data using the syntactic elements.

[0049] In at least the eleventh to thirteenth aspects, the syntactic elements related to overriding of the reference picture list decoding tools may include flags, and setting the flag to not enabled indicates that the reference picture list will not be overridden.

[0050] In a fourteenth aspect according to the present invention, there is provided a method for encoding video data into a bitstream, the bitstream including video data, the video data including a sequence of pictures having one or more than one strip, wherein the bitstream includes one or more than one syntax element, and the encoding includes: determining whether one or more than one syntax element of a reference picture list indicating a picture to be decoded refers to one or more than one syntax element of a sequence parameter set (SPS) reference picture list; if one or more than one syntax element indicates that the reference picture list of the picture to be decoded does not refer to the SPS reference picture list, omitting encoding one or more than one syntax element related to an override of the reference picture list of the strip of the picture in the strip header; and encoding the video data using the syntax element.

[0051] The parsing of omitting one or more than one syntax element related to the override of the reference picture list may also require that the picture has only one strip. The one or more than one syntax element includes a syntax element in the strip header of the picture header, the syntax element in the strip header of the picture header indicating whether the picture header is signaled in the strip header, and the omission requires that the picture header is signaled in the strip header. Each strip may include one or more than one block, and the one or more than one syntax element indicating that the current picture has only one strip includes a syntax element indicating the number of blocks in the current picture and a syntax element indicating the number of blocks in the strip, wherein the number of blocks in the picture is greater than one and the number of blocks in the strip is equal to the number of blocks in the picture.

[0052] If the reference picture list is signaled in the strip header, encoding one or more than one syntax element related to the override of the reference picture list may be omitted.

[0053] In a fifteenth aspect according to the present invention, there is provided a method for encoding video data into a bitstream, the bitstream including video data, the video data including a sequence of pictures having one or more than one strip, and the bitstream including one or more than one syntax element, and the encoding includes: encoding a high-level syntax element at a level higher than the strip level in the bitstream, the high-level syntax element indicating whether the use or availability of a decoding tool or parameter at the strip level is permitted; if the high-level syntax element indicates that the use or availability of a decoding tool or parameter at the strip level is not permitted, omitting encoding one or more than one syntax element indicating the use or availability of a decoding tool or parameter for the strip in the strip header; and encoding the video data using the syntax element.

[0054] The high-level syntax element may be signaled in one or more than one of a sequence parameter set (SPS), a picture parameter set (PPS), a video parameter set (VPS), and a picture header (PH).

[0055] Optionally, if the number of reference picture lists in the sequence parameter set (SPS) is zero, no high-level syntax elements are coded.

[0056] Optionally, if a picture has only one slice, no high-level syntax elements are coded.

[0057] Decoding tools or parameters can be related to the reference picture list. Optionally, if the reference picture list is signaled in the slice header, no high-level syntax elements are coded.

[0058] Syntax elements indicating the use or availability of decoding tools or parameters can include activation flags. Decoding tools or parameters can include a luminance mapping with chroma scaling (LMCS) tool. Decoding tools or parameters can include a scaling list.

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

[0060] In a sixteenth aspect according to the present invention, there is provided a method of encoding video data into a bitstream, the bitstream including video data, the video data including a picture sequence having 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 one or more slices, the slice header including syntax elements to be used when decoding a slice, the encoding including: parsing the syntax elements, and if a picture contains only one slice, limiting the value of one or more syntax elements indicating the use or availability of one or more decoding tools or parameters for the slice in the picture to the same value as the corresponding syntax element indicating the use or availability of decoding tools or parameters signaled in the picture header of the picture containing the slice; and encoding the video data using the syntax elements.

[0061] Optionally, the method can include encoding syntax elements of the picture header in the slice header, wherein if the syntax elements of the picture header in the slice header indicate that the picture header is signaled in the slice header, the picture contains only one slice.

[0062] Optionally, the method can include encoding syntax elements indicating the number of blocks in the current picture and syntax elements indicating the number of blocks in the slice, wherein the number of blocks in the picture being greater than one and the number of blocks in the slice being equal to the number of blocks in the picture indicates that the current picture contains only one block.

[0063] In a seventeenth aspect according to the present invention, there is provided a method of encoding video data into a bitstream, the bitstream including the video data, the video data including a picture sequence having one or more than one strip, wherein the bitstream includes a picture header and a strip header, the picture header including syntax elements to be used when decoding one or more than one strip, the strip header including syntax elements to be used when decoding a strip, the encoding including: determining syntax elements, and if the picture header is signaled in the strip header, limiting the value of one or more than one syntax element indicating the use or availability of one or more than one decoding tool or parameter for the strip in the picture to the same value as the corresponding syntax element indicating the use or availability of the decoding tool or parameter signaled in the picture header of the picture containing the strip; and encoding the video data using the syntax elements.

[0064] In an eighteenth aspect according to the present invention, there is provided a method of encoding video data into a bitstream, the bitstream including the video data, the video data including a picture sequence having one or more than one strip, wherein each strip may include one or more than one block, and wherein the bitstream includes a picture header and a strip header, the picture header including syntax elements to be used when decoding one or more than one strip, the strip header including syntax elements to be used when decoding a strip, the decoding including: determining syntax elements, and if the number of blocks in the picture being encoded is greater than one and the number of blocks in the strip is equal to the number of blocks in the picture, limiting the value of one or more than one syntax element indicating the use or availability of one or more than one decoding tool or parameter for the strip to the same value as the corresponding syntax element indicating the use or availability of the decoding tool or parameter signaled in the picture header of the picture containing the strip; and encoding the video data using the syntax elements.

[0065] One or more than one decoding tool or parameter may include a Luminance Mapping with Chroma Scaling (LMCS) tool.

[0066] One or more than one decoding tool or parameter may include a scaling list.

[0067] In a nineteenth aspect according to the present invention, there is provided an apparatus for decoding video data from a bitstream, the apparatus being configured to perform the method according to any one of the first aspect to the ninth aspect.

[0068] In a twentieth aspect according to the present invention, there is provided an apparatus for encoding video data into a bitstream, the apparatus being configured to perform the method according to any one of the tenth aspect to the eighteenth aspect.

[0069] In 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.

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

[0071] Any feature in one aspect of the present invention may be applied in any suitable combination to other aspects of the present invention. In particular, method aspects may be applied to apparatus aspects and vice versa.

[0072] Furthermore, features implemented in hardware may be implemented in software and vice versa. Any reference herein to software and hardware features shall be construed accordingly.

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

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

[0075] The present invention will now be described, by way of example, with reference to the accompanying drawings, in which:

[0076] Figure 1 is a diagram for illustrating the coding structures used in HEVC and VVC;

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

[0078] Figure 3 is a block diagram showing the components of a processing device in which one or more embodiments of the present invention may be implemented;

[0079] Figure 4 is a flowchart showing the steps of an encoding method according to an embodiment of the present invention;

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

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

[0082] Figure 7 Shows another structure of a bitstream in an exemplary coding system VVC;

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

[0084] Figure 9 Shows sub-tools of LMCS;

[0085] Figure 10 Is a diagram of the raster scan strip mode and the rectangular strip mode of the current VVC draft standard;

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

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

[0088] Figure 13 Is a diagram showing a network camera system; and

[0089] Figure 14 Is a diagram showing a smart phone. Detailed Description

[0090] Figure 1 Relates to a coding structure used in the High Efficiency Video Coding (HEVC) video standard. Video sequence 1 consists of a series of digital images i. Each such digital image is represented by one or more matrices. Matrix coefficients represent pixels.

[0091] The images 2 of the sequence can be segmented into strips 3. In some cases, a strip can constitute the entire image. These strips are segmented into non-overlapping Coding Tree Units (CTUs). A 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 units used in several previous video standards. A CTU is sometimes also referred to as a Largest Coding Unit (LCU). A CTU has luminance and chrominance component parts, and each component part is called a Coding Tree Block (CTB). These different color components are not shown in Figure 1 in.

[0092] A CTU is typically 64 pixels by 64 pixels. Quadtree decomposition can be used to iteratively divide each CTU into smaller variable-sized coding units (CUs) 5.

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

[0094] Each slice is embedded in a network abstraction layer (NAL) unit. Additionally, the coding parameters of the video sequence are stored in dedicated NAL units called parameter sets. In HEVC and H.264 / AVC, two types of parameter set NAL units are adopted: First, the sequence parameter set (SPS) NAL unit, which collects all the parameters that remain unchanged during the entire video sequence. Generally, it deals with the coding profile, the size of the video frames, 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 another. HEVC also includes a video parameter set (VPS) NAL unit, which contains parameters that describe the overall structure of the bitstream. The 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 sub-layers, and all version 1 bitstreams are limited to a single layer. HEVC has certain hierarchical extensions for scalability and multi-view, and these extensions will allow multiple layers with a backward-compatible version 1 base layer.

[0095] In the current definition of Versatile Video Coding (VVC), there are three high-level possibilities for partitioning of pictures: sub-pictures, slices, and tiles. Each has its own characteristics and usefulness. Partitioning into sub-pictures is for spatial extraction and / or merging of regions of the video. Partitioning into slices is based on a concept similar to that of previous standards and corresponds to sub-packets 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 independent coding regions of (almost) the same size of the picture. But this tool can also be used for other applications.

[0096] Since these three high-level available ways of picture partitioning can be used together, there are several modes for their use. As defined in the current draft specification of VVC, two modes for defining slices are defined. For the raster scan slice mode, a slice contains a complete sequence of tiles in the tile raster scan of the picture. This mode in the current VVC specification is inFigure 10 Shown in (a). As shown in the figure, the picture contains 18 by 12 luminance CTUs shown as partitioned into 12 stripes and 3 raster scan stripes.

[0097] For the second (rectangular stripe mode), the stripes contain several complete blocks that are jointly from a rectangular area of the picture. This mode in the current VVC specification is Figure 10 Shown in (b). In this example, the picture has 18 by 12 luminance TUs shown as partitioned into 24 blocks and 9 rectangular stripes.

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

[0099] The data stream 204 provided by the server 201 can be composed of multimedia data representing video and audio data. In some embodiments of the present invention, the audio and video data streams can be respectively captured by the server 201 using a microphone and a camera. In some embodiments, the data stream can 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 to provide a compressed bitstream for transmission, which is a more compact representation of the data presented as the input to the encoder.

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

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

[0102] Although a streaming scenario is considered in the Figure 2 example, it will be recognized that in some embodiments of the present invention, data communication between the encoder and the decoder can be performed using, for example, a media storage device (such as an optical disc, etc.).

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

[0104] Figure 3 Schematically illustrated is a processing device 300 configured to implement at least one embodiment of the present invention. 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 that is connected to:

[0105] - A central processing unit 311 represented as a CPU, such as a microprocessor;

[0106] - A read-only memory 306 represented as a ROM, which is used to store a computer program for implementing the present invention;

[0107] - A random access memory 312 represented as a RAM for storing executable code of the method of embodiments of the present invention, and registers suitable for recording variables and parameters that are required for implementing a method of encoding a digital image sequence and / or a method of decoding a bitstream according to embodiments of the present invention; and

[0108] - A communication interface 302 connected to a communication network 303, through which digital data to be processed is transmitted or received.

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

[0110] - A data storage component 304 such as a hard disk, which is used to store 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;

[0111] - A disk drive 305 for the disk 306, which is suitable for reading data from the disk 306 or writing data to the disk;

[0112] - A screen 309, which is used to display data by means of a keyboard 310 or any other indicating device and / or serves as a graphical interface for interacting with the user.

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

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

[0115] The disk 306 can be replaced by any information medium such as a rewritable or non-rewritable compact disk (CD-ROM), ZIP disk, or memory card, and in general, by an information storage component readable by a microcomputer or microprocessor. The disk 306 may or may not be integrated into the device, may be removable, and is adapted to store one or more programs whose execution enables the implementation of a method for encoding a digital image sequence and / or a method for decoding a bitstream according to the present invention.

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

[0117] The central processing unit 311 is adapted to control and direct the execution of instructions or portions of software code of one or more programs according to the present invention and the execution of instructions stored in one of the above storage components. When powered on, one or more programs stored in non-volatile memory (for example, 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 one or more programs) and registers for storing variables and parameters necessary for implementing the present invention.

[0118] In this embodiment, the device is a programmable device that uses software to implement the present invention. However, alternatively, the present invention can be implemented in hardware (for example, in the form of an application-specific integrated circuit or ASIC).

[0119] Figure 4 A block diagram illustrating an encoder according to at least one embodiment of the present invention. The encoder is represented by the 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 in an image sequence according to one or more embodiments of the present invention, for example, in the form of programming instructions executed by the CPU 311 of device 300.

[0120] The encoder 400 receives the original sequence 401 of digital images i 0 to i n as input. Each digital image is represented by a set of samples (referred to as pixels).

[0121] After the encoder 400 implements the encoding process, it outputs a bitstream 410. The bitstream 410 includes a plurality of coding units or strips. Each strip includes a strip header for transmitting the coded values of the coding parameters used for strip coding, and a strip body including coded video data.

[0122] Module 402 divides the input digital image i 0 to i n 401 into pixel blocks. The blocks correspond to image portions and can have variable sizes (e.g., 4×4, 8×8, 16×16, 32×32, 64×64, 128×128 pixels, and several rectangular block sizes can also be considered). An encoding mode is selected for each input block. Two families of encoding modes are provided: an encoding mode based on spatial prediction coding (intra prediction) and an encoding mode based on temporal prediction (inter prediction, merge, skip). The possible encoding modes are tested.

[0123] Module 403 implements intra prediction processing, where the block to be encoded is predicted by a predictor calculated based on the neighboring pixels of the given block to be encoded. If intra encoding is selected, the selected intra predictor and an indication of the difference between the given block and its predictor are encoded to provide a residual.

[0124] Temporal prediction is implemented by a motion estimation module 404 and a motion compensation module 405. First, a reference image from a reference image set 416 is selected, and a portion of the reference image (also referred to as a reference region or image portion), which is the region closest to the given block to be encoded, is selected by the motion estimation module 404. Then the motion compensation module 405 uses the selected region to predict the block to be encoded. The difference between the selected reference region and the given block (also referred to as the residual block) is calculated by the motion compensation module 405. The selected reference region is indicated by a motion vector.

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

[0126] In the intra prediction implemented by module 403, the prediction direction is encoded. In temporal prediction, at least one motion vector is encoded. In the inter 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 temporal prediction.

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

[0128] The encoder 400 further includes a selection module 406 that is used to select an encoding mode by applying an encoding cost criterion (such as, rate-distortion criterion, etc.). To further reduce redundancy, a transform (such as DCT, etc.) is applied to the residual block by the transform module 407. Then, the obtained transform data is quantized by the quantization module 408 and entropy encoded by the entropy encoding module 409. Finally, the encoded residual block of the currently encoded block is inserted into the bitstream 410.

[0129] The encoder 400 also decodes the encoded image to generate a reference image for motion estimation of subsequent images. This enables the encoder and decoder that receive the bitstream to have the same reference frames. The inverse quantization module 411 performs inverse quantization of the quantization data, followed by the inverse transform of 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 the module 412 to the reference region obtained from the set of reference images 416.

[0130] Then, post-filtering is applied by the module 415 to filter the reconstructed pixel frame. In an embodiment of the present invention, the SAO loop filter is used, where a compensation offset is added to the pixel value of the reconstructed pixels of the reconstructed image.

[0131] Figure 5 A block diagram of a decoder 60 according to an embodiment of the present invention is shown. The decoder 60 can be used to receive data from an encoder. The decoder is represented by the connected modules, and each module is 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.

[0132] The decoder 60 receives a bitstream 61 including encoded units, and each encoded unit consists of a header containing information related to the encoded parameters and a body containing the encoded video data. The structure of the bitstream in VVC is described in more detail below with reference to Figure 6 As illustrated with respect to Figure 4 For a given block, the encoded video data is entropy encoded on a predetermined number of bits, and the index of the motion vector predictor is encoded. The received encoded video data is entropy decoded by the module 62. Then the residual data is dequantized by the module 63, and then the inverse transform is applied by the module 64 to obtain the pixel values.

[0133] The mode data for indicating an encoding mode is also entropy decoded, and based on this mode, an intra-type decoding or an inter-type decoding is performed on the encoded blocks of the image data.

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

[0135] 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. A motion vector predictor is added to the motion vector residual to obtain a motion vector by the motion vector decoding module 70.

[0136] The motion vector decoding module 70 applies motion vector decoding to each current block encoded 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 this actual value is used to apply inverse motion compensation by module 66. The reference image portion indicated by the decoded motion vector is extracted from the reference image 68 to apply inverse motion compensation 66. The motion vector field data 71 is updated with the decoded motion vector for inverse prediction of subsequent decoded motion vectors.

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

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

[0139] The bitstream 600 according to the VVC encoding system consists of a sequence of syntax elements and encoded data. The syntax elements and the 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 (representing Real-time Transport Protocol / Internet Protocol), ISO base media file format, etc. The network abstraction layer also provides a framework for packet loss resilience.

[0140] The NAL units are partitioned into video coding layer (VCL) NAL units and non-VCL NAL units. The VCL NAL units contain the actual encoded video data. The non-VCL NAL units contain additional information. This additional information can be parameters required to decode the encoded video data or supplementary data that can enhance the usability of the decoded video data. The NAL unit 606 corresponds to a slice and constitutes a VCL NAL unit of the bitstream.

[0141] The different NAL units 601 - 605 correspond to different parameter sets and these NAL units 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 thus 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.

[0142] The sequence parameter set (SPS) NAL unit 603 contains parameters defined for a video sequence. In particular, the SPS NAL unit can define the sub-picture layout of the video sequence and associated parameters. The parameters associated with each sub-picture specify the encoding constraints applied to the sub-picture. In particular, it includes a flag indicating that temporal prediction between sub-pictures is restricted to data from the same sub-picture. Another flag can enable or disable the loop filter across sub-picture boundaries.

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

[0144] The syntax of the PPS as proposed in the current version of VVC includes syntax elements that specify the size of the picture in terms of luminance samples and the partitioning of each picture into tiles and slices.

[0145] The PPS contains syntax elements that enable the determination of the slice positions in a frame. Since the sub-pictures form rectangular regions in the frame, the set of slices, tile parts, or tiles belonging to a sub-picture can be determined based on the parameter set NAL units. The PPS, like the APS, has an ID mechanism to limit the amount of the same PPS sent.

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

[0147] The bitstream can also contain supplementary enhancement information (SEI) NAL units ( Figure 6(not shown in the figure). The occurrence period of these parameter sets in the bitstream is variable. The VPS defined for the entire bitstream can occur only once in the bitstream. In contrast, the APS defined for a slice can occur once for each slice in each picture. In fact, different slices can depend on the same APS, and thus there are usually fewer APSs than slices in each picture. In particular, the APS is defined in the picture header. However, the ALF APS can be refined in the slice header.

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

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

[0150] Table 1 Syntax AUD

[0151]

[0152]

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

[0154] "pic_type indicates that the slice_type value for all slices of the encoded pictures in the AU containing the AUD NAL unit is a member of the set listed in Table 2 for a given pic_type value. The value of pic_type in the bitstream conforming to this version of the specification shall be equal to 0, 1, or 2. Other values of pic_type are reserved for future use by ITUT|ISO / IEC. Decoders conforming to this version of the 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 parsed bitstream is an integer number of bytes.

[0156] Table 2 Interpretation 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 an encoded picture. A picture may refer to one or more APSs to indicate AFL parameters, shaper models, and scaling matrices used by the slices of the picture.

[0159] The VCL NAL units 606 each contain a slice. A slice may correspond to an entire picture or sub - picture, a single block or multiple blocks or a fragment of a block. For example, Figure 6 a slice contains a number of blocks 620. A slice consists of a slice header 610 and a raw byte sequence payload RBSP 611, and the RBSP 611 contains encoded pixel data encoded as encoded blocks 640.

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

[0161] The PPS contains syntax elements that enable the determination of the slice positions in a frame. Since sub - pictures form rectangular regions in a frame, the set of slices, block parts, or blocks 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 Slice layer syntax

[0165]

[0166] APS

[0167] The Adaptive 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: for ALF parameters

[0170] · LMCS_APS: for LMCS parameters

[0171] · SCALLING_APS: for scaling list - related parameters

[0172] Table 4 Adaptive Parameter Set syntax

[0173]

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

[0175] ALF APS

[0176] 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 and Cr components. If the luma filter flag is enabled, another flag is decoded to know whether the cropping value (alf_luma_clip_flag) is signaled. Then, the number of filters signaled is 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. Then, the absolute value and sign of each coefficient of each filter are decoded.

[0177] If alf_luma_clip_flag is enabled, the cropping index of each coefficient of each enabled filter is decoded.

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

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

[0180] Table 5 Adaptive Loop Filter Data Syntax

[0181]

[0182]

[0183]

[0184] LMCS Syntax Elements for Both Luma Mapping and Chroma Scaling

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

[0186] These parameters are used to construct the forward and inverse mapping functions for luminance and the scaling function for chrominance.

[0187] Table 6 Luminance mapping with chroma scaling data syntax

[0188]

[0189]

[0190] Scaling list APS

[0191] The scaling list provides the possibility to update the quantization matrix used for quantization. In VVC, this 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. If the scaling list is used for the chroma component (scaling_list_chroma_present_flag), the second one is specified. Then, the syntax elements required to decode and 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] Picture header

[0196] The picture header is sent at the start of each picture before other slice data. This is very large compared to the previous headers in the previous drafts of the standard. A full 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 syntax elements that can be decoded involve:

[0198] · Whether to use the picture, reference frame

[0199] · The type of the picture

[0200] · Output frame

[0201] · The number of pictures

[0202] · Use sub - pictures (if required)

[0203] · List of reference pictures (if required)

[0204] · Color plane (if required)

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

[0206] · Delta QP parameter (if required)

[0207] · Motion information parameter (if required)

[0208] · ALF parameter (if required)

[0209] · SAO parameter (if required)

[0210] · Quantization parameter (if required)

[0211] · LMCS parameter (if required)

[0212] · Scaling list parameter (if required)

[0213] · Picture header extension (if required)

[0214] · And so on

[0215] Picture "type"

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

[0217] Then decode the ph_inter_slice_allowed_flag to identify the allowed inter - slice.

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

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

[0220] If the picture is a GDR or IRAP picture, then decode the no_output_of_prior_pics_flag.

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

[0222] ALF

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

[0224] The alf_info_in_ph_flag is defined as follows:

[0225] "alf_info_in_ph_flag being equal to 1 specifies that ALF information exists in the PH syntax structure and does not exist in the slice header that references a PPS that does not contain the PH syntax structure. alf_info_in_ph_flag being equal to 0 specifies that ALF information does not exist in the PH syntax structure and may exist in the slice header that references a PPS that does not contain the PH syntax structure."

[0226] First, decode the ph_alf_enabled_present_flag to determine whether the ph_alf_enabled_flag should be decoded. If the ph_alf_enabled_present_flag is enabled, then 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 IDs 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, for Cr only, or for Cb only. If enabled, the ph_alf_aps_id_chroma syntax element is used to decode the value of the APS ID for chroma.

[0229] In this way, the APS IDs for the CC-ALF method are decoded if the Cb and / or Cr components require it.

[0230] LMCS

[0231] If LMCS is enabled at the SPS level, a set of LMCS APS ID syntax elements is decoded. First, the 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 the ph_chroma_residual_scale_flag is decoded to enable or disable the method for chroma.

[0232] Scaling list

[0233] If the scaling list is enabled at the SPS level, a 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-picture

[0235] When the sub-picture parameters are enabled at the SPS and if the signaling of the sub-picture ID is disabled, the sub-picture parameters are enabled. Some information about the virtual boundaries is also included. For the 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 picture list

[0244] If the reference picture list is signaled in the picture header (due to rpl_info_in_ph_flag being equal to 1), then the parameters of the reference picture list ref_pic_lists() are decoded, which contain 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 are defined in the following syntax table:

[0251] Table 8 Reference picture list syntax

[0252]

[0253] Partition

[0254] If required, the set of partition parameters is decoded, and the set of partition parameters 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 equal to 1), then decode the weighted prediction parameters pred_weight_table().

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

[0271] Table 9 Weighted Prediction Parameter Syntax

[0272]

[0273]

[0274]

[0275] Delta QP

[0276] When the picture is intra, if necessary, ph_cu_qp_delta_subdiv_intra_slice and ph_cu_chroma_qp_offset_subdiv_intra_slice are decoded. And if inter - slice is allowed, ph_cu_qp_delta_subdiv_inter_slice and ph_cu_chroma_qp_offset_subdiv_inter_slice are decoded when needed. Finally, if necessary, the picture header extension syntax elements are decoded.

[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 Picture Header Structure

[0279]

[0280]

[0281]

[0282]

[0283]

[0284]

[0285] Strip header

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

[0287] Table 11 Partial strip header

[0288]

[0289]

[0290]

[0291]

[0292] First, decode picture_header_in_slice_header_flag to know if picture_header_structure() exists in the strip header.

[0293] Then, if necessary, decode slice_subpic_id to determine the sub-picture ID of the current strip. Then decode slice_address to determine the address of the current strip. The strip address is decoded if the current strip mode is the rectangular strip mode (rest_slice_flag equals 1) and if the number of strips in the current sub-picture is higher than 1. The strip address can also be decoded if the current strip mode is the raster scan mode (rest_slice_flag equals 0) and if the number of tiles in the current picture is higher than 1 calculated based on the variables defined in the PPS.

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

[0295] "num_tiles_in_slice_minus1 plus 1 (when present) specifies the number of tiles in the strip. The value of num_tiles_in_slice_minus1 shall be in the range of 0 to NumTilesInPic - 1 (inclusive of the end values)."

[0296] Then decode slice_type.

[0297] 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 equal to 0), then decode the ALF information. This includes the flag (slice_alf_enabled_flag) indicating that ALF is enabled for the current slice. If enabled, decode the number of APS ALF IDs for luma (slice_num_alf_aps_ids_luma), and then decode the APS IDs (slice_alf_aps_id_luma[i]). Then, decode slice_alf_chroma_idc to know whether ALF is enabled for the chroma component and which chroma component is enabled. Then, if necessary, decode the APS IDs for chroma (slice_alf_aps_id_chroma). In the same way, if necessary, decode slice_cc_alf_cb_enabled_flag to know whether the CC ALF method is enabled. If the CC ALF is enabled and if the CC ALF is enabled for Cr and / or Cb, then decode the relevant APS IDs for Cr and / or Cb.

[0298] If the color plane is sent independently (separate_colour_plane_flag equal to 1), then decode the colour_plane_id.

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

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

[0301] "The num_ref_idx_active_override_flag being equal to 1 specifies the existence of the syntax element num_ref_idx_active_minus1[0] for P and B slices, and the existence of the syntax element num_ref_idx_active_minus1[1] for B slices. The num_ref_idx_active_override_flag being equal to 0 specifies the non-existence of the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1]. When they do not exist, it is inferred that the value of the num_ref_idx_active_override_flag is equal to 1."

[0302] If the num_ref_idx_active_override_flag is enabled, decode the number of reference indices num_ref_idx_active_minus1[i] for each list "i" when needed. The number of reference index overrides for the current list should be less than or equal to the number of reference frame indices signaled in ref_pic_lists(). Thus, the override either reduces or does not reduce the maximum number of reference frames for each list.

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

[0304] In the same way, when the slice type is not intra, decode the parameters of weighted prediction pred_weight_table().

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

[0306] If the SAO information is sent in the slice header (sao_info_in_ph_flag equals 0) and if it is enabled at the SPS level (sps_sao_enabled_flag), then decode the SAO enable flags: slice_sao_luma_flag, slice_sao_chroma_flag for both luma and chroma.

[0307] Then, if the deblocking filter parameters are signaled in the slice header (dbf_info_in_ph_flag equals 0), decode the deblocking filter parameters.

[0308] Decode the flag slice_ts_residual_coding_disabled_flag systemically to know whether the transform skip residual coding method is enabled for the current slice.

[0309] If LMCS is enabled in the picture header (ph_lmcs_enabled_flag equals 1), then decode the flag slice_lmcs_enabled_flag. In the current VVC specification, slice_lmcs_enabled_flag is defined as follows:

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

[0311] In the same way, if the scaling list is enabled in the picture header (phpic_scaling_list_presentenabled_flag equals 1), then decode the flag slice_scaling_list_present_flag. In the current VVC specification, slice_scaling_list_present_flag is defined as follows:

[0312] "The slice_scaling_list_present_flag being 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). The slice_scaling_list_present_flag being equal to 0 specifies that the scaling list data for the current picture is the default scaling list data specified for export in Clause 7.4.3.21. When not present, the value of slice_scaling_list_present_flag is inferred to be 0."

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

[0314] The picture header is in the slice header

[0315] In a specific signaling manner, such as Figure 7 depicted in, the picture header 708 can be signaled within the slice header 710. In this case, there is no NAL unit that contains 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, and can thus be understood from the foregoing description. Due to the flag picture_header_in_slice_header_flag, it can be enabled in the slice header. In addition, when the picture header is signaled within the slice header, the picture should contain only one slice. Therefore, each picture always has only one picture header. In addition, the flag picture_header_in_slice_header_flag should have the same value for all pictures of the CLVS (Coded Layer Video Sequence). This means that all pictures between two IRAPs, including the first IRAP, have only one slice for each picture."

[0316] The flag picture_header_in_slice_header_flag is defined as follows:

[0317] "The picture_header_in_slice_header_flag being equal to 1 specifies that there is a PH syntax structure in the slice header. The picture_header_in_slice_header_flag being equal to 0 specifies that there is no PH syntax structure in the slice header."

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

[0319] It is a requirement for bitstream compliance that when picture_header_in_slice_header_flag is equal to 1 for a coded slice, there shall be no VCL NAL unit with nal_unit_type equal to PH_NUT in the CLVS.

[0320] 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.

[0321] picture_header_structure() contains the syntax elements of picture_rbsp() except for the filler bits rbsp_trailing_bits().

[0322] Streaming applications

[0323] Some streaming applications only extract certain parts of the bitstream. These extractions can be spatial (as sub - pictures) or temporal (sub - parts of the video sequence). Then, these extracted parts can be merged with other bitstreams. Other frames reduce the frame rate by only extracting some frames. Generally, the main purpose of these streaming applications is to use the maximum allowed bandwidth to produce the highest quality for the end - user.

[0324] In VVC, for frame rate reduction, the APS ID numbers have been restricted so that the new APS ID number of a frame cannot be used for frames in the upper temporal layer. However, for streaming applications that extract parts of the bitstream, it is necessary to track the APS ID to determine which APSs should be retained for the sub - parts of the bitstream, because frames (due to IRAP) do not reset the numbering of the APS ID.

[0325] LMCS (Luminance Mapping with Chroma Scaling)

[0326] The Luminance Mapping with Chroma Scaling (LMCS) technique is a sample value conversion method applied to blocks before applying loop filters in a video decoder such as VVC.

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

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

[0329] 2) The second sub-tool is related to the chrominance component that applies luminance-dependent chrominance residual scaling. The chrominance residual scaling is designed to compensate for the interaction between the luminance signal and its corresponding chrominance signals. The chrominance residual scaling depends on the average of the reconstructed neighboring luminance samples above and / or to the left of the current block.

[0330] As with most other tools in a video encoder (such as VVC), the LMCS can be enabled / disabled at the sequence level using an SPS flag. It is also signaled at the slice level whether the chrominance residual scaling is enabled. If the luminance mapping is enabled, an additional flag is signaled to indicate whether the luminance-dependent chrominance residual scaling is enabled. When the luminance mapping is not used, the luminance-dependent chrominance residual scaling is completely disabled. Additionally, for chrominance blocks of size less than or equal to 4, the luminance-dependent chrominance residual scaling is always disabled.

[0331] Figure 8 Illustrates the principle of the LMCS as described above for the luminance mapping sub-tool. Figure 8 The shaded blocks in are the new LMCS functional blocks, including the forward and inverse mapping of the luminance signal. It is important to note that when the LMCS is used, some decoding operations are applied in the "mapping domain". These operations are represented by the dashed blocks in this Figure 8 They typically correspond to inverse quantization, inverse transform, in-frame luminance prediction, and the reconstruction step (which consists of adding the luminance prediction and the luminance residual). In contrast, Figure 8 The solid blocks in indicate the locations where the decoding processes are applied in the original (i.e., non-mapped) domain, and this includes loop filtering such as deblocking, ALF, and SAO, motion compensation prediction, and the storage of the decoded pictures as reference pictures (DPB).

[0332] Figure 9 Illustrates a figure similar to Figure 8 but this time it is for the chrominance scaling sub-tool of the LMCS tool. Figure 9 The shaded blocks in are the new LMCS functional blocks, which include the luminance-dependent chrominance scaling process. However, in terms of chrominance, there are some important differences compared to the luminance case. Here, for chrominance samples, only the inverse quantization and inverse transform represented by the blocks in the dashed line are performed in the "mapping domain". All other steps of in-frame chrominance prediction, motion compensation, and loop filtering are performed in the original domain. As Figure 9As shown, for brightness mapping, there is only scaling processing and no forward and inverse processing.

[0333] Brightness mapping using a piecewise linear model

[0334] The brightness mapping sub-tool uses a piecewise linear model. This means that the piecewise linear model divides the input signal dynamic range into 16 equal sub-ranges, and for each sub-range, the number of codewords assigned to that range is used to represent its linear mapping parameter.

[0335] Semantics of brightness mapping

[0336] The syntax element lmcs_min_bin_idx specifies the minimum bin index used in the construction process of the luminance mapping with chroma scaling (LMCS). The value of lmcs_min_bin_idx should be in the range of 0 to 15 (including the end values).

[0337] The syntax element lmcs_delta_max_bin_idx specifies the incremental value between 15 and the maximum bin index LmcsMaxBinIdx used in the construction process of the luminance mapping with chroma scaling. The value of lmcs_delta_max_bin_idx should be in the range of 0 to 15 (including the end values). The value of LmcsMaxBinIdx is set to be equal to 15 - lmcs_delta_max_bin_idx. The value of LmcsMaxBinIdx should be greater than or equal to lmcs_min_bin_idx.

[0338] 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].

[0339] The syntax element lmcs_delta_abs_cw[i] specifies the absolute incremental codeword value of the i-th bin.

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

[0341] LMCS intermediate variable calculation for brightness mapping

[0342] To apply the forward and inverse brightness mapping processes, some intermediate variables and data arrays are required.

[0343] First, the variable OrgCW is derived as follows:

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

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

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

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

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

[0349] - For i = lmcs_min_bin_idx... LmcsMaxBinIdx, the following is applied:

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

[0351] The value of lmcsCW[i] should be in the range of (OrgCW >> 3) to (OrgCW << 3 - 1) (including the end values).

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

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

[0354] InputPivot[i] = i * OrgCW

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

[0356] LmcsPivot[0] = 0;

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

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

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

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

[0361] InvScaleCoeff[i] = 0

[0362] else

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

[0364] Forward luminance mapping

[0365] As Figure 8 shown, when LMCS is applied to luminance, luminance remapped samples called predMapSamples[i][j] are obtained from the predicted samples predSamples[i][j].

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

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

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

[0369] Then, predMapSamples[i][j] is derived as follows using the intermediate variables idxY, LmcsPivot[idxY], and InputPivot[idxY] with the lower 0 bits:

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

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

[0372] Luminance reconstruction samples

[0373] The reconstruction process is obtained from the predicted luminance samples predMapSample[i][j] and the residual luminance samples resiSamples[i][j].

[0374] The reconstructed luminance picture sample recSamples[i][j] is simply obtained by adding predMapSample[i][j] to resiSamplei[i][j] as follows:

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

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

[0377] Inverse luminance mapping

[0378] 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:

[0379] First, the index idxY is calculated from the reconstructed sample recSamples[i][j] at position (i, j).

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

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

[0382] invLumaSample[i][j] =

[0383] InputPivot[idxYInv] + (InvScaleCoeff[idxYInv] * (recSample[i][j] - LmcsPivot[idxYInv])+(1 << 10)) >> 11

[0384] Then a clipping operation is performed to obtain the final sample:

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

[0386] Chroma scaling

[0387] LMCS semantics for chroma scaling

[0388] 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 from 0 to 7 (inclusive). When it is absent, it is inferred that lmcs_delta_abs_crs is equal to 0.

[0389] The syntax element lmcs_delta_sign_crs_flag specifies the sign of the variable lmcsDeltaCrs. When it is absent, it is inferred that lmcs_delta_sign_crs_flag is equal to 0.

[0390] LMCS Intermediate Variable Calculation for Chroma Scaling

[0391] To apply the chroma scaling process, some intermediate variables are required.

[0392] The variable lmcsDeltaCrs is derived as follows:

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

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

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

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

[0397] else

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

[0399] Chroma Scaling Process

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

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

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

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

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

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

[0406] }

[0407] IdxYInv = Min(idxYInv, 15)

[0408] The variable varScale is derived as follows:

[0409] varScale = ChromaScaleCoeff[idxYInv]

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

[0411] recSamples[i][j] = Clip1(predSamples[i][j] + Sign(resiSamples[i][j]) * ((Abs(resiSamples[i][j]) * varScale + (1 << 10)) >> 11))

[0412] If the transform has not been applied to the current block, then the following is applied:

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

[0414] Encoder considerations

[0415] The basic principle of the LMCS encoder is to first allocate more codewords to those ranges of the dynamic range segment that have a lower variance than the average. In an alternative conception of this, the main goal of LMCS is to allocate fewer codewords to those dynamic range segments that have a higher variance than the average. In this way, the smooth regions of the picture will be encoded with more codewords than the average, and vice versa.

[0416] All parameters of the LMCS tool stored in the APS are determined at 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 above basic principle. Then, optimization is performed to obtain the best PSNR metric for the final reconstructed samples of a given block.

[0417] Embodiment

[0418] Signaling of reference frames

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

[0420] In an embodiment, when at least one syntax element indicates that the current picture contains only one slice, the override of the reference picture list is not signaled in the slice header. In fact, when a picture contains one slice, the encoder should not override the reference picture list because the reference picture list should be written only once. Similarly, in the case where the current picture contains only one slice, the decoder should not seek to parse the syntax element for overriding the reference picture list. If the slice uses the reference picture list (or 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 the coding efficiency trade-off for practical applications, it is preferred to avoid such override to save the bits associated with its signaling. In addition, the slice header parsing for some implementations is simplified.

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

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

[0423] In addition, the definition of "num_ref_idx_active_override_flag" should be modified as follows:

[0424] "The num_ref_idx_active_override_flag being equal to 1 specifies that there is the syntax element num_ref_idx_active_minus1[0] for P and B slices and the syntax element num_ref_idx_active_minus1[1] for B slices. The num_ref_idx_active_override_flag being equal to 0 specifies that there are no syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1]. When they do not exist, And when the slice of the reference PPS The header does not contain the PH syntax structure , it is inferred that the value of the num_ref_idx_active_override_flag is equal to 1. Otherwise, when When it does not exist, and when the slice header of the reference PPS contains the PH syntax structure, infer that the value of num_ref_idx_active_ override_flag is equal to 0 ."

[0425] The advantage is an improvement in coding efficiency when the picture is in the slice header. In fact, for low-latency and low-bitrate applications, signaling the picture header in the slice header is efficient. In this case, the cost of the override flags for multiple pictures is greater than the cost of setting a set of several reference picture lists in the SPS. In fact, typically for these use cases, the amount of reference frames is limited to one or two reference frames per list.

[0426] Table 12 shows the modified partial slice header

[0427]

[0428]

[0429] Avoid signaling additional reference frames 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

[0430] In one embodiment, when 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 override of the reference frames is not signaled in the slice header. In this case, it is ensured that the current picture contains only one slice. Table 13 shows this embodiment. Furthermore, in the embodiment, there is no need: the syntax requirement for the override of reference frames that are not signaled (i.e., encoded or decoded) enables the raster scan slice mode. That is to say, even when the raster scan slice mode is not enabled, the syntax for overriding reference frames can be not signaled.

[0431] Furthermore, the definition of "num_ref_idx_active_override_flag" should be modified as follows:

[0432] "The num_ref_idx_active_override_flag being equal to 1 specifies that the syntax element num_ref_idx_active_minus1[0] exists for P and B slices and the syntax element num_ref_idx_active_minus1[1] exists for B slices. The num_ref_idx_active_override_flag being equal to 0 specifies that the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1] do not exist. When they do not exist, And when raster scan The strip mode is not enabled or the number of blocks in the current picture is no higher than 1, or when the number of blocks in the strip is not equal to the number of blocks in the current picture When it is inferred that the value of the num_ref_idx_active_override_flag is equal to 1. Otherwise, when When it does not exist, and when the raster scan strip mode is enabled, and the number of blocks in the current picture is higher than 1, and when the number of blocks in the strip is equal to the number of blocks in the current picture, infer that the value of num_ref_idx_active_override_ flag is equal to 0 And when raster scan ."

[0433] Table 13 shows the modified partial slice header

[0434]

[0435]

[0436] 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 the number of blocks in the slice is equal to the number of blocks in the current picture, the override of the reference frame is not signaled in the slice header.

[0437] Furthermore, the definition of "num_ref_idx_active_override_flag" shall be modified as follows:

[0438] "The num_ref_idx_active_override_flag being equal to 1 specifies that the syntax element num_ref_idx_active_minus1[0] exists for P and B slices and the syntax element num_ref_idx_active_minus1[1] exists for B slices. The num_ref_idx_active_override_flag being equal to 0 specifies that the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1] do not exist. When they do not exist, The strip mode is not enabled, or the number of blocks in the current picture is no higher than 1, or when the number of blocks in the strip 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 Otherwise, when it does not exist, and when the raster scan strip The mode is enabled, the number of blocks in the current picture is higher than 1, and when the number of blocks in the strip is equal to the number of blocks in the current picture, or when the slice header of the reference PPS contains the PH syntax structure, infer that the value of num_ref_idx_active_, it is inferred that the value of num_ref_idx_active_override_flag is equal to 1. override_flag is equal to 0 high_level_slice_rpl_override_enabled_flag equal to 1 specifies that the reference picture list syntax element can be overridden in the slice header. high_level_slice_rpl_override_enabled_flag equal to 0 specifies that The reference picture list syntax element cannot be overridden in the slice header. When it does not exist, infer that it is equal to 0 And when the slice header of the reference PPS does not contain the PH syntax structure .

[0439] Table 14 shows the modified partial slice header

[0440]

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

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

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

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

[0445] Force num_ref_idx_active_override_flag to be equal to 0 when the number of tiles in a slice is equal to the number of tiles in the picture and the number of tiles in the picture is greater than 1

[0446] In one embodiment, when the raster scan slice 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, setting the flag num_ref_idx_active_override_flag to be equal to 0 is a bitstream requirement.

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

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

[0449] In an embodiment, signaling of an additional reference picture list is only allowed when the reference picture list of each list refers to the reference picture list signaled in the SPS. In the current VVC specification, due to the variables rpl_sps_flag[0] for list L0 and rpl_sps_flag[1] for list L1, the reference picture list signaled in the SPS can be identified. Table 15 shows this embodiment, where if the slice type is P or B and the number of reference frames for L0 is greater 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 greater than 1 and if the reference picture list for L1 is signaled in the SPS, then the syntax element num_ref_idx_active_override_flag is extracted from the bitstream. In the same way, if the flag is true, then if the slice type is P or B and the number of reference frames for L0 is greater 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 greater than 1 and if the reference picture list for L1 is signaled in the SPS, then the number of reference activations decoded for L0 is decremented by 1.

[0450] Table 15 shows the modified partial slice header

[0451]

[0452]

[0453] In one embodiment, due to the variable num_ref_pic_lists_in_sps[0] of list L0 and the variable num_ref_pic_lists_in_sps[1] of list L1, the reference picture lists signaled in the SPS can be identified. This variable gives the number of lists signaled in the SPS. When it is equal to 0, it means that there is no reference picture list in the SPS. Therefore, this variable does not give information about the currently signaled reference picture list, but gives information about all reference picture lists using the same SPS. Table 16 shows this embodiment.

[0454] Table 16 shows the modified partial slice header

[0455]

[0456]

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

[0458] In an embodiment, due to the comparison of RplsIdx[i] with num_ref_pic_lists_in_sps[i], the reference picture lists signaled in the SPS can be identified. 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 lists sent in the SPS. This embodiment gives better accuracy than the previous embodiment.

[0459] Other conditions for only one slice

[0460] In another embodiment, it is only allowed to signal an additional reference picture list when the reference picture list of each list refers to the reference picture lists signaled in the SPS and when at least one syntax element indicates that the current picture can contain more than one slice. In fact, when the picture contains one slice, the encoder should not overwrite the reference picture list explicitly sent in the slice header or picture header. However, if the reference picture lists sent in the SPS are used, it is beneficial to overwrite the list to limit the number of reference pictures. However, in terms of the coding efficiency trade-off in practical applications, it is preferred to avoid such overwriting to save the bits related to its signaling. In addition, the slice header parsing of some implementations is simplified.

[0461] Other conditions of PH in SH

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

[0463] Table 17 shows the modified partial slice header

[0464]

[0465]

[0466] The advantage is an improvement in coding efficiency when the picture is in the slice header. In fact, signaling the picture header in the slice header is efficient for low-latency and low-bitrate applications, in which case the cost of the override flag for multiple pictures is greater than the cost of setting a number of reference picture lists in the SPS.

[0467] Other conditions where the number of blocks in the slice is equal to the number of blocks in the picture and the number of blocks in the picture is greater than 1

[0468] In an additional embodiment, signaling of an additional reference frame is allowed only if the reference frame list reference of each list signals the reference picture list signaled in the SPS and 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. In this case, it is determined that the current picture contains only one slice. This can be achieved by changing!picture_header_in_slice_header_flag in Table 17 to (!(!(rect_slice_flag && NumTilesInPic > 1 && num_tiles_in_slice_minus1 ==

[0469] NumTilesInPic - 1)).

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

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

[0472] Avoid signaling of an additional reference picture list that uses syntax elements sent at a higher level

[0473] In one embodiment, signaling of an additional reference picture list is only allowed when the high-level flag indicates that the reference picture list can be overwritten in the strip header.

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

[0475] Table 18 shows the modified partial strip header

[0476]

[0477] The semantics of this flag should be defined as follows:

[0478] “ When the slice header of the reference PPS contains the PH syntax structure, infer that slice_lmcs_enabled_flag is equal to ph_lmcs_enabled_flag And when the slice header of the reference PPS does not contain .”

[0479] Compared with the previous embodiment with similar coding efficiency improvement, the advantage of this embodiment is greater flexibility.

[0480] Signaling in the SPS

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

[0482] Decoding conditional on num_ref_pic_lists_in_sps[i]

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

[0484] When there is only one slice, the flag is not decoded or inferred.

[0485] In an embodiment, when there are more than one slice in the picture referring to the current SPS, sps_slice_rpl_override_enabled_flag is not decoded and / or is inferred to be equal to 1. The use of only one slice may depend on the syntax elements signaled to send 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.

[0486] When rpl is in the SH, the flag is not decoded or inferred.

[0487] In an additional embodiment, when the reference picture list is sent in the slice header, sps_slice_rpl_override_enabled_flag is not decoded. In this case, the flag rpl_info_in_ph_flag is set to be equal 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 ensured that the reference picture list is sent for each slice. Therefore, there is no need to override this information. Table 19 shows this embodiment.

[0488] Table 19 shows the modified partial SPS

[0489]

[0490]

[0491] Signaling in the PPS

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

[0493] Decoding conditional on num_ref_pic_lists_in_sps[i]

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

[0495] When there is only one slice, the flag is not decoded or inferred

[0496] In an additional embodiment, when there are more than one slice in the picture referring to 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 the syntax element that signals the picture header sent in the slice header or when the number of blocks in the picture is the same as the number of blocks in the slice.

[0497] When the reference picture list (RPL) is in the slice header (SH), the flag is not decoded or inferred

[0498] In an additional embodiment, when the reference picture list is sent in the slice header, pps_slice_rpl_override_enabled_flag is not decoded. In this case, the flag rpl_info_in_ph_flag is set to be equal 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 they are not the reference picture lists sent in the SPS, it is ensured that the reference picture list is sent for each slice. Therefore, there is no need to override this information. Table 20 shows this embodiment.

[0499] Table 20 shows the modified partial PPS

[0500]

[0501]

[0502] Signaling in the Video Parameter Set (VPS)

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

[0504] Signal notification 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 conditioned on num_ref_pic_lists_in_sps[i]

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

[0508] The flag is not decoded or inferred when there is only one slice

[0509] In an additional embodiment, when there are more than one slice in the picture that references the current picture header, the ph_slice_rpl_override_enabled_flag is not decoded and / or is inferred to be equal to 1. The use of only one slice can depend on the syntax element that signals the picture header to be sent 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] The flag is not decoded or inferred when rpl is in the slice header (SH)

[0511] In an additional embodiment, when the reference picture list is 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 be equal 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 they are not the reference picture lists sent in the picture header, it is ensured that the reference picture list is sent for each slice. Therefore, there is no need to override this information. Table 21 shows the implementation of this embodiment.

[0512] Table 21 shows the modified partial picture header

[0513]

[0514] Embodiments related to LMC and scaling lists

[0515] Avoid signaling of XXX activation flag when there is only one slice

[0516] In one embodiment, when the current picture contains only one slice, the following syntax element sent in the slice header is not sent in the slice header. The syntax element 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 (or parameter) XXX.

[0517] The advantage of this embodiment is improved coding efficiency because the syntax element is not sent when it is 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 the picture header is in the slice header, the following syntax element sent in the slice header is not sent in the slice 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.

[0520] The advantage of this additional embodiment is improved coding efficiency when the picture is in the slice header. In fact, having 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 the global bitrate.

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

[0522] Avoid signaling of XXX flag when the number of tiles in a slice is equal to the number of tiles in the picture and the number of tiles in the picture is greater than 1

[0523] In an embodiment, when the raster scan slice 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, the following syntax element sent in the slice header is not sent in the slice. 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.

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

[0525] Predict slice_XXX_flag from the value of ph_XXX_flag

[0526] In an embodiment, when a 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 from the value of a 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 that enables 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] Furthermore, when the conditions defined above are met, the variable slice_lmcs_enabled_flag is predicted from 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 luminance mapping with chroma scaling is enabled for the current slice. slice_lmcs_enabled_flag equal to 0 specifies that luminance mapping with chroma scaling is not enabled for the current slice. When slice_lmcs_enabled_flag does not exist, The PH syntax structure , it is inferred to be equal to 0. When the slice header of the reference PPS Contains the PH syntax structure, infer that slice_lmcs_enabled_flag is equal to ph_scaling_list_present_ .”

[0532] Table 22 shows the modified partial slice header

[0533]

[0534] XXX is the scaling list

[0535] In one embodiment, due to the conditions defined above, the syntax element slice_scaling_list_present_flag that specifies the existence of a scaling list 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] Furthermore, when the conditions defined above are met, the value of the variable slice_scaling_list_present_flag is predicted by the value of ph_scaling_list_present_flag. For example, for the condition "the picture header is in the slice header", slice_lmcs_enabled_flag is defined as follows:

[0538] "slice_scaling_list_present_flag being 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 being equal to 0 specifies that the scaling list data for the current picture is the default scaling list data specified for derivation in Clause 7.4.3.21. When it does not exist, flag When the slice header of the reference PPS contains the PH syntax structure , it is inferred that the value of slice_scaling_list_present_flag is equal to 0. ​ ​ ​ ."

[0539] In the embodiment, the proposed restrictions on the variable XXX are applied to both slice_lmcs_enabled_flag and slice_scaling_list_present_flag.

[0540] In the embodiment, 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, the following syntax element that is sent in the slice header and enables or specifies the existence of a tool and depends on at least one variable in the picture header that enables or specifies the existence of the tool is not sent in the slice header. Table 23 shows the implementation of this embodiment.

[0541] In another embodiment, the slice_lmcs_enabled_flag and slice_scaling_list_present_flag are sent in the slice header, which enable LMCS and specify the presence of a scaling list respectively, and which depend on the 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, the 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 that slice_XXX_flag equals ph_XXX_flag when there is only one slice

[0546] In an embodiment, when the current picture contains only one slice, the following syntax elements are sent in the slice header, which enable or specify the presence of a tool or parameter XX and depend on at least one variable that enables or specifies the presence of the tool in the picture header. When there is only one slice, the bitstream consistency requirement may appropriately make the syntax elements in the slice header have the same value as the syntax elements in the picture header, which enable or specify the presence of the same tool or parameter.

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

[0548] In one embodiment, when the picture header is in the slice header, the following syntax elements are sent in the slice header, which enable or specify the presence of a tool or parameter XXX and depend 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 the slice header, the bitstream consistency requirement may appropriately make the syntax elements in the slice header have the same value as the syntax elements in the picture header, which enable or specify the presence of the same tool or parameter.

[0549] Bitstream constraint that slice_XXX_flag equals ph_XXX_flag when the number of blocks in the slice is equal to the number of blocks in the picture and the number of blocks in the picture is greater than 1

[0550] In one embodiment, when the raster scan strip mode is enabled, and the number of blocks in the current picture is greater than 1, and the number of blocks in the strip is equal to the number of blocks in the current picture, the following syntax element is sent in the strip header, which enables or specifies the presence of tool or parameter XXX and depends on at least one variable that enables or specifies the presence of the tool in the picture header. When the number of blocks in the strip is equal to the number of blocks in the picture and the number of blocks in the picture is greater than 1, the bitstream consistency requirement may appropriately make the syntax element in the strip header have the same value as the syntax element in the picture header.

[0551] XXX is LMCS

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

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

[0554] "slice_lmcs_enabled_flag equal to 1 specifies that luminance mapping with chroma scaling is enabled for the current strip. slice_lmcs_enabled_flag equal to 0 specifies that luminance mapping with chroma scaling is not enabled for the current strip. When slice_lmcs_enabled_flag does not exist, it is inferred to be equal to 0. ​ When constructing, slice_lmcs_enabled_flag shall be equal to ph_lmcs_enabled_flag, which is a requirement for bitstream consistency ."

[0555] XXX is the scaling list

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

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

[0558] "When slice_scaling_list_present_flag equals 1, it 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 equals SCALING_APS and adaptation_parameter_set_id equals ph_scaling_list_aps_id). When slice_scaling_list_present_flag equals 0, it specifies that the scaling list data for the current picture is the default scaling list data specified for derivation in Clause 7.4.3.21. When not present, it is inferred that the value of slice_scaling_list_present_flag equals 0." When the slice header of the reference PPS contains the PH syntax structure, infer 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 syntax structure, slice_lmcs_enabled_flag shall be equal to ph_lmcs_enabled_flag, which is a requirement for bitstream consistency requirement "."

[0559] In an embodiment, this restriction is applied to LMCS and the scaling list.

[0560] 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 tiles in the current picture is greater than 1, and when the number of tiles in the slice is equal to the number of tiles in the current picture, the following syntax elements are sent in the slice header, which enable or specify the presence of a tool (or parameter) and depend on at least one variable that enables or specifies 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 tiles in the current picture is greater than 1, and when the number of tiles in the slice is equal to the number of tiles in the current picture, slice_lmcs_enabled_flag and slice_scaling_list_present_flag, where slice_lmcs_enabled_flag and slice_scaling_list_present_flag enable LMCS and specify the presence of the scaling list respectively 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 enable and specify the presence of LMCS and the scaling list in the picture header respectively.

[0562] Avoid signaling of the XXX activation flag when due to flags sent at a higher level

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

[0564] Signaling in SPS, PPS, VPS, PH

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

[0566] Predict slice_XXX_flag from value ph_XXX_flag

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

[0568] XXX is LMCS

[0569] In an embodiment, the syntax element slice_lmcs_enabled_flag that enables LMCS at the slice level is sent only when the high-level flag indicates the presence of slice_lmcs_enabled_flag.

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

[0571] Table 24 shows the modified partial slice header

[0572]

[0573]

[0574] XXX is a scaling list

[0575] In an embodiment, when the high-level flag indicates the presence of slice_scaling_list_present_flag, the syntax element slice_scaling_list_present_flag specifies the presence of a scaling list for the current slice.

[0576] Table 24 shows this embodiment of the high-level flag sent in SPS sps_override_slice_scaling_list_present_flag.

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

[0578] Implementation

[0579] Figure 11Systems 191, 195 according to embodiments of the present invention are shown, which include at least one of an encoder 150 or a decoder 100 and a communication network 199. According to an embodiment, system 195 is used to process and provide content to a user (e.g., video and audio content for display / output or streaming of video / audio content), and the user accesses decoder 100, for example, through a user interface of a user terminal including decoder 100 or a user terminal communicable with decoder 100. Such a user terminal can be a computer, a mobile phone, a tablet, or any other type of device capable of providing / displaying (the provided / streamed) content to the user. System 195 obtains / receives bitstream 101 via communication network 199 (in the form of a continuous stream or signal (e.g., when displaying / outputting earlier video / audio)). According to an embodiment, system 191 is used to process content and store the processed content, e.g., video and audio content processed for display / output / streaming at a later time. System 191 obtains / receives content including original 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 bitstream 101 that will be transmitted to decoder 100 via communication network 199. Then, bitstream 101 is transmitted to decoder 100 in various 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 the user requests the content (i.e., the bitstream data) from the storage device, at which time the data is transmitted / streamed from the storage device to decoder 100. System 191 may also include a content providing device for providing / streaming (e.g., by transmitting data of a user interface to be displayed on the user terminal) content information of the content stored in the storage device (e.g., the title of the content and other meta / storage location data for identifying, selecting, and requesting the content), and for receiving and processing user requests for the content so that the requested content can be transmitted / streamed from the storage device to the user terminal. Alternatively, encoder 150 generates bitstream 101 and directly transmits / streams it to decoder 100 when the user requests the content. Then, decoder 100 receives bitstream 101 (or signal) and filters it using a deblocking filter according to the present invention to obtain / generate a video signal 109 and / or an audio signal, and then the user terminal uses the video signal 109 and / or the audio signal to provide the requested content to the user.

[0580] Any step of a method / process according to the present invention or the functions described herein can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the steps / functions can be stored as one or more instructions or code or programs or computer-readable media on or transmitted via one or more hardware-based processing units and executed by one or more hardware-based processing units, such as programmable computing machines, which can be a PC (“personal computer”), DSP (“digital signal processor”), circuits, circuitry, processors and memories, general microprocessors or central processing units, microcontrollers, ASICs (“application specific integrated circuits”), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, as used herein, the term “processor” can refer to any one of the foregoing structures or any other structure suitable for implementing the techniques described herein.

[0581] Embodiments of the present invention can also be implemented by various apparatuses or devices, including wireless handsets, integrated circuits (ICs) or JC collections (e.g., chip sets). Various components, modules, or units are described herein to illustrate functional aspects of the apparatuses / devices configured to perform these embodiments, but need not necessarily be implemented by distinct hardware units. Rather, the various modules / units can be combined in a codec hardware unit or provided by a collection of interoperating hardware units, including one or more processors in conjunction with suitable software / firmware.

[0582] Embodiments of the present invention can be implemented by a computer that reads and executes computer-executable instructions (e.g., one or more programs) recorded on a storage medium to perform one or more of the modules / units / functions in the above embodiments and / or a system or device including one or more processing units or circuits for performing one or more of the functions in the above embodiments, and can be implemented by a method performed by the computer of the system or device, e.g., reading and executing computer-executable instructions from a storage medium to perform one or more of the functions in the above embodiments and / or controlling one or more processing units or circuits to perform one or more of the functions in the above embodiments. The computer can include a single computer or a network of individual processing units to read and execute the computer-executable instructions. The computer-executable instructions can be provided to the computer, for example, via a network or a tangible storage medium from a computer-readable medium such as a communication medium. The communication medium can be a signal / bitstream / carrier wave. The tangible storage medium is a "non-transitory computer-readable storage medium", which can include (e.g.) one or more of a hard disk, random access memory (RAM), read-only memory (ROM), storage devices of a distributed computing system, optical discs (e.g., compact discs (CDs), digital versatile discs (DVDs) or Blu-ray discs (BD) TM ), flash memory devices, memory cards, etc. At least some of the steps / functions can also be implemented in hardware by a machine or a dedicated component such as an FPGA ("field programmable gate array") or an ASIC ("application specific integrated circuit").

[0583] Figure 12Schematic 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 embodiments of the present invention and registers suitable for recording variables and parameters required to implement a method for encoding or decoding at least a part of an image according to the embodiments of the present invention, the storage capacity of which can be expanded, for example, by an optional RAM connected to an expansion port; - a read-only memory (ROM) 2003 for storing a computer program for implementing the embodiments of the present invention; - a network interface (NET) 2004, which is generally 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 consist of a set of different network interfaces (e.g., wired and wireless interfaces, or different types of wired or wireless interfaces). Under the control of a software application running in the CPU 2001, data packets are written to the network interface for transmission or read from the network interface for reception; - a user interface (UI) 2005, which may be used to receive input from a user or display information to the user; - a hard disk (HD) 2006, which may be provided as a mass storage device; - an input / output module (IO) 2007, which may be used to receive / send data from / to an external device (such as a video source or a display). The executable code may be stored in the ROM 2003, on the HD 2006, or on a removable digital medium such as a disk. According to a variant, the executable code of the program may be received via the NET 2004 by means of a communication network and stored in one of the storage components (such as the HD 2006, etc.) of the computing device 2000 before being executed. The CPU 2001 is adapted to control and direct the execution of instructions or portions of software code of one or more programs according to the embodiments of the present invention, the instructions being stored in one of the aforementioned storage components. For example, after power-on, the CPU 2001 is capable of executing those instructions related to the software application from the main RAM memory 2002 after loading the instructions from the program ROM 2003 or the HD 2006. Such a software application, when executed by the CPU 2001, causes the steps of the method according to the present invention to be performed.

[0584] It should also be understood that, according to other embodiments of the present invention, a decoder according to the above embodiments is provided in a user terminal such as a computer, a mobile phone (cellular phone), a tablet, or any other type of device capable of providing / displaying content to a user (e.g., a display device). According to another embodiment, an encoder according to the above embodiments is provided in an image capture device, which further includes a camera, a video camera, or a network camera (e.g., a closed-circuit television or video surveillance camera) for capturing and providing content for encoding by the encoder. The following refers to Figure 13 and 14 Two such examples are provided.

[0585] Network camera

[0586] Figure 13 FIG. is an illustration of a network camera system 2100 including a network camera 2102 and a client device 2104.

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

[0588] The network camera 2102 and the client device 2104 are interconnected via a network 200 to enable communication with each other.

[0589] The imaging unit 2106 includes a lens and an image sensor (e.g., a charge-coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS)), and captures an image of an object and generates image data based on the image. The image may be a still image or a video image.

[0590] The encoding unit 2108 encodes the image data by using the encoding method described above.

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

[0592] In addition, the communication unit 2110 receives commands from the client device 2104. The commands include commands for setting parameters for encoding by the encoding unit 2108.

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

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

[0595] The communication unit 2114 of the client device 2104 transmits commands to the network camera 2102.

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

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

[0598] 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.

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

[0600] 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 for encoding by the encoding unit 2108).

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

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

[0603] Smartphone

[0604] Figure 14 is a diagram illustrating the smartphone 2200.

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

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

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

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

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

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

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

[0612] It should also be understood that any result of the above comparison, determination, evaluation, selection, execution, performance or consideration (e.g., a selection made during an encoding or filtering process) can be indicated in the data in the bitstream (e.g., a flag or data indicating the result) or determined / inferred from the data in the bitstream, such that the indicated or determined / inferred result can be used for processing instead of actually performing the comparison, determination, evaluation, selection, execution, performance or consideration, for example, during a decoding process.

[0613] 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 these features cannot be used advantageously in combination.

[0614] The reference signs appearing in the claims are for illustration only and should not limit the scope of the claims.

Claims

1. A method for decoding video data from a bitstream, wherein, the bitstream includes a picture header and a slice header, the picture header includes syntax elements to be used when decoding one or more slices, and the slice header includes syntax elements to be used when decoding a slice, the method includes: parsing the syntax elements; and using the parsed syntax elements to decode the video data from the bitstream, wherein, according to the value of a second flag indicating whether the picture header exists in the slice header, a first flag related to the use of a scaling list for the slice is parsed from the slice header, and wherein, when the second flag indicates that the picture header exists in the slice header, parsing of the first flag is omitted.

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 third flag related to the availability of a luminance mapping with chroma scaling, i.e., LMCS, is parsed from the slice header, and when the second flag indicates that the picture header exists in the slice header, parsing of the third flag is omitted.

4. The method according to claim 1 or 2, wherein, the bitstream further includes an adaptive parameter set, i.e., APS, the adaptive parameter set having an aps_params_type syntax element equal to SCALING_APS for scaling list parameters, and wherein, when the value of the first flag for the slice is 1, the scaling list data included in the adaptive parameter set, i.e., APS, can be used for the slice.

5. The method according to claim 1 or 2, wherein, when the second flag indicates that the picture header exists in the slice header, the value of the first flag is derived from the value of a fourth flag related to the scaling list in the picture header.

6. An apparatus for decoding video data from a bitstream, wherein, the bitstream includes a picture header and a slice header, the picture header includes syntax elements to be used when decoding one or more slices, the slice header includes syntax elements to be used when decoding a slice, and the apparatus includes: components for parsing the syntax elements; and components for using the parsed syntax elements to decode the video data from the bitstream, wherein, according to the value of a second flag indicating whether the picture header exists in the slice header, a first flag related to the use of a scaling list for the slice is parsed from the slice header, and wherein, when the second flag indicates that the picture header exists in the slice header, parsing of the first flag is omitted.

7. A method for encoding video data into a bitstream, wherein, The bitstream includes a picture header and a slice header, the picture header includes syntax elements to be used when decoding one or more slices, the slice header includes syntax elements to be used when decoding a slice, and the method includes: encoding the syntax elements; and encoding the video data into the bitstream, wherein, according to the value of a second flag indicating whether the picture header exists in the slice header, a first flag related to the use of a scaling list for the slice is encoded into the slice header, and wherein, when the second flag indicates that the picture header exists in the slice header, the first flag is not encoded.

8. An apparatus for encoding video data into a bitstream, wherein, the bitstream includes a picture header and a slice header, the picture header includes syntax elements to be used when decoding one or more slices, the slice header includes syntax elements to be used when decoding a slice, and the apparatus includes: means for encoding the syntax elements; and means for encoding the video data into the bitstream, wherein, according to the value of a second flag indicating whether the picture header exists in the slice header, a first flag related to the use of a scaling list for the slice is encoded into the slice header, and wherein, when the second flag indicates that the picture header exists in the slice header, the first flag is not encoded.

9. A computer-readable storage medium storing a computer program including executable instructions, the executable instructions, when executed by a processor, cause the method according to any one of claims 1 to 5 and 7 to be performed.

10. A computer program product having a computer program including executable instructions, the executable instructions, when executed by a processor, cause the method according to any one of claims 1 to 5 and 7 to be performed.

Images