High-Level Syntax for Video Encoding and Decoding

Abstract

To provide a method for decoding video data from a bit stream.SOLUTION: A method includes decoding a plurality of syntax elements, and decoding video data from a bit stream by using the decoded syntax elements. When information signalled by a picture header or a slice header is signalled in the picture header, constraints are applied so that a flag having a value indicating that the picture header is not in the slice header is decoded. The information signalled in the picture header or the slice header is an adaptation parameter set id for an adaptive loop filter (ALF). An adaptation parameter set (APS) indicated by the adaptation parameter set id can include alf_luma_clip_flag related to the ALF. A clipping index for the ALF is decoded according to a value of alf_luma_clip_flag.SELECTED DRAWING: None

Description

[Technical Field]

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

[0002] Recently, the Joint Video Experts Team (JVET), a joint effort between MPEG and ITU-T Study Group 16's VCEG, began work on a new video coding standard called Versatile Video Coding (VVC). VVC's goal is to significantly improve compression performance (typically double) compared to the existing HEVC standard, with completion expected 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 testing laboratory. Some proposals demonstrated compression efficiency gains of typically 40% or more compared to HEVC. This was particularly effective for ultra-high-definition (UHD) video test material. Therefore, compression efficiency gains far exceeding the 50% goal of the final standard are expected.

[0003] The JVET Exploration Model (JEM) uses all HEVC tools and introduces many new ones. These changes required 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 degrading coding performance.

[0005] According to a first aspect of the present invention, there is provided a method for decoding video data from a bitstream, the bitstream including video data corresponding to one or more 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 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, 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 bitstream compatibility requirement that if the first syntax element indicates that the information is signaled within the picture header, 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, the information includes all information that can be signaled in the picture header and the slice header.

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

[0013] According to a second aspect of the present invention, there is provided a method for encoding video data into a bitstream, the video data corresponding to one or more slices, 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 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 can 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 bitstream compatibility requirement that if the first syntax element indicates that the information is signaled within the picture header, 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, the information includes all information that can be signaled in the picture header and the slice header.

[0020] Optionally, the reference picture list information includes one or more of slice_collocated_from_l0_flag, slice_collocated_ref_idx, ph_collocated_from_l0_flag, 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 slice, the decoding including imposing, if information that can be signaled in the picture header or slice header 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 slice, the decoding including treating as inapplicable a combination of (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 tool information is signaled in a slice header, and decoding the bitstream using the syntax elements. The decoding is not performed if the combination of syntax elements (a) and (b) treated as inapplicable is present.

[0023] According to a related aspect of the present 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 for 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 within 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 slice, 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 a 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 is present.

[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 to be used when decoding the slice, the picture header being to be signaled in the slice header, constraining parsing of information that can 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 slice. 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 to be used when decoding the slice, the picture header being to be signaled in the slice header, constraining parsing of information that can 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 the picture header does not have tool information (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 to be used when decoding the slice, wherein the decoding includes allowing, if the picture header is signaled in the slice header, only one of the slice header or the picture header to parse information that may be signaled in the slice header and the picture header, and decoding the bitstream using the syntax elements.

[0029] If a picture header is present in a slice header, this means that there is only one slice for the current picture. Therefore, transmitting or allowing transmission of information for both slices and pictures does not improve the flexibility of the encoder or decoder, since the parameters are the same. That is, if information is present in the picture header, the corresponding information in the slice header is redundant. Similarly, if information is present 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 present in the slice header, redundancy in signaling can be limited and decoder implementation can be simplified. Therefore, syntax analysis can be simplified without sacrificing 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. A second syntax element indicating whether the information is in a picture header may be parsed, and bitstream conformance requires that if the first syntax element indicates that a picture header is signaled in a slice header, the second syntax element indicates that the information is signaled in a 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 permitted. The method may further include parsing a second syntax element indicating whether the information is in the picture header, where bitstream conformance requires 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 header and slice header.

[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 for 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, when 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 information is present in the picture header, the corresponding information in the slice header is redundant. Similarly, if information is present 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 present in the slice header, redundancy in signaling can be limited, simplifying decoder implementation. This can simplify coding and reduce signaling costs without sacrificing 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 can 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, 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 within a slice header, signaling of picture header information is not allowed.

[0044] A second syntax element may be coded to indicate whether the information is in the picture header, and it is a bitstream conformance requirement that if the first syntax element indicates signaling a picture header within a slice header, 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 if the flag is set the information is signaled in the picture header, and if not set the information is signaled in the slice header or is absent.

[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 can be signaled in a picture header and a slice header, for example, all of quantization parameter value information, reference picture list information, deblocking filter information, sample adaptive offset (SAO) information, weighted prediction information, and adaptive loop 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 slice, the method comprising parsing, in the slice header, a syntax element indicating whether a picture header is signaled in the slice header, wherein an ALF APS_ID related syntax element is parsed before the syntax element indicating whether a picture header is signaled in the slice header. The ALF APS_ID related information may be parsed near 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 including one or more slices into a bitstream, the bitstream including a picture header including syntax elements for use in decoding the one or more slices, and a slice header including syntax elements for use in decoding the slice, the method including parsing a syntax element in the slice header indicating whether a picture header is signaled in the slice header, wherein an ALF APS_ID related syntax element is coded before the syntax element indicating whether a picture header is signaled in the slice header. The ALF APS_ID related information may be coded near 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, wherein the decoding includes limiting a number of weights to signal for a weighted prediction mode, if to be signaled in the slice header, and decoding the bitstream using the syntax elements. If a picture header is signaled 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 coded for a weighted prediction mode, and encoding the bitstream using the syntax elements, and, if signaling a picture header in the slice header, coding 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 being 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 being 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, the execution of which causes the computer to carry out the method of any of the first to sixth further aspects. 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 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 used when decoding the one or more slices, and a slice header including syntax elements used when decoding the slice. 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 the information is not in the slice header, and the method includes 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 that, 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 explanation 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. [Figure 2] 1 is a block diagram that schematically illustrates a data communications system in which one or more embodiments of the present invention may be implemented; [Figure 3] FIG. 1 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] 3 is a flowchart illustrating steps of an encoding method according to an embodiment of the present invention. [Figure 5] 3 is a flow chart illustrating steps of a decoding method according to an embodiment of the present invention; [Figure 6] FIG. 1 illustrates the structure of a bitstream in an exemplary coding scheme VVC. [Figure 7] FIG. 10 illustrates another structure of a bitstream in an exemplary coding scheme VVC. [Figure 8] FIG. 1 is a diagram illustrating luma modeling chroma scaling (LMCS). [Figure 9] FIG. 1 is a diagram showing sub-tools of LMCS. [Figure 10] 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 illustrating a smartphone. DETAILED DESCRIPTION OF THE INVENTION

[0064] Figure 1 illustrates the coding structure used in the High Efficiency Video Coding (HEVC) video standard. A video sequence 1 consists of a sequence 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 a sequence may be divided into multiple slices 3. In some cases, a slice may constitute an entire image. These slices are divided into multiple 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 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 Figure 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 for predicting 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 a 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: the sequence parameter set (SPS) NAL unit, which collects all parameters that remain constant throughout a video sequence. It typically handles coding profiles, video frame sizes, and other parameters. The picture parameter set (PPS) NAL unit contains parameters that may change from one picture (or frame) in a sequence to another. HEVC also includes the video parameter set (VPS) NAL unit, which contains parameters that describe the overall structure of the bitstream. The VPS is a new type of parameter set defined in HEVC and applies to all layers of the bitstream. A layer may contain multiple sublayers, whereas all Version 1 bitstreams are limited to one layer. HEVC has specific layer extensions for scalability and multiview, allowing multiple layers within a backward-compatible Version 1 base layer.

[0069] 2 illustrates a data communication system in which one or more embodiments of the present invention may be implemented. The data communication system comprises 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 hybrid network including multiple different networks. In certain embodiments 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 multiple 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 on the server 201, received by the server 201 from other data providers, or generated by the server 201. The server 201 comprises, among other things, an encoder 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, the video data can be compressed, 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 Figure 2 considers a streaming scenario, it will be appreciated that in some embodiments of the present invention, data communication between the encoder and decoder may be performed using a media storage device, such as an optical disc.

[0074] In one or more embodiments of the present invention, a video image is transmitted along with data representative of compensation offsets to apply 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 methods of the present invention, as well as registers adapted to record variables and parameters necessary for implementing the methods of encoding a sequence of digital images and / or decoding a bitstream according to the present invention; and a communication interface 302 connected to a communication network 303 over which the digital data to be processed is transmitted and received; 3. The communication bus 313 is connected to the

[0076] Optionally, the device 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 present invention and data used or generated during the implementation of one or more embodiments of the present 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 can 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) to provide 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, and in particular the central processing unit is operable to transmit instructions to any element of the device 300 directly or by another element of the device 300.

[0079] Disk 306 may be replaced by any information medium, such as a compact disk (CD-ROM), rewritable or not, a ZIP disk, a memory card, etc., and in general any information storage means readable by a microcomputer or microprocessor, whether incorporated in the device or not, removable, and which may be adapted to store one or more programs, the execution of which can implement the method for encoding a sequence of digital images and / or the method for 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, so as 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, the invention may alternatively 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 perform, e.g., in the form of programming instructions executed by CPU 311 of apparatus 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 containing coded video data.

[0086] The input digital image (i0~in) 401 is divided into blocks of pixels by module 402. The blocks correspond to image portions and may be of variable size (e.g., 4x4, 8x8, 16x16, 32x32, 64x64, 128x128 pixels, and several rectangular block sizes are also 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 performs 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 the representation of the selected intra predictor and the 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 portion of the reference image (also called a reference region or image portion, 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 performed by module 403, the prediction direction is coded. In the temporal prediction, at least one motion vector is coded. In the inter prediction performed 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, the motion vector is coded by the difference with respect to the motion vector predictor, assuming that the motion is homogeneous. 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 applying a coding cost criterion, such as a rate-distortion criterion, to select a coding mode. 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 coded image to generate reference images for motion estimation of subsequent images, so that the encoder and decoder receiving the bitstream have the same reference frame. An inverse quantization module 411 performs inverse quantization of the quantized data, followed by inverse transformation by an inverse transform module 412. An inverse intra prediction module 413 uses the prediction information to determine which predictor to use for a given block, and an inverse motion compensation module 414 actually adds the residual obtained by module 412 to a reference region obtained from a reference image set 416.

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

[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 perform a corresponding step of a method performed 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 containing multiple coding units, each of which includes a header containing information about coding parameters and a body containing coded video data. The structure of a bitstream in VVC is described in detail below with reference to Figure 6. As described with reference to Figure 4, the coded video data is entropy coded, and the index of the motion vector predictor is coded with a predetermined number of bits for a given block. The received coded video data is entropy decoded by module 62. Then, the residual data is inverse quantized by module 63, and then inverse transformed by module 64 to obtain pixel values.

[0097] Also, 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 use. 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 the motion vector by the motion vector decoding module 70.

[0100] A motion vector decoding module 70 applies motion vector decoding to each current block that has been coded with 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 for applying 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, the decoded blocks are 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-encoded 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 in different protocols, such as RTP / IP (Real-Time Protocol / Internet Protocol) and ISO Base Media File Format. 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 therefore the entire bitstream. The DPS_NAL unit may define parameters that are more static than the VPS parameters; that is, the DPS parameters change less frequently than the VPS parameters.

[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 subpicture layout and associated parameters of a video sequence. The parameters associated with each subpicture specify the coding constraints that apply to the subpicture. In particular, it includes a flag that indicates that temporal prediction between subpictures is restricted to data coming from the same subpicture. Another flag can enable or disable the loop filter across subpicture 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 the 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 subpictures form rectangular regions within a frame, it is possible to determine the set of slices, tile portions, and tiles that belong to a subpicture using parameter set NAL units. PPS has an ID mechanism, similar to 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, while the PH is transmitted systematically for each picture. Therefore, 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 shown in Figure 6). The frequency of appearance of these parameter sets in the bitstream is variable. A VPS defined for the entire bitstream may appear only once in the bitstream. Conversely, an APS defined for a slice may occur only once for each slice in each picture. In practice, different slices may depend on the same APS, and therefore there are generally fewer APSs than slices in each picture. In particular, APSs are defined in the picture header. However, ALF APSs can be refined in the slice header.

[0112] An Access Unit Delimiter (AUD) NAL unit 607 separates 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 the amount of parsed bitstream is an integral number of bytes after executing this function.

[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 APSs to indicate the AFL parameters, reshaper models, and scaling matrices used by the slices of the picture.

[0118] Each VCL_NAL unit 606 contains 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 in Figure 3 contains multiple tiles 620. A slice consists of a slice header 610 and a raw byte sequence payload (RBSP) 611 that contains coded pixel data encoded 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 set 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] As shown in Table 4, there are three types of APS given by the aps_params_type syntax element: ALF_AP: for ALF parameters LMCS_APS: for LMCS parameters ·SCALING_APS: for scaling list relative parameters

[0125] [Table 4]

[0126] These three types of 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 whether or not the luma and chroma ALF filters are enabled, and whether or not the Cb and Cr components are enabled with CC-ALF (Cross-Component Adaptive Loop Filter). If the luma filter flag is enabled, another flag (alf_luma_clip_flag) is decoded to determine whether the clip value is signaled. 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 of 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] TIFF0007804814000006.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 backward 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 specifies if the scaling list is used for the chroma components (scaling_list_chroma_present_flag). Then, the syntax elements required to construct 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 header 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, whether it is a reference frame or not Picture type Output Frame Picture number Use subpictures (if necessary) Reference image list (if necessary) Color planes (if needed) - Updating partitions when the overwrite flag is enabled Delta QP parameters (if required) Movement 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 needed) ·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, 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, the non_reference_picture_flag, ph_pic_parameter_set_id indicating the PPS_ID, and the 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 needed.

[0144] ALF After these parameters describing important information about the current picture, a set of ALF APS_ID syntax elements is decoded if ALF is enabled at the SPS level and if ALF is enabled at the picture header level. ALF is enabled at the SPS level due to the sps_alf_enabled_flag flag. Also, ALF signaling is enabled at the picture header level because alf_info_in_ph_flag is 1, otherwise (alf_info_in_ph_flag is 0), ALF signaling is signaled at the 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 not 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 whether 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 needed for the Cb and / or Cr components.

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

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

[0151] Subpicture Subpicture parameters are valid if enabled in SPS and subpicture ID signaling is disabled, and contain some information about the virtual border. Eight syntax elements are defined for 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 needed 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 the weighted prediction parameters for list L0 and for list L1 if bidirectional weighted prediction is enabled. When weighted prediction parameters are transmitted in the picture header, the number of weights for each list is transmitted 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 slicing is 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, wp_info_in_ph_flag are signaled in PPS.

[0160] [Table 9] TIFF0007804814000011.tif248170TIFF0007804814000012.tif248167TIFF0007804814000013.tif200170

[0161] Slice Header The slice header is transmitted at the beginning of each slice. The slice header contains approximately 65 syntax elements, which is significantly larger than slice headers in previous video coding standards. A complete description of all slice header parameters is provided in JVET-Q2001-vD. Table 10 shows these parameters in the current slice header decoding syntax.

[0162] [Table 10] TIFF0007804814000015.tif245170TIFF0007804814000016.tif95170

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

[0164] Next, slice_subpic_id is decoded, if necessary, to determine the subpicture ID of the current slice. Next, slice_address is decoded to determine the address of the current slice. Next, 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, followed by the APS_ID (slice_alf_aps_id_luma[i]). Next, slice_alf_chroma_idc is decoded to determine whether and for which chroma components ALF is enabled. Next, the APS_ID for chroma (slice_alf_aps_id_chroma) is decoded, if necessary. Similarly, slice_cc_alf_cb_enabled_flag is decoded, if necessary, to determine whether 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 is not IDR or transmits a reference picture list for an 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 for 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 following syntax elements are also decoded: slice_cb_qp_offset, slice_cr_qp_offset, slice_joint_cbcr_qp_offset, and cu_chroma_qp_offset_enabled_flag.

[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 for 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 the scaling list was enabled in the picture header (phpic_scaling_list_presentenabled_flag is 1), the flag slice_scaling_list_present_flag is decoded.

[0175] Other parameters are then decoded as needed.

[0176] Picture Header in Slice Header In a specific signaling method, as depicted in Figure 7, the picture header 708 can 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, and 740 correspond to 601, 602, 603, 604, 605, 606, 607, 620, and 640 in Figure 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, the picture shall contain only one slice. Therefore, there is always only one picture header in a picture. Furthermore, the flag picture_header_in_slice_header_flag shall have the same value for all pictures in a 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: "picture_header_in_slice_header_flag = 1 indicates that the slice header has a PH syntax structure. Picture_header_in_slice_header_flag = 0 indicates that the slice header does not have a PH syntax structure. 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, conformance requires 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 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 be one of the mentioned tools, in the current syntax xxx can be signaled in the slice header when 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] 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 because the parameters are the same. That is, if information is present in the picture header, the corresponding information in the slice header is redundant. Similarly, if information is present in the slice header, the corresponding information in the picture header is redundant. The embodiments described herein simplify decoder implementation by limiting redundancy in 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 present in the picture header but not in the slice header.

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

[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 ​​applied to blocks before applying a loop filter in a video decoder such as VVC.

[0185] LMCS can be divided into two sub-tools, the first tool applied to the luma block and the second tool 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 backward mapping function back to the "input domain." 2) The second sub-tool concerns the chroma component, where luma-dependent chroma residual scaling is applied. Chroma residual scaling is designed to compensate for the interaction between the luma signal and its corresponding chroma signal. Chroma residual scaling depends on the average 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 the SPS flag, similar to other tools in video coding such as VVC. The enablement of 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. 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 principles of LMCS described above for the luma mapping subtool. The hatched blocks in Figure 8 are functional blocks of the new LMCS, including forward and backward mapping of the luma signal. When using LMCS, it is important to note that some decoding operations are applied in the "mapped domain." These operations are represented by dashed blocks in Figure 8. These typically correspond to reconstruction steps, including inverse quantization, inverse transform, luma intraprediction, and summation of luma prediction and luma residual. Conversely, the solid blocks in Figure 8 indicate where decoding processes are applied in the original (i.e., unmapped) domain, including deblocking, loop filtering such as ALF and SAO, motion compensation prediction, and storing 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 functional blocks of the new LMCS 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 inverse transform represented by the dashed blocks are performed on the chroma samples in the "mapped domain." All other steps, such as intra-chroma prediction, motion compensation, and loop filtering, are performed in the original domain. As shown in Figure 9, only the scaling process is present, and there are no forward and inverse transform processes 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 its linear mapping are represented 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 construction process with chroma scaling 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 ith 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] Next, 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 variables lmcsCW[i] are 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] (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 reconstructed 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 to ensure that the reconstructed 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 reconstructed 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] Chroma scaling LMCS semantics for chroma 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 To apply the chroma scaling process, several 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] (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 surrounding 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, the variable idxYInv is derived 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] Applying the transformation to the current chroma block, the reconstructed chroma image sample 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 the current block has no transformations applied to it, 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. Alternatively, 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 average, and vice versa.

[0217] All parameters of the LMCS tool (see Table 6) stored in the APS 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 described above. The optimization is then performed to obtain the best PSNR metric for the final reconstructed samples of a given block.

[0218] Embodiments in which information is reported in picture headers instead of slice headers In an embodiment, when a picture header is signaled in a slice header, the signaling of information that can be signaled in a picture header or a slice header is signaled in the picture header, but not in the slice header. Alternatively, an equivalent method is that when the signaling of information that can be signaled in a picture header or a slice header is signaled in the slice header, the picture header is not signaled in the slice header. In another equivalent method, when the signaling of information that can be signaled in a picture header or a slice is signaled in the picture header, the picture header is signaled in the slice header. Table 12 shows an embodiment in which tool names are replaced with XXX. In this table, when a picture header is signaled in a slice header, parameter signaling 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 referencing 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 information is present in the picture header, the corresponding information in the slice header is redundant. Similarly, if information is present in the slice header, the corresponding information in the picture header is redundant. In this way, by enforcing the condition that if a picture header is present in a slice header, the information must be present in the picture header and not in the slice header, signaling redundancy can be limited, simplifying decoder implementation.

[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 so 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 encode the same encoding 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 referencing 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 the 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. 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, 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 a picture header is signaled in a slice header, reference picture list signaling is avoided in the slice header. In an equivalent manner, a picture header is not signaled in a slice header when reference picture list signaling is signaled in a slice header. In another equivalent manner, a picture header is signaled in a slice header when reference picture list signaling is performed in a picture header. In other words, the above tool XXX is an RPL.

[0232] Table 16 shows an example 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 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 decoder, since the parameters are the same. According to this embodiment, the complexity of the decoder implementation is reduced, since it is better to only have the possible signaling of information in one of the slice or picture headers to encode the same coding possibility (in this case, Reference Picture List (RPL) information (rpl_info)).

[0235] In an embodiment, the following condition is added to the semantics of rpl_info_in_ph_flag: "If a slice header referencing a PPS contains a PH syntax structure, it is a bitstream conformance requirement that rpl_info_in_ph_flag be 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 in 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 RPL 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 18. In this table, the RPL information in a 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, signaling of deblocking filter parameters is avoided in slice headers when picture headers are signaled in slice headers. In an equivalent manner, picture headers are not signaled in slice headers when deblocking filter parameters are signaled in slice headers. In another equivalent manner, picture headers are signaled in slice headers when deblocking filter parameters are signaled in picture headers. That is, the above-mentioned tool XXX is DBF.

[0243] Table 19 shows 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, and the information transmitted in the slice or picture has the same parameters, so it does not increase the flexibility of the encoder or decoder. Therefore, to reduce the complexity of the decoder implementation, it is better to have only one possible encoding of the DBF information for 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 referencing a PPS contains a PH syntax structure, it is a bitstream conformance requirement that dbf_info_in_ph_flag be 1." and / or "When dbf_info_in_ph_flag is 0, picture_header_in_slice_header_flag is 0."

[0247] In an embodiment, 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, as depicted in Table 20. In this table, if 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 carried 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 slice headers when picture headers are signaled in slice headers. In an equivalent manner, when SAO signaling is signaled in slice headers, picture headers are not signaled in slice headers. In another equivalent manner, when SAO signaling is signaled in picture headers, picture headers are signaled in slice headers. 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 a slice header, there is only one slice for the current picture, so the information transmitted in the slice or picture has the same parameters, which does not increase the flexibility for the encoder or decoder. Therefore, 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 referencing a PPS contains a PH syntax structure, it is a bitstream conformance requirement that sao_info_in_ph_flag be 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 the 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 if 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 a picture header is signaled in a slice header, signaling of weighted prediction is avoided in the slice header. In an equivalent manner, when signaling of weighted prediction is signaled in a slice header, a picture header is not signaled in the slice header. In another equivalent manner, when signaling of weighted prediction is signaled in a picture header, a picture header is signaled in a 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 example implementation of this embodiment in which WP signaling is not allowed when signaling picture headers within slice headers.

[0264] [Table 25]

[0265] If the picture header is in a slice header, there is only one slice for the current picture, so the information transmitted in the slice or picture has the same parameters, which does not increase the flexibility of the encoder or decoder. 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 referencing a PPS contains a PH syntax structure, it is a bitstream conformance requirement that wp_info_in_ph_flag be 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, decoding of WP 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 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, ALF signaling is avoided in slice headers when picture headers are signaled in slice headers. In an equivalent manner, when ALF signaling is signaled in slice headers, picture headers are not signaled in slice headers. In another equivalent manner, when ALF signaling is signaled in picture headers, picture headers are signaled in slice headers. That is, the above tool XXX is 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. As a result, all variables such as PPS, SPS, picture header, etc. must be kept in memory to parse the APS_ID of the ALF, which increases the parsing complexity for some streaming applications.

[0273] Furthermore, if the picture header is in the slice header, there is only one slice for the current picture, and the information transmitted in the slice or picture has the same parameters, so it does not increase the flexibility of the encoder or decoder. Therefore, to reduce the complexity of the decoder implementation, it is better to have only one signaling for the same encoding possibility. Table 28 shows this embodiment in which ALF signaling is not allowed 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 referencing a PPS contains a PH syntax structure, it is a bitstream conformance requirement that alf_info_in_ph_flag be 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 ALF information is signaled at the picture level (alf_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).

[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 a slice header are restricted to be signaled in the picture header. As mentioned in the above description, in the embodiment, the relevant tools are: QP delta information, reference picture list, deblocking filter, SAO weighted prediction, and ALF. However, other tools are also possible, 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, 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 referencing 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. Therefore, 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 signaled in a slice header but not in a picture header In one embodiment, 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 a picture header. Also, 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, when signaling of information that can be signaled in a picture header or a slice header is signaled in a slice header, the picture header is signaled in a slice header. Table 33 shows this embodiment with tool (or parameter) names replaced with XXX. In this table, signaling of parameters in a picture header is not allowed when a picture header is signaled in a slice header.

[0289] [Table 33]

[0290] In one embodiment, the semantics of xxx_info_in_ph_flag adds the following condition: "If a slice header referencing 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 because the parameters are the same. That is, if information is present in the picture header, the corresponding information in the slice header is redundant. Similarly, if information is present in the slice header, the corresponding information in the picture header is redundant. The embodiments described herein simplify decoder implementation by limiting redundancy in signaling of the same encoding. In particular, in embodiments, if a picture header is signaled in a slice header, information is allowed to be present in the slice header but not in the picture header.

[0292] QP Delta In one embodiment, tool XXX is QP delta. In one embodiment, decoding of the QP delta parameters of the slice header is allowed when the value of 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 a value equal to 0 if the QP delta parameters are signaled in the picture header. In another equivalent way, as depicted in Table 33, picture_header_in_slice_header_flag is set to 1 when the QP delta parameters are signaled in the slice header. In this table, the slice_qp_delta information of the slice header can be decoded if the QP delta information is signaled at the slice level (qp_delta_info_in_ph_flag 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 referencing a PPS contains 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 a 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 a 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, tool XXX is a reference picture list. In one embodiment, decoding of reference picture list parameters in a slice header is authorized only if the value of 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 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 signaling reference picture parameters in the slice header as shown in Table 33. 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 transmitted in the slice header (picture_header_in_slice_header_flag is 1), the ref_pic_lists() information in 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 may 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 only possible to decode the RPL information in the picture header 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, tool XXX is a deblocking filter (DBF). In an alternative or additional embodiment, as depicted in Table 33, when the value of flag picture_header_in_slice_header_flag is set to 1, DBF parameters in the slice header are enabled. Also as shown in Table 33, when picture_header_in_slice_header_flag is set to 0, DBF parameters are signaled in the picture header. Also as shown in Table 33, when DBF parameters are stored in the slice header, picture_header_in_slice_header_flag is set to 1. In this table, the slice_deblocking_filter_override_flag flag in the slice header can be decoded if 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, DBF information in the picture header can be decoded only if 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, 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, 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), the slice_sao_luma_flag in the slice header can be decoded.

[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 the 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, tool XXX is WP (weighted prediction). In one embodiment, WP parameters in the slice header are authorized only if the value of 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 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 WP parameters are signaled in the slice header. In this table, the pred_weight_table() function containing weighted prediction parameters can be decoded if 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, tool XXX is ALF (Adaptive Loop Filter). In one embodiment, decoding of the ALF parameters in 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 in 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] TIFF0007804814000041.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 as follows: 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 referencing 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 in the same header, the complexity of the decoder implementation is reduced, since it is better to have only one signaling if the tools or parameters necessarily have the same value or characteristics.

[0313] implementation 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, via 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 (to be provided / streamed) content to a user. The system 195 obtains / receives a 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 acquires / receives content including an original image sequence 151 that has been received and processed (including filtered by a deblocking filter according to the present invention) by an encoder 150, which generates a bitstream 101 that is then communicated to the decoder 100 via a communications network 199. The bitstream 101 may then be communicated to the decoder 100 in several ways, but may also be pre-generated by the encoder 150 and stored as data in a storage device (e.g., a server or cloud storage) within the communications 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., content titles and other meta / storage location data for identifying, selecting, and requesting content) for content stored in a storage device to a user (e.g., by communicating user interface data 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 a bitstream 101 when a user requests content and communicates / streams it directly to the decoder 100. The decoder 100 then receives the bitstream 101 (or signal), filters it with a deblocking filter according to the present invention, and obtains / generates a video signal 109 and / or audio signal, which the user terminal uses to provide the requested content to the user.

[0314] Any step of a method / process according to the present invention or function described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the step / function may be stored on or transmitted as one or more instructions, code, or programs, or as a computer-readable medium, and may be executed by one or more hardware-based processing devices, such as a programmable computing device, which may be a PC (personal computer). The device may also 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 foregoing structures or other structures suitable for implementing the techniques described herein.

[0315] 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 implement the embodiments, but do not necessarily require implementation by different hardware units. Rather, 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] Embodiments of the present invention can be realized by a computer of a system or device that reads and executes computer-executable instructions (e.g., one or more programs) recorded on a storage medium to perform one or more modules / units / functions of the above-described embodiments and / or includes one or more processing units or circuits for performing one or more functions of the above-described embodiments. For example, the present invention can be realized by a method executed by a computer of a system or device that reads and executes computer-executable instructions from a storage medium to perform one or more functions of the above-described embodiments and / or controls one or more processing units or circuits to perform one or more functions of the above-described 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 a communication medium via a network or a tangible storage medium. The communication medium may be a signal / bitstream / 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), storage of a distributed computing system, an optical disk (such as a compact disk (CD), a digital versatile disk (DVD), or a Blu-ray disk (BD)™)), 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 communications bus; random access memory (RAM) 2002 for storing executable code for methods of embodiments of the present invention and registers adapted for recording variables and parameters required to implement methods for encoding or decoding at least a portion of an image according to embodiments of the present invention (the memory capacity may be expanded, for example, by an optional RAM connected to an expansion port); read-only memory (ROM) 2003 for storing computer programs for implementing embodiments of the present invention; and a network interface (NET) 2004, typically connected to a communications 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 comprise 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 or read from the network interface for transmission 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 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. CPU 2001 is adapted to control and direct the execution of instructions or parts of the program or software code of the program according to an embodiment of the invention, said instructions being stored in one of the aforementioned storage means. After power-on, CPU 2001 can execute instructions from main RAM memory 2002 associated with a software application, after these instructions have been loaded, for example, from program ROM 2003 or HD 2006. Such a software application, when executed by CPU 2001, causes the steps of the method according to the invention to be carried out.

[0318] It will also be appreciated that, according to another embodiment of the present invention, the decoder according to the aforementioned embodiments is provided in a user terminal such as a computer, a mobile phone (cellular phone), a table, or any other type of device (e.g., a display device) that can provide / display content to a user. According to yet another embodiment, the encoder according to the aforementioned embodiments is provided in an imaging device, including also a camera, a video camera, or a network camera (e.g., a closed circuit television or 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 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 encoding by the encoding unit 2108. The control unit 2112 controls the other units in the network camera 2102 according to the 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 coded 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 and 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 . In addition, the control unit 2118 of the client device 2104 controls the display device 2120 to display a GUI (Graphical User Interface) for specifying parameter values ​​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 user operation inputs to the GUI displayed on 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 operation input to the GUI displayed by the display device 2120.

[0320] Smartphone FIG. 12 is a diagram illustrating 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] While the present invention has been described with reference to embodiments, it will be understood that the invention is not limited to the disclosed embodiments. Those skilled in the art will recognize 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 accompanying claims, abstract, and drawings), and / or all steps of any method or process so disclosed, may be combined in any combination, except where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including the accompanying 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 disclosed feature 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 comparison, determination, evaluation, selection, execution, performing, or consideration (e.g., a selection made during an encoding or filtering process) may be indicated or determined / referenced in data in the bitstream (e.g., a flag or data indicating the result), and that the indicated or determined / referenced result may be used in processing instead of actually performing the comparison, determination, evaluation, selection, execution, performing, or consideration, for example, 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] 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 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 in the slice header 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 in the slice header when the second flag has the first value; The ALF information includes an adaptation parameter set ID for an adaptive loop filter (ALF), and the 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 characterized by:

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. When deblocking filter information is included in the picture header syntax structure, the first flag having a value indicating that the picture header syntax structure is not in the slice header is constrained to be decoded.

2. The method of claim 1 .

7. The method of claim 6, wherein if QP delta information is included in the picture header syntax structure, the first flag is constrained to be decoded with a value indicating that the picture header syntax structure is absent from the slice header.

2. The method of claim 1 .

8. 1. A method 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 method includes encoding the video data using a plurality of syntax elements including: a first flag in the slice header 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 the 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 characterized by:

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

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

9. The method of claim 8.

11. 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 means for decoding a plurality of syntax elements, the plurality of syntax elements including a first flag in the slice header indicating whether the picture header syntax structure is in the slice header, the first flag being a flag 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; and 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 in the slice header when the second flag has the first value; The ALF information includes an adaptation parameter set ID for an adaptive loop filter (ALF), and the 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 characterized by:

12. 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 comprises means for encoding the video data using a plurality of syntax elements including: a first flag in the slice header 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 the 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.

1. An encoding device comprising:

13. A computer program causing a computer to carry out the method according to any one of claims 1 to 10.

Images