High-Level Syntax for Video Encoding and Decoding

Abstract

To provide a method and a device for decoding video data, and a decoding device and method.SOLUTION: A decoding method includes decoding video data from a bitstream by using a plurality of decoded syntax elements. When information signalled in a picture header or a slice header is signalled in the picture header, the bitstream is restricted so that a flag is decoded which has a value indicating that the picture header is not in the slice header. The information which may be signalled in the picture header or the slice header is an adaptation parameter set id for adaptive loop filter (ALF). The adaptation parameter set indicated by the adaptation parameter set id can include an alf_luma_clip_flag related to the ALF, and a clipping index for the ALF is decoded according to a value of the alf_luma_clip_flag.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to video encoding and decoding, and in particular to high level syntax used in the bitstream. [Background technology]

[0002] Recently, the Joint Video Experts Team (JVET), a joint team formed by MPEG and VCEG of ITU-T Study Group 16, has begun work on a new video coding standard called Versatile Video Coding (VVC). The goal of VVC is to provide a significant improvement in compression performance (typically double that of the previous standard) compared to the existing HEVC standard, and it is expected to be completed in 2020. Primary target applications and services include, but are not limited to, 360-degree video and high dynamic range (HDR) video. JVET evaluated responses from 32 organizations through formal subjective testing by an independent test lab. Some proposals showed compression efficiency improvements of typically 40% or more compared to using HEVC. This was particularly effective for ultra-high definition (UHD) video test material. Thus, compression efficiency improvements are expected to far exceed the 50% goal of the final standard.

[0003] The JVET Exploration Model (JEM) uses all the HEVC tools and introduces many new ones. These changes have necessitated changes to the bitstream structure, especially the high-level syntax, which may affect the overall bitrate of the bitstream. Summary of the Invention

[0004] The present invention relates to an improved high-level syntax structure that reduces complexity without compromising coding performance.

[0005] According to a first 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 slices, the bitstream including a picture header including a plurality of syntax elements to be used when decoding one or more slices, and a slice header including a plurality of syntax elements to be used when decoding a slice, the decoding comprising: imposing (e.g., constraining) that the picture header is not in the slice header if information that may be signaled in the picture header or in the slice header is signaled in the picture header; and decoding the bitstream using the plurality of syntax elements.

[0006] Optionally, the decoding further includes parsing a first syntax element indicating whether the information is signaled in the picture header or not, and allowing the parsing of the information that may be signaled in a slice header and a picture header in only one of the slice header or 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, if the first syntax element indicates that the information is signaled in the picture header, parsing of the information in the slice header is not allowed.

[0009] Optionally, the method further includes parsing a second syntax element indicating whether the picture header is within the slice header, and it is a requirement of bitstream conformance that if the first syntax element indicates that the information is signaled within the picture header, then the second syntax element indicates that the picture header is not within the slice header.

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

[0011] Optionally, said information includes all information that can be signaled in the picture header and in 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, ph_collocated_ref_idx.

[0013] According to a second 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 slices, the bitstream including a picture header including a plurality of syntax elements to be used when decoding one or more slices, and a slice header including a plurality of syntax elements to be used when decoding a slice, the encoding including: if information that may be signaled in the picture header or in the slice header is signaled in the picture header, signaling that the picture header is not in the slice header; and encoding the video data using the plurality of syntax elements.

[0014] Optionally, the encoding further includes encoding a first syntax element indicating whether the information is signaled in the picture header or not, and allowing encoding of the information that may be signaled in a slice header and a picture header only in either the slice header or 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, if 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.

[0017] Optionally, the method further includes parsing a second syntax element indicating whether the picture header is within the slice header, and it is a requirement of bitstream conformance that if the first syntax element indicates that the information is signaled within the picture header, then the second syntax element indicates that the picture header is not within the slice header.

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

[0019] Optionally, said information includes all information that can be signaled in the picture header and in 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, ph_collocated_ref_idx.

[0021] In an alternative aspect of the present invention, a method is provided for decoding video data from a bitstream, the bitstream including video data corresponding to one or more slices, the bitstream including a picture header including syntax elements for use when decoding the one or more slices, and a slice header including syntax elements for use when decoding the slices, the decoding including imposing information that can be signaled in the picture header or slice header if it is signaled in the slice header that is not signaled 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 slices, the bitstream including a picture header including syntax elements to be used when decoding the one or more slices, and a slice header including syntax elements to be used when decoding the slices, the decoding including treating as inapplicable a combination of (a) a syntax element indicating that the tool information is signaled in a picture header rather than a slice header and (b) a syntax element indicating that the tool information is signaled in the slice header, and decoding the bitstream using the syntax elements. The decoding is not performed if the combination of syntax elements (a) and (b) that are treated as inapplicable are present.

[0023] According to a related aspect of the invention, a bitstream includes video data corresponding to one or more slices, a picture header including syntax elements used when decoding the one or more slices, and a slice header including syntax elements used when decoding the slice. The bitstream has a constraint that the following combinations must not be present: (a) a syntax element indicating that tool information is signaled in a picture header rather than a slice header, and (b) a syntax element indicating that a picture header is signaled in a slice header. The tool information may 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 filter (ALF) information. In a related aspect, a method of decoding a bitstream is provided. In another related aspect, a decoder configured to decode the bitstream is provided. The bitstream may be constrained to conform to a video coding standard. In one embodiment, the video coding standard is a versatile video coding standard. The constraint may be systematically applied to the entire bitstream. For example, in an embodiment, constraints are applied to any or all of sequences, pictures and slices in a 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 slices, the bitstream including a picture header including syntax elements to be used when decoding the one or more slices, and a slice header including syntax elements to be used when decoding the slices, the decoding including treating as inapplicable a combination of (a) a syntax element indicating that tool information is signaled in a slice header rather than a picture header and (b) a syntax element indicating that a picture header is signaled in the slice header, and decoding the bitstream using the syntax elements. The decoding is not performed if there are syntax elements (a) and (b) that are treated as inapplicable in combination.

[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, the bitstream including a picture header including syntax elements to be used when decoding the one or more slices, and a slice header including syntax elements used when decoding the slices, the picture header being to be signaled in the slice header, constraining parsing of information that may be signaled in only one of the slice header or the picture header, and the decoding including not signaling in the slice header (e.g., forcing picture_header_in_slice_header_flag to 0) if a syntax element (xxx_info_in_ph_flag) indicates that tool information is present in the picture header (e.g., if xxx_info_in_ph_flag=1).

[0026] According to related aspects of the invention, a bitstream includes video data corresponding to one or more slices, a picture header including syntax elements used when decoding the one or more slices, and a slice header including syntax elements used when decoding the slices. The bitstream has a constraint that the following combinations must not be present in it: (a) a syntax element indicating that tool information is signaled in a slice header rather than a picture header, and (b) a syntax element indicating that a picture header is signaled in a 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, the bitstream including a picture header including syntax elements to be used when decoding the one or more slices, and a slice header including syntax elements used when decoding the slices, the picture header being to be signaled in the slice header, constraining parsing of information that may be signaled in only one of the slice header or the picture header, and the decoding including not signaling in the slice header (e.g., forcing picture_header_in_slice_header_flag to 0) if a syntax element (xxx_info_in_ph_flag) indicates that there is no tool information in the picture header (e.g., if xxx_info_in_ph_flag=0).

[0028] According to a first further 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, the bitstream including a picture header including syntax elements to be used when decoding the one or more slices, and a slice header including syntax elements used when decoding the slice, the decoding including allowing parsing information that may be signaled in the slice header and the picture header in only one of the slice header or the picture header if the picture header is signaled in the slice header, and decoding the bitstream using the syntax elements.

[0029] If a picture header is in a slice header, this means that there is only one slice for the current picture. Therefore, transmitting or allowing information to be transmitted for both slices and pictures does not increase the flexibility of the encoder or decoder, since the parameters are the same. That is, if there is information in the picture header, the corresponding information in the slice header is redundant. Similarly, if there is information in the slice header, the corresponding information in the picture header is redundant. By only allowing information in the picture header or slice header when the picture header is in the slice header, it is possible to limit the redundancy in the signaling and simplify the implementation of the decoder. Thus, it is possible to simplify the syntax analysis without compromising the coding efficiency.

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

[0031] Optionally, parsing of information in a slice header is not allowed if the first syntax element indicates that a picture header is signaled in the slice header, and a second syntax element indicating whether the information is in a picture header may be parsed, with bitstream conformance requiring that if the first syntax element indicates that a picture header is signaled in the slice header, then the second syntax element indicates that the information is signaled in the picture header.

[0032] Alternatively, if the first syntax element indicates that the picture header is signaled in the slice header, signaling of the 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, and it is a bitstream conformance requirement that if the first syntax element indicates that the picture header is signaled in the slice header, the second syntax element indicates that the information is in the picture header. The second syntax element may be a picture parameter setting flag, where if the flag is set, the information is in the picture header, and if not set, the information is in the slice header or is not present.

[0033] According to an embodiment, 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 filter (ALF) information. For example, the information may include all of the 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.

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

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

[0036] When signaling a picture header within a slice header, the number of weighted prediction weights that can be parsed can be limited.

[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 slices, the bitstream including a picture header including syntax elements used when decoding the one or more slices, and a slice header including syntax elements used when decoding the slice, wherein the encoding includes, in the case where a picture header is signaled within the slice header, allowing information that may be signaled in the slice header and the picture header to be encoded only in either the slice header or the picture header, and encoding the video data using the syntax elements.

[0038] If a picture header is in a slice header, this means that there is only one slice for the current picture. Therefore, transmitting or allowing information to be transmitted for both slices and pictures does not increase the flexibility of the encoder or decoder, since the parameters are the same. That is, if there is information in the picture header, the corresponding information in the slice header is redundant. Similarly, if there is information in the slice header, the corresponding information in the picture header is redundant. By only allowing information in the picture header or slice header when the picture header is in the slice header, the redundancy in signaling can be limited, simplifying the implementation of the decoder. Thus, coding can be simplified and signaling costs reduced without compromising coding efficiency (because the relevant information is included only once in the bitstream).

[0039] The encoding may further include encoding a first syntax element indicating whether to signal a picture header in the slice header and allowing encoding of information that may be signaled in only one of the slice header or the picture header based on the first syntax element.

[0040] The first syntax element may be a picture header of a slice header flag.

[0041] If the first syntax element indicates that the picture header is signaled within the slice header, encoding of information in the slice header may not be allowed.

[0042] A second syntax element may be coded indicating whether the information is in the picture header or not, and it is a bitstream conformance requirement that if the first syntax element indicates that the picture header is signaled in the slice header, the second syntax element indicates that the information is in the picture header.

[0043] Alternatively, if the first syntax element indicates that a picture header is signaled in the slice header, then signaling of picture header information is not allowed.

[0044] A second syntax element may be coded indicating whether the information is in the picture header or not, and it is a bitstream conformance requirement that if the first syntax element indicates signaling a picture header in a slice header, then the second syntax element indicates that the information is in the picture header.

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

[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 filter (ALF) information. Optionally, the information includes all information that may be signaled in the picture header and slice header, such as all of the 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.

[0047] The reference image 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, if the picture header is signaled in the slice header, the number of weights for weighted prediction may be limited.

[0049] According to a third further aspect of the present invention, there is provided a method for decoding a bitstream comprising video data corresponding to one or more slices, the bitstream comprising a picture header comprising syntax elements to be used when decoding the one or more slices, and a slice header comprising syntax elements to be used when decoding the slices, the method comprising parsing in the slice header a syntax element indicating whether a picture header is signalled in the slice header, wherein an APS_ID related syntax element of the ALF is parsed before a syntax element indicating whether a picture header is signalled in the slice header. The APS_ID related information of the ALF may be parsed close to or at the beginning of the slice header.

[0050] According to a fourth further aspect of the present invention, there is provided a method for encoding video data comprising one or more slices into a bitstream, the bitstream comprising a picture header comprising syntax elements for use when decoding the one or more slices, and a slice header comprising syntax elements for use when decoding the slices, the method comprising parsing in the slice header a syntax element indicating whether a picture header is signalled in the slice header, where an APS_ID related syntax element for the ALF is coded prior to a syntax element indicating whether a picture header is signalled in the slice header. The APS_ID related information for the ALF may be coded adjacent to or at the beginning of the slice header.

[0051] According to a fifth further 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, the bitstream including a picture header including syntax elements for use when decoding the one or more slices, and a slice header including syntax elements for use when decoding the slice, the decoding including limiting a number of weights to be signaled for a weighted prediction mode if to be signaled in the slice header, and decoding the bitstream using the syntax elements. In case of signaling a picture header in a slice header, parsing of information that may be signaled in the slice header and in the picture header may only be allowed in either the slice header or the picture header.

[0052] According to a sixth further aspect of the present invention, there is provided a method for encoding video data from a bitstream, the bitstream including video data corresponding to one or more slices, the bitstream including a picture header including syntax elements for use when decoding the one or more slices, and a slice header including syntax elements for use when decoding the slice, and the encoding includes, if signaling in the slice header, limiting the number of weights to be encoded for a weighted prediction mode, and encoding the bitstream using the syntax elements, and, if signaling a picture header in the slice header, encoding of information that may be signaled in the slice header and in the picture header may be allowed only in either the slice header or 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 configured to perform a method of any of the first, third or fifth further aspects.

[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 configured to perform a method of any of the second, fourth or sixth further aspects.

[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 of the first to sixth further aspects to be performed. The program may be provided on its own or may be carried on, by or in a carrier medium. The carrier medium may be non-transitory, for example a storage medium, in particular a computer-readable storage medium. The carrier medium may also be transitory, for example a signal or other transmission medium. The signal may be transmitted via any suitable network, including the Internet. Further features of the present invention are characterized by the independent and dependent claims.

[0056] According to yet another aspect of the first 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 slices, the bitstream including a picture header including syntax elements for use when decoding the one or more slices, and a slice header including syntax elements for use when decoding the slices. If the bitstream includes a first syntax element having a value indicating that information that can be signaled in a picture header or a slice header is signaled in the picture header, the bitstream is constrained to also include a second syntax element having a value indicating that it is not in the slice header, the method including decoding the bitstream using the syntax elements. The bitstream may be constrained to conform to a video coding standard. In an embodiment, the video coding standard is a versatile video coding standard. The second syntax element may be a picture header in a slice header syntax element. The first syntax element may be a flag indicating encoding in the picture header of 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. The bitstream constraint may be applied systematically. For example, in an embodiment, the constraint is applied to any or all of sequences, pictures, and slices in the bitstream.

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

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

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

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

[0061] It is also to be understood that specific combinations of the various features described and defined in any embodiment of the present invention can be implemented and / or 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]FIG. 1 is a diagram used to explain the coding structure used in HEVC and VVC. [Diagram 2] 1 is a block diagram that illustrates generally a data communications system in which one or more embodiments of the present invention may be implemented; [Diagram 3] FIG. 2 is a block diagram illustrating components of a processing device in which one or more embodiments of the present invention may be implemented. [Figure 4] 4 is a flow chart illustrating steps of an encoding method according to an embodiment of the present invention. [Diagram 5] 4 is a flow chart illustrating steps of a decoding method according to an embodiment of the present invention; [Figure 6] FIG. 2 illustrates the structure of a bitstream in an exemplary coding scheme VVC. [Figure 7] FIG. 2 illustrates another structure of a bitstream in an exemplary coding scheme VVC. [Figure 8] FIG. 1 is a diagram explaining luma modeling chroma scaling (LMCS). [Figure 9] FIG. 1 is a diagram showing sub-tools of LMCS. [Figure 10] FIG. 1 illustrates a system including an encoder or decoder according to an embodiment of the present invention and a communication network. [Figure 11] 1 is a schematic block diagram of a computing device for implementing one or more embodiments of the present invention. [Figure 12] FIG. 1 is a diagram illustrating a network camera system. [Figure 13] FIG. 1 is a diagram for explaining a smartphone. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0064] Figure 1 relates to the coding structure used in the High Efficiency Video Coding (HEVC) video standard. A video sequence 1 consists of a succession of digital images i, where each such digital image is represented by one or more matrices. The coefficients of the matrices represent pixels.

[0065] An image 2 of the sequence may be divided into a number of slices 3. A slice may in some cases constitute the entire image. These slices are divided into a number of non-overlapping coding tree units (CTUs). A coding tree unit (CTU) is the basic processing unit of the High Efficiency Video Coding (HEVC) video standard and conceptually corresponds in structure to the macroblock unit used in some previous video standards. A CTU is sometimes also called a maximal coding unit (LCU). A CTU has luma and chroma component parts, each of which is called a coding tree block (CTB). These different color components are not shown in FIG. 1.

[0066] A CTU is typically 64 pixels by 64 pixels in size. Each CTU may be iteratively divided into multiple smaller, variable-sized coding units (CUs) 5 using a quadtree decomposition.

[0067] A coding unit is a basic coding element and consists of two types of subunits called prediction units (PUs) and transform units (TUs). The maximum size of a PU or TU is equal to the size of a CU. A prediction unit corresponds to a division of a CU to predict pixel values. When dividing a CU into PUs, various divisions are possible, such as dividing into four square PUs as shown in 606 or dividing into two rectangular PUs. A transform unit is a basic unit that undergoes spatial transformation using DCT. A CU can be divided into multiple TUs based on a quadtree representation 607.

[0068] Each slice is embedded in one network abstraction layer (NAL) unit. Furthermore, the coding parameters of a video sequence are stored in a dedicated NAL unit called a parameter set. HEVC and H.264 / AVC employ two types of parameter set NAL units: First, the sequence parameter set (SPS) NAL unit collects all parameters that do not change throughout a video sequence. It typically handles coding profiles, sizes of multiple video frames, and multiple other parameters. Second, the picture parameter set (PPS) NAL unit contains multiple parameters that may change from one picture (or frame) of a sequence to another. HEVC also includes the video parameter set (VPS) NAL unit, which contains multiple parameters that describe the overall structure of the bitstream. VPS is a new type of parameter set defined in HEVC that applies to all layers of the bitstream. A layer may contain multiple sublayers, while all version 1 bitstreams are limited to one layer. HEVC has specific layer extensions for scalability and multiview, and these are the backward-compatible version 1 base layer that allows multiple layers.

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

[0070] The data stream 204 provided by the server 201 may consist of multimedia data representing video and audio data. The audio and video data streams may in some embodiments of the invention be acquired by the server 201 using a microphone and a camera, respectively. In some embodiments, the data streams may be stored in the server 201, received by the server 201 from other data providers or generated by the server 201. The server 201 comprises an encoder, in particular for encoding the video and audio streams, to provide a compressed bitstream for transmission, which is a more compact representation of the data presented as input to the encoder.

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

[0072] The client 202 receives the transmitted bitstream, decodes the reconstructed bitstream, and plays the video images on a display device and the audio data on a loudspeaker.

[0073] Although the example of FIG. 2 considers a streaming scenario, it will be appreciated that in some embodiments of the invention, data communication between the encoder and the decoder may be performed using a media storage device, such as an optical disc.

[0074] In one or more embodiments of the invention, a video image is transmitted along with data representative of compensation offsets to be applied to reconstructed pixels of the image to provide filtered pixels in the final image.

[0075] 3 shows a schematic diagram of a processing device 300 configured to implement at least one embodiment of the present invention. The processing device 300 may be a device such as a microcomputer, a workstation, or a lightweight portable device. The device 300 may include: - a central processing unit 311 (denoted as CPU), such as a microprocessor; - a read-only memory 306 (denoted ROM) for storing a computer program for implementing the invention; a random access memory 312 (denoted RAM) for storing the executable code of the method of an embodiment of the invention, as well as registers adapted to record variables and parameters necessary for implementing the method of encoding a sequence of digital images and / or the method of decoding a bitstream according to an embodiment of the invention; and a communications interface 302 connected to a communications network 303 over which the digital data to be processed is sent and received; 3. The communication bus 313 is connected to the

[0076] Optionally, the apparatus 300 may include the following components: - data storage means 304 (hard disk) for storing computer programs for implementing the methods of one or more embodiments of the invention and data used or generated during the implementation of one or more embodiments of the invention; a disk drive 305 for a disk 306, the disk drive being adapted to read data from or write data to the disk 306; A screen 309 for displaying data and / or acting as a graphical interface with the user, by means of a keyboard 310 or any other pointing means.

[0077] The device 300 may be connected to a variety of peripheral devices, such as a digital camera 320 and a microphone 308, each connected to an input / output card (not shown) for providing multimedia data to the device 300.

[0078] 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 limiting, in particular the central processing unit is operable to transmit instructions to any element of the device 300 directly or by other elements of the device 300.

[0079] The disk 306 may be replaced by any information medium, such as, for example, a compact disk (CD-ROM), rewritable or not, a ZIP disk, a memory card, and in general any medium that is a microcomputer or microprocessor readable information storage means, whether incorporated in the device or not, that may be removable and that may be adapted to store one or more programs, the execution of which may implement the method of encoding a sequence of digital images and / or the method of decoding a bitstream according to the present invention.

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

[0081] The central processing unit 311 is adapted to control and direct the execution of instructions or parts of the software code of a program or program according to the invention, instructions stored in one of the aforementioned storage means. On power-up, the program or programs stored in a 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 stores the executable code of the program or programs, as well as registers for storing variables and parameters necessary to implement the invention.

[0082] In this embodiment, the device is a programmable device that uses software to implement the invention, however, alternatively, the invention may be implemented in hardware (e.g., in the form of an application specific integrated circuit or ASIC).

[0083] 4 is a block diagram of an encoder according to at least one embodiment of the present invention, the encoder being represented by a number of connected modules, each adapted to implement, for example in the form of programming instructions executed by the CPU 311 of the device 300, at least one corresponding step of a method for implementing at least one embodiment of encoding images of a sequence of images according to one or more embodiments of the present invention.

[0084] An original sequence of multiple digital images (i0 to in) 401 is received as input by an encoder 400. Each digital image is represented by a collection of samples known as pixels.

[0085] After performing the encoding process, the encoder 400 outputs a bitstream 410. The bitstream 410 includes multiple coding units or slices, each of which includes a slice header for transmitting coded values ​​of coding parameters used to code the slice, and a slice body that includes coded video data.

[0086] The input digital image (i0~in) 401 is divided into blocks of pixels by a module 402. The blocks correspond to image portions and may be of variable size (for example 4x4, 8x8, 16x16, 32x32, 64x64, 128x128 pixels and several rectangular block sizes can also be considered). A coding mode is selected for each input block. There are two families of coding modes: coding modes based on spatial prediction (intra prediction) and coding based on temporal prediction (inter coding, merge, SKIP). Possible coding modes are tested.

[0087] Module 403 executes an intra prediction process, in which a given block to be coded is predicted by a predictor calculated from a number of pixels in the neighborhood of the block to be coded. The difference between a representation of the selected intra predictor and a given block and its predictor is coded to provide a residual if intra coding is selected.

[0088] Temporal prediction is performed 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 part of the reference image (also called a reference region or image part, which is the region closest to a given block to be coded) is selected by the motion estimation module 404. Then, the motion compensation module 405 uses the selected region to predict the block to be coded. The difference between the selected reference region and a given block, also called a residual block, is calculated by the motion compensation module 405. The selected reference region is indicated by a motion vector.

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

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

[0091] If inter prediction is selected, the relative information of the motion vector and the residual block is coded. To further reduce the bit rate, assuming that the motion is homogeneous, the motion vector is coded by the difference with respect to the motion vector predictor. The motion vector predictor of the set of motion information predictors is obtained from the motion vector field 418 by the motion vector prediction and coding module 417.

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

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

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

[0095] 5 is a block diagram of a decoder 60 that may be used to receive data from an encoder according to an embodiment of the present invention. The decoder is represented by a number of connected modules, each adapted to implement a corresponding step of a method implemented by the decoder 60, for example in the form of programming instructions executed by the CPU 311 of the device 300.

[0096] The decoder 60 receives a bitstream 61 including a number of coding units, each including a header containing information of coding parameters and a body containing the coded video data. The structure of the bitstream in VVC is explained in detail below with reference to Fig. 6. As explained with reference to Fig. 4, the coded video data is entropy coded, and the index of the motion vector predictor is coded with a certain number of bits for a given block. The received coded video data is entropy decoded by a module 62. Then, the residual data is inverse quantized by a module 63, and then inverse transformed by a module 64 to obtain pixel values.

[0097] Also, the mode data indicating the coding mode is entropy decoded, and intra-type or inter-type decoding is performed on the coded image data block based on the mode.

[0098] For intra modes, the intra predictor is determined by the intra inverse prediction module 65 based on the intra prediction mode specified in the bitstream.

[0099] For inter modes, the encoder extracts motion prediction information from the bitstream to find the reference region to be used. The motion prediction information consists of a reference frame index and a motion vector residual. The motion vector prediction information is added to the motion vector residual to obtain a motion vector by the motion vector decoding module 70.

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

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

[0102] FIG. 6 is a diagram showing the structure of a bitstream in an exemplary coding system VVC described in JVET-Q2001-vD.

[0103] A VVC coded bitstream 61 consists of an ordered sequence of syntax elements and coded data. The syntax elements and coded data are arranged in Network Abstraction Layer (NAL) units 601-608. There are various types of NAL units. The Network Abstraction Layer provides the ability to encapsulate the bitstream into different protocols such as RTP / IP (Real Time Protocol / Internet Protocol), ISO Base Media File Format, etc. The Network Abstraction Layer also provides a framework for packet loss recovery.

[0104] NAL units are divided into video coding layer (VCL) NAL units and non-VCL_NAL units. VCL_NAL units contain the actual coded video data. Non-VCL_NAL units contain additional information. This additional information may be parameters required for decoding the coded video data or supplemental data that may improve the usability of the decoded video data. NAL units 606 correspond to slices and constitute the VCL_NAL units of the bitstream.

[0105] 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 may define parameters that are more static than the parameters of the VPS, i.e., the parameters of the DPS change less frequently than the parameters of the VPS.

[0106] 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 and associated parameters of a video sequence. The parameters associated with each sub-picture specify the coding constraints that apply to the sub-picture. In particular, it includes a flag that indicates that temporal prediction between sub-pictures is restricted to data coming from the same sub-picture. Another flag can enable or disable the loop filter across sub-picture boundaries.

[0107] Picture Parameter Set (PPS) NAL unit 604, where PPS contains parameters defined for a picture or group of pictures. Adaptation Parameter Set (APS) NAL unit 605 typically contains parameters for an adaptation loop filter (ALF) or reshaper model (or luma mapping with chroma scaling (LMCS) model) or scaling matrix used at slice level.

[0108] The PPS syntax proposed in the current version of VVC consists of syntax elements that specify the size of the picture in luma samples and further divide each picture into tiles and slices.

[0109] PPS includes syntax elements to determine slice locations within a frame. Since a subpicture forms a rectangular region within a frame, it is possible to determine the set of slices, parts of tiles, and tiles that belong to a subpicture in the parameter set NAL unit. PPS has an ID mechanism like APS, which limits the amount of transmission of the same PPS.

[0110] The main difference between the PPS and the picture header is their transmission: the PPS is typically transmitted for a group of pictures, whereas the PH is transmitted systematically for each picture. Thus, the PPS contains parameters that remain constant across pictures, compared to the PH.

[0111] The bitstream may also contain supplemental enhancement information (SEI) NAL units (not represented in FIG. 6). The periodicity of appearance of these parameter sets in the bitstream is variable. A VPS defined for the entire bitstream may occur only once in the bitstream. Conversely, an APS defined for a slice may occur only once for each slice in each picture. In practice, different slices may depend on the same APS, and thus there are generally fewer APSs than slices in each picture. In particular, the APSs are defined in the picture header. However, the APSs of the ALF can be refined in the slice header.

[0112] An Access Unit Delimiter (AUD) NAL unit 607 separates the two access units. An access unit is a set of NAL units that can constitute one or more coded 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 value of slice_type for all slices of coded pictures in the AU. If pic_type is 0, the AU contains only intra slices. If it is 1, it contains P and I slices. If it is 2, it contains B, P or intra slices. This NAL unit contains only one syntax element, pic-type.

[0113] [Table 1]

[0114] In JVET-Q2001-vD, pic_type is defined as follows: "pic_type indicates that the slice_type values ​​of all slices of the coded picture in the AU containing the AU delimiter NAL unit are members of the set indicated by the value of pic_type in Table 2. The value of pic_type MUST be 0, 1, or 2 in bitstreams conforming to this version of the standard. Other values ​​of pic_type are reserved for future use by ITU-T and / or ISO / IEC. Decoders conforming to this specification shall ignore reserved values ​​of pic_type."

[0115] rbsp_trailing_bits() is a function that adds bits to align the end of a byte, so that after executing this function the amount of parsed bitstream is an integral number of bytes.

[0116] [Table 2]

[0117] The PH_NAL unit 608 is a picture header NAL unit that groups parameters common to a set of slices of one coded picture. A picture can reference one or more APS to indicate the AFL parameters, reshaper models, and scaling matrices used by the slices of the picture.

[0118] Each of the VCL_NAL units 606 includes a slice. A slice may correspond to an entire picture or a subpicture, a single tile or multiple tiles or portions of a tile. For example, the slice of Figure 3 includes multiple tiles 620. A slice consists of a slice header 610 and a raw byte sequence payload (RBSP) 611 that includes coded pixel data coded as coded blocks 640.

[0119] The PPS syntax proposed in the current version of VVC consists of syntax elements that specify the size of the picture in luma samples and further divide each picture into tiles and slices.

[0120] The PPS contains syntax elements for determining slice locations within a frame. Since a subpicture forms a rectangular region within a frame, it is possible to determine in a parameter set NAL unit the collection of slices, portions of tiles, or tiles that belong to a subpicture.

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

[0122] [Table 3]

[0123] APS The adaptation parameter set (APS) NAL unit 605 is defined in Table 4, which shows syntax elements.

[0124] There are three types of APS that may be given by the aps_params_type syntax element, as shown in Table 4: -ALF_AP: for ALF parameters ·LMCS_APS: for LMCS parameters · SCALING_APS: for scaling list relative parameters

[0125] [Table 4]

[0126] These three APS parameters are explained below in order.

[0127] ALF APS The ALF parameters are described in the adaptive loop filter data syntax element (Table 5). First, four flags specify the presence or absence of ALF filters for luma and chroma, and the presence or absence of CC-ALF (Cross-Component-Adaptive Loop Filter) for Cb and Cr components. If the luma filter flag is enabled, another flag is decoded (alf_luma_clip_flag) to know whether the clip value is signaled or not. Next, the number of signaled filters is decoded using the alf_luma_num_filters_signalled_minus1 syntax element. If necessary, the syntax element "alf_luma_coeff_delta_idx", which represents the ALF coefficient delta, is decoded for each enabled filter. Then, the absolute value and sign of each coefficient of each filter are decoded.

[0128] If alf_luma_clip_flag is enabled, the clip index for each coefficient of each enabled filter is decoded.

[0129] Similarly, the chroma coefficients of the ALF are decoded as needed.

[0130] If CC-ALF is enabled for Cr or Cb, the number of filters is decoded (alf_cc_cb_filters_signalled_minus1 or alf_cc_cr_filters_signalled_minus1) and the associated coefficients are decoded (alf_cc_cb_mapped_coeff_abs and alf_cc_cb_coeff_sign or alf_cc_cr_mapped_coeff_abs and alf_cc_cr_coeff_sign, respectively).

[0131] [Table 5] TIFF0007672538000006.tif115170

[0132] LMCS syntax elements for both luma mapping and chroma scaling Table 6 below gives all LMCS syntax elements that are coded in the adaptation parameter set (APS) syntax structure when the aps_params_type parameter is set to 1 (LMCS_APS). Up to four LMCS_APS can be used in a coded video sequence, but only a single LMCS_APS can be used for a given picture.

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

[0134] [Table 6]

[0135] Scaling List APS 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 (Scaling List Data Syntax in Table 7). The first syntax element specifies whether the scaling matrix is ​​used for the LFNST (Low Frequency Non-Separable Transform) tool based on the flag scaling_matrix_for_lfnst_disabled_flag. The second one specifies if the scaling list is used for the chroma components (scaling_list_chroma_present_flag). Then the syntax elements required to build the scaling matrix are decoded (scaling_list_copy_mode_flag, scaling_list_pred_mode_flag, scaling_list_pred_id_delta, scaling_list_dc_coef, scaling_list_delta_coef).

[0136] [Table 7]

[0137] Picture Header The picture header is transmitted at the beginning of each picture before any other slice data. It is significantly larger than the headers in previous standard drafts. A complete description of all these parameters is given in JVET-Q2001-vD. Table 9 shows these parameters in the current picture header decoding syntax.

[0138] The relevant syntax elements that can be decoded are: How to use this picture, reference frame or not Picture type Output Frame Picture Number Use subpictures (if necessary) · Reference image list (if necessary) Color planes (if required) -Updating partitions when overwrite flag is enabled Delta QP parameters (if required) -Motion information parameters (if necessary) ALF parameters (if required) ·SAO parameters (if necessary) Quantification parameters (if required) ·LMCS parameters (if required) · Scaling list parameters (if required) Picture header extension (if required) And many more...

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

[0140] Then, the ph_inter_slice_allowed_flag is decoded to identify that inter slices are allowed.

[0141] If allowed, the flag ph_intra_slice_allowed_flag is decoded to know whether intra slices are allowed in the current picture.

[0142] Next, non_reference_picture_flag, ph_pic_parameter_set_id indicating the PPS_ID, and picture order count ph_pic_order_cnt_lsb are decoded. The picture order count indicates the number of the current picture.

[0143] If the picture is a GDR or IRAP picture, the flag no_output_of_prior_pics_flag is decoded. If the picture is a GDR picture, recovery_poc_cnt is decoded. Then, ph_poc_msb_present_flag and poc_msb_val are decoded as necessary.

[0144] ALF After these parameters describing important information about the current picture, a set of APS_ID syntax elements for ALF are decoded if ALF is enabled at SPS level and if ALF is enabled at picture header level. ALF is enabled at SPS level due to the flag sps_alf_enabled_flag. Also, ALF signaling is enabled at picture header level because alf_info_in_ph_flag is 1, otherwise (alf_info_in_ph_flag is 0) ALF signaling is signaled at slice level.

[0145] alf_info_in_ph_flag is defined as follows: "alf_info_in_ph_flag equal to 1 specifies that ALF information is present in the PH syntax structure but is not present in slice headers that reference PPSs that do not contain a PH syntax structure. alf_info_in_ph_flag equal to 0 specifies that ALF information is not present in the PH syntax structure but may be present in slice headers that reference PPSs that do not contain a PH syntax structure."

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

[0147] If ALF is enabled, the amount of ALF APS_id for luma is decoded using the pic_num_alf_aps_ids_luma syntax element. For each APS_ID, the APS_ID value for luma is decoded as "ph_alf_aps_id_luma".

[0148] For chroma, the syntax element ph_alf_chroma_idc is decoded to determine if ALF is enabled for chroma, Cr only, or Cb only. If enabled, the value of APS_ID for chroma is decoded using the ph_alf_aps_id_chroma syntax element. The APS_ID for the CC-ALF method is decoded if required for the Cb and / or Cr components.

[0149] LMCS If LMCS is enabled at the SPS level, then a set of APS_ID syntax elements for LMCS are decoded next. First, ph_lmcs_enabled_flag is decoded to determine if LMCS is enabled for the current picture. If LMCS is enabled, the ID value ph_lmcs_aps_id is decoded. For chroma only, ph_chroma_residual_scale_flag is decoded to enable or disable the method for chroma.

[0150] Scaling List If the scaling list is valid at the SPS level, then the set of APS_IDs of the scaling list is decoded next. The ph_scaling_list_present_flag is decoded to determine whether the scaling matrix is ​​valid for the current picture. Then, the value of APS_ID, ph_scaling_list_aps_id, is decoded.

[0151] Subpicture Subpicture parameters are valid if they are enabled in the SPS and Subpicture ID signaling is disabled, and contain some information about the virtual border. Eight syntax elements are defined for the subpicture parameters: ·ph_virtual_boundaries_present_flag ·ph_num_ver_virtual_boundaries ·ph_virtual_boundaries_pos_x[i] ·ph_num_hor_virtual_boundaries ·ph_virtual_boundaries_pos_y[i]

[0152] Output Flags These subpicture parameters are followed by pic_output_flag, if present.

[0153] Reference Picture List If reference picture lists are signaled in the picture header (rpl_info_in_ph_flag is 1), the reference picture lists parameter ref_pic_lists() is decoded and contains the following syntax elements: rpl_sps_flag[] rpl_idx[] poc_lsb_lt[][] ·delta_poc_msb_present_flag[][] delta_poc_msb_cycle_lt[][]

[0154] partition The set of partition parameters is decoded as necessary and contains the following syntax elements: ·partition_constraints_override_flag ·ph_log2_diff_min_qt_min_cb_intra_slice_luma ·ph_max_mtt_hierarchy_depth_intra_slice_luma ·ph_log2_diff_max_bt_min_qt_intra_slice_luma ·ph_log2_diff_max_tt_min_qt_intra_slice_luma ·ph_log2_diff_min_qt_min_cb_intra_slice_chroma ·ph_max_mtt_hierarchy_depth_intra_slice_chroma ·ph_log2_diff_max_bt_min_qt_intra_slice_chroma ·ph_log2_diff_max_tt_min_qt_intra_slice_chroma ·ph_log2_diff_min_qt_min_cb_inter_slice ·ph_max_mtt_hierarchy_depth_inter_slice ·ph_log2_diff_max_bt_min_qt_inter_slice ·ph_log2_diff_max_tt_min_qt_inter_slice

[0155] Weighted Prediction The weighted prediction parameters pred_weight_table() are decoded if the weighted prediction method is enabled at the PPS level and the weighted prediction parameters are signaled in the picture header (wp_info_in_ph_flag is 1).

[0156] pred_weight_table() contains weighted prediction parameters for list L0 and for list L1 when bidirectional weighted prediction is enabled. When weighted prediction parameters are signaled in the picture header, the number of weights for each list is signaled explicitly, as depicted in the pred_weight_table() syntax table (Table 8).

[0157] [Table 8]

[0158] Delta QP If the picture is intra, ph_cu_qp_delta_subdiv_intra_slice and ph_cu_chroma_qp_offset_subdiv_intra_slice are decoded as needed. Also, if inter slices are allowed, ph_cu_qp_delta_subdiv_inter_slice and ph_cu_chroma_qp_offset_subdiv_inter_slice are decoded as needed. Finally, picture header extension syntax elements are decoded as needed.

[0159] 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, and wp_info_in_ph_flag are signaled in the PPS.

[0160] [Table 9] TIFF0007672538000011.tif248170TIFF0007672538000012.tif248167TIFF0007672538000013.tif200170

[0161] Slice Header The slice header is transmitted at the beginning of each slice. The slice header contains about 65 syntax elements. This is very large compared to slice headers in previous video coding standards. A complete description of all slice header parameters is given in JVET-Q2001-vD. Table 10 shows these parameters in the current slice header decoding syntax.

[0162] [Table 10] TIFF0007672538000015.tif245170TIFF0007672538000016.tif95170

[0163] First, the picture_header_in_slice_header_flag is decoded to find out whether a picture_header_structure() is present in the slice header.

[0164] Then, slice_subpic_id is decoded, if necessary, to determine the subpicture ID of the current slice. Then, slice_address is decoded to determine the address of the current slice. Then, if the number of tiles in the current picture is greater than 1, num_tiles_in_slice_minus1 is decoded.

[0165] Then the slice_type is decoded.

[0166] If ALF is enabled at the SPS level (sps_alf_enabled_flag) and ALF is signaled in the slice header (alf_info_in_ph_flag is 0), the ALF information is decoded. This includes a flag indicating that ALF is enabled for the current slice (slice_alf_enabled_flag). If it is enabled, the number of ALF_IDs of the APS for luma (slice_num_alf_aps_ids_luma) is decoded, then the APS_ID is decoded (slice_alf_aps_id_luma[i]). Then slice_alf_chroma_idc is decoded to know if and for which chroma component ALF is enabled. Then the APS_ID for chroma, slice_alf_aps_id_chroma, is decoded as needed. Similarly, slice_cc_alf_cb_enabled_flag is decoded as needed to know if the CC_ALF scheme is enabled. If CC_ALF is valid for Cr and / or Cb, the associated APS_ID of Cr and / or Cb is decoded.

[0167] If multiple color planes are transmitted independently (separate_colour_plane_flag is 1), color_plane_id is decoded. If the picture header does not transmit a reference picture list (rpl_info_in_ph_flag is 0) and the NAL unit transmits a reference picture list for a non-IDR or IDR picture (sps_idr_rpl_present_flag is 1), the reference picture list parameters are decoded; these are the same parameters as in the picture header.

[0168] If reference picture lists are transmitted in the picture header (rpl_info_in_ph_flag is 1) or if the NAL unit is not IDR or reference picture lists are transmitted in an IDR picture (sps_idr_rpl_present_flag is 1), the override flag num_ref_idx_active_override_flag is decoded if the number of references to at least one list is greater than 1. If this flag is enabled, the reference index of each list is decoded.

[0169] If the slice type is not intra, and if necessary, cabac_init_flag is decoded. If a reference picture list is transmitted in the slice header, slice_collocated_from_l0_flag and slice_collocated_ref_idx are decoded. These data are related to CABAC coding and motion vector placement. Similarly, if the slice type is not intra, parameters of the weighted prediction pred_weight_table() are decoded.

[0170] slice_qp_delta is decoded if delta QP information is transmitted in the slice header (qp_delta_info_in_ph_flag is 0). If necessary, the slice_cb_qp_offset, slice_cr_qp_offset, slice_joint_cbcr_qp_offset, and cu_chroma_qp_offset_enabled_flag syntax elements are also decoded.

[0171] If SAO information is carried in the slice header (sao_info_in_ph_flag is 0) and enabled at the SPS level (sps_sao_enabled_flag), the enable flags for SAO in both luma and chroma are decoded: slice_sao_luma_flag, slice_sao_chroma_flag. Then, the deblocking filter parameters are decoded if they are signaled in the slice header (dbf_info_in_ph_flag is 0).

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

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

[0174] Similarly, if scaling lists were enabled in the picture header (phpic_scaling_list_presentenabled_flag is 1), the flag slice_scaling_list_present_flag is decoded.

[0175] Then, other parameters are decoded as required.

[0176] Picture Header in Slice Header In a particular signaling method, as depicted in Fig. 7, the picture header 708 may be signaled inside the slice header 710. In that case, there is no NAL unit that contains only the picture header 608. Units 701, 702, 703, 704, 705, 706, 707, 720, 740 correspond to 601, 602, 603, 604, 605, 606, 607, 620, 640 in Fig. 6 and can therefore be understood from the previous description. This can be enabled in the slice header thanks to the flag picture_header_in_slice_header_flag. Furthermore, if a picture header is signaled in a slice header, a picture shall contain only one slice. Thus, there is always only one picture header in a picture. Furthermore, the flag picture_header_in_slice_header_flag shall have the same value in all pictures of the CLVS (Coded Layered Video Sequence), which means that all pictures between two IRAPs including the first IRAP have only one slice per picture.

[0177] The flag picture_header_in_slice_header_flag is defined as follows: "When picture_header_in_slice_header_flag is set to 1, it indicates that the PH syntax structure is present in the slice header. When picture_header_in_slice_header_flag is set to 0, it indicates that the PH syntax structure is not present in the slice header. It is a bitstream conformance requirement that all coded slices in a CLVS have the same value for picture_header_in_slice_header_flag. If picture_header_in_slice_header_flag is 1 in a coded slice, it is a conformance requirement that there are no VCL_NAL units in the CLVS with nal_unit_type set to PH_NUT. When picture_header_in_slice_header_flag is 0, all coded slices of the current picture have picture_header_in_slice_header_flag set to 0 and the current PU has a PH_NAL unit. The picture_header_structure() contains the syntax elements of picture_rbsp() except for the stuff bits, rbsp_trailing_bits()."

[0178] Interaction of Picture Header in Slice Header and Tool Signaling in Picture Header and Slice Header The QP delta information, reference picture list parameters, deblocking filter parameters, sample adaptation offset parameters, weighted prediction parameters and ALF parameters can be signaled in the picture header or slice header by respective flags: qp_delta_info_in_ph_flag rpl_info_in_ph_flag dbf_info_in_ph_flag sao_info_in_ph_flag wp_info_in_ph_flag alf_info_in_ph_flag These flags are transmitted within the PPS.

[0179] As shown in Table 11 (Overview of XXX signaling according to flags picture_header_in_slice_header_flag and xxx_info_in_ph_flag), considering "xxx" to one of the mentioned tools, in the current syntax xxx can be signaled in the slice header if xxx_info_in_ph_flag is set to 0. That is, in the following description, we use the abbreviation XXX or xxx to refer to information types (examples of which are given above) that can be signaled in both picture and slice headers.

[0180] [Table 11]

[0181] When a picture header is in a slice header, this means that there is only one slice for the current picture. Therefore, transmitting or allowing information to be transmitted for both slices and pictures does not increase the flexibility of the encoder or decoder, since the parameters are the same. That is, if there is information in the picture header, the corresponding information in the slice header is redundant. Similarly, if information is in the slice header, the corresponding information in the picture header is redundant. The embodiments described herein simplify the implementation of the decoder by limiting the redundancy in the signaling of the same encoding. In particular, in the embodiments, when a picture header is signaled in a slice header, information is allowed to be in the picture header but not in the slice header.

[0182] Streaming Applications Some streaming applications extract only certain parts of the bitstream. These extractions can be spatial (as subpictures) or temporal (subparts of a video sequence). These extracted parts can then be merged with other bitstreams. Others reduce the frame rate by extracting only some frames. In general, the main goal of these streaming applications is to provide the best possible quality to the end user using the maximum allowed bandwidth.

[0183] VVC restricts the APS_ID numbering so that a new APS_ID number for a frame cannot be used for a frame higher in the temporal hierarchy to reduce frame rate, but streaming applications that extract portions of the bitstream need to keep track of which APS to keep for that portion of the bitstream, since frames (as IRAPs) do not reset the APS_ID numbering.

[0184] LMCS (Luma Mapping with Chroma Scaling) The luma mapping with chroma scaling (LMCS) technique is a method of transforming sample values ​​that is applied to a block before applying a loop filter in a video decoder such as VVC.

[0185] LMCS can be divided into two sub-tools, the first one applied to the luma block and the second one applied to the chroma block, as described below: 1) The first sub-tool is in-loop mapping of the luma component based on an adaptive piecewise linear model. In-loop mapping of the luma component adjusts the dynamic range of the input signal by redistributing codewords across the dynamic range to improve compression efficiency. Luma mapping uses a forward mapping function to the "mapping domain" and a corresponding reverse mapping function back to the "input domain". 2) The second sub-tool concerns the chroma components, where luma-dependent chroma residual scaling is applied. The chroma residual scaling is designed to compensate for the interaction between a luma signal and its corresponding chroma signal. The chroma residual scaling depends on the average value of the reconstructed neighboring (above and / or left) luma samples of the current block.

[0186] LMCS can be enabled / disabled at the sequence level using an SPS flag, similar to other tools in video coding such as VVC. Chroma residual scaling is also signaled at the slice level. If luma mapping is enabled, an additional flag is signaled indicating whether luma-dependent chroma residual scaling is enabled or not. If luma mapping is not used, luma-dependent chroma residual scaling is completely disabled. Also, chroma-dependent chroma residual scaling is always disabled if the chroma block size is 4 or less.

[0187] Figure 8 illustrates the principle of LMCS explained above for the luma mapping sub-tool. The hatched blocks in Figure 8 are the functional blocks of the new LMCS, including forward and backward mapping of the luma signal. When using LMCS, it should be noted that some decoding operations are applied in the "mapped domain". These operations are represented by dashed blocks in this Figure 8. These usually correspond to the reconstruction steps, including inverse quantization, inverse transform, luma intra prediction, and addition of luma prediction and luma residual. Conversely, the solid blocks in Figure 8 indicate where decoding operations are applied in the original (i.e., unmapped) domain, including deblocking, loop filtering such as ALF and SAO, motion compensation prediction, and storage of the decoded image as a reference picture (DPB).

[0188] Figure 9 is a diagram similar to Figure 8, but this time of the chroma scaling subtool of the LMCS tool. The hatched blocks in Figure 9 are the new LMCS functional blocks that contain the luma-dependent chroma scaling process. However, there are some important differences in chroma compared to the luma case. Here, only the inverse quantization and the inverse transform represented by the dashed blocks are performed in the "mapped domain" for the chroma samples. All other steps of intra-chroma prediction, motion compensation, and loop filtering are performed in the original domain. As shown in Figure 9, there is only the scaling process, there is no forward and inverse transform process like luma mapping.

[0189] Luma mapping with piecewise linear models. The luma mapping subtool uses a piecewise linear model, which separates the dynamic range of the input signal into 16 equal subranges, and for each subrange, the parameters of the linear mapping are expressed by the number of codewords assigned to that range.

[0190] Luma mapping semantics lmcs_min_bin_idx specifies the minimum bin index to use in the Luma Mapping with Chroma Scaling (LMCS) construction process. The value of lmcs_min_bin_idx ranges from 0 to 15.

[0191] lmcs_delta_max_bin_idx specifies the difference between the maximum bin index LmcsMaxBinIdx used in the luma mapping with chroma scaling construction process and 15. The value of lmcs_delta_max_bin_idx must be in the range from 0 to 15. The value of LmcsMaxBinIdx is set to 15-lmcs_delta_max_bin_idx. The value of LmcsMaxBinIdx must be greater than or equal to lmcs_min_bin_idx.

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

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

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

[0195] LMCS intermediate variable calculation for luma mapping To apply the forward and backward luma mapping processes, some intermediate variables and data arrays are required.

[0196] First, the variable OrgCW is derived as follows: OrgCW=(1< <BitDepth) / 16

[0197] Then, the variable lmcsDeltaCW[i] (i=lmcs_min_bin_idx....LmcsMaxBinIdx) is calculated as follows: lmcsDeltaCW[i]=(1-2*lmcs_delta_sign_cw_flag[i])*lmcs_delta_abs_cw[i]

[0198] The new variable lmcsCW[i] is derived as follows: For i=0...lmcs_min_bin_idx-1, lmcsCW[i] is set to 0. For i=lmcs_min_bin_idx...LmcsMaxBinIdx, the following applies: lmcsCW[i]=OrgCW+lmcsDeltaCW[i] The value of lmcsCW[i] must be in the range (OrgCW>>3) to (OrgCW<<3-1). For i=LmcsMaxBinIdx+1...15, lmcsCW[i] is set to 0.

[0199] The variable InputPivot[i], for i = 0...16, is derived as follows: InputPivot[i]=i*OrgCW

[0200] The variables LmcsPivot[i] (i=0..16), ScaleCoeff[i] and InvScaleCoeff[i] (i=0..15) are calculated as follows: LmcsPivot[0] = 0; for(i=0;i<=15;i++) { LmcsPivot[i+1]=LmcsPivot[i]+lmcsCW[i] ScaleCoeff[i]=(lmcsCW[i]*(1<<11)+(1<<(Log2(OrgCW)-1)))>>(Log2(OrgCW)) if(lmcsCW[i]==0) InvScaleCoeff[i]=0 else InvScaleCoeff[i]=OrgCW*(1<<11) / lmcsCW[i]

[0201] Forward Luma Mapping As shown in FIG. 8, when LMCS is applied to luma, luma remap samples called predMapSamples[i][j] are obtained from prediction samples predSamples[i][j].

[0202] predMapSamples[i][j] is calculated as follows: First, the index idxY of the position (i,j) is calculated from the predicted samples predSamples[i][j]. idxY=predSamples[i][j]>>Log2(OrgCW) Then, using the intermediate variables idxY, LmcsPivot[idxY], and InputPivot[idxY] from the 0th section, predMapSamples[i][j] is derived as follows: predMapSamples[i][j]=LmcsPivot[idxY]+(ScaleCoeff[idxY]*(predSamples[i][j]-InputPivot[idxY])+(1<<10))>>11

[0203] Luma Reconstruction Sample The reconstruction process is performed from the predicted luma samples predMapSample[i][j] and the residual luma samples resiSamples[i][j].

[0204] The reconstituted luma image sample recSamples[i][j] is obtained only by adding predMapSample[i][j] to resiSamples[i][j] as follows: recSamples[i][j]=Clip1(predMapSamples[i][j]+resiSamples[i][j])

[0205] In the above relationship, the Clip1 function is a clipping function for ensuring that the reconstituted sample is between 0 and 1<<BitDepth-1.

[0206] Inverse luma mapping When applying inverse luma mapping according to FIG. 8, the following operations are applied to each sample recSample[i][j] of the current block being processed:

[0207] First, an index idxY is calculated from the reconstituted sample recSamples[i][j] at position (i,j). idxY=recSamples[i][j]>>Log2(OrgCW) The inverse-mapped luma sample invLumaSample[i][j] is derived as follows: invLumaSample[i][j]=InputPivot[idxYInv]+(InvScaleCoeff[idxYInv]*(recSample[i][j]-LmcsPivot[idxYInv])+(1<<10))>>11 Then, a clipping operation is performed to obtain the final sample: finalSample[i][j]=Clip1(invLumaSample[i][j])

[0208] Chrominance scaling LMCS semantics for chrominance scaling The syntax element lmcs_delta_abs_crs in Table 6 specifies the codeword absolute value of the variable lmcsDeltaCrs. The value of lmcs_delta_abs_crs ranges from 0 to 7. If not present, lmcs_delta_abs_crs is inferred to be 0.

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

[0210] LMCS intermediate variable calculation for chroma scaling In order to apply the chroma scaling process, some intermediate variables are required. The variable lmcsDeltaCrs is derived as follows: lmcsDeltaCrs=(1-2*lmcs_delta_sign_crs_flag)*lmcs_delta_abs_crs

[0211] The variable ChromaScaleCoeff[i], for i = 0...15, is derived as follows: if(lmcsCW[i]==0) ChromaScaleCoeff[i]=(1<<11) else ChromaScaleCoeff[i]=OrgCW*(1<<11) / (lmcsCW[i]+lmcsDeltaCrs)

[0212] Chroma Scaling Processing In the first step, the variable invAvgLuma is derived to calculate the average luma value of the reconstructed luma samples around the current corresponding chroma block. The average luma is calculated from the left and top luma blocks surrounding the corresponding chroma block. If there are no samples, the variable invAvgLuma is set as follows: invAvgLuma=1<<(BitDepth-1)

[0213] Then, based on the intermediate array LmcsPivot[] of the 0th section, we derive the variables idxYInv as follows: For(idxYInv=lmcs_min_bin_idx;idxYInv<=LmcsMaxBinIdx;idxYInv++){ if(invAvgLuma <LmcsPivot[idxYInv+1]) break } IdxYInv = Min(idxYInv,15)

[0214] The variable varScale is derived as follows: varScale=ChromaScaleCoeff[idxYInv]

[0215] After applying the transformation to the current chroma block, the reconstructed chroma image samples array recSamples is derived as follows: recSamples[i][j]=Clip1(predSamples[i][j]+Sign(resiSamples[i][j])*((Abs(resiSamples[i][j])*varScale+(1<<10))>>11)) If no transformations have been applied to the current block, then: recSamples[i][j]=Clip1(predSamples[i][j])

[0216] Encoder Considerations The basic principle of the LMCS coder is to first assign more codewords to segments of the dynamic range whose codewords are lower than the average variance. As another form of this, the main target of LMCS is to assign fewer codewords to segments of the dynamic range whose codewords are higher than the average variance. In this way, smooth regions of the image are coded with more codewords than the average, and vice versa.

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

[0218] An embodiment in which information is reported in a picture header instead of a slice header In an embodiment, the signaling of information that can be signaled in a picture header or a slice header is signaled in a picture header when the picture header is signaled in a slice header, and is not signaled in a slice header. Also, there is an equivalent method in which the picture header is not signaled in a slice header when the signaling of information that can be signaled in a picture header or a slice header is signaled in a slice header. In another equivalent method, the picture header is signaled in a slice header when the signaling of information that can be signaled in a picture header or a slice is signaled in a picture header. Table 12 is a table showing an embodiment in which the tool name is replaced with XXX. In this table, when the picture header is signaled in a slice header, the signaling of parameters is not allowed in the slice header.

[0219] [Table 12]

[0220] In one embodiment, the semantics of xxx_info_in_ph_flag adds the following condition: "If a slice header that references a PPS contains a PH syntax structure, it is a bitstream conformance requirement that XXX_info_in_ph_flag be 1." and / or "When XXX_info_in_ph_flag is 0, picture_header_in_slice_header_flag is 0."

[0221] If a picture header is in a slice header, this means that there is only one slice for the current picture. Therefore, transmitting or being able to transmit information for both slices and pictures does not increase the flexibility of the encoder or decoder, since the parameters are the same. That is, if there is information in the picture header, the corresponding information in the slice header is redundant. Similarly, if there is information in the slice header, the corresponding information in the picture header is redundant. In this way, by enforcing the condition that if the picture header is in the slice header, the information is in the picture header and not in the slice header, the signaling redundancy can be limited and the decoder implementation can be simplified.

[0222] QP (quantization parameter) delta In an embodiment, when a picture header is signaled in a slice header, QP delta signaling is avoided in the slice header. In an equivalent manner, when QP delta signaling is signaled in a slice header, a picture header is not signaled in the slice header. In another equivalent manner, when a QP delta is signaled in a picture header, a picture header is signaled in a slice header. That is, the above tool XXX is QP delta.

[0223] Table 13 shows how this can be implemented such that signaling of QP delta information is not authorized (ie, not allowed) if the picture header is signaled within the slice header.

[0224] [Table 13]

[0225] If the picture header is in the slice header (meaning that there is only one slice for the current picture), the information that can be conveyed in the slice and picture headers does not increase the flexibility of the encoder or decoder, since the parameters are the same. Therefore, in order to reduce the complexity of the decoder implementation, it is more preferable to have only one possible signaling QP delta information in the slice or picture header to code the same coding possibility (in this case, the QP delta parameter (qp_delta_info)).

[0226] In implementing the first embodiment, the following condition may be added to the semantics of qp_delta_info_in_ph_flag: "If a slice header that references a PPS contains a PH syntax structure, it is a bitstream conformance requirement that qp_delta_info_in_ph_flag be 1." and / or "When qp_delta_info_in_ph_flag is 0, picture_header_in_slice_header_flag is 0."

[0227] In another embodiment, decoding of QP delta parameters in the slice header is only allowed if the value of the flag picture_header_in_slice_header_flag is set to 0, as depicted in Table 14. The syntax changes are underlined. In this table, the slice_qp_delta information in the slice header can be decoded if the QP delta information is signaled at the slice level (qp_delta_info_in_ph_flag is 0) and the picture header is not transmitted in the slice header (picture_header_in_slice_header_flag is 0).

[0228] [Table 14]

[0229] In an embodiment, decoding of QP delta parameters in a picture header is systematically allowed when the value of the flag picture_header_in_slice_header_flag is set to 1, as depicted in Table 15. According to this table, the QP delta information in a slice header can be decoded only if the QP delta information is signaled in the picture header (qp_delta_info_in_ph_flag is 1) or if the picture header is transmitted within the slice header (picture_header_in_slice_header_flag is 1).

[0230] [Table 15]

[0231] Reference Picture List (RPL) In one embodiment, when the picture header is signaled in the slice header, the signaling of the reference picture list is avoided in the slice header. In an equivalent manner, the picture header is not signaled in the slice header when the signaling of the reference picture list is signaled in the slice header. In another equivalent manner, the picture header is signaled in the slice header when the signaling of the reference picture list is performed in the picture header. In other words, the above tool XXX is RPL.

[0232] Table 16 shows an implementation of this embodiment that does not allow RPL signaling when signaling a picture header within a slice header.

[0233] [Table 16]

[0234] If the picture header is in the slice header (meaning that there is only one slice for the current picture), the possibility of conveying information in the slice header and the picture header does not increase the flexibility for the encoder or the decoder, since the parameters are the same. According to this embodiment, the complexity of the decoder implementation is reduced, since it is better to have only possible signaling of information in one of the slice or picture headers to code the same coding possibility (in this case Reference Picture List (RPL) information (rpl_info)).

[0235] In an embodiment, the semantics of rpl_info_in_ph_flag adds the following condition: "If a slice header that references a PPS contains a PH syntax structure, it is a bitstream conformance requirement that rpl_info_in_ph_flag be set to 1." and / or "When rpl_info_in_ph_flag is 0, picture_header_in_slice_header_flag is 0."

[0236] In an embodiment, decoding of reference picture list parameters in a slice header is allowed only if the value of the flag picture_header_in_slice_header_flag is set to 0, as depicted in Table 17. In this table, if reference picture list information is signaled at the slice level (rpl_info_in_ph_flag is 0) and the picture header is not transmitted in the slice header (picture_header_in_slice_header_flag is 0), the ref_pic_lists() information of the slice header can be decoded.

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

[0238] [Table 17]

[0239] In an embodiment, decoding of the RPL parameters of the picture header is systematically allowed if the value of the flag picture_header_in_slice_header_flag is set to 1, as depicted in Table 18. 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 1) or if the picture header is transmitted in the slice header (picture_header_in_slice_header_flag is 1).

[0240] In an embodiment, as depicted in Table 18, when the picture header is within the slice header, the temporal parameters ph_collocated_from_l0_flag and ph_collocated_ref_idx may be decoded.

[0241] [Table 18]

[0242] Deblocking Filter (DBF) In an embodiment, the signaling of the deblocking filter parameters is avoided in the slice header when the picture header is signaled in the slice header. In an equivalent manner, the picture header is not signaled in the slice header when the signaling of the deblocking filter parameters is signaled in the slice header. In another equivalent manner, the picture header is signaled in the slice header when the signaling of the deblocking filter parameters is performed in the picture header. That is, the above-mentioned tool XXX is a DBF.

[0243] Table 19 illustrates an implementation according to the present invention that does not allow DBF signaling when signaling a picture header within a slice header.

[0244] [Table 19]

[0245] If the picture header is in the slice header, there is only one slice for the current picture, so the information transmitted in the slice or picture does not increase the flexibility of the encoder or decoder, since the parameters are the same. Therefore, in order to reduce the complexity of the decoder implementation, it is better that there is only one possible encoding of the DBF information to encode the same encoding possibility.

[0246] In an embodiment, the following condition is added to the semantics of dbf_info_in_ph_flag: "If a slice header that references a PPS contains a PH syntax structure, it is a bitstream conformance requirement that dbf_info_in_ph_flag be set to 1." and / or "When dbf_info_in_ph_flag is 0, picture_header_in_slice_header_flag is 0."

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

[0248] [Table 20]

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

[0250] [Table 21]

[0251] SAO (Sample Adaptive Offset) In one embodiment, SAO signaling is avoided in the slice header when the picture header is signaled in the slice header. In an equivalent manner, the picture header is not signaled in the slice header when the SAO signaling is signaled in the slice header. In another equivalent manner, the picture header is signaled in the slice header when the SAO signaling is signaled in the picture header. That is, the above tool XXX is SAO.

[0252] Table 22 illustrates this embodiment in which SAO signaling is not allowed when signaling a picture header within a slice header.

[0253] [Table 22]

[0254] If the picture header is in the slice header, there is only one slice for the current picture, so the information transmitted in the slice or picture does not increase the flexibility for the encoder or decoder, since the parameters are the same. Therefore, in order to reduce the complexity of the decoder implementation, it is better to have only one possible encoding of the SAO information to encode the same encoding possibility.

[0255] In an embodiment, the following condition is added to the semantics of sao_info_in_ph_flag: "If a slice header that references a PPS contains a PH syntax structure, it is a bitstream conformance requirement that sao_info_in_ph_flag be set to 1." and / or "When sao_info_in_ph_flag is 0, picture_header_in_slice_header_flag is 0."

[0256] In an embodiment, decoding of SAO parameters in a slice header is allowed only if the value of the flag picture_header_in_slice_header_flag is set to 0, as shown below.

[0257] Table 23. In this table, if SAO information is signaled at the slice level (sao_info_in_ph_flag is 0) and no picture header is transmitted in the slice header (picture_header_in_slice_header_flag is 0), slice_sao_luma_flag in the slice header can be decoded.

[0258] [Table 23]

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

[0260] [Table 24]

[0261] Weighted average forecast (WP) In one embodiment, when the picture header is signaled in the slice header, the signaling of the weighted prediction is avoided in the slice header. In an equivalent manner, when the signaling of the 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 the weighted prediction is signaled in the picture header, the picture header is signaled in the slice header. That is, the above-mentioned tool XXX is WP.

[0262] As shown in Table 25, WP parameters can be signaled in the slice header by setting wp_info_in_ph_flag to 0 in the current syntax.

[0263] Table 25 shows an implementation of this embodiment where WP signaling is not allowed when signaling a picture header within a slice header.

[0264] [Table 25]

[0265] If the picture header is in the slice header, there is only one slice for the current picture, so the information transmitted in the slice or picture does not increase the flexibility of the encoder or decoder, since the parameters are the same. Therefore, to reduce the complexity of the decoder implementation, it is better to have only one possible encoding of the WP information to encode the same encoding possibility.

[0266] In an embodiment, the following condition is added to the semantics of wp_info_in_ph_flag: "If a slice header that references a PPS contains a PH syntax structure, it is a bitstream conformance requirement that wp_info_in_ph_flag be set to 1." and / or "If wp_info_in_ph_flag is 0, picture_header_in_slice_header_flag is 0."

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

[0268] [Table 26]

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

[0270] [Table 27]

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

[0272] In fact, currently, if a picture header is signaled in a slice header (picture_header_in_slice_header_flag is 1) and if an ALF is signaled in a slice header (alf_info_in_ph_flag is 0), all parameters of the picture header should be parsed before getting the APS_ID of the ALF, which increases the parsing complexity of some streaming applications, since all variables such as PPS, SPS, picture header, etc. have to be kept in memory to parse the APS_ID of the ALF.

[0273] Moreover, if the picture header is in the slice header, it does not increase the flexibility of the encoder or decoder, since there is only one slice for the current picture, and the information transmitted in the slice or picture has the same parameters. Therefore, in order to reduce the complexity of the decoder implementation, it is better to have only one signaling of the same encoding possibility. Table 28 shows this embodiment, which does not allow ALF signaling when the picture header is signaled in the slice header.

[0274] [Table 28]

[0275] In an embodiment, the following condition is added to the semantics of alf_info_in_ph_flag: "If a slice header that references a PPS contains a PH syntax structure, it is a bitstream conformance requirement that alf_info_in_ph_flag be set to 1." and / or "When alf_info_in_ph_flag is 0, picture_header_in_slice_header_flag is 0."

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

[0277] [Table 29]

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

[0279] [Table 30]

[0280] All Tools / Parameters In one embodiment, if a picture header is signaled in a slice header, all tools (and / or parameters) that can be signaled in a picture header or in a slice header are restricted to be 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, ALF. However, other tools are possible and they can be signaled in both slice and picture headers.

[0281] This can be expressed by adding the following constraint: "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, and qp_delta_info_in_ph_flag is set to 0, the value of picture_header_in_slice_header_flag shall be 0." and / or add: "When picture_header_in_slice_header_flag is 1, the flags rpl_info_in_ph_flag, dbf_info_in_ph_flag, sao_info_in_ph_flag, wp_info_in_ph_flag, and qp_delta_info_in_ph_flag shall be 1."

[0282] Also add the following constraints to each XXX_info_in_ph_flag: "If a slice header that references a PPS contains a PH syntax structure, it is a bitstream conformance requirement that XXX_info_in_ph_flag be 1."

[0283] If all these parameters are signaled in the same header, it is better to have only one signaling for encoding the same encoding possibility, which can reduce the complexity of the decoder implementation.

[0284] Signaling Order Embodiments In one alternative embodiment to the previous one related to ALF, the information related to the APS_ID of the ALF in the slice header is set before the structure of the picture header, as depicted in Table 31. In this embodiment, when an ALF is signaled in the slice header and when an intra-picture header is signaled in the slice header, the APS_ID can be quickly obtained without parsing all the parameters of the picture header.

[0285] [Table 31]

[0286] Weight Number Implementation Example In an embodiment where the picture header is within the slice header, the number of weighted prediction weights for each list L0-L1 is decoded as depicted in the syntax element portion of Table 32. Thus, signaling of the number of weights may be limited to the picture header.

[0287] [Table 32]

[0288] Overview of an embodiment in which information is reported in a slice header but not in a picture header In one embodiment, the signaling of information that can be signaled in a picture header or a slice header is signaled in a slice header when the picture header is signaled in a slice header, and is not signaled in the picture header. Also, the signaling of information that can be signaled in a picture header or a slice header is not signaled in a slice header when it is signaled in a picture header. In another equivalent method, the picture header is signaled in a slice header when the signaling of information that can be signaled in a picture header or a slice header is signaled in a slice header. Table 33 shows this embodiment with the tool (or parameter) name replaced with XXX. In this table, if the picture header is signaled in a slice header, the signaling of the parameter in the picture header is not allowed.

[0289] [Table 33]

[0290] In one embodiment, the semantics of xxx_info_in_ph_flag adds the following condition: "If a slice header that references a PPS contains PH syntax, it is a bitstream conformance requirement that XXX_info_in_ph_flag be 0." and / or "When XXX_info_in_ph_flag is 1, picture_header_in_slice_header_flag is 0."

[0291] If a picture header is in a slice header, this means that there is only one slice for the current picture. Therefore, transmitting or allowing information to be transmitted for both slices and pictures does not increase the flexibility of the encoder or decoder, since the parameters are the same. That is, if there is information in the picture header, the corresponding information in the slice header is redundant. Similarly, if information is in the slice header, the corresponding information in the picture header is redundant. The embodiments described herein simplify the implementation of the decoder by limiting the redundancy in the signaling of the same encoding. In particular, in the embodiments, if the picture header is signaled in the slice header, it is allowed for information to be in the slice header, but not in the picture header.

[0292] QP Delta In one embodiment, the tool XXX is QP delta. In one embodiment, as depicted in Table 33, when the value of the flag picture_header_in_slice_header_flag is set to 1, decoding of the QP delta parameter of the slice header is allowed. Also as shown in Table 33, picture_header_in_slice_header_flag is set to a value equal to 0 if the QP delta parameter is signaled in the picture header. In another equivalent manner, as depicted in Table 33, when the QP delta parameter is signaled in the slice header, picture_header_in_slice_header_flag is set to 1. In this table, slice_qp_delta information of the slice header may be decoded if the QP delta information is signaled at the slice level (qp_delta_info_in_ph_flag is 0) or if the picture header is transmitted in the slice header (picture_header_in_slice_header_flag is 1).

[0293] This is achieved by adding the following to the semantics: "If a slice header that references a PPS contains the PH syntax, it is a bitstream conformance requirement that qp_delta_info_in_ph_flag be 0." and / or "When qp_delta_info_in_ph_flag is 1, picture_header_in_slice_header_flag is 0."

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

[0295] RPL (Reference Picture List) In one embodiment, the tool XXX is a reference picture list. In one embodiment, the decoding of the parameters of the reference picture list in the slice header is authorized only if the value of the flag picture_header_in_slice_header_flag is set to 1, as depicted in Table 33. Also, picture_header_in_slice_header_flag is set to 0 when the reference picture list parameters are signaled in the picture header, as shown in Table 33. Also, picture_header_in_slice_header_flag is set to 1 when the reference picture parameters are signaled in the slice header, as shown in Table 33. In this table, if the reference picture list information is signaled at the slice level (rpl_info_in_ph_flag is 0) and the picture header is transmitted in the slice header (picture_header_in_slice_header_flag is 1), the ref_pic_lists() information of the slice header can be decoded.

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

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

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

[0299] Deblocking Filter (DBF) In one embodiment, the tool XXX is a 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 1, the DBF parameters in the slice header are authorized. Also as shown in Table 33, when the picture_header_in_slice_header_flag is set to 0, the DBF parameters are signaled in the picture header. Also as shown in Table 33, when the DBF parameters are stored in the slice header, the picture_header_in_slice_header_flag is set to 1. In this table, the slice_deblocking_filter_override_flag flag in the slice header may be decoded if the DBF information is signaled at the slice level (dbf_info_in_ph_flag is 0) or if the picture header is carried in the slice header (picture_header_in_slice_header_flag is 1).

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

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

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

[0303] WP (Weighted Prediction) In one embodiment, the tool XXX is WP (weighted prediction). In one embodiment, the WP parameters in the slice header are authorized only if the value of the flag picture_header_in_slice_header_flag is set to 1, as depicted in Table 33. Also as shown in Table 33, picture_header_in_slice_header_flag is set to 0 when the WP parameters are signaled in the picture header. Also as shown in Table 33, picture_header_in_slice_header_flag is set to 1 when the WP parameters are signaled in the slice header. In this table, the pred_weight_table() function including the weighted prediction parameters may be decoded if the WP information is signaled at the slice level (wp_info_in_ph_flag is 0) or if the picture header is transmitted in the slice header (picture_header_in_slice_header_flag is 1).

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

[0305] ALF (Adaptive Loop Filter) In one embodiment, the tool XXX is an ALF (adaptive loop filter). In one embodiment, the decoding of the ALF parameters of the slice header is allowed only if the value of the flag picture_header_in_slice_header_flag is set to 1, as depicted in Table 33. Also, picture_header_in_slice_header_flag is set to 0 if the ALF parameters are signaled in the picture header (Table 33). In another equivalent way, picture_header_in_slice_header_flag is set to 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 is 1), if the ALF information is signaled at the slice level (alf_info_in_ph_flag is 0), or if the picture header is transmitted in the slice header (picture_header_in_slice_header_flag is 1).

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

[0307] [Table 34] TIFF0007672538000041.tif198170

[0308] [Table 35]

[0309] All Tools / Parameters In an embodiment, if a picture header is signaled in a slice header, all tools (and / or parameters) that can be signaled in a picture header or a 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 may be possible if they can be signaled in both slice and picture headers.

[0310] This can be expressed by adding the following constraint: "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, and qp_delta_info_in_ph_flag is 1, picture_header_in_slice_header_flag shall be 0." and / or add: "When picture_header_in_slice_header_flag is 1, the flags rpl_info_in_ph_flag, dbf_info_in_ph_flag, sao_info_in_ph_flag, wp_info_in_ph_flag, and qp_delta_info_in_ph_flag shall be 0."

[0311] Also add the following constraints to each XXX_info_in_ph_flag: "If a slice header that references a PPS contains PH syntax, it is a bitstream conformance requirement that XXX_info_in_ph_flag be 0."

[0312] If all these parameters are signaled within the same header, the complexity of the decoder implementation is reduced, since if the tools or parameters necessarily have the same value or characteristics, it is better to have only one signaling possible.

[0313] implementation Fig. 10 illustrates a system 191, 195 including at least one of the encoder 150 or the decoder 100 and a communication network 199 according to an embodiment of the present invention. According to an embodiment, the system 195 is a system for processing and providing content (e.g. video and audio content for display / output or streaming) to a user accessing the decoder 100, for example through a user interface of a user terminal constituting the decoder 100 or capable of communicating with the decoder 100. Such a user terminal may be a computer, a mobile phone, a tablet or any other type of device capable of providing / displaying content (to be provided / streamed) to a user. The system 195 obtains / receives the bitstream 101 (in the form of a continuous stream or signal (e.g. while a previous video / audio is being displayed / output)) via the communication network 199. According to an embodiment, the system 191 is for processing content and storing the processed content, for example the processed video and audio content for display / output / streaming at a later time. The system 191 obtains / receives content comprising an original image sequence 151 that has been received and processed (including filtered by a deblocking filter according to the invention) by an encoder 150 which generates a bitstream 101 to be communicated to the decoder 100 via a communication network 191. The bitstream 101 may then be communicated to the decoder 100 in a number of ways, but may for example be pre-generated by the encoder 150 and stored as data in a storage device (e.g. a server or cloud storage) in the communication network 199 until a user requests the content (i.e. bitstream data) from the storage device, at which point the data is communicated / streamed from the storage device to the decoder 100.The system 191 may also include a content providing device that provides / streams content information (e.g., title of the content and other meta / location data for identifying, selecting and requesting the content) of the content stored in the storage device to the user (e.g., by communicating data of a user interface to be displayed on the user terminal) and receives and processes user requests for content so that the requested content can be delivered / streamed from the storage device to the user terminal. Alternatively, the encoder 150 generates the bitstream 101 when the user requests the content and communicates / streams it directly to the decoder 100. The decoder 100 then receives the bitstream 101 (or signal) and filters it with a deblocking filter according to the present invention to obtain / generate a video signal 109 and / or an audio signal, which is used by the user terminal to provide the requested content to the user.

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

[0315] The embodiments of the present invention may be implemented by a wide variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs) or IC sets (e.g., chipsets). Various components, modules, or units are described herein to describe functional aspects of devices / apparatuses configured to carry out the embodiments, but do not necessarily require implementation by different hardware units. Rather, the various modules / units may be combined into a codec hardware unit or provided by a collection of interoperable hardware units including one or more processors in conjunction with appropriate software / firmware.

[0316] The embodiments of the present invention may be realized by a computer of a system or apparatus including one or more processing units or circuits for reading and executing computer-executable instructions (e.g., one or more programs) recorded on a storage medium to perform one or more modules / units / functions of the above-mentioned embodiments, for example, by a method executed by a computer of a system or apparatus that reads and executes computer-executable instructions from a storage medium to perform one or more functions of the above-mentioned embodiments, and / or controls one or more processing units or circuits to perform one or more functions of the above-mentioned embodiments. The computer may include a separate computer or a network of separate processing units for reading and executing the computer-executable instructions. The computer-executable instructions may be provided to the computer from a computer-readable medium, such as, for example, a communication medium via a network or a tangible storage medium. The communication medium may be a signal / bit stream / carrier wave. The tangible storage medium is a "non-transitory computer-readable storage medium" and may include, for example, one or more of a hard disk, a random access memory (RAM), a read-only memory (ROM), a storage of a distributed computing system, an optical disk (such as a compact disk (CD), a digital versatile disk (DVD), a Blu-ray disk (BD)™), a flash memory device, a memory card, etc. Also, at least some of the steps / functions may 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).

[0317] FIG. 11 is a schematic block diagram of a computing device 2000 for implementing one or more embodiments of the present invention. The computing device 2000 may be a device such as a microcomputer, a workstation, or a lightweight handheld device. The computing device 2000 comprises a central processing unit (CPU) 2001, such as a microprocessor, connected to a communication bus; a random access memory (RAM) 2002 for storing executable codes of the methods of the present invention and registers adapted for recording variables and parameters required for implementing the methods of encoding or decoding at least a part of an image according to the embodiments of the present invention (the memory capacity 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; and a network interface (NET) 2004, which is typically connected to a communication network over which digital data to be processed is transmitted or received. The network interface (NET) 2004 may be a single network interface or may be composed of a collection of different network interfaces (e.g., a wired interface and a wireless interface, or different types of wired or wireless interfaces). Data packets are written to the network interface for transmission or read from the network interface for reception under the control of software applications executing on the CPU 2001, a user interface (UI) 2005 may be used to receive input from a user or display information to a user, a hard disk (HD) 2006 may be provided as a mass storage device, an input / output module (IO) 2007 may be used to receive / transmit data from / to external devices such as video sources or displays, etc. Executable code may be stored in either the ROM 2003, the HD 2006, or on a removable digital medium such as a disk.According to a variant, the executable code of the program can be received by the communication network means, via NET 2004, in order to be stored in one of the storage means of the communication device 2000, such as HD 2006, before being executed. The CPU 2001 is adapted to control and direct the execution of instructions or parts of a program or software code of a program according to an embodiment of the invention, said instructions being stored in one of the aforementioned storage means. After power-on, the CPU 2001 is capable of executing instructions from the main RAM memory 2002 related to a software application, after those instructions have been loaded, for example, 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 invention to be carried out.

[0318] It is also understood that according to another embodiment of the present invention, the decoder according to the aforementioned embodiment is provided in a user terminal such as a computer, a mobile phone (cellular phone), a table, or other type of device (e.g., display device) that can provide / display content to a user. According to yet another embodiment, the encoder according to the aforementioned embodiment is provided in an imaging device, including also a camera, a video camera or a network camera (e.g., a closed circuit television or a video surveillance camera), that captures and provides content for the encoder to encode. Two such examples are provided below with reference to Figures 11 and 12.

[0319] Network camera FIG. 11 is a diagram illustrating a network camera system 2100 including a network camera 2102 and a client device 2104 . The network camera 2102 includes an imaging unit 2106 , an encoding unit 2108 , a communication unit 2110 , and a control unit 2112 . A network camera 2102 and a client device 2104 are connected to each other via a network 200 so that they can communicate with each other. 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)), captures an image of an object, and generates image data based on the image. This image may be a still image or a video image. The encoding unit 2108 encodes the image data using the encoding method described above. 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 . Furthermore, the communication unit 2110 receives commands from the client device 2104. The commands include a command to set parameters for the encoding unit 2108 to encode. The control unit 2112 controls other units within the network camera 2102 according to commands received by the communication unit 2110 . The client device 2104 includes a communication unit 2114 , a decoding unit 2116 , and a control unit 2118 . The communication unit 2114 of the client device 2104 transmits a command to the network camera 2102 . Furthermore, the communication unit 2114 of the client device 2104 receives the encoded image data from the network camera 2102 . The decoding unit 2116 decodes the encoded image data using the above-mentioned decoding method. The control unit 2118 of the client device 2104 controls other units within the client device 2104 in accordance with user operations or commands received by the communication unit 2114 . The control unit 2118 of the client device 2104 controls the display device 2120 to display the image decoded by the decoding unit 2116 . Also, the control unit 2118 of the client device 2104 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 . Furthermore, the control unit 2118 of the client device 2104 controls other units within the client device 2104 in response to a user operation input to a GUI displayed by the display device 2120 . The control unit 2119 of the client device 2104 controls the communication unit 2114 of the client device 2104 to send a command specifying a parameter value for the network camera 2102 to the network camera 2102 in response to a user's operational input to the GUI displayed by the display device 2120.

[0320] Smartphone FIG. 12 is a diagram for explaining the smartphone 2200. As shown in FIG. 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 . The communication unit 2202 receives the encoded image data via the network 200 . The decoding unit 2204 decodes the encoded image data received by the communication unit 2202 . The decoding unit 2204 decodes the coded image data using the above-mentioned decoding method. The control unit 2206 controls other units within the smartphone 2200 in accordance with user operations and commands received by the communication unit 2202 . For example, the control unit 2206 controls the display unit 2208 to display the image decoded by the decoding unit 2204 .

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

[0322] It will also be understood that any result of the above comparisons, decisions, evaluations, selections, executions, performing, or considerations (e.g., selections made during an encoding or filtering process) may be indicated or determined / referenced in data in the bitstream (e.g., flags or data indicating the results), and that the indicated or determined / referenced results may be used in processing in lieu of actually performing the comparisons, decisions, evaluations, selections, executions, performing, or considerations, e.g., during a decoding process.

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

[0324] Any reference numerals appearing in the claims are for illustrative purposes only and do not limit the scope of the claims.

Claims

1. 1. A method for decoding video data from a bitstream, comprising the steps of: the bitstream includes a picture parameter set, a picture header syntax structure including a plurality of syntax elements used when decoding one or more slices, and a slice header including a plurality of syntax elements used when decoding a slice; The method comprises: decoding a plurality of syntax elements including a first flag indicating whether the picture header syntax structure is in the slice header and a second flag in the picture parameter set; decoding the video data from the bitstream using the decoded syntax elements; and Including, When the second flag has a first value, the second flag indicates that adaptive loop filter (ALF) information may be present in the picture header syntax structure and is not present in the slice header that references the picture parameter set that does not include the picture header syntax structure; If the second flag has a second value different from the first value, the second flag indicates that ALF information is not present in the picture header syntax structure and may be present in the slice header referencing the picture parameter set; constraining the first flag to be decoded with a value indicating that the picture header syntax structure is not present in the slice header if the second flag has the first value; The ALF information includes an adaptation parameter set id for an adaptive loop filter (ALF), and an adaptation parameter set (APS) indicated by the adaptation parameter set id includes a third flag indicating whether multiple clipping indexes for the ALF are decoded. A method comprising:

2. The one or more slices may include image portions of any of the following sizes: 4x4, 8x8, 16x16, 32x32, 64x64, 128x128.

2. The method of claim 1 .

3. The third flag is alf_luma_clip_flag, and each of the plurality of clipping indexes is alf_luma_clip_idx.

2. The method of claim 1 .

4. The picture header syntax structure corresponds to picture_header_structure( ).

2. The method of claim 1 .

5. The adaptation parameter set (APS) indicated by the adaptation parameter set id includes information corresponding to the number of filters for luma.

2. The method of claim 1 .

6. 1. A method for encoding video data into a bitstream, comprising the steps of: the bitstream includes a picture parameter set, a picture header syntax structure including a plurality of syntax elements used when decoding one or more slices, and a slice header including a plurality of syntax elements used when decoding a slice; The method includes encoding the video data using a plurality of syntax elements including a first flag indicating whether the picture header syntax structure is in the slice header and a second flag in the picture parameter set; When the second flag has a first value, the second flag indicates that adaptive loop filter (ALF) information may be present in the picture header syntax structure and is not present in the slice header that references the picture parameter set that does not include the picture header syntax structure; If the second flag has a second value different from the first value, the second flag indicates that ALF information is not present in the picture header syntax structure and may be present in the slice header referencing the picture parameter set; When the second flag has the first value, the first flag necessarily has a value indicating that the picture header syntax structure is absent from the slice header; The ALF information includes an adaptation parameter set id for an adaptive loop filter (ALF), and an adaptation parameter set (APS) indicated by the adaptation parameter set id includes a third flag indicating whether multiple clipping indexes for the ALF are decoded. A method comprising:

7. The one or more slices may include image portions of any of the following sizes: 4x4, 8x8, 16x16, 32x32, 64x64, 128x128.

7. The method of claim 6.

8. The third flag is alf_luma_clip_flag, and each of the plurality of clipping indexes is alf_luma_clip_idx.

7. The method of claim 6.

9. 1. A decoding device for decoding video data from a bitstream, comprising: the bitstream includes a picture parameter set, a picture header syntax structure including a plurality of syntax elements used when decoding one or more slices, and a slice header including a plurality of syntax elements used when decoding a slice; The decoding device comprises: means for decoding a plurality of syntax elements including a first flag indicating whether the picture header syntax structure is in the slice header and a second flag in the picture parameter set; means for decoding the video data from the bitstream using the decoded syntax elements; having When the second flag has a first value, the second flag indicates that adaptive loop filter (ALF) information may be present in the picture header syntax structure and is not present in the slice header that references the picture parameter set that does not include the picture header syntax structure; If the second flag has a second value different from the first value, the second flag indicates that ALF information is not present in the picture header syntax structure and may be present in the slice header referencing the picture parameter set; constraining the first flag to be decoded with a value indicating that the picture header syntax structure is not present in the slice header if the second flag has the first value; The ALF information includes an adaptation parameter set id for an adaptive loop filter (ALF), and an adaptation parameter set (APS) indicated by the adaptation parameter set id includes a third flag indicating whether multiple clipping indexes for the ALF are decoded. A decoding device comprising:

10. 1. An encoding device for encoding video data into a bitstream, comprising: the bitstream includes a picture parameter set, a picture header syntax structure including a plurality of syntax elements used when decoding one or more slices, and a slice header including a plurality of syntax elements used when decoding a slice; the encoding device having means for encoding the video data using a plurality of syntax elements including a first flag indicating whether the picture header syntax structure is in the slice header and a second flag in the picture parameter set; When the second flag has a first value, the second flag indicates that adaptive loop filter (ALF) information may be present in the picture header syntax structure and is not present in the slice header that references the picture parameter set that does not include the picture header syntax structure; If the second flag has a second value different from the first value, the second flag indicates that ALF information is not present in the picture header syntax structure and may be present in the slice header referencing the picture parameter set; When the second flag has the first value, the first flag necessarily has a value indicating that the picture header syntax structure is absent from the slice header; The ALF information includes an adaptation parameter set id for an adaptive loop filter (ALF), and an adaptation parameter set (APS) indicated by the adaptation parameter set id includes a third flag indicating whether multiple clipping indexes for the ALF are decoded.

13. An encoding device comprising:

11. A computer program product causing a computer to carry out the method according to any one of claims 1 to 8.

Images