Advanced Syntax for Video Coding and Decoding

Abstract

A method for decoding video data from a bitstream is provided. The bitstream includes video data corresponding to one or more slices. 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. Decoding includes: in the case where information that can be signaled in the picture header or the slice header is signaled in the picture header, signaling the picture header in the slice header, allowing parsing of information that could otherwise be signaled in both the slice header and the picture header in only one of the slice header and the picture header; forcing the picture header not to be in the slice header, 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 over the existing HEVC standard (i.e., typically twice as much as before) 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 used formal subjective tests conducted by independent test laboratories to evaluate feedback from 32 organizations. Some suggestions indicate that when compared with using HEVC, the compression efficiency is generally increased by 40% or more. Specific effects were 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 changing 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 improvements in advanced syntax structures, which achieve a reduction in complexity without any degradation in coding performance.

[0005] According to a first aspect of 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 than one strip, 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 than one strip, the strip header includes syntax elements to be used when decoding a strip, and the decoding includes: when information that can be signaled in the picture header or the strip header is signaled in the picture header, forcing the picture header not to be in the strip header (e.g., applying the constraint that the picture header is not in the strip header), and decoding the bitstream using the syntax elements.

[0006] Optionally, the decoding further includes: parsing a first syntax element indicating whether the information is to be signaled in the picture header, and allowing the information that can be signaled in the strip header and the picture header to be parsed in only one of the strip header and the picture header based on the first syntax element.

[0007] Optionally, the first syntax element is information in a picture parameter set flag or information in a picture header flag.

[0008] Optionally, when the first syntax element indicates signaling information in the picture header, it is not allowed to parse this information in the slice header.

[0009] Optionally, the method further includes: parsing a second syntax element indicating whether the picture header is in the slice header, where when the first syntax element indicates signaling information in the picture header, it is a requirement for bitstream conformance that the second syntax element indicates that the picture header is not in the slice header.

[0010] Optionally, the information includes one or more of quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop filtering (ALF) information.

[0011] Optionally, the information includes all information that can be signaled in the picture header and the slice header.

[0012] Optionally, the reference picture list information includes one or more of slice_collocated_from_l0_flag, slice_collocated_ref_idx, ph_collocated_from_l0_flag, and ph_collocated_ref_idx.

[0013] According to a second aspect of the present invention, there is provided a method for encoding video data into a bitstream, the 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: when signaling information that can be signaled in the picture header or in the slice header in the picture header, signaling that the picture header is not in the slice header, and decoding the video data using the syntax elements.

[0014] Optionally, the encoding further includes: encoding a first syntax element indicating whether to signal the information in the picture header, and allowing encoding of information that can be signaled in the slice header and the picture header in only one of the slice header and the picture header based on the first syntax element.

[0015] Optionally, the first syntax element is information in a picture parameter set flag or information in a picture header flag.

[0016] Optionally, when the first syntax element indicates signaling information in the picture header, encoding of the information in the slice header is not allowed.

[0017] Optionally, the method further includes encoding a second syntax element indicating whether the picture header is in the slice header, where it is a requirement for bitstream conformance that the second syntax element indicates that the picture header is not in the slice header when the first syntax element indicates signaling the information in the picture header.

[0018] Optionally, the information includes one or more of quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop filter (ALF) information.

[0019] Optionally, the information includes all information that can be signaled in the picture header and the slice header.

[0020] Optionally, the reference picture list information includes one or more of slice_collocated_from_l0_flag, slice_collocated_ref_idx, ph_collocated_from_l0_flag, and ph_collocated_ref_idx.

[0021] In an alternative aspect of the present invention, a method of decoding video data from a bitstream is provided, the bitstream including video data corresponding to one or more slices, where 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, and the decoding includes: when the slice header signals information that can be signaled in the picture header or the slice header, forcing the picture header not to be in the slice header; and decoding the bitstream using the syntax elements.

[0022] According to another aspect of 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 syntax elements to be used when decoding one or more strips, the strip header including syntax elements to be used when decoding a strip, and the decoding includes: treating (a) a syntax element indicating tool information signaled in the picture header rather than in the strip header and (b) a syntax element indicating the picture header signaled in the strip header as not combinably applicable; and decoding the bitstream using the syntax elements. When there are the syntax elements (a) and (b) regarded as not combinably applicable, decoding does not occur.

[0023] According to a related aspect of the present invention, a bitstream includes: video data corresponding to one or more strips; a picture header, which includes syntax elements to be used when decoding one or more strips; and a strip header, which includes syntax elements to be used when decoding a strip. The bitstream has the following constraint: there must be no combination in the bitstream of (a) a syntax element indicating tool information signaled in the picture header rather than in the strip header and (b) a syntax element indicating the picture header signaled in the strip header. The tool information can be any one of quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop filtering (ALF) information. In a related aspect, there is provided a method for decoding the bitstream. In another related aspect, there is provided a decoder configured to decode the bitstream. The bitstream can be constrained to conform to a video coding standard. In an embodiment, the video coding standard is the General Video Coding standard. The constraint can be systematically applied throughout the bitstream. For example, in an embodiment, the constraint is applied to any one or all of sequences, pictures, and strips in the bitstream.

[0024] According to another aspect of 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 syntax elements to be used when decoding one or more strips, the strip header including syntax elements to be used when decoding a strip, and the decoding includes: treating (a) a syntax element indicating tool information signaled in the strip header rather than in the picture header and (b) a syntax element indicating the picture header signaled in the strip header as not combinably applicable; and decoding the bitstream using the syntax elements. When there are the syntax elements (a) and (b) regarded as not combinably applicable, decoding does not occur.

[0025] According to another aspect of 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, wherein the picture header is to be signaled in the slice header and wherein there is a constraint to resolve information that could otherwise be signaled in both the slice header and the picture header in only one of the slice header and the picture header; and the decoding includes: when a syntax element (xxx_info_in_ph_flag) indicates the presence of tool information in the picture header (e.g., when xxx_info_in_ph_flag = 1), not signaling the picture header in the slice header (e.g., forcing picture_header_in_slice_header_flag to 0).

[0026] According to a related aspect of the present invention, the bitstream includes: video data corresponding to one or more slices; a picture header, which includes syntax elements to be used when decoding one or more slices; and a slice header, which includes syntax elements to be used when decoding a slice. The bitstream has the following constraint: in the bitstream, there must not be a combination of (a) a syntax element indicating that tool information is signaled not in the picture header but in the slice header and (b) a syntax element indicating that the picture header is signaled in the slice header.

[0027] According to another aspect of 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, wherein the picture header is to be signaled in the slice header and wherein there is a constraint to resolve information that could otherwise be signaled in both the slice header and the picture header in only one of the slice header and the picture header; and the decoding includes: when a syntax element (xxx_info_in_ph_flag) indicates the absence of tool information in the picture header (e.g., when xxx_info_in_ph_flag = 0), not signaling the picture header in the slice header (e.g., forcing picture_header_in_slice_header_flag to 0).

[0028] In a first further aspect of the present invention, there is provided a method of decoding video data from a bitstream, the bitstream including video data corresponding to 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, and the decoding includes: in the case where the picture header is to be signaled in the slice header, allowing parsing of information that could otherwise be signaled in both the slice header and the picture header in only one of the slice header and the picture header; and decoding the bitstream using the syntax elements.

[0029] When the picture header is within the slice header, this means that there is only one slice for the current picture. Thus, having information sent or sendable for both the slice and the picture does not increase the flexibility of the encoder or decoder, since the parameters will be the same. In other words, if the information is in the picture header, the corresponding information in the slice header will be redundant. Similarly, if the information is in the slice header, the corresponding information in the picture header will be redundant. By allowing information in only the picture header or the slice header, in the case where the picture header is within the slice header, decoder implementation can be simplified by limiting redundancy in signaling. Thus, parsing can be simplified without any loss of coding efficiency.

[0030] The decoding may further include parsing a first syntax element indicating whether the picture header is to be signaled in the slice header, and allowing parsing of information that could otherwise be signaled in both the slice header and the picture header in only one of the slice header and the picture header based on the first syntax element. The first syntax element may be the picture header in the slice header flag.

[0031] Optionally, in the case where the first syntax element indicates that the picture header is to be signaled in the slice header, parsing of information in the slice header is not allowed. A second syntax element indicating whether the information is in the picture header may be parsed, wherein the second syntax element indicates that the information is signaled in the picture header in the case where the first syntax element indicates that the picture header is to be signaled in the slice header is a requirement for bitstream conformance.

[0032] Alternatively, in a case where a first syntax element indicates signaling of a picture header in a slice header, signaling of information in the picture header is not allowed. The method may further include parsing a second syntax element indicating whether the information is in the picture header, where it is a requirement for bitstream conformance that the second syntax element indicates that the information is in the picture header in a case where the first syntax element indicates signaling of the picture header in the slice header. The second syntax element may be information in a picture parameter set flag, where when the flag is set, the information is in the picture header, and when the flag is not set, the information is in the slice header or does not exist.

[0033] According to an embodiment, the information may include one or more than one of quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop filtering (ALF) information. For example, all of quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop filtering (ALF) information.

[0034] Optionally, the information includes all information that may be signaled in both the picture header and the slice header.

[0035] The reference picture list information may include one or more than one of the following syntax elements: slice_collocated_from_l0_flag, slice_collocated_ref_idx, ph_collocated_from_l0_flag, and ph_collocated_ref_idx.

[0036] In a case where the picture header is to be signaled in the slice header, the number of weights that are resolvable for weighted prediction may be restricted.

[0037] According to a second further aspect of the present invention, there is provided a method of encoding video data into a bitstream, the video data corresponding to one or more than one slice, where the bitstream includes a picture header and a slice header, the picture header includes syntax elements to be used when decoding one or more than one slice, the slice header includes syntax elements to be used when decoding a slice, and the encoding includes: in a case where the picture header is to be signaled in the slice header, allowing encoding of information that otherwise may be signaled in both the slice header and the picture header in only one of the slice header and the picture header, and encoding the video data using the syntax elements.

[0038] When the picture header is within the slice header, this means that there is only one slice for the current picture. Thus, making information sendable or send for both the slice and the picture does not increase the flexibility of the encoder or decoder because the parameters will be the same. In other words, if the information is in the picture header, the corresponding information in the slice header will be redundant. Similarly, if the information is in the slice header, the corresponding information in the picture header will be redundant. By allowing information only in the picture header or the slice header, in the case where the picture header is within the slice header, the decoder implementation can be simplified by limiting the redundancy in signaling. Thus, encoding can be simplified without any loss of coding efficiency and the cost of signaling is reduced (since the relevant information is included only once in the bitstream).

[0039] Encoding may also include: encoding a first syntax element indicating whether the picture header is to be signaled in the slice header, and allowing information that can be signaled in both the slice header and the picture header to be encoded in only one of the slice header and the picture header based on the first syntax element.

[0040] The first syntax element may be the picture header in the slice header flag.

[0041] In the case where the first syntax element indicates that the picture header is signaled in the slice header, it may not be allowed to encode information in the slice header.

[0042] A second syntax element indicating whether the information is in the picture header may be encoded, where in the case where the first syntax element indicates that the picture header is signaled in the slice header, the second syntax element indicating that the information is in the picture header is a requirement for bitstream consistency.

[0043] Alternatively, in the case where the first syntax element indicates that the picture header is signaled in the slice header, it is not allowed to signal information in the picture header.

[0044] A second syntax element indicating whether the information is in the picture header may be encoded, where in the case where the first syntax element indicates that the picture header is signaled in the slice header, the second syntax element indicating that the information is in the picture header is a requirement for bitstream consistency.

[0045] The second syntax element may be the information in the picture parameter set flag or the information in the picture header flag, where when the flag is set, the information is signaled in the picture header, and when the flag is not set, the information is signaled in the slice header or the information does not exist.

[0046] The information may include one or more of quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop filtering (ALF) information. Optionally, the information includes all information that may be signaled in the picture header and the slice header. For example, all quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop filtering (ALF) information.

[0047] The reference picture list information includes one or more of slice_collocated_from_l0_flag, slice_collocated_ref_idx, ph_collocated_from_l0_flag, and ph_collocated_ref_idx.

[0048] Optionally, when signaling the picture header in the slice header, the number of weights for weighted prediction may be restricted.

[0049] In a third further aspect according to the present invention, there is provided a method of decoding a bitstream comprising 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 method includes: parsing, in the slice header, a syntax element indicating whether the picture header is signaled in the slice header, wherein the ALF APS ID related syntax elements are parsed before the syntax element indicating whether the picture header is signaled in the slice header. The ALF APS ID related information may be parsed at or near the start of the slice header.

[0050] In a fourth further aspect according to the present invention, there is provided a method of encoding video data including one or more slices 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: parsing, in the slice header, a syntax element indicating whether the picture header is signaled in the slice header; wherein the ALP APS ID syntax elements are encoded before the syntax element indicating whether the picture header is signaled in the slice header. The ALF APS ID related information may be encoded at or near the start of the slice header.

[0051] In a fifth further aspect of the present invention, there is provided a method of decoding video data from a bitstream, the bitstream including video data corresponding to 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, and the decoding includes: restricting the number of weights signaled for a weighted prediction mode in a case where the picture header is to be signaled in the slice header; and decoding the bitstream using the syntax elements. In a case where the picture header is to be signaled in the slice header, it may be allowed to resolve information that otherwise may be signaled in both the slice header and the picture header in only one of the slice header and the picture header.

[0052] In a sixth further 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 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, and the encoding includes: restricting the number of weights encoded for a weighted prediction mode in a case where the picture header is to be signaled in the slice header; and encoding the bitstream using the syntax elements. In a case where the picture header is to be signaled in the slice header, it may be allowed to encode information that otherwise may be signaled in both the slice header and the picture header in only one of the slice header and the picture header.

[0053] According to a seventh further aspect of the present invention, there is provided a decoder for decoding video data from a bitstream, the decoder being configured to perform the method of any one of the first aspect, the third aspect and the fifth further aspect.

[0054] According to an eighth further aspect of the present invention, there is provided an encoder for encoding video data into a bitstream, the encoder being configured to perform the method of any one of the second aspect, the fourth aspect and the sixth further aspect.

[0055] According to a ninth further aspect of the present invention, there is provided a computer program which, when executed, causes the method of any one of the first aspect to the sixth further aspect to be performed. The program may be provided alone, or may be carried on, by or in a carrier medium. The carrier medium may be non-transitory, such as a storage medium, in particular a computer-readable storage medium. The carrier medium may also be 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.

[0056] According to a first further aspect, there is provided a method of decoding video data from a bitstream, the bitstream comprising video data corresponding to one or more than one strip, wherein the bitstream comprises a picture header and a strip header, the picture header comprising syntax elements to be used when decoding one or more than one strip, the strip header comprising syntax elements to be used when decoding the strip, and constraining the bitstream such that, in the case where the bitstream comprises a first syntax element having a value indicating information that can be signaled in the picture header or the strip header, the bitstream further comprises a second syntax element having a value indicating that the picture header is not in the strip header, the method comprising: decoding the bitstream using the syntax elements. The bitstream can be constrained to conform to a video coding standard. In an embodiment, the video coding standard is the H.265 / HEVC standard. The second syntax element can be the picture header in the strip header syntax elements. The first syntax element can be a flag indicating one or more than one of quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop filter (ALF) information signaled in the picture header. The bitstream constraints can be applied systematically. For example, in an embodiment, the constraints are applied to any or all of sequences, pictures, and strips in the bitstream.

[0057] According to a second further aspect, there is provided a method of encoding video data into a bitstream or decoding video data from a bitstream, the method comprising: applying a constraint regarding whether a picture header is allowed in a strip header based on whether information that can be signaled in the picture header or in the strip header is signaled in the picture header. According to a third further aspect, there is provided an apparatus configured to perform the method of the second further aspect. According to a fourth further aspect, there is provided a computer program comprising instructions which, when executed, cause the method of the second further aspect to be performed.

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

[0059] Furthermore, features implemented in hardware can be implemented in software and vice versa. Any reference herein to software and hardware features should be construed accordingly.

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

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

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

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

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

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

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

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

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

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

[0070] Figure 8 shows Luma Modelling Chroma Scaling (LMCS);

[0071] Figure 9 shows sub-tools of LMCS;

[0072] Figure 10 is a diagram showing a system according to an embodiment of the present invention including an encoder or decoder and a communication network;

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

[0074] Figure 12 is a diagram showing a network camera system; and

[0075] Figure 13 is a diagram showing a smart phone. DETAILED DESCRIPTION

[0076] Figure 1 Relates to coding structures used in the High Efficiency Video Coding (HEVC) video standard. A 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.

[0077] The images 2 of the sequence can be segmented into slices 3. In some cases, a slice can constitute the entire image. These slices are segmented into non - overlapping Coding Tree Units (CTUs). The Coding Tree Unit (CTU) is the basic processing unit of the High Efficiency Video Coding (HEVC) video standard and conceptually corresponds in structure to the macroblock unit used in several previous video standards. The CTU is sometimes also referred to as the Largest Coding Unit (LCU). The 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 it.

[0078] The CTU is typically sized 64 pixels × 64 pixels. Quadtree decomposition can be used to iteratively divide each CTU into smaller variable - sized Coding Units (CUs) 5.

[0079] The coding unit is the basic coding element and consists of two types of sub - units called Prediction Units (PUs) and Transform Units (TUs). 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 the prediction of pixel values. Various different partitions of the CU into PUs are possible, as shown in 606, 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 607.

[0080] 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 constant throughout the video sequence. Typically, 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 image (or frame). 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.

[0081] Figure 2 An example of a data communication system that can implement one or more embodiments of the present invention is illustrated. 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.

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

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

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

[0085] Although a streaming scenario is considered in the example of Figure 2 , 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.).

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

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

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

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

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

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

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

[0093] - A data storage component 304 such as a hard disk, etc., which is used to store the computer program for implementing the method of one or more embodiments of the present invention and the data used or generated during the implementation of one or more embodiments of the present invention;

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

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

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

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

[0098] The disc 306 can be replaced by any information medium such as a rewritable or non-rewritable compact disc (CD-ROM), ZIP disc, or memory card, and in general, by an information storage component readable by a microcomputer or microprocessor. The disc 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 the method for encoding a digital image sequence and / or the method for decoding a bitstream according to the present invention.

[0099] 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 disc 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 the device 300 (such as the hard disk 304, etc.) before execution.

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

[0101] 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).

[0102] 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, and each module is adapted to implement at least one corresponding step of at least one embodiment of the method for encoding an image in an image sequence according to at least one embodiment of the present invention, for example, in the form of programming instructions executed by the CPU 311 of the device 300.

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

[0104] After implementing the encoding process, the encoder 400 outputs a bitstream 410. The bitstream 410 includes a plurality of coding units or strips, and 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.

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

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

[0107] Temporal prediction is implemented by a motion estimation module 404 and a motion compensation module 405. First, a reference image is selected from a set of reference images 416, 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.

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

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

[0110] 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 the motion is homogeneous, the motion vector is encoded by the difference relative to a 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.

[0111] The encoder 400 further includes a selection module 406 that is configured 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 a transform module 407. Then, the obtained transformed data is quantized by a quantization module 408 and entropy encoded by an entropy encoding module 409. Finally, the encoded residual block of the currently encoded block is inserted into the bitstream 410.

[0112] 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 frame. An inverse quantization module 411 performs inverse quantization of the quantized data, followed by an inverse transform by an inverse transform module 412. An intra-inverse prediction module 413 uses prediction information to determine which predictor to use for a given block, and an inverse motion compensation module 414 actually adds the residual obtained by module 412 to a reference region obtained from a set of reference images 416.

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

[0114] 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 a CPU 311 of the device 300.

[0115] The decoder 60 receives a bitstream 61 including coding units, and each coding unit is composed 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 a module 62. Then the residual data is dequantized by a module 63, and then an inverse transform is applied by a module 64 to obtain pixel values.

[0116] The mode data for indicating the encoding mode is also entropy decoded, and based on this mode, the encoded blocks of the image data are decoded as intra type or inter type.

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

[0118] If the mode is inter-frame, 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.

[0119] 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 through module 66. A 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.

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

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

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

[0123] NAL units are divided into video coding layer (VCL) NAL units and non-VCL NAL units. VCL NAL units contain the actual encoded video data. 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. NAL unit 606 corresponds to a slice and constitutes the VCL NAL unit of the bitstream.

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

[0125] 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, a flag indicating that temporal prediction between sub-pictures is restricted to data from the same sub-picture is included. Another flag can enable or disable the loop filter across sub-picture boundaries.

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

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

[0128] 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 transmission of the same PPS.

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

[0130] The bitstream can also contain Supplemental 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 appear only once in the bitstream. In contrast, the APS defined for a slice can appear 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.

[0131] The Access Unit Delimiter (AUD) NAL unit 607 separates two access units. An access unit is a collection of NAL units, which may 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.

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

[0133] Table 1 Syntax AUD

[0134]

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

[0136] "pic_type indicates that the slice_type value of 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 of this version of the specification should be equal to 0, 1, or 2. Other values of pic_type are reserved for future use by ITUT|ISO / IEC. Decoders compliant with this version of the specification will ignore the reserved values of pic_type."

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

[0138] Table 2 Interpretation of pic_type

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

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

[0141] Each of the VCL NAL units 606 contains 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 3 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.

[0142] 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 in terms of blocks and slices.

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

[0144] NAL unit slice

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

[0146] Table 3 Slice layer syntax

[0147]

[0148] APS

[0149] The Adaptive Parameter Set (APS) NAL unit 605 is defined in Table 4 showing the syntax elements.

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

[0151] · ALF_AP: for ALF parameters

[0152] · LMCS_APS: for LMCS parameters

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

[0154] Table 4 Adaptive Parameter Set syntax

[0155]

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

[0157] ALF APS

[0158] 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 signaled filters 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.

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

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

[0161] 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).

[0162] Table 5 Adaptive Loop Filter Data Syntax

[0163]

[0164]

[0165]

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

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

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

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

[0170]

[0171]

[0172] Scaling list APS

[0173] 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 chrominance 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.

[0174] Table 7 Scaling list data syntax

[0175]

[0176]

[0177] Picture header

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

[0179] The relevant syntax elements that can be decoded involve:

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

[0181] · The type of the picture

[0182] · Output frame

[0183] · The number of pictures

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

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

[0186] · Color plane (if required)

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

[0188] · Incremental QP parameter (if required)

[0189] · Motion information parameter (if required)

[0190] · ALF parameter (if required)

[0191] · SAO parameter (if required)

[0192] · Quantization parameter (if required)

[0193] · LMCS parameter (if required)

[0194] · Scaling list parameter (if required)

[0195] · Picture header extension (if required)

[0196] · And so on

[0197] Picture "type"

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

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

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

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

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

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

[0204] ALF

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

[0206] The alf_info_in_ph_flag is defined as follows:

[0207] "alf_info_in_ph_flag being equal to 1 specifies that ALF information is present in the PH syntax structure and not in the slice header that refers to a PPS that does not contain the PH syntax structure. alf_info_in_ph_flag being equal to 0 specifies that ALF information is not present in the PH syntax structure and may be present in the slice header that refers to a PPS that does not contain the PH syntax structure."

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

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

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

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

[0212] LMCS

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

[0214] Scaling list

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

[0216] Sub-picture

[0217] When the sub-picture parameters are enabled at the SPS and if 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:

[0218] ·ph_virtual_boundaries_present_flag

[0219] ·ph_num_ver_virtual_boundaries

[0220] ·ph_virtual_boundaries_pos_x[i]

[0221] ·ph_num_hor_virtual_boundaries

[0222] ·ph_virtual_boundaries_pos_y[i]

[0223] Output flag

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

[0225] Reference picture list

[0226] If the reference picture list is signaled in the picture header (since rpl_info_in_ph_flag equals 1), then the parameters of the reference picture list ref_pic_lists() are decoded, which contain the following syntax elements:

[0227] ·rpl_sps_flag[]

[0228] ·rpl_idx[]

[0229] ·poc_lsb_lt[][]

[0230] ·delta_poc_msb_present_flag[][]

[0231] ·delta_poc_msb_cycle_lt[][]

[0232] Partition

[0233] If required, the set of partition parameters is decoded, and the set of partition parameters contains the following syntax elements:

[0234] ·partition_constraints_override_flag

[0235] ·ph_log2_diff_min_qt_min_cb_intra_slice_luma

[0236] ·ph_max_mtt_hierarchy_depth_intra_slice_luma

[0237] ·ph_log2_diff_max_bt_min_qt_intra_slice_luma

[0238] ·ph_log2_diff_max_tt_min_qt_intra_slice_luma

[0239] ·ph_log2_diff_min_qt_min_cb_intra_slice_chroma

[0240] ·ph_max_mtt_hierarchy_depth_intra_slice_chroma

[0241] ·ph_log2_diff_max_bt_min_qt_intra_slice_chroma

[0242] ·ph_log2_diff_max_tt_min_qt_intra_slice_chroma

[0243] ·ph_log2_diff_min_qt_min_cb_inter_slice

[0244] ·ph_max_mtt_hierarchy_depth_inter_slice

[0245] ·ph_log2_diff_max_bt_min_qt_inter_slice

[0246] ·ph_log2_diff_max_tt_min_qt_inter_slice

[0247] Weighted Prediction

[0248] 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().

[0249] When bi-predictive 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 8), when the weighted prediction parameters are sent in the picture header, the number of weights for each list is sent explicitly.

[0250] Table 8 Weighted Prediction Parameter Syntax

[0251]

[0252]

[0253]

[0254] Incremental QP

[0255] When the picture is intra, if necessary, decode ph_cu_qp_delta_subdiv_intra_slice and ph_cu_chroma_qp_offset_subdiv_intra_slice. And if inter slice strips are allowed, decode ph_cu_qp_delta_subdiv_inter_slice and ph_cu_chroma_qp_offset_subdiv_inter_slice when necessary. Finally, if necessary, decode the picture header extension syntax elements.

[0256] Signal 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 in the PPS.

[0257] Table 9 Picture Header Structure

[0258]

[0259]

[0260]

[0261]

[0262]

[0263]

[0264] Slice Header

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

[0266] Table 10 Partial Slice Header

[0267]

[0268]

[0269]

[0270]

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

[0272] Then, if necessary, decode slice_subpic_id to determine the sub-picture ID of the current slice. Then decode slice_address to determine the address of the current slice. If the number of blocks in the current picture is greater than 1, decode num_tiles_in_slice_minus1.

[0273] Then decode slice_type.

[0274] 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 equals 0), then decode the ALF information. This includes the flag indicating that ALF is enabled for the current slice (slice_alf_enabled_flag). If it is 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 if ALF is enabled for the chrominance component and which chrominance component is enabled. Then, if necessary, decode the APS IDs for chrominance (slice_alf_aps_id_chroma). In the same way, if necessary, decode slice_cc_alf_cb_enabled_flag to know if the CC ALF method is enabled. If the CC ALF is enabled and if the CC ALF is enabled for Cr and / or Cb, decode the relevant APS IDs for Cr and / or Cb.

[0275] If the color plane is sent independently (separate_colour_plane_flag equals 1), then decode colour_plane_id.

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

[0277] If the reference picture list is sent in the picture header (rpl_info_in_ph_flag equals 1) or the NAL unit is not an IDR, or if the reference picture list is sent for an IDR picture (sps_idr_rpl_present_flag equals 1), and if the reference count of at least one list is greater than 1, then the override flag num_ref_idx_active_override_flag is decoded.

[0278] If this flag is enabled, then the reference indices of each list are decoded.

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

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

[0281] If the delta QP information is sent in the slice header (qp_delta_info_in_ph_flag equals 0), then slice_qp_delta is decoded. If necessary, the syntax elements slice_cb_qp_offset, slice_cr_qp_offset, slice_joint_cbcr_qp_offset, cu_chroma_qp_offset_enabled_flag are decoded.

[0282] 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 the SAO enable flags for both luma and chroma are decoded: slice_sao_luma_flag, slice_sao_chroma_flag.

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

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

[0285] If LMCS is enabled in the picture header (ph_lmcs_enabled_flag equals 1), the flag slice_lmcs_enabled_flag is decoded.

[0286] In the same way, if the scaling list is enabled in the picture header (phpic_scaling_list_presentenabled_flag equals 1), the flag slice_scaling_list_present_flag is decoded.

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

[0288] Picture header in the slice header

[0289] In a specific signaling manner, 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, 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.

[0290] The flag picture_header_in_slice_header_flag is defined as follows:

[0291] "The picture_header_in_slice_header_flag being equal to 1 specifies the presence of the PH syntax structure in the slice header. The picture_header_in_slice_header_flag being equal to 0 specifies the absence of the PH syntax structure in the slice header.

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

[0293] When picture_header_in_slice_header_flag is equal to 1 for a coded slice, it is a bitstream conformance requirement that there should be no VCL NAL unit with nal_unit_type equal to PH_NUT in the CLVS.

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

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

[0296] Interaction between the picture header in the slice header and the signaling of tools in the picture header and slice header

[0297] QP delta information, reference picture list parameters, deblocking filter parameters, sample adaptive offset parameters, weighted prediction parameters, and ALF parameters can be signaled in either the picture header or the slice header, thanks to the following respective flags:

[0298] qp_delta_info_in_ph_flag

[0299] rpl_info_in_ph_flag

[0300] dbf_info_in_ph_flag

[0301] sao_info_in_ph_flag

[0302] wp_info_in_ph_flag

[0303] alf_info_in_ph_flag

[0304] Send these flags in the PPS.

[0305] As shown in Table 11 (Summary of signaling XXX according to the flags picture_header_in_slice_header_flag and xxx_info_in_ph_flag), by considering "xxx" of one of the tools mentioned, when xxx_info_in_ph_flag is set to equal 0 using the current syntax, xxx can be signaled in the slice header. In other words, we use the shorthand XXX or xxx in the subsequent description to refer to the type of information that can be signaled in both the picture header and the slice header (examples of which are given above).

[0306] Table 11 Summary of signaling XXX according to the flags picture_header_in_slice_header_flag and xxx_info_in_ph_flag

[0307]

[0308] When the picture header is in the slice header, this means that there is only one slice for the current picture. Therefore, making the information sendable or sent for both the slice and the picture does not increase the flexibility of the encoder or decoder because the parameters will be the same. In other words, if the information is in the picture header, the corresponding information in the slice header will be redundant. Similarly, if the information is in the slice header, the corresponding information in the picture header will be redundant. The embodiments described herein simplify decoder implementation by limiting the redundancy in the signaling of the same encoding. In particular, in an embodiment, when signaling the picture header in the slice header, the information is allowed to be in the picture header rather than in the slice header.

[0309] Streaming applications

[0310] 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). These extracted parts can then 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.

[0311] 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 the frames in the upper layer in the temporal hierarchy. However, for streaming applications that extract parts of the bitstream, it is necessary to track the APS ID to determine which APSs should be reserved for the sub - parts of the bitstream because the frames (due to IRAP) do not reset the numbering of the APS ID.

[0312] LMCS (Luminance Mapping with Chroma Scaling)

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

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

[0315] 1) The first sub - tool is an in - loop mapping of the luminance component based on an adaptive piece - wise 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 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".

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

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

[0318] Figure 8 Illustrates the principle of 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 using LMCS, some decoding operations are applied in the "mapping domain". These operations are represented by the Figure 8 dashed - line blocks in. They typically correspond to inverse quantization, inverse transform, intra - frame luminance prediction, and the reconstruction step (which consists of adding the luminance prediction and the luminance residual). Conversely, Figure 8The solid blocks in [ ] indicate the positions where decoding processes are applied in the original (i.e., non-mapped) domain, and this includes in-loop filtering such as deblocking, ALF, and SAO, motion-compensated prediction, and storage of decoded pictures as reference pictures (DPB).

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

[0320] Luminance mapping using a piecewise linear model

[0321] The luminance 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 parameters.

[0322] Semantics of luminance mapping

[0323] The syntax element lmcs_min_bin_idx specifies the minimum bin (interval) index used in the construction process of 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).

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

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

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

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

[0328] LMCS Intermediate Variable Calculation for Luminance Mapping

[0329] For applying forward and inverse luminance mapping processing, some intermediate variables and data arrays are required.

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

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

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

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

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

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

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

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

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

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

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

[0341] InputPivot[i] = i * OrgCW

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

[0343]

[0344] Forward luminance mapping

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

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

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

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

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

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

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

[0352] Luminance reconstruction samples

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

[0354] The reconstructed luminance picture samples recSamples[i][j] are simply obtained by adding predMapSample[i][j] to resiSamplei[i][j] as follows:

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

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

[0357] Inverse luminance mapping

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

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

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

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

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

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

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

[0365] Chroma scaling

[0366] LMCS semantics for chroma scaling

[0367] 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 should be in the range from 0 to 7 (including the end values). When it does not exist, it is inferred that lmcs_delta_abs_crs is equal to 0.

[0368] The syntax element lmcs_delta_sign_crs_flag specifies the sign of the variable lmcsDeltaCrs. When it does not exist, it is inferred that lmcs_delta_sign_crs_flag is equal to 0.

[0369] LMCS Intermediate Variable Calculation for Chroma Scaling

[0370] To apply chroma scaling processing, some intermediate variables are required.

[0371] The variable lmcsDeltaCrs is derived as follows:

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

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

[0374]

[0375] Chroma Scaling Processing

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

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

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

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

[0380]

[0381] The variable varScale is derived as follows:

[0382] varScale = ChromaScaleCoeff[idxYInv]

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

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

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

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

[0387] Encoder considerations

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

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

[0390] Embodiment of signaling information in the picture header instead of in the strip header

[0391] In an embodiment, when signaling the picture header in the strip header, the signaling of information that can be signaled in the picture header or strip header is signaled in the picture header instead of in the strip header. In an equivalent manner, when signaling the signaling of information that can be signaled in the picture header or strip header in the strip header, the picture header is not signaled in the strip header. In another equivalent manner, when signaling the signaling of information that can be signaled in the picture header or strip in the picture header, the picture header is signaled in the strip header. Table 12 shows the implementation of the embodiment with the tool name replaced by xxx. In this table, when signaling the picture header in the strip header, the signaling of parameters is not authorized in the strip header.

[0392] Summary of signaling in Table 12

[0393]

[0394] In one embodiment, the following conditions are added to the semantics of xxx_info_in_ph_flag:

[0395] "When the slice header of the reference PPS contains the PH syntax structure, it is a requirement for bitstream conformance that XXX_info_in_ph_flag shall be equal to 1."

[0396] And / or

[0397] "When XXX_info_in_ph_flag is equal to 0, picture_header_in_slice_header_flag shall be equal to 0."

[0398] When the picture header is in the slice header, this means that there is only one slice for the current picture. Therefore, making the information sendable or capable of being sent for both the slice and the picture does not increase the flexibility of the encoder or decoder because the parameters will be the same. In other words, if the information is in the picture header, the corresponding information in the slice header will be redundant. Similarly, if the information is in the slice header, the corresponding information in the picture header will be redundant. By forcing the condition such that in the case where the picture header is in the slice header, such information can be in the picture header and not in the slice header, the decoder implementation can be simplified by limiting the redundancy in signaling.

[0399] QP (Quantization Parameter) increment

[0400] In an embodiment, when signaling the picture header in the slice header, avoid signaling the QP increment in the slice header. In an equivalent manner, when signaling the QP increment in the slice header, do not signal the picture header in the slice header. In another equivalent manner, when signaling the QP increment in the picture header, signal the picture header in the slice header. In other words, the above tool XXX is the QP increment.

[0401] Table 13 shows a way that can be implemented such that when signaling the picture header in the slice header, signaling of QP increment information is not authorized (i.e., not allowed).

[0402] Table 13 Signaling of QP increment

[0403]

[0404] When the picture header is within the slice header (meaning there is only one slice for the current picture), sending information in both the slice and picture headers does not increase the flexibility of the encoder or decoder because the parameters will be the same. Therefore, to reduce decoder implementation complexity, it is preferable to have only one possible signaling of the QP delta information in either the slice or picture header to encode the same coding possibilities (in this case, the QP delta parameter (qp_delta_info)).

[0405] In the implementation of the first embodiment, the following conditions can be added to the semantics of qp_delta_info_in_ph_flag:

[0406] "When the slice header of the reference PPS contains the PH syntax structure, qp_delta_info_in_ph_flag shall be equal to 1 as a requirement for bitstream conformance."

[0407] And / or

[0408] "When qp_delta_info_in_ph_flag is equal to 0, picture_header_in_slice_header_flag shall be equal to 0."

[0409] In another embodiment, as depicted in Table 14, decoding of the QP delta parameter in the slice header is authorized only when the value of the flag picture_header_in_slice_header_flag is set to be equal to 0. The syntax modifications are underlined. In this table, if the QP delta information is signaled at the slice level (qp_delta_info_in_ph_flag equal to 0) and if the picture header is not sent in the slice header (picture_header_in_slice_header_flag equal to 0), then the slice_qp_delta information of the slice header can be decoded.

[0410] Table 14 shows the partial slice header with modifications to the QP delta

[0411]

[0412] In an embodiment, as depicted in Table 15, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, the decoding of the QP delta parameter in the picture header is systematically authorized. According to this table, the QP delta information in the slice header can be decoded only if the QP delta information is signaled in the picture header (qp_delta_info_in_ph_flag equal to 1) or if the picture header is sent in the slice header (picture_header_in_slice_header_flag equal to 1).

[0413] Table 15 shows a partial picture header depicting modifications to the QP delta

[0414]

[0415] Reference Picture List (RPL)

[0416] In one embodiment, when the picture header is signaled in the slice header, signaling of the reference picture list in the slice header is avoided. In an equivalent manner, when the signaling of the reference picture list is signaled in the slice header, the picture header is not signaled in the slice header. In another equivalent manner, when the signaling of the reference picture list is signaled in the picture header, the picture header is signaled in the slice header. In other words, the above tool XXX is RPL. In other words, the above tool XXX is RPL.

[0417] Table 16 shows the implementation of this embodiment, where when the picture header is signaled in the slice header, signaling of the RPL is not authorized.

[0418] Table 16 Summary of signaling of RPL

[0419]

[0420] When the picture header is in the slice header (meaning that for the current picture, there is only one slice), the sending of information in the slice and picture headers does not increase the flexibility of the encoder or decoder, because the parameters will be the same. According to this embodiment, the decoder implementation complexity is reduced because it is better to have only one possible signaling of the information in one of the slice and picture headers to encode the same coding possibilities (in this case, the reference picture list (RPL) information (rpl_info)).

[0421] In an embodiment, the following condition is added to the semantics of rpl_info_in_ph_flag:

[0422] "When the strip header of the reference PPS contains the PH syntax structure, it is a bitstream compliance requirement that rpl_info_in_ph_flag shall be equal to 1."

[0423] and / or

[0424] "When rpl_info_in_ph_flag is equal to 0, picture_header_in_slice_header_flag shall be equal to 0."

[0425] In an embodiment, as depicted in Table 17, decoding of the reference picture list parameters in the strip header is authorized only when the value of the flag picture_header_in_slice_header_flag is set to be equal to 0. In this table, if the reference picture list information is signaled at the strip level (rpl_info_in_ph_flag is equal to 0) and if the picture header is not sent in the strip header (picture_header_in_slice_header_flag is equal to 0), then the ref_pic_lists() information of the strip header can be decoded.

[0426] In an embodiment, as depicted in Table 17, when the picture header is in the strip header, the temporal parameters slice_collocated_from_l0_flag and slice_collocated_ref_idx cannot be decoded.

[0427] Table 17 shows the modified partial strip header of the RPL

[0428]

[0429]

[0430] In an embodiment, as depicted in Table 18, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, decoding of the RPL parameters in the picture header is systematically authorized. In this table, the RPL information of the picture header can be decoded only if the RPL information is signaled at the picture level (rpl_info_in_ph_flag is equal to 1) or if the picture header is sent in the strip header (picture_header_in_slice_header_flag is equal to 1).

[0431] In an embodiment, as depicted in Table 18, when the picture header is in the slice header, the temporal parameters ph_collocated_from_flag and ph_collocated_ref_idx can be decoded.

[0432] Table 18 shows the modified partial picture header of RPL

[0433]

[0434]

[0435] Deblocking Filter (DBF)

[0436] In an embodiment, when signaling the picture header in the slice header, signaling of deblocking filter parameters in the slice header is avoided. In an equivalent manner, when signaling of deblocking filter parameters is signaled in the slice header, the picture header is not signaled in the slice header. In another equivalent manner, when signaling of deblocking filter parameters is signaled in the picture header, the picture header is signaled in the slice header. In other words, the above tool XXX is DBF. In other words, the above tool XXX is DBF.

[0437] Table 19 shows the implementation according to this embodiment, where signaling of DBF is not authorized when signaling the picture header in the slice header.

[0438] Table 19 Summary of signaling of DBF

[0439]

[0440] When the picture header is in the slice header, since there is only one slice for the current picture, the information sent in the slice or picture does not increase the flexibility of the encoder or decoder because the parameters are the same. Therefore, to reduce decoder implementation complexity, it is preferable to have only one possible signaling of DBF information to encode the same coding possibilities.

[0441] In an embodiment, the following condition is added to the semantics of dbf_info_in_ph_flag:

[0442] "When the slice header of the reference PPS contains the PH syntax structure, it is a requirement for bitstream conformance that dbf_info_in_ph_flag shall be equal to 1."

[0443] and / or

[0444] "When dbf_info_in_ph_flag is equal to 0, picture_header_in_slice_header_flag shall be equal to 0."

[0445] In an embodiment, as depicted in Table 20, the DBF parameters in the slice header are authorized only when the value of the flag picture_header_in_slice_header_flag is set to be equal to 0. In this table, if the DBF information is signaled at the slice level (dbf_info_in_ph_flag equal to 0), and if the picture header is not sent in the slice header (picture_header_in_slice_header_flag equal to 0), then the slice_deblocking_filter_override_flag flag of the slice header can be decoded.

[0446] Table 20 shows the modified partial slice header of DBF

[0447]

[0448] In an embodiment, as depicted in Table 21, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, the DBF parameters in the picture header are systematically authorized. In this table, the DBF information of the slice header can be decoded only if the DBF information is signaled in the picture header (dbf_info_in_ph_flag equal to 1) or if the picture header is sent in the slice header (picture_header_in_slice_header_flag equal to 1).

[0449] Table 21 shows the modified partial picture header of DBF

[0450]

[0451] SAO (Sample Adaptive Offset)

[0452] In one embodiment, when the picture header is signaled in the slice header, signaling of SAO in the slice header is avoided. In an equivalent manner, when the signaling of SAO is signaled in the slice header, the picture header is not signaled in the slice header. In another equivalent manner, when the signaling of SAO is signaled in the picture header, the picture header is signaled in the slice header. In other words, the above tool XXX is SAO.

[0453] Table 22 shows this embodiment, where when signaling the picture header in the slice header, signaling of SAO is not authorized.

[0454] Table 22 Summary of SAO Signaling

[0455]

[0456] When the picture header is in the slice header, since there is only one slice for the current picture, the information sent in the slice or picture does not increase the flexibility of the encoder or decoder because the parameters are the same. Therefore, to reduce decoder implementation complexity, it is preferable to have only one possible signaling of SAO information to encode the same coding possibilities.

[0457] In the embodiment, the following conditions are added to the semantics of sao_info_in_ph_flag:

[0458] "When the slice header of the reference PPS contains the PH syntax structure, sao_info_in_ph_flag shall be equal to 1 as a requirement for bitstream conformance."

[0459] And / or

[0460] "When sao_info_in_ph_flag is equal to 0, picture_header_in_slice_header_flag shall be equal to 0."

[0461] In the embodiment, as depicted in Table 23, decoding of the SAO parameters in the slice header is authorized only when the value of the flag picture_header_in_slice_header_flag is set to be equal to 0. In this table, the slice_sao_luma_flag flag of the slice header can be decoded only if SAO information is signaled at the slice level (sao_info_in_ph_flag is equal to 0) and if the picture header is not sent in the slice header (picture_header_in_slice_header_flag is equal to 0).

[0462] Table 23 shows the modified partial slice header of SAO

[0463]

[0464]

[0465] In an embodiment, as depicted in Table 24, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, the decoding of SAO parameters in the picture header is systematically authorized. In this table, the SAO information in the slice header can be decoded only if the SAO information is signaled in the picture header (sao_info_in_ph_flag equal to 1) or the picture header is sent in the slice header (picture_header_in_slice_header_flag equal to 1).

[0466] Table 24 shows the modified partial picture header of SAO

[0467]

[0468] Weighted Prediction (WP)

[0469] In one embodiment, when the picture header is signaled in the slice header, signaling of weighted prediction is avoided in the slice header. In an equivalent manner, when the signaling of weighted prediction is signaled in the slice header, the picture header is not signaled in the slice header. In another equivalent manner, when the signaling of weighted prediction is signaled in the picture header, the picture header is signaled in the slice header. In other words, the above tool XXX is WP.

[0470] As depicted in Table 25, when wp_info_in_ph_flag is set to be equal to 0 using the current syntax, WP parameters can be signaled in the slice header.

[0471] Table 25 shows the implementation of this embodiment, where the signaling of WP is not authorized when the picture header is signaled in the slice header.

[0472] Table 25 Summary of the signaling of WP

[0473]

[0474] When the picture header is in the slice header, since there is only one slice for the current picture, the information sent in the slice or picture does not increase the flexibility of the encoder or decoder because the parameters are the same. Therefore, in order to reduce the decoder implementation complexity, it is preferable to have only one possible signaling of WP information to encode the same coding possibilities.

[0475] In an embodiment, the following condition is added to the semantics of wp_info_in_ph_flag:

[0476] "When the slice header of the reference PPS contains the PH syntax structure, it is a bitstream conformity requirement that wp_info_in_ph_flag shall be equal to 1."

[0477] and / or

[0478] "When wp_info_in_ph_flag is equal to 0, picture_header_in_slice_header_flag shall be equal to 0".

[0479] In an embodiment, as depicted in Table 26, the decoding of the WP parameters in the slice header is authorized only when the value of the flag picture_header_in_slice_header_flag is set to be equal to 0. In this table, if the WP information is signaled at the slice level (wp_info_in_ph_flag equal to 0) and if the picture header is not sent in the slice header (picture_header_in_slice_header_flag equal to 0), then the pred_weight_table() function containing the weighted prediction parameters can be decoded.

[0480] Table 26 shows the modified partial slice header for WP

[0481]

[0482] In an embodiment, as depicted in Table 27, when the value of picture_header_in_slice_header_flag is set to be equal to 1, the decoding of the WP parameters in the picture header is systematically authorized. In this table, the WP information can be decoded only if the WP information is signaled in the picture header (wp_info_in_ph_flag equal to 1) or if the picture header is sent in the slice header (picture_header_in_slice_header_flag equal to 1).

[0483] Table 27 shows the modified partial picture header for WP

[0484]

[0485] ALF

[0486] In one embodiment, when signaling a picture header in a slice header, signaling of the ALF is avoided in the slice header. In an equivalent manner, when signaling of the ALF is signaled in the slice header, the picture header is not signaled in the slice header. In another equivalent manner, when signaling of the ALF is signaled in the picture header, the picture header is signaled in the slice header. In other words, the above tool XXX is the ALF.

[0487] In fact, currently when signaling a picture header in a slice header (picture_header_in_slice_header_flag = 1) and when signaling the ALF in the slice header (alf_info_in_ph_flag = 0), all parameters of the picture header should be parsed before obtaining the ALF APS ID. Thus, the complexity of parsing for some streaming applications is increased because all variables such as PPS, SPS, picture header, etc. should be maintained in memory to parse the ALF APS ID.

[0488] Furthermore, when the picture header is in the slice header, since there is only one slice for the current picture, the information sent in the slice or picture does not increase the flexibility of the encoder or decoder because the parameters are the same. Thus, to reduce decoder implementation complexity, it is better to have only one possible signaling to encode the same coding possibilities.

[0489] Table 28 shows this embodiment where when signaling a picture header in the slice header, signaling of the ALF is not authorized.

[0490] Table 28 Summary of Signaling of the ALF

[0491]

[0492] In the embodiment, the following conditions are added to the semantics of alf_info_in_ph_flag:

[0493] "When the slice header referring to the PPS contains the PH syntax structure, alf_info_in_ph_flag shall be equal to 1 as a requirement for bitstream conformity."

[0494] And / or

[0495] "When alf_info_in_ph_flag is equal to 0, picture_header_in_slice_header_flag shall be equal to 0."

[0496] In an embodiment, as depicted in Table 29, decoding of the ALF parameter in the slice header is authorized only when the value of the flag picture_header_in_slice_header_flag is set to be equal to 0. In this table, the ALF information in the slice header can be decoded only if ALF is enabled at the SPS level (sps_alf_enabled_flag is equal to 1) and if ALF information is signaled at the slice level (alf_info_in_ph_flag is equal to 0) and if a picture header is not sent in the slice header (picture_header_in_slice_header_flag is equal to 0).

[0497] Table 29 shows the modified partial slice header for ALF

[0498]

[0499]

[0500] In an embodiment, as depicted in Table 30, decoding of the ALF parameter in the picture header is systematically authorized when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1. In this table, the ALF information in the slice header can be decoded only if ALF is enabled at the SPS level (sps_alf_enabled_flag is equal to 1) and ALF information is signaled at the picture level (alf_info_in_ph_flag is equal to 1) or a picture header is sent in the slice header (picture_header_in_slice_header_flag is equal to 1).

[0501] Table 30 shows the modified partial picture header for ALF

[0502]

[0503]

[0504] All tools / parameters

[0505] In one embodiment, when a picture header is signaled in the slice header, all tools (and / or parameters) that can be signaled in the picture header or in the slice header are restricted to being signaled in the picture header. As mentioned in the above description, in an embodiment, the relevant tools are: QP delta information, reference picture list, deblocking filter, SAO weighted prediction, and ALF. However, other tools are possible in cases where other tools can be signaled in both the slice and picture headers.

[0506] This can be expressed by adding the following constraints:

[0507] "When at least one of the flags rpl_info_in_ph_flag, dbf_info_in_ph_flag, sao_info_in_ph_flag, alf_info_in_ph_flag, wp_info_in_ph_flag, qp_delta_info_in_ph_flag is set to be equal to 0, the value of picture_header_in_slice_header_flag shall be equal to 0."

[0508] And / or by adding:

[0509] "When picture_header_flag_in_slice_header_flag is equal to 1, the flags rpl_info_in_ph_flag, dbf_info_in_ph_flag, sao_info_in_ph_flag, wp_info_in_ph_flag, qp_delta_info_in_ph_flag shall be equal to 1."

[0510] And / or by adding the following constraints to each XXX_info_in_ph_flag:

[0511] "When the slice header of the reference PPS contains the PH syntax structure, it is a requirement for bitstream conformance that XXX_info_in_ph_flag shall be equal to 1."

[0512] When all these parameters are signaled in the same header, the decoder implementation complexity is reduced because it is preferable to have only one possible signaling to encode the same coding possibilities.

[0513] Embodiment of the signaling order

[0514] In an alternative embodiment to the previous embodiment related to ALF, as depicted in Table 31, the information related to the ALF APS ID in the slice header is set before the picture header structure. With this embodiment, when ALF is signaled in the slice header and when the picture header is signaled in the slice header, the APS ID can be obtained quickly without parsing all the parameters of the picture header.

[0515] Table 31 shows the modified partial slice header

[0516]

[0517]

[0518] Example of the number of weights

[0519] In an example, as depicted in the partial table of syntax element table 32, when the picture header is within the slice header, the number of weights for weighted prediction of each of the lists L0, L1 is decoded. Thus, signaling of the number of weights can be restricted to the picture header.

[0520] Table 32 Partial syntax table for weighted prediction parameters

[0521]

[0522] Summary of an example of signaling information in the slice header rather than in the picture header

[0523] In one example, when signaling the picture header in the slice header, signaling of information that can be signaled in the picture header or in the slice header is signaled in the slice header rather than in the picture header. In an equivalent manner, when signaling of information that can be signaled in the picture header or in the slice header is signaled in the picture header, the picture header is not signaled in the slice header. In another equivalent manner, when signaling of information that can be signaled in the picture header or in the slice header is signaled in the slice header, the picture header is signaled in the slice header. Table 33 shows this example, where the tool (or parameter) name is replaced with XXX. In this table, when the picture header is signaled in the slice header, signaling of parameters is not permitted in the picture header.

[0524] Summary of signaling of tools

[0525]

[0526] In one example, the following condition is added to the semantics of XXX_info_in_ph_flag:

[0527] "When the slice header of the reference PPS contains the PH syntax structure, XXX_info_in_ph_flag shall be equal to 0 as a requirement for bitstream conformance"

[0528] And / or

[0529] "When XXX_info_in_ph_flag is equal to 1, picture_header_in_slice_header_flag shall be equal to 0"

[0530] When the picture header is within the slice header, this means that there is only one slice for the current picture. Thus, sending or making information sendable for both the slice and the picture does not increase the flexibility of the encoder or decoder because the parameters will be the same. In other words, if the information is in the picture header, the corresponding information in the slice header will be redundant. Similarly, if the information is in the slice header, the corresponding information in the picture header will be redundant. The embodiments described herein simplify decoder implementation by limiting redundancy in the signaling of the same coded signals. In particular, in an embodiment, when signaling the picture header in the slice header, the information is allowed to be in the slice header rather than in the picture header.

[0531] QP Delta

[0532] In one embodiment, the tool XXX is the QP Delta. In an embodiment, as depicted in Table 33, when the value of the flag picture_header_in_slice_header_flag is set to equal 1, decoding of the QP Delta parameter in the slice header is authorized. In an equivalent manner, as depicted in Table 33, when signaling the QP Delta parameter in the picture header, picture_header_in_slice_header_flag is set to equal 0. In another equivalent manner, as depicted in Table 33, when signaling the QP Delta parameter in the slice header, picture_header_in_slice_header_flag is set to equal 1. In this table, the slice_qp_delta information of the slice header can be decoded if the QP Delta information is signaled at the slice level (qp_delta_info_in_ph_flag equal to 0) or if the picture header is sent in the slice header (picture_header_in_slice_header_flag equal to 1).

[0533] This can be obtained by adding to the semantics:

[0534] "When the slice header referring to the PPS contains the PH syntax structure, it is a requirement for bitstream conformance that qp_delta_info_in_ph_flag shall be equal to 0."

[0535] and / or

[0536] "When qp_delta_info_in_ph_flag is equal to 1, picture_header_in_slice_header_flag shall be equal to 0".

[0537] In an embodiment, as depicted in Table 35, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, decoding of the QP delta parameter in the picture header is systematically avoided. In this table, the QP delta information of the picture header can be decoded only if the QP delta information is signaled in the picture header (qp_delta_info_in_ph_flag equal to 1) and if picture_header_in_slice_header_flag is set to be equal to 0.

[0538] RPL (Reference Picture List)

[0539] In one embodiment, the tool XXX is the reference picture list. In an embodiment, as depicted in Table 33, decoding of the reference picture list parameter in the slice header is authorized only when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1. In an equivalent manner, as depicted in Table 33, when the reference picture list parameter is signaled in the picture header, picture_header_in_slice_header_flag is set to be equal to 0. In another equivalent manner, as depicted in Table 33, when the reference picture list parameter is signaled in the slice header, picture_header_in_slice_header_flag is set to be equal to 1. In this table, if the reference picture list information is signaled at the slice level (rpl_info_in_ph_flag equal to 0) and if the picture header is sent in the slice header (picture_header_in_slice_header_flag equal to 1), then the ref_pic_list() information of the slice header can be decoded.

[0540] In an embodiment, as depicted in Table 34, when the picture header is in the slice header, the temporal parameters slice_collocated_from_l0_flag and slice_collocated_ref_idx can be decoded.

[0541] In an embodiment, as depicted in Table 35, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, the decoding of the RPL parameters in the picture header is systematically avoided. In this table, the RPL information in the picture header can be decoded only if the RPL information is signaled at the picture level (rpl_info_in_ph_flag equal to 1) and if picture_header_in_slice_header_flag is set to be equal to 0.

[0542] In an embodiment, as depicted in Table 35, when the picture header is in the slice header, the temporal parameters ph_collocated_from_l0_flag and ph_collocated_ref_idx cannot be decoded.

[0543] Deblocking Filter (DBF)

[0544] In one embodiment, the tool XXX is the Deblocking Filter (DBF). In an alternative or additional embodiment, as depicted in Table 33, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, the DBF parameters in the slice header are authorized. In an equivalent manner, as depicted in Table 33, when the DBF parameters are signaled in the picture header, picture_header_in_slice_header_flag is set to be equal to 0. In another equivalent manner, as depicted in Table 33, in the case where the DBF parameters are signaled in the slice header, picture_header_in_slice_header_flag is set to be equal to 1. In this table, if the DBF information is signaled at the slice level (dbf_info_in_ph_flag equal to 0) or if the picture header is sent in the slice header (picture_header_in_slice_header_flag equal to 1), then the slice_deblocking_filter_override_flag flag in the slice header can be decoded.

[0545] In an embodiment, as depicted in Table 35, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, the DBF parameter in the picture header is systematically avoided. In this table, the DBF information of the picture header can be decoded only if the DBF information is signaled in the picture header (dbf_info_in_ph_flag is equal to 1) and if picture_header_in_slice_header_flag is equal to 0.

[0546] Sample Adaptive Offset (SAO)

[0547] In one embodiment, the tool XXX is SAO (Sample Adaptive Offset). In an alternative or additional embodiment, as depicted in Table 33, the SAO parameter in the slice header is authorized only when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1. In an equivalent manner, as depicted in Table 33, when the SAO parameter is signaled in the picture header, the value of picture_header_in_slice_header_flag is set to be equal to 0. In another equivalent manner, as depicted in Table 33, when the SAO parameter is signaled in the slice header, picture_header_in_slice_header_flag is set to be equal to 1. In this table, if the SAO information is signaled at the slice level (sao_info_in_ph_flag is equal to 0) and if the picture header is sent in the slice header (picture_header_in_slice_header_flag is equal to 1), the slice_sao_luma_flag flag of the slice header can be decoded.

[0548] In an embodiment, as depicted in Table 35, when the value of the flag picture_header_in_slice_header_flag is set to be equal to 1, the SAO parameter in the picture header is systematically avoided. In this table, the SAO information of the picture header can be decoded only if the SAO information is signaled in the picture header (sao_info_ph_flag is equal to 1) and if picture_header_in_slice_header_flag is set to be equal to 0.

[0549] Weighted Prediction (WP)

[0550] In one embodiment, the tool XXX is WP (weighted prediction). In the embodiment, as depicted in Table 33, the WP parameters in the slice header are authorized only when the value of the flag picture_header_in_slice_header_flag is set to equal 1. In an equivalent manner, as depicted in Table 33, when the WP parameters are signaled in the picture header, picture_header_in_slice_header_flag is set to equal 0. In another equivalent manner, as depicted in Table 33, when the WP parameters are signaled in the slice header, picture_header_in_slice_header_flag is set to equal 1. In this table, if the WP information is signaled at the slice level (wp_info_in_ph_flag equals 0) or if the picture header is sent in the slice header (picture_header_in_slice_header_flag equals 1), then the pred_weight_table() function containing the weighted prediction parameters can be decoded.

[0551] In an additional embodiment, as described in Table 35, when the value of the flag picture_header_in_slice_header_flag is set to equal 1, the decoding of the WP parameters in the picture header is systematically avoided. In this table, the WP information can be decoded only if the WP information is signaled in the picture header (wp_info_in_ph_flag equals 1) and if picture_header_in_slice_header_flag is set to equal 0.

[0552] ALF (Adaptive Loop Filter)

[0553] In one embodiment, tool XXX is an ALF (Adaptive Loop Filter). In the embodiment, as depicted in Table 33, decoding of the ALF parameters in the slice header is authorized only if the value of the flag picture_header_in_slice_header_flag is set to equal 1. In an equivalent manner, as depicted in Table 33, when the ALF parameters are signaled in the picture header, picture_header_in_slice_header_flag is set to equal 0. In another equivalent manner, as depicted in Table 33, when the ALF parameters are signaled in the slice header, picture_header_in_slice_header_flag is set to equal 1. In this table, the ALF information of the slice header can be decoded only if ALF is enabled at the SPS level (sps_alf_enabled_flag equals 1) and if the ALF information is signaled at the slice level (alf_info_in_ph_flag equals 1) and if the picture header is sent in the slice header (picture_hearder_in_slice_flag equals 1).

[0554] In the embodiment, as depicted in Table 35, decoding of the ALF parameters in the picture header is systematically avoided when the value of picture_header_slice_header_flag is set to equal 1. In this table, the ALF information of the slice header can be decoded only if ALF is enabled at the SPS level (sps_alf_enabled_flag equals 1) and if the ALF information is signaled at the picture level (alf_info_in_ph_flag equals 1) and if picture_hearder_in_slice_flag is set to equal 0.

[0555] Table 34 shows the modified partial slice header

[0556]

[0557]

[0558]

[0559] Table 35 shows the modified partial picture header

[0560]

[0561]

[0562] All tools / parameters

[0563] In an embodiment, when signaling the picture header in the slice header, all tools (and / or parameters) that can be signaled in either the picture header or the slice header are signaled in the slice header. As mentioned in the above description of the embodiment, the relevant tools are: QP delta information, reference picture list, deblocking filter, SAO weighted prediction, and ALF. However, other tools are also possible in cases where other tools can be signaled in both the slice and picture headers.

[0564] This can be expressed by adding the following constraint:

[0565] "When at least one of the flags rpl_info_in_ph_flag, dbf_info_in_ph_flag, sao_info_in_ph_flag, alf_info_in_ph_flag, wp_info_in_ph_flag, qp_delta_info_in_ph_flag is set to equal 1, the value of picture_header_in_slice_header_flag shall be equal to 0."

[0566] And / or by adding the following constraint:

[0567] "When picture_header_in_slice_header_flag is equal to 1, the flags rpl_info_in_ph_flag, dbf_info_in_ph_flag, sao_info_in_ph_flag, wp_info_in_ph_flag, qp_delta_info_in_ph_flag shall be equal to 0."

[0568] And / or by adding the following constraint to each XXX_info_in_ph_flag:

[0569] "When the slice header of the reference PPS contains the PH syntax structure, it is a requirement for bitstream conformance that XXX_info_in_ph_flag shall be equal to 0."

[0570] When signaling all these parameters in the same header, the complexity of decoder implementation is reduced because it is better to have only one possible signaling for tools or parameters that will necessarily have the same value or attribute.

[0571] Implementation

[0572] Figure 10Systems 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 191. 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 the user's request 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 video signal 109 and / or audio signal, and then the user terminal uses video signal 109 and / or audio signal to provide the requested content to the user.

[0573] Any step of the 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 one or more hardware-based processing units 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, circuit systems, 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 circuit systems. 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.

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

[0575] 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 disc (CD), digital versatile disc (DVD) or Blu-ray disc (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 dedicated components such as an FPGA ("field programmable gate array") or an ASIC ("application specific integrated circuit").

[0576] Figure 11Schematic 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 an embodiment 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 computer programs 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 external devices (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) 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.

[0577] 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 yet 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 the encoder to encode. Refer to the following Figure 11 and 12 Two such examples are provided.

[0578] Network camera

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

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

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

[0582] 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 can be a still image or a video image.

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

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

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

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

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

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

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

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

[0591] The control unit 2118 of the client device 2104 controls other units in the client device 2104 according to a user operation or command received by the communication unit 2114.

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

[0593] 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).

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

[0595] The control unit 2118 of the client device 2104 controls the communication unit 2114 of the client device 2104 according to a user operation input to the GUI displayed on the display device 2120, so as to transmit a command for specifying values of parameters of the network camera 2102 to the network camera 2102.

[0596] Smartphone

[0597] Figure 12 is a diagram illustrating the smartphone 2200.

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

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

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

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

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

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

[0604] 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, may be combined in any combination, except for combinations in which at least some of such features and / or steps are mutually exclusive. Unless otherwise expressly stated, each feature disclosed in this specification (including any appended claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose. Therefore, unless otherwise expressly stated, each disclosed feature is only an example of a general series of equivalent or similar features.

[0605] 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) may 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, e.g., during a decoding process.

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

[0607] 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, the bitstream including video data, a picture header, a slice header, and flags, wherein, The video data corresponds to one or more strips, 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 flag indicates whether the picture header is in the strip header. The method includes: Decoding the bitstream using the syntax elements, wherein, when information that can be signaled in the picture header or in the strip header is signaled in the picture header, the flag is required to have a value indicating that the picture header is not in the strip header, and wherein the information that can be signaled in the picture header or the strip header is an adaptive parameter set ID for adaptive loop filtering, i.e., ALF, and the adaptive parameter set, i.e., APS, indicated by the adaptive parameter set ID includes a flag indicating whether a cropping index related to ALF is to be decoded for luma.

2. The method according to claim 1, wherein, The decoding further includes: parsing a first syntax element indicating whether the information is to be signaled in the picture header, and allowing the information that can be signaled in the strip header and the picture header to be parsed in only one of the strip header and the picture header based on the first syntax element.

3. The method according to claim 2, wherein The first syntax element is information in the picture parameter set flag.

4. The method according to claim 3, wherein When the first syntax element indicates that the information is signaled in the picture header, parsing of the information in the strip header is not allowed.

5. The method according to claim 1, wherein, The picture header is picture_header_structure().

6. The method according to claim 1, wherein, The flag indicating whether one or more of the cropping indices are to be decoded for luma is alf_luma_clip_flag, and each cropping index corresponds to alf_luma_clip_idx.

7. The method according to claim 1, wherein, The adaptive parameter set, i.e., APS, indicated by the adaptive parameter set ID includes information corresponding to the number of filters for luma.

8. A method for decoding video data, the method including: Receiving a bitstream including video data, a picture header, a strip header, and a flag, wherein the video data corresponds to one or more strips, 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 flag indicates whether the picture header is in the strip header, wherein when the bitstream includes a syntax element having a value indicating that information that can be signaled in the picture header or in the strip header is signaled in the picture header, the value of the flag must indicate that the picture header is not in the strip header; and Decoding the bitstream using the syntax elements, Wherein, the information that can be signaled in the picture header or the slice header is an adaptive parameter set ID for adaptive loop filtering, i.e., ALF, and the adaptive parameter set, i.e., APS, indicated by the adaptive parameter set ID includes a flag indicating whether to decode a clipping index related to ALF for luma.

9. A method for encoding video data into a bitstream, the video data corresponding to one or more slices, 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, and a flag indicating whether the picture header is in the slice header, the method comprising: Encoding the video data using the syntax elements, Wherein, when the information that can be signaled in the picture header is signaled in the picture header, the flag has a value indicating that the picture header is not in the slice header, and Wherein, the information that can be signaled in the picture header or the slice header is an adaptive parameter set ID for adaptive loop filtering, i.e., ALF, and the adaptive parameter set, i.e., APS, indicated by the adaptive parameter set ID includes a flag indicating whether to decode a clipping index related to ALF for luma.

10. The method according to claim 9, wherein, The encoding further includes: encoding a first syntax element indicating whether to signal the information in the picture header, and allowing the information that can be signaled in the slice header and the picture header to be encoded in only one of the slice header and the picture header based on the first syntax element.

11. The method according to claim 10, wherein, The first syntax element is information in a picture parameter set flag.

12. The method according to claim 10, wherein When the first syntax element indicates that the information is signaled in the picture header, encoding of the information in the slice header is not allowed.

13. The method according to claim 9, wherein, The picture header is picture_header_structure().

14. The method according to claim 9, wherein, The flag indicating whether to decode one or more of the clipping indexes for coefficients used in the filter for luma is alf_luma_clip_flag, and each of the clipping indexes corresponds to alf_luma_clip_idx.

15. The method according to claim 9, wherein, The flag indicating whether the picture header is in the slice header is signaled in the slice header.

16. An apparatus for decoding video data from a bitstream, comprising a decoder configured to perform the method according to any one of claims 1 to 8.

17. An apparatus for encoding video data into a bitstream, comprising an encoder configured to perform the method according to any one of claims 9 to 15.

18. A computer-readable storage medium storing a computer program, which when running on a computer or a processor causes the computer or the processor to perform the method according to any one of claims 1 to 15.

19. A computer program product comprising a computer program which, when run on a computer or a processor, causes the computer or the processor to perform the method according to any one of claims 1 to 15.

Images