High-level syntax for video encoding and decoding

Abstract

To provide a method for decoding video data from a bitstream, a coding method, a device, and a computer program.SOLUTION: A method for decoding a bitstream having video data corresponding to multiple slices and having a picture header includes: determining a coding mode for at least one slice; determining a set of syntax elements used in the coding mode from the picture header; and decoding the at least one slice by using the determined syntax elements.SELECTED DRAWING: Figure 6

Description

[Technical field]

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

[0002] Recently, the Joint Video Experts Team (JVET), a joint team formed by MPEG and the VCEG of ITU-T Study Group 16, has begun work on a new video coding standard called Versatile Video Coding (VVC). The goal of VVC is to provide significant improvements in compression performance over the existing HEVC standard (i.e., typically twice as much as before) and to be completed in 2020. Primary target applications and services include (but are not limited to) 360-degree and high dynamic range (HDR) video. In total, the JVET evaluated responses from 32 parties using formal subjective testing conducted by an independent testing laboratory. Several proposals demonstrated compression efficiency gains of typically 40% or more compared to using HEVC. They showed particular effectiveness for ultra-high definition (UHD) video test material. Compression efficiency gains are therefore expected to far exceed the 50% targeted for the final standard. Summary of the Invention [Problem to be solved by the invention]

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

[0004] One of the key changes in the high-level syntax is the introduction of a "picture header" to the bitstream. A picture header is a header that specifies the syntax elements used to decode each slice in a particular picture (or frame). Thus, the picture header precedes the data related to the slice in the bitstream, and each slice has its own "slice header." This structure is described in more detail below with reference to FIG. 6.

[0005] Document JVET-P0239 of the 16th meeting: Geneva, CH, 1-11 October 2019, entitled "AHG17: Picture Header", proposed the introduction of a mandatory picture header into VVC, which was adopted as Generic Video Coding (Draft 7) uploaded as document JVET_P2001. However, although this structure provides flexibility in the use of all VVC tools, there is an increase in the amount of syntax elements signaled in the bitstream that affects the bitrate of the transmission, especially for low bitrate instances.

[0006] Therefore, a solution to at least one of the aforementioned problems is desirable.

[0007] In general, the inventors have found that the flexibility built into the recently adopted high-level syntax is rarely used, thus unnecessarily increasing the bit rate. In particular, most pictures contain only slices that use one slice coding mode (e.g., Inter or Intra), while the high-level syntax allows different types of slices in each picture. The present invention is concerned with taking advantage of the fact that most pictures use only slices of one coding type, and being able to reduce the bit rate.

[0008] Optional features that reintroduce the flexibility of multiple coding types within a single picture are also considered. Specific syntax elements and / or additional constraints on syntax elements are added to reduce bitrate compared to recently adopted high-level syntaxes. These "add-on" features may increase bitrate, but are rarely used, so that the average bitrate for a given video sequence is reduced compared to the prior art.

[0009] The present invention proposes modifications to the picture header signaling to avoid extra signaling of some picture header parameters that are not needed when the whole picture contains only one slice type (I, P, B). In particular, parameters related to inter and intra delta QP signaling are merged into a single parameter. The override flag of the partitioning parameters is changed to two override flags, one for inter slices and one for intra slices. In addition, an override flag is added for the motion information parameters in inter slices. These modifications provide almost the same flexibility compared to the current design, but it increases the coding efficiency.

[0010] In one aspect of the present invention, a decoder only needs to decode one set of syntax elements from the picture header, where the set of syntax elements is defined by the slice coding mode (e.g., INTER or INTRA) for the picture. Alternatively, the syntax elements in the picture header are coding mode independent and include a merged set of syntax elements. In this way, the bit rate is reduced because unnecessary syntax elements can be skipped by the decoder.

[0011] According to one aspect of the present invention, there is provided a method for decoding video data from a bitstream, where the bitstream comprises video data corresponding to one or more slices, a picture comprises one or more slices, and the video bitstream comprises a picture header, the method comprising: determining whether one or more slices in the picture use a single coding mode, determining from the picture header a set of syntax elements used in the single coding mode, and decoding the one or more slices using the determined syntax elements.

[0012] Optionally, determining the coding mode of the one or more slices depends on at least one syntax element in the picture header. Optionally, the single coding mode is one of inter or intra. Optionally, said single coding mode is inter. Optionally, the inter coding mode is one of Inter-B or Inter-P. Optionally, determining a configuration of syntax elements used in the single coding mode comprises enabling and / or disabling at least one syntax element in a picture header. Optionally, determining a set of syntax elements to be used in the single coding mode comprises enabling and / or disabling at least one syntax element in a slice header. Optionally, the encoding mode is determined based on the value of an AU delimiter. Optionally, determining the encoding mode comprises decoding one or more override flags. Optionally, the one or more override flags comprise a first flag indicating whether an inter mode is used and a second flag indicating whether an intra mode is used.

[0013] In an aspect of the present invention, there is provided a method of decoding video data from a bitstream, where the bitstream comprises video data corresponding to one or more slices, a picture comprises one or more slices, and the video bitstream comprises a picture header, the method comprising determining a coding mode for one or more slices in the picture, determining from the picture header a set of syntax elements used in the coding mode, and decoding the one or more slices using the determined syntax elements.

[0014] In an aspect of the present invention, there is provided a method for encoding video data into a bitstream, where the bitstream comprises video data corresponding to one or more slices, where a picture comprises one or more slices, and where the video bitstream comprises a picture header, the method comprising: defining a single coding mode for the at least one slice in the picture, encoding in the picture header a set of syntax elements used in the single coding mode, and encoding the one or more slices using the determined syntax elements.

[0015] In an aspect of the present invention, there is provided a method for encoding video data into a bitstream, wherein the bitstream comprises video data corresponding to one or more slices, a picture comprises one or more slices, and the video bitstream comprises a picture header, the method comprising: The method includes determining an encoding mode for the one or more slices in the picture, determining a set of syntax elements in the picture header to be used with the encoding mode, and encoding the one or more slices using the determined syntax elements.

[0016] Optionally, the coding mode is inter, and encoding the picture header comprises encoding an inter syntax element in the picture header. Optionally, the coding mode is intra and encoding the picture header comprises encoding an intra syntax element in the picture header.

[0017] In another aspect of the invention, there is provided a decoder adapted to decode a bitstream by performing a method in accordance with the corresponding decoding method above. In another aspect of the invention, there is provided an encoder adapted to encode a bitstream by performing a method according to the corresponding encoding method above.

[0018] According to one aspect of the present invention, there is provided a method for decoding video data from a bitstream, where the bitstream comprises video data corresponding to a plurality of slices, the video bitstream comprising a picture header, the method comprising: determining a coding mode for at least one slice, determining from the picture header a set of syntax elements used in the coding mode, and decoding the at least one slice using the determined syntax elements.

[0019] This allows for reduced bit rates and overall more efficient decoding.

[0020] Optionally, determining the coding mode of at least one slice depends on a syntax element in said picture header. Optionally, the coding mode is one of inter or intra. For flexibility, the coding mode may be one of inter, intra, or a combination of inter and intra. For more flexibility, the inter coding mode is one of Inter-B or Inter-P. Optionally, determining the set of coding mode specific syntax elements comprises enabling and / or disabling at least one syntax element in a picture header. Optionally, determining the coding mode specific syntax element comprises enabling and / or disabling at least one syntax element in a slice header. Optionally, the method further comprises inferring a value of an AU delimiter based on the determined encoding type. Optionally, inferring a value of the AU delimiter is performed if it is determined that the stream includes only one layer.

[0021] According to another aspect of the present invention, there is provided a method for decoding video data from a bitstream, where the bitstream includes video data corresponding to a plurality of slices, the video bitstream including a picture header, the method comprising: determining whether all slices in a picture use the same coding mode; and if the determination is true, decoding the picture using the syntax elements from the picture header.

[0022] According to another aspect of the present invention, there is provided a method of decoding video data from a bitstream, where the bitstream includes video data corresponding to a plurality of slices, the video bitstream including a picture header, and the method includes decoding a picture using the syntax elements from the picture header, where all syntax elements correspond to a same slice coding mode.

[0023] These aspects reduce the rate for headers, especially for pictures that contain only inter-slices (which is the majority of pictures in many video sequences). Optionally, if said determination is not true, intra coding parameters of intra slices in said picture are inferred from corresponding inter syntax elements in said picture header. Optionally, the intra syntax element is restricted in value to the corresponding inter value. Optionally, the method further comprises predicting syntax elements of the slice based on values ​​of previous syntax elements. Optionally, determining the coding mode of the at least one slice depends on syntax elements of a header different from the picture header. In one example, the header different from the picture header is a sequence header. In another example, the header different from a picture header is an AUD NAL unit. In one example, the determined coding mode is inter. In another example, the determined coding mode is intra. Optionally, determining the encoding mode includes decoding one or more override flags. Optionally, one or more of the above override flags may be present in a header at a higher level than the picture header.

[0024] According to another aspect of the present invention, there is provided a method for decoding video data from a bitstream, where the bitstream comprises video data corresponding to a number of slices, the video bitstream comprising a picture header, the method comprising: decoding one or more override flags; and decoding particular syntax elements encoded from the picture header in dependence on the one or more override flags, the one or more override flags being in a header at a higher level than the picture header.

[0025] This aspect provides the advantage of rate reduction with the flexibility to override the default case.

[0026] Optionally, the high level header is an SPS or a PPS. Optionally, the method further includes decoding two override flags from the picture header before the encoding-dependent syntax elements, where a first override flag indicates that an inter element is overridden and a second override flag indicates that an intra element is overridden. Optionally, the syntax elements utilized for the determined coding mode are coding mode independent.

[0027] According to another aspect of the present invention, there is provided a method for decoding video data from a bitstream, where the bitstream includes video data corresponding to a number of slices, the video bitstream includes a picture header, the picture header including only coding mode independent syntax elements, and using the syntax elements to decode each slice in the picture.

[0028] This aspect provides rate reduction by reducing the number of redundant syntax elements in the picture header.

[0029] Optionally, the method further comprises determining, from a header different from the picture header, syntax elements specific to the determined coding mode. Optionally, said header distinct from said picture header is a slice header. For flexibility, both inter and intra syntax elements may be provided in the slice header. Optionally, the method further comprises decoding an override flag, the override flag determining whether to decode a coding-specific syntax element from a slice header. Optionally, the syntax elements in the slice header have values ​​restricted to equivalent syntax elements in a picture header. Optionally, the method further comprises predicting one or more syntax elements in the slice header based on values ​​of previous syntax elements in the slice header.

[0030] According to another aspect of the present invention, there is provided a method for encoding video data into a bitstream, where the bitstream comprises video data corresponding to a plurality of slices, the video bitstream comprising a picture header, the method comprising: defining a coding mode for at least one slice, encoding a set of syntax elements used for the coding mode from the picture header, and encoding the at least one slice using the determined syntax elements.

[0031] According to another aspect of the present invention, there is provided a method for encoding video data into a bitstream, where the bitstream comprises video data corresponding to a plurality of slices, one or more slices comprising a picture, the video bitstream comprising a picture header, the method comprising: defining a coding mode for the picture; and encoding a syntax element into the picture header, a value of the syntax element being dependent on the defined coding mode.

[0032] According to another aspect of the present invention, there is provided a method for encoding video data into a bitstream, where the bitstream comprises video data corresponding to a plurality of slices, one or more slices comprising a picture, the video bitstream comprising a picture header, the method comprising: defining coding modes for all slices in the picture; and encoding the picture header using syntax elements according to the defined coding modes.

[0033] According to another aspect of the present invention, there is provided a method of encoding video data into a bitstream, where the bitstream comprises video data corresponding to a plurality of slices, the video bitstream comprising a picture header, and the method comprises encoding a picture using the syntax elements from the picture header, where all syntax elements correspond to a same slice coding mode.

[0034] Optionally, the coding mode is inter, and encoding the picture header comprises encoding an inter syntax element in a picture header. Alternatively, the coding mode is intra and encoding the picture header comprises encoding an intra syntax element in the picture header. Optionally, the method further comprises: if the defined coding mode is intra, encoding inter syntax elements into a picture header and encoding intra syntax elements into a slice header.

[0035] According to another aspect of the present invention, there is provided a method for encoding video data into a bitstream, where the bitstream comprises video data corresponding to a number of slices, the video bitstream comprising a picture header, the method comprising: encoding one or more override flags; and encoding coding-specific syntax elements into the picture header in dependence on the one or more override flags, the one or more override flags being in a header higher than the picture header.

[0036] These encoding methods, as discussed above, allow for more efficient decoding, and in some cases, lower coding complexity because fewer syntax elements are coded into each header and / or there is less redundancy in the bitstream.

[0037] Yet another aspect of the invention relates to a decoder and an encoder adapted to carry out the aforementioned decoding and encoding methods, respectively.

[0038] Yet another aspect of the present invention relates to a program which, when executed by a computer or a processor, causes said computer or processor to perform the method of any one of the above-mentioned method aspects of the present invention. The program may be provided by itself or may be carried on, by or within 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 over any suitable network, including the Internet.

[0039] Further features of the invention are characterized in the other independent and dependent claims.

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

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

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

[0043] It is also to be understood that specific combinations of the various features described and defined in any embodiment of the present invention can be implemented and / or provided and / or used independently. [Brief description of the drawings]

[0044] Reference is now made, by way of example, to the accompanying drawings in which: [Figure 1] FIG. 1 is a diagram for explaining the coding structure used in HEVC and VVC. [Diagram 2] 1 is a block diagram that illustrates generally a data communications system in which one or more embodiments of the present invention may be implemented; [Diagram 3] FIG. 1 is a block diagram illustrating components of a processing device capable of implementing one or more embodiments of the present invention. [Figure 4] 4 is a flow chart illustrating steps of an encoding method according to an embodiment of the present invention. [Diagram 5] 4 is a flow chart illustrating steps of a decoding method according to an embodiment of the present invention. [Figure 6] FIG. 2 illustrates the structure of a bitstream in an exemplary coding system VVC. [Figure 7] FIG. 1 illustrates a system comprising an encoder or decoder and a communication network according to an embodiment of the invention. [Figure 8] 1 is a schematic block diagram of a computing device for implementing one or more embodiments of the present invention. [Figure 9] FIG. 1 illustrates a network camera system. [Figure 10] FIG. 1 illustrates a smartphone. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0045] Figure 1 relates to 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. Each such digital image is represented by one or more matrices, whose coefficients represent pixels.

[0046] An image 2 of a sequence can be divided into slices 3. A slice can possibly constitute an entire image. These slices are divided into non-overlapping Coding Tree Units (CTUs). A Coding Tree Unit (CTU) is the basic processing unit of the High Efficiency Video Coding (HEVC) video standard and corresponds conceptually to the macroblock unit used in some previous video standards. A CTU is sometimes also called a Largest Coding Unit (LCU). A CTU has luma (luminance) and chroma (color difference) component parts, each of which is called a Coding Tree Block (CTB). These different color components are not shown in FIG. 1.

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

[0048] A coding unit is an elementary coding element and consists of two types of sub-units called prediction unit (PU) and transform unit (TU). The maximum size of a PU or TU is equal to the CU size. A prediction unit corresponds to a partition of a CU for prediction of pixel values. Various different partitions of a CU into PUs are possible, including a partition into four square PUs and two different partitions into two rectangular PUs, as shown by 606. A transform unit is a basic unit that performs spatial transformation using DCT. A CU can be divided into TUs based on a quadtree representation 607.

[0049] Each slice is embedded in one Network Abstraction Layer (NAL) unit. Furthermore, the coding parameters of a video sequence are stored in a dedicated NAL unit called a parameter set. In HEVC and H.264 / AVC, two types of parameter set NAL units are used: the first is the Sequence Parameter Set (SPS) NAL unit, which collects all parameters that do not change during the entire video sequence. Typically, it handles the coding profile, the size of the video frames, and other parameters. The second is the Picture Parameter Set (PPS) NAL unit, which contains parameters that can change from one picture (or frame) of the 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 that applies to all layers of the bitstream. A layer can contain multiple temporal sublayers, and all version 1 bitstreams are limited to one layer. HEVC has specific layer extensions for scalability and multiview that allow for multiple layers with a backwards compatible version 1 base layer.

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

[0051] The data stream 204 provided by the server 201 may be composed of multimedia data representing video and audio data. The audio and video data streams may, in some embodiments of the invention, be captured by the server 201 using a microphone and a camera, respectively. In some embodiments, the data streams may be stored on the server 201 or may be received by the server 201 from another data provider or may be generated at the server 201. The server 201 comprises, inter alia, 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.

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

[0053] Client 202 receives the transmitted bitstream, decodes the reconstructed bitstream, and plays the video images on a display device and the audio data through speakers.

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

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

[0056] 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 light portable device. The device 300 has a communication bus 313 to which the following are connected: - a central processing unit 311, such as a microprocessor, indicated by CPU; - a read-only memory 306, denoted ROM, for storing a computer program for implementing the invention; a random access memory 312, denoted as RAM, for storing the executable code of the method of the embodiments of the invention, as well as registers adapted to record variables and parameters necessary for implementing the method of encoding a sequence of digital images and / or the method of decoding a bitstream according to an embodiment of the invention; and a communications interface 302 connected to a communications network 303 over which the digital data to be processed is transmitted and received;

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

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

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

[0060] The disk 306 may be replaced by any information carrier, for example a compact disk (CD-ROM), a ZIP disk or a memory card, rewritable or not, etc. Generally speaking, it may be replaced by any information storage means readable by a microcomputer or microprocessor, integrated or not integrated in the device, possibly removable, and configured to store one or more programs whose execution enables the method of encoding a sequence of digital images and / or the method of decoding a bitstream according to the invention.

[0061] The executable code may be stored either in the read-only memory 306, in the hard disk 304 or on a removable digital medium as previously explained, 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, in order to be stored in one of the storage means of the device 300, such as the hard disk 304, before being executed.

[0062] The central processing unit 311 is arranged to control and direct the execution of instructions or parts of the program or software code of the program according to the invention with 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 the read-only memory 306, are transferred to the random access memory 312. This includes the executable code of the program or programs as well as registers for storing variables and parameters necessary to implement the invention.

[0063] The device in this embodiment 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 (ASIC)).

[0064] 4 shows a block diagram of an encoder according to at least one embodiment of the present invention. The encoder is represented by connected modules, each adapted to perform at least one or more corresponding steps of a method for implementing at least one or more embodiments of encoding images of an image sequence according to at least one embodiment of the present invention, for example in the form of program instructions to be executed by the CPU 311 of the device 300.

[0065] An original sequence of digital images i0 to in401 is received as input by the encoder 400. Each digital image is represented by a set of samples known as pixels.

[0066] A bitstream 410 is output by the encoder 400 after the encoding process is performed. The bitstream 410 comprises a number of coding units or slices. Each slice comprises a slice header for transmitting coded values ​​of coding parameters used to code the slice, and a slice body with coded video data.

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

[0068] Module 403 performs an intra prediction process, where a given block to be coded is predicted by a predictor calculated from pixels in the neighborhood of the block to be coded. If intra coding is selected, an indication of the selected intra predictor and the difference between the given block and its predictor are coded to provide a residual.

[0069] Temporal prediction is performed by the motion estimation module 404 and the motion compensation module 405. First, a reference image is selected from the set of reference images 416, and the part of the reference image, also called reference region or image part, that is closest to the given block to be coded is selected by the motion estimation module 404. The motion compensation module 405 then uses the selected area to predict the block to be coded. The difference between the selected reference region and the given block, also called residual block, is calculated by the motion compensation module 405. The selected reference region is indicated by a motion vector.

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

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

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

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

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

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

[0076] 5 shows a block diagram of a decoder 60 that may be used to receive data from an encoder according to one embodiment of the present invention. The decoder is represented by connected modules, each module configured to carry out a corresponding step of a method realized by the decoder 60, for example in the form of program instructions executed by the CPU 311 of the device 300.

[0077] The decoder 60 receives a bitstream 61 containing coding units, each of which consists of a header containing information about coding parameters and a body containing the coded video data. The structure of a bitstream in VVC is explained in more detail below with reference to FIG. 6. As explained with reference to FIG. 4, the coded video data is entropy coded and the index of the motion vector predictor is coded with a predefined number of bits for a given block. The received coded video data is entropy decoded by module 62. The residual data is then inverse quantized by module 63 and then an inverse transform is applied by module 64 to obtain pixel values.

[0078] Mode data indicating the coding mode is also entropy decoded, and based on the mode, INTRA-type or INTER-type decoding is performed on the coded block of image data.

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

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

[0081] A motion vector decoding module 70 applies motion vector decoding for each current block coded by motion prediction. Once the motion vector predictor index is obtained, for the current block, the actual value of the motion vector associated with the current block may 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 and inverse motion compensation 66 is applied. Motion vector field data 71 is updated with the decoded motion vector for use in inverse prediction of subsequent decoded motion vectors.

[0082] Finally, the decoded blocks are obtained. Post-filtering is applied by a post-filtering module 67. A decoded video signal 69 is finally provided by the decoder 60.

[0083] FIG. 6 shows the structure of a bitstream in an exemplary coding system VVC, as described in JVET_P2001-VE.

[0084] The bitstream 61 from the VVC coding system 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 different NAL unit types. The Network Abstraction Layer provides the ability to encapsulate the bitstream into different protocols, such as RTP / IP, Real Time Protocol / Internet Protocol, ISO Base Media File Format, etc. The Network Abstraction Layer also provides a framework for packet loss resiliency.

[0085] The NAL units are divided into Video Coding Layer (VCL) NAL units and non-VCL NAL units. The VCL NAL units contain the actual encoded video data. The non-VCL NAL units contain additional information, which may be parameters required for decoding the encoded video data or supplementary data that may improve the usability of the decoded video data. The NAL units 606 correspond to slices and constitute the VCL NAL units of the bitstream.

[0086] 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, i.e., the entire bitstream. The DPS NAL unit may define parameters that are more static than the parameters in the VPS. In other words, the parameters of the DPS change less frequently than the parameters of the VPS.

[0087] 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 a loop filter that crosses subpicture boundaries.

[0088] Picture Parameter Set (PPS) NAL unit 604, PPS contains parameters defined for a picture or group of pictures. Adaptive Parameter Set (APS) NAL unit 605 contains parameters for loop filters, typically an Adaptive Loop Filter (ALF) or reshaper model (or Luma mapping with chroma scaling (LMCS) model) or scaling matrices used at slice level.

[0089] The syntax of the PPS as proposed in the current version of VVC includes syntax elements that specify the size of the picture in luma samples, and the division of each picture into tiles and slices.

[0090] The PPS contains syntax elements that allow to determine the location of slices within a frame. Since a subpicture forms a rectangular region within a frame, it is possible to determine from the parameter set NAL unit the set of slices, parts of tiles, or tiles that belong to a subpicture. The PPS as an APS has an ID mechanism to limit the amount of identical PPSs transmitted.

[0091] The main difference between the PPS and the Picture Header is that the PPS is transmitted, and generally, for a group of pictures, as compared to the PH, which is transmitted systematically for each picture. Thus, in comparison to the PH, the PPS contains parameters that may be constant for several pictures.

[0092] The bitstream may also contain Supplemental Enhancement Information (SEI) NAL units (not shown in FIG. 6). The periodicity with which these parameter sets occur within the bitstream is variable. A VPS defined for the entire bitstream may occur only once in the bitstream. Conversely, an APS defined for a slice may occur once for each slice in each picture. In practice, different slices may rely on the same APS, and thus, in general, there are fewer APSs than slices in each picture. In particular, the APSs are defined in the picture header. However, the ALF APSs may be refined in the slice header.

[0093] An Access Unit Delimiter (AUD) NAL unit 607 separates two access units. An access unit is a set of NAL units that can comprise 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. This syntax element indicates the slice_type value of all slices of coded pictures in the AU. If pic_type is set equal to 0, the AU contains only intra slices. If it is equal to 1, it contains P and I slices. If it is equal to 2, it contains B, P or intra slices, as shown in Table 1 below.

[0094] Table 1 Interpretation of pic_type JPEG2024069479000002.jpg26103

[0095] Picture Header 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 may reference one or more APSs to indicate the AFL parameters, reshaper models, and scaling matrices used by the slices of the picture.

[0096] Each of the VCL NAL units 606 contains a slice. A slice can correspond to an entire picture or a subpicture, a single tile, or multiple tiles, or a portion of a tile. For example, the slice in Figure 6 contains several tiles 620. A slice consists of a slice header 610 and a RAW Byte Sequence payload RBSP 611 that contains coded pixel data coded as coding blocks 640.

[0097] The picture header is transmitted at the beginning of each picture. The associated syntax elements that can be decoded are: Usage of this picture, whether it is a reference frame Output Frame · Usage of subpictures if necessary Reference image list if necessary Color planes as needed Updating partitions when override flag is enabled Delta QP parameters if necessary Movement information parameters if necessary ALF parameters if necessary SAO parameters as required Quantification parameters as required LMCS parameters if necessary Scaling list parameters if necessary Picture header extension if necessary

[0098] A complete description of all these parameters can be found in JVET_P2001-VE.

[0099] This structure of the picture header provides flexibility in providing all the tools that may be needed for a particular picture. As such, this structure essentially defines the "worst case" for decoding a picture, which is often an important consideration for hardware decoders. However, this structure has significant redundancy that causes an increase in bit rate.

[0100] The problem addressed by the present invention concerns the set of parameters in this picture header that are associated with a particular coding mode. For a particular set of parameters, a set of syntax elements is transmitted for both inter and intra slices. This increases the rate when all slices in a picture have the same type.

[0101] Table 2 shows these parameters in the current picture header decoding syntax, using the definitions provided in JVET_P2001-VE. In this table, "..." denotes syntax elements that are not relevant to this description.

[0102] Table 2 Partial Picture Header JPEG2024069479000003.jpg177127JPEG2024069479000004.jpg150128

[0103] Three particular sets of parameters in the above header may be redundant in certain cases. These three sets are considered in turn below. The first set of parameters is related to the partitioning. The following are used for inter-slice only: · pic_log2_diff_min_qt_min_cb_inter_slice · pic_max_mtt_hierarchy_depth_inter_slice · pic_log2_diff_max_bt_min_qt_inter_slice · pic_log2_diff_max_tt_min_qt_inter_slice And the following is used for intra slices only: · pic_log2_diff_min_qt_min_cb_intra_slice_luma · pic_max_mtt_hierarchy_depth_intra_slice_luma · pic_log2_diff_max_bt_min_qt_intra_slice_luma · pic_log2_diff_max_tt_min_qt_intra_slice_luma · pic_log2_diff_min_qt_min_cb_intra_slice_chroma · pic_max_mtt_hierarchy_depth_intra_slice_chroma · pic_log2_diff_max_bt_min_qt_intra_slice_chroma · pic_log2_diff_max_tt_min_qt_intra_slice_chroma

[0104] These parameters are equivalent to those described for interpictures for intra and chroma respectively. The chroma parameters, as defined in Table 2, are only enabled if the flag qtbtt_dual_tree_intra_flag (SPS level) is set to 1. As shown in Table 2, these partitioning parameters (Inter, Intra, Chroma) are updated only if partition_constraints_override_enabled_flag is enabled and partition_constraints_override_flag is set to 1 in the Picture header. The flag partition_constraints_override_enabled_flag is sent within the SPS.

[0105] The second set of parameters relates to delta QP parameters. The following two parameters are only required for inter-slice: · pic_cu_qp_delta_subdiv_inter_slice · pic_cu_chroma_qp_offset_subdiv_inter_slice These are two intra-slice versions: · pic_cu_qp_delta_subdiv_intra_slice · pic_cu_chroma_qp_offset_subdiv_intra_slice

[0106] pic_cu_qp_delta_subdiv_inter_slice and pic_cu_qp_delta_subdiv_intra_slice are sent only if cu_qp_delta_enabled_flag is set to 1 in the PPS.

[0107] Similarly, pic_cu_chroma_qp_offset_subdiv_inter_slice and pic_cu_chroma_qp_offset_subdiv_intra_slice are decoded only if ppsS_cu_chroma_qp_offset_list_enabled_flag is enabled in the PPS.

[0108] The third set of parameters relates to motion parameters and is only used in inter-slice: · pic_temporal_mvp_enabled_flag mvd_l1_zero_flag · pic_six_minus_max_num_merge_cand · pic_five_minus_max_num_subblock_merge_cand pic_fpel_mmvd_enabled_flag pic_disable_bdof_flag pic_disable_dmvr_flag pic_disable_prof_flag · pic_max_num_merge_cand_minus_max_num_triangle_cand

[0109] Each of these parameters can be decoded (or not) based on the "enable flag" or "overriding flag" signaled in the SPS or PPS header, but each of these parameters is always transmitted, which leads to an increase in bit rate.

[0110] This rate increase is especially noticeable when a coded picture uses only one type of slice (intra or inter), so that some parameters are defined but never used.

[0111] A first way to improve this problem is to signal the coding type in the picture header and decode only the syntax elements related to that coding type. Most pictures are of a single coding type (e.g., INTER or INTRA), and therefore this represents an effective way to reduce the bitrate as unnecessary syntax elements.

[0112] Picture type indicated in the picture header In one general concept, the picture type syntax element "picture_type_pic_header" is transmitted at the beginning of the picture header.

[0113] This picture type can be defined as follows: If the picture type is set equal to I (or 0), all slices of the picture have the same slice type, Intra. If the picture type is set equal to P (or 1), all slices of the picture have the same slice type, Inter P (Uni-prediction). If the picture type is set equal to B (or 2), all slices of the picture have the same slice type, Inter B (Bi-prediction).

[0114] When a decoder receives a picture header that specifies picture_type_pic_header, it first determines the coding mode that corresponds to the picture type and decodes only those syntax elements that are relevant to this coding mode (or ignores syntax elements that are only relevant to a different coding mode).

[0115] In one example, picture_type_pic_header is used to enable and disable some syntax elements that are not required by imposing conditions on whether to decode certain parts of the picture header.

[0116] Table 3 below shows an example of a modified picture header that illustrates one way to implement this conditional decoding. Notable changes are underlined. Note that this table represents a partial header, reordered for reasons of clarity and brevity. A larger header, potentially with a different order, may be more appropriate in practice.

[0117] Table 3 - Picture header with conditional decoding JPEG2024069479000005.jpg177125JPEG2024069479000006.jpg134126

[0118] "Conditions" are associated with the encoding type and allow conditional decoding of certain syntax elements, and elements that do not require decoding are skipped, thus improving decoding performance.

[0119] An example of a condition is: Condition1: picture_type_pic_header == P OR picture_type_pic_header == B Condition2: picture_type_pic_header == I Condition3: picture_type_pic_header == B

[0120] If Condition1 is false, all slices are intra and the following syntax elements are not decoded: · pic_max_mtt_hierarchy_depth_inter_slice · pic_log2_diff_max_bt_min_qt_inter_slice · pic_log2_diff_max_tt_min_qt_inter_slice · pic_cu_qp_delta_subdiv_inter_slice · pic_cu_chroma_qp_offset_subdiv_inter_slice · pic_temporal_mvp_enabled_flag mvd_l1_zero_flag · pic_six_minus_max_num_merge_cand · pic_five_minus_max_num_subblock_merge_cand pic_fpel_mmvd_enabled_flag pic_disable_bdof_flag pic_disable_dmvr_flag pic_disable_prof_flag · pic_max_num_merge_cand_minus_max_num_triangle_cand

[0121] If Condition2 is false, all slices are inter and the following syntax elements are not decoded: · pic_log2_diff_min_qt_min_cb_intra_slice_luma · pic_max_mtt_hierarchy_depth_intra_slice_luma · pic_log2_diff_max_bt_min_qt_intra_slice_luma · pic_log2_diff_max_tt_min_qt_intra_slice_luma · pic_log2_diff_min_qt_min_cb_intra_slice_chroma · pic_max_mtt_hierarchy_depth_intra_slice_chroma · pic_log2_diff_max_bt_min_qt_intra_slice_chroma · pic_log2_diff_max_tt_min_qt_intra_slice_chroma · pic_cu_qp_delta_subdiv_intra_slice · pic_cu_chroma_qp_offset_subdiv_intra_slice

[0122] If Condition3 is false, all slices are NOT B pictures and the following syntax elements are not decoded: mvd_l1_zero_flag pic_disable_bdof_flag pic_disable_dmvr_flag · pic_max_num_merge_cand_minus_max_num_triangle_cand

[0123] Therefore, only the specific syntax elements of an I, P, or B picture are decoded from the picture header, thus reducing the rate of each picture.

[0124] Enable / disable syntax elements in slice header In one example, picture_type_pic_header is used to enable or disable some syntax elements that are not required, as shown in the modified picture header in Table 4.

[0125] In this table, slice_type is never sent, and its value has been replaced by the syntax element picture_type_pic_header. Based on this flag, num_ref_idx_active_override_flag can be sent if the picture contains only inter slices and not for intra. Similarly, the table num_ref_idx_active_minus1[i] is not decoded for pictures that contain intra slices.

[0126] The parameters num_ref_idx_active_override_flag and num_ref_idx_active_minus1[i] are both related to the amount of reference frames: num_ref_idx_active_override_flag indicates whether the parameter num_ref_idx_active_minus1[i], which represents the number of reference frames, needs to be decoded.

[0127] Similarly, if the picture contains intra slices, cabac_init_flag is not decoded. This parameter is related to the initialization CABAC context.

[0128] collocated_from_l0_flag, collocated_ref_idx are not decoded if the picture contains an intra slice. These parameters relate to the selection of a collocated reference frame for the temporal motion predictor.

[0129] Finally, if a picture contains intra slices, the pred_weight_table() is not decoded. An advantage of this embodiment is that the rate associated with the transmission of this slice type is saved compared to current designs.

[0130] Table 4 Modified slice header by pic_type_pic_header JPEG2024069479000007.jpg181124JPEG2024069479000008.jpg66125

[0131] In one particularly advantageous example, the above features can be combined: in this case picture_type_pic_header can be used to enable and disable some syntax elements that are not required in the picture header, and slice_type is not specified in the slice header and can be replaced by picture_type_pic_head to determine whether to decode some syntax elements of the slice header.

[0132] Slice type constraints in picture headers This feature represents a modification to the example above, where instead of picture_type_pic_header, the syntax element "pic_slice_type_constraint" is sent at the beginning of the picture header. This syntax element indicates constraints on the coding modes used for each slice in the picture. It differs from picture_type_pic_header because it does not necessarily require that all slices are the same, but allows a wider range of values.

[0133] Below are examples of pic_slice_type_constraint values ​​and their corresponding definitions: Equal to 0 indicates that all slices of the picture are intra. · Equal to 1 indicates that all slices of the picture are inter. Equal to 2 indicates that slices of a picture can have different types. Two more definitions can be added: · Equal to 3 indicates that all slices of the picture are Inter B. · Equal to 4 indicates that all slices of the picture are Inter P.

[0134] One alternative is that the pic_slice_type_constraint definition is defined as follows: · Equal to 0 indicates that all slices of the picture are Inter A, equal to 1. · Equal to 1 indicates that all slices of the picture are Inter-P. · Equal to 2 indicates that all slices of the picture are intra. · Equal to 3 indicates that slices of a picture may have different types. · Equal to 4 indicates that all slices of the picture are inter.

[0135] In this example, the different picture type constraints are ordered from the most probable to the least probable setting of a video sequence in order to reduce the general number of bits required to signal the pic_slice_type_constraint. In practice, the pic_slice_type_constraint can be coded with a unary code or a unary max or a Golomb code. Therefore, it is preferable to order the pic_slice_type_constraint values ​​according to their probability.

[0136] Other properties of the pic_slice_type_constraint that can be incorporated into the above list are: - The picture is an Instantaneous Decoder Refresh (IDR) picture. - The picture is a Clean Random Access (CRA) picture. - The picture is a Gradual Decoding Refresh (GDR) picture. - The picture is a non-Intra Random Access Point (non-IRAP), non-GDR picture and contains only I-slices. - The picture is a non-IRAP, non-GDR picture and contains only P and I slices. - The picture is a non-IRAP, non-GDR picture and contains either a B slice, a P slice, and / or an I slice.

[0137] Such values ​​may be useful for streaming applications where IRAP and GDR pictures are more relevant: indeed, these pictures provide intra-random access points that can be used, for example, to change the first picture of a sequence or to synchronize streams for live applications.

[0138] Indeed, in streaming applications, at least one intra slice will likely be required to "refresh" the stream in the event of a network package loss. In a simple embodiment, this reference can be performed at a picture-wide level to avoid pictures with mixed coding types.

[0139] This example provides similar rate reduction as the previous embodiment, but allows greater flexibility in the decoder by allowing differently coded slices within the same picture directly via the picture header.

[0140] Similar to the above example with pic_type_pic_header, the pic_slice_type_constraint is used to enable and disable some syntax elements that are not required. This corresponds to cases 1, 2 and 3 in Table 3 as follows: Condition1: pic_slice_type_constraint != 0 Condition2: pic_slice_type_constraint == 0 OR pic_slice_type_constraint == 2 Condition3: pic_slice_type_constraint == 3 OR pic_slice_type_constraint == 2

[0141] As an additional feature that provides additional improvement, the slice type in the slice header can be inferred and / or decoded with fewer bits than current designs.

[0142] As shown in Table 5, slice_type is decoded only if pic_slice_type_constraint is set to 2. In that case, slice_type can have one of three values: I, P, or B. When pic_slice_type_constraint is set to 1, slice_type is partially decoded. In fact, thanks to pic_slice_type_constraint, only one bit needs to be decoded to know whether slice_type is P or B, since the slice is inter (P or B). If pic_slice_type_constraint is set to 0, then slice_type is checked to be equal to I. If pic_slice_type_constraint is set to 0, then slice_type is checked to be equal to B. Otherwise, set it to P.

[0143] Compared to the example shown in Table 3 above, the slice_type is not removed and its decoding is adapted.

[0144] The advantage of this feature is that it allows for a reduction in the slice_type rate if all slices in a frame are intra or all are inter.

[0145] Table 5 Modified slice header with pic_Slice_type_constraint JPEG2024069479000009.jpg126124

[0146] In a further modification, the pic_slice_type_constraint is used to enable and disable some syntax elements that are not required in the picture header, and the slice_type in the slice header is inferred fully or partially based on the pic_slice_type_constraint value.

[0147] The picture type "pic_type" of the AU delimiter NAL unit can be set according to the value of pic_slice_type_constraint. Thus, if pic_type is set to I, then all pic_slice_type_constraints of this layer are set to 0. If pic_type is set to 2(P,I), then all pic_slice_type_constraints of this layer are either 0 or 3. Otherwise, all pic_slice_type_constraints of this layer can take any value (e.g., one of the five values ​​discussed above).

[0148] Change to AU NUL When using the above mentioned features, the syntax element "pic_type" of the decoded AU delimiter NAL unit does not need to be decoded if the stream has only one layer, or its decoding is optional depending on the flags transmitted in the VPS or SPS. Indeed, in such a case it is redundant to transmit this syntax element as similar information is present in the picture header. This feature contributes to rate reduction.

[0149] Optionally, the AU delimiter NAL unit is not decoded if the stream contains only one layer and is inferred based on the information in the picture header. Indeed, in that case, the information contained in the AU delimiter is not needed, since it is redundant with the syntax elements of the picture header. This feature further contributes to rate reduction.

[0150] AU NAL pic_type that sets the set of decoded syntax elements In one simplified variant, the pic_type of the AU NAL unit is used to determine the set of syntax elements decoded in the picture header. In this variant, no picture type or picture type constraint is set in the picture header. However, the conditions "condition1, condition2, and condition3" shown in Table 3 are determined based on the pic_type of the AU NAL unit when the AU NAL unit is signaled. Thus, the decoding of the picture header is conditioned on the slice coding mode (pic_type) of the slices in the picture, and the slice coding mode is determined at a higher level than the picture header.

[0151] "Condition" relates to the coding type, pic_type in this example, and allows for conditional decoding of certain syntax elements with elements that do not need to be skipped for decoding, as defined for the previous embodiment, thereby improving decoding performance.

[0152] An example of a condition is: Condition1: pic_type == 1 OR pic_type == 2 Condition2: pic_type == 0 Condition3: pic_type == 2 If the pic_type of an AU NAL unit is not signaled, the pic_type of the AU NAL unit is inferred to be equal to 2.

[0153] Merged syntax elements Similar syntax elements used in both inter and intra modes may be merged to reduce element redundancy in the picture header and / or to reduce the number of conditions that require verification before decoding. In one example, the picture header contains only syntax elements that are independent of the coding mode used. That is, the same syntax elements can be used in inter or intra. This is because most pictures contain only slices that require one type of coding mode (inter or intra), and so two such sets of syntax elements are not necessary.

[0154] Merging intra and inter syntax elements therefore avoids redundant coding of these syntax elements, especially when all slices in a picture are of the same type (I, P or B). When both inter and intra slices are present in a picture, there is less flexibility, but the impact on intra slices can be compensated for by adapting the coding choice.

[0155] Syntax elements that differ only in their "coding type" label are particularly suitable for merging.

[0156] Following the same design as above, the following syntax elements may be merged as shown in Table 6 below:

[0157] Table 6 Merged syntax elements JPEG2024069479000010.jpg65123

[0158] Table 7 shows an example of a simplification of this picture header syntax table.

[0159] Table 7. Picture Header with Merged Syntax Elements JPEG2024069479000011.jpg177124JPEG2024069479000012.jpg128124

[0160] Syntax element common values In one alternative, each pair of parameters still exists, the common value is decoded in the picture header, and the intra slice value is set to the common value if intra (defined in the slice header), the intra slice value is set to the common value if intra (defined in the slice header), and the inter slice value is set to the common value if inter (defined in the slice header).

[0161] In one additional example, at least one flag is present at the higher level (PPS, SPS) that indicates whether the intra-slice and / or inter-slice should use a common value or should keep the value given at the higher level (SPS, PPS). This allows for more flexibility.

[0162] In a further example, intra values ​​can be updated at the slice level depending on variables in the slice header.

[0163] For example, the parameters in an intra slice header are: · slice_log2_diff_min_qt_min_cb_intra_slice_luma · slice_max_mtt_hierarchy_depth_intra_slice_luma · slice_log2_diff_max_bt_min_qt_intra_slice_luma · slice_log2_diff_max_tt_min_qt_intra_slice_luma · slice_log2_diff_min_qt_min_cb_intra_slice_chroma · slice_max_mtt_hierarchy_depth_intra_slice_chroma · slice_log2_diff_max_bt_min_qt_intra_slice_chroma · slice_log2_diff_max_tt_min_qt_intra_slice_chroma · slice_cu_qp_delta_subdiv_intra_slice · slice_cu_chroma_qp_offset_subdiv_intra_slice

[0164] The advantage compared to the first example is the increased flexibility: in fact, this additional feature allows us to obtain the same flexibility as the current design, and by adapting these parameters for each slice, we obtain even more flexibility.

[0165] Overriding flags in PPS / SPS For increased flexibility, both intra and inter values ​​can be transmitted in the slice header. These parameters can be signaled (or not) in the slice header depending on one or more override flags transmitted in the PPS and / or SPS or picture header to reduce the additional rate required for these syntax elements in the slice header.

[0166] For example, if the parameter pic_log2_diff_min_qt_min_cb_slice is transmitted in the picture header, the override flag log2_diff_min_qt_cb_slice_Inter_override_flag is decoded to determine whether the slice_log2_diff_min_qt_min_cb_Inter_slice_luma value in the slice is updated for inter slices. If pic_log2_diff_min_qt_min_cb_slice is not decoded, this parameter is not updated for inter slices and log2_diff_min_qt_min_cb_slice_Inter_override_flag is set to 0. Similarly, for intra slices, the override flag log2_diff_min_qt_min_cb_slice_Intra_override_flag can be sent.

[0167] Optionally, when parameters are transmitted in the slice header, their values ​​are constrained by the equivalent syntax element values ​​in the picture header, or more precisely, their values ​​are limited to avoid increased complexity.

[0168] For example, slice_log2_diff_min_qt_min_cb_intra_slice_luma in the slice header is limited to the value of pic_log2_diff_min_qt_min_cb_slice sent in the picture header. More precisely, slice_log2_diff_min_qt_min_cb_intra_slice_luma is never less than pic_log2_diff_min_qt_min_cb_slice. The effect of this restriction is that slices cannot use block sizes smaller than the size defined in the picture header.

[0169] The advantage of this example is that the decoder can set its complexity parameters for each picture, so the complexity does not have to increase with each new slice.

[0170] To further reduce the number of required bits, when a slice syntax element is constrained by an equivalent syntax element in the picture header value, its value may be predicted by the last value coded.

[0171] It should be appreciated that the above "merging" of syntax elements can be combined with other features to reduce the overall number of separate syntax elements. As an example, in such a combination, a picture header may include coding mode independent syntax elements that are always decoded (i.e., "merged syntax elements"), an indication of the coding type (e.g., pic_type_pic_header or pic_slice_type_constraint), and syntax elements that are conditionally decoded based on the coding type.

[0172] Duplication of inter-parameters only In yet another example, all parameters related only to intra slices are removed from the picture header. Table 8 shows this example. Compared to the current design, the following syntax elements are not present in the picture header: · pic_log2_diff_min_qt_min_cb_intra_slice_luma · pic_max_mtt_hierarchy_depth_intra_slice_luma · pic_log2_diff_max_bt_min_qt_intra_slice_luma · pic_log2_diff_max_tt_min_qt_intra_slice_luma · pic_log2_diff_min_qt_min_cb_intra_slice_chroma · pic_max_mtt_hierarchy_depth_intra_slice_chroma · pic_log2_diff_max_bt_min_qt_intra_slice_chroma · pic_log2_diff_max_tt_min_qt_intra_slice_chroma · pic_cu_qp_delta_subdiv_intra_slice · pic_cu_chroma_qp_offset_subdiv_intra_slice

[0173] In this example, the values ​​of these omitted syntax elements are set in PPS and / or SPS. The advantage of this example is the rate reduction associated with the picture header. In fact, in a video sequence, there are many more inter-slices than intra-slices, since the temporal correlation is significantly higher than the spatial correlation. Therefore, in the picture header, the least used syntax parameters are those related only to intra-slices. This impact is greatest for pictures that contain only inter-slices, since the rate of the inter-slices is significantly lower than the rate of the intra-slices for the same image area and quality.

[0174] Table 8. Picture header with intra-syntax removed JPEG2024069479000013.jpg172125JPEG2024069479000014.jpg60125

[0175] Alternatively, when a sequence contains only intra pictures (as signed in the sequence header or SPS), the above intra parameters are transmitted in the picture header. The advantage of this embodiment is that the intra parameters can be adapted to the complete intra sequence, where the impact of this adaptation should be more significant.

[0176] Similarly, when a sequence contains only intra pictures, the set of inter syntax elements is not transmitted, the advantage being that there is no additional rate associated with unused inter parameters.

[0177] In a further embodiment, when the slice type is intra, a set of intra syntax elements is transmitted in the slice header. The advantage of this embodiment is that it has more flexibility compared to the main embodiment since intra can be adapted. Furthermore, the impact on the rate is lower due to the adaptation of intra slices since fewer intra slices are transmitted in the video.

[0178] In essence, the picture header is modified to remove the intra / inter elements when it is determined that the picture has only slices coded in one of these modes. In this way, the picture header contains only syntax elements related to the coding mode used for the whole picture. For the majority of pictures, this is inter-coded (because inter pictures are more common than intra), and for simplicity, this option can be implemented in all instances. If a picture has slices with different coding modes, the syntax elements for that slice / whole picture can be determined from a different header (such as the slice header).

[0179] For example, the parameters in an intra slice header are: · slice_log2_diff_min_qt_min_cb_intra_slice_luma · slice_max_mtt_hierarchy_depth_intra_slice_luma · slice_log2_diff_max_bt_min_qt_intra_slice_luma · slice_log2_diff_max_tt_min_qt_intra_slice_luma · slice_log2_diff_min_qt_min_cb_intra_slice_chroma · slice_max_mtt_hierarchy_depth_intra_slice_chroma · slice_log2_diff_max_bt_min_qt_intra_slice_chroma · slice_log2_diff_max_tt_min_qt_intra_slice_chroma · slice_cu_qp_delta_subdiv_intra_slice · slice_cu_chroma_qp_offset_subdiv_intra_slice

[0180] To reduce complexity, when parameters are transmitted in an intra-slice, their values ​​may be constrained by the values ​​of their equivalent inter-syntax elements. More precisely, their values ​​are limited to avoid an increase in complexity.

[0181] For example, slice_log2_diff_min_qt_min_cb_intra_slice_luma in the slice header is limited to the value of pic_log2_diff_min_qt_min_cb_inter_slice sent in the picture header. More precisely, the value of the minimum QT size (which gives the minimum block size) in the current slice is not inferior to the minimum QT size value defined in the PH. Thus, slice_log2_diff_min_qt_min_cb_intra_slice_luma is not inferior to pic_log2_diff_min_qt_min_cb_inter_slice.

[0182] The advantage of this feature is that the decoder can set its complexity parameters for each picture, and there is no need to increase this complexity for every new slice, since the "worst case" complexity is set in the picture header. This constraint also applies if inter parameters can be transmitted in the slice header.

[0183] To further reduce the number of coding bits, if a slice syntax element is constrained by its even syntax element inter value in the picture header, its value may be predicted by its even syntax element inter value. For example, the value may be decoded such that slice_log2_diff_min_qt_min_cb_intra_slice_luma is equal to this value + pic_log2_diff_min_qt_min_cb_inter_slice.

[0184] For increased flexibility, a set of intra syntax elements are sent in the slice header when the slice type is intra and regardless of whether an override flag signals its use. The override flags are signaled at the SPS or PPS level. Furthermore, additional override flags can be sent in the slice header as current override flags in the picture header for these parameters.

[0185] Intra / Inter flag override Picture header syntax elements defined only for intra or inter slices may (or may not) be decoded depending on one or more intra- and inter-specific override flags. This allows for increased flexibility while avoiding the decoding of unnecessary syntax elements. Table 9 illustrates this feature.

[0186] In this table, syntax elements related to partitioning are grouped separately for intra and inter. partition_constraints_override_enabled_flag is replaced by two syntax elements decoded in the SPS: partition_constraints_override_enabled_flag_inter and partition_constraints_override_enabled_flag_intra.

[0187] Based on partition_constraints_override_enabled_flag_intra, a new flag syntax element partition_constraints_override_flag_intra is decoded and if it is set to 1, the following partition syntax elements for intra are decoded or can be decoded subject to other constraints: · pic_log2_diff_min_qt_min_cb_intra_slice_luma · pic_max_mtt_hierarchy_depth_intra_slice_luma · pic_log2_diff_max_bt_min_qt_intra_slice_luma · pic_log2_diff_max_tt_min_qt_intra_slice_luma · pic_log2_diff_min_qt_min_cb_intra_slice_chroma · pic_max_mtt_hierarchy_depth_intra_slice_chroma · pic_log2_diff_max_bt_min_qt_intra_slice_chroma · pic_log2_diff_max_tt_min_qt_intra_slice_chroma

[0188] If the override flag is set to 0, the default values ​​set in the SPS are used to set these values.

[0189] Similarly, partition_constraints_override_flag_inter is decoded if the associated override flag is set to 1 in the SPS. If this picture header syntax element is true, the inter partitioning syntax elements are used. · pic_log2_diff_min_qt_min_cb_inter_slice · pic_max_mtt_hierarchy_depth_inter_slice · pic_log2_diff_max_bt_min_qt_inter_slice · pic_log2_diff_max_tt_min_qt_inter_slice

[0190] If the override flag is set to 0, the default values ​​set in the SPS will be used to set these values.

[0191] Similarly, for syntax elements related to delta QP, cu_QP_delta_enabled_flag is separated into two flags, one for intra and one for inter: cu_QP_delta_enabled_flag_Intra, cu_QP_delta_enabled_flag_Inter. These flags are sent in PPS or SPS and are sent only if no_qp_delta_constraint_flag is 0.

[0192] pps_cu_chroma_qp_offset_list_enabled_flag is separated into two flags, one for intra and one for inter: pps_cu_chroma_qp_offset_list_enabled_flag ag_Intra and pps_cu_chroma_qp_offset_list_enabled_flag_Inter. These flags are sent in the PPS and replace pps_cu_chroma_qp_offset_list_enabled_flag.

[0193] For picture header syntax elements related to motion parameters, the motion_parameters_override_enabled_flag is transmitted in the SPS. If enabled, the motion_parameters_override_flag flag is decoded. If it is equal to true, all syntax elements related to these parameters can be decoded. If it is equal to false, these parameters take the value of their corresponding PPS or SPS value. For flags, the value can only be an SPS or PPS value. For example: pic_temporal_mvp_enabled_flag = sps_temporal_mvp_enabled_flag mvd_l1_zero_flag = !pps_mvd_l1_zero_idc pic_fpel_mmvd_enabled_flag = sps_fpel_mmvd_enabled_flag pic_disable_bdof_flag= sps_bdof_pic_present_flag pic_disable_dmvr_flag = sps_dmvr_pic_present_flag pic_disable_prof_flag = sps_prof_pic_present_flag

[0194] In one example, at least a default value may be sent in an SPS or PPS header to define one of these default values.

[0195] For non-flag values: For example, you can use the maximum value set in SPS or PPS. For example: pic_six_minus_num_max_merge_cand and pic_max_merge_cand_minus_max_num_triangle_cand can depend on pps_six_minus_max_num_merge_cand_plus1 and pps_max_num_merge_cand_cand_minus_max_num_triangle_cand_plu, respectively.

[0196] At the SPS level, there is no definition of pic_five_minus_max_num_subblock_merge_cand, but the default value can be set as 5 - (SPS_sbtmvp_enabled_flag && pic_temporal_mvp_enabled_flag).

[0197] In an embodiment, an SPS and / or PPS value is transmitted to fix this default value. Additionally, one further embodiment specific parameter can be sent in the SPS or PPS header to set this value.

[0198] The advantages of using override flags are the same as above, but they are more flexible (at the expense of sending and decoding flags) since intra parameters can be sent if a given override flag is set to true.

[0199] Table 9. Picture Header with Override Flag JPEG2024069479000015.jpg177125JPEG2024069479000016.jpg183124JPEG2024069479000017.jpg82125

[0200] Note that the location of these new override flags can be modified, for example the inter flag can be moved above the intra flag, which can be beneficial since as more pictures use inter coding this flag can be more relevant.

[0201] Similarly, the previous flag partition_constraints_override_flag is retained and can be checked whether the inter or intra flag should be checked.

[0202] In one embodiment, two override flags are sent before these different syntax elements: one to specify whether inter elements are overridden and one to specify that intra elements are overridden. These override flags may also be defined in the same way at higher levels. Fewer additional override flags are needed compared to the previous embodiment.

[0203] Override Flags and Merged Syntax Elements A particularly interesting combination is the combination of using the override flag (e.g., Table 9) and the merged syntax elements (e.g., Table 6). Additionally, some of the parameters can be removed from the picture header as described above (e.g., Table 8).

[0204] For example, syntax elements that can be merged are merged. The cu delta QP parameters are of interest, as are the partitioning flags related to intra and inter luma. If not, the chroma partitioning parameters can be removed as described above, and the motion parameters can be set (or not) depending on one or more override flags. Table 10 shows examples of such combinations.

[0205] Table 10 Picture headers with feature combinations JPEG2024069479000018.jpg177124JPEG2024069479000019.jpg89123

[0206] It should be understood that the above features may be provided in combination with one another. As with the particular combinations discussed above, doing so may provide certain advantages suited to a particular implementation, such as increased flexibility, or specification of a "worst case" example. In other instances, complexity requirements may have a higher priority than rate reduction (for example), and such features may be implemented individually.

[0207] Implementation of the invention Fig. 7 shows a system 191 195 comprising 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 for processing and providing content (e.g. video and audio content for displaying / outputting or streaming video / audio content) to a user who can access the decoder 100, for example, via a user interface of a user terminal including the decoder 100 or a user terminal 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 (provided / streamed) content to a user. The system 195 obtains / receives the bitstream 101 (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 later displaying / outputting / streaming. The system 191 obtains / receives content comprising an original image sequence 151 that has been received and processed (including filtering by a deblocking filter according to the invention) by an encoder 150, which generates a bitstream 101 that is communicated to the decoder 100 via a communication network 191. The bitstream 101 is then communicated to the decoder 100 in several ways, for example being pre-generated by the encoder 150 and stored as data in a storage device (e.g. a server or cloud storage) in the communication network 199 until a user requests the content (i.e. bitstream data) from the storage device, at which point the data is communicated / streamed from the storage device to the decoder 100.The system 191 may also provide / stream to the user (e.g., by communicating data for a user interface to be displayed on the user terminal) content information (e.g., title of the content and other meta / storage location data for identifying, selecting and requesting the content) of the content stored in the storage device, and may comprise a content providing device for receiving and processing user requests for content so that the requested content can be delivered / streamed from the storage device to the user terminal. Alternatively, the encoder 150 generates the bitstream 101 when the user requests the content and communicates / streams it directly to the decoder 100. The decoder 100 then receives the bitstream 101 (or signal) and performs filtering with a deblocking filter according to the present invention to obtain / generate a video signal 109 and / or an audio signal, which is used by the user terminal to provide the requested content to the user.

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

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

[0210] The embodiments of the present invention can be realized by a computer of a system or apparatus including one or more processors or circuits for reading and executing computer executable instructions (e.g., one or more programs) recorded on a storage medium to perform one or more modules / units / functions of the above-mentioned embodiments, and / or by a method executed by the computer of the system or apparatus, e.g., by reading and executing computer executable instructions from a storage medium to perform one or more functions of the above-mentioned embodiments, and / or by controlling one or more processors or circuits to perform one or more functions of the above-mentioned embodiments. The computer may include a separate computer or a network of separate processing units to read and execute the computer executable instructions. The computer executable instructions may be provided to the computer from a computer readable medium, such as a communication medium, for example, via a network or a tangible storage medium. The communication medium may be a signal / bit stream / carrier wave. The tangible storage medium may be, for example, a hard disk, a random access memory, a read-only memory, a storage device of a distributed computing system, an optical disk (Compact Disc (CD), Digital Versatile Disc (DVD), or Blu-ray Disc (BD)). TMThe "non-transitory computer-readable storage medium" may include one or more of a memory device, a flash memory device, a memory card, etc. At least some of the steps / functions may also be implemented in hardware by machines or dedicated components such as an FPGA ("Field Programmable Gate Array") or an ASIC ("Application Specific Integrated Circuit").

[0211] FIG. 8 is a schematic block diagram of a computing device 1300 for implementing one or more embodiments of the present invention. The computing device 1300 can be a device such as a microcomputer, a workstation, or a light portable device. The computing device 1300 has a central processing unit (CPU) 1301, such as a microprocessor; a random access memory (RAM) 1302 for storing executable code of the method of the embodiments of the present invention as well as registers adapted to record variables and parameters necessary for implementing the method for encoding or decoding at least a portion of an image according to the embodiments of the present invention, where the memory capacity can be expanded, for example, by connecting an optional RAM to an expansion port; a read only memory (ROM) 1303 for storing computer programs for implementing the embodiments of the present invention; and a network interface (NET) 1304 for connecting to a communication network over which digital data to be processed is transmitted or received. The network interface (NET) 1304 may be a single network interface or may be composed of a set of different network interfaces (e.g., wired and wireless interfaces, or different types of wired or wireless interfaces). Data packets are written to the network interface for transmission or read from the network interface for reception under the control of a software application executed in the CPU 1301. A user interface (UI) 1305 may be used to receive input from a user or to display information to a user. A hard disk (HD) 1306 may be provided as a mass storage device. An input / output module (IO) 1307 may be used to send and receive data to and from external devices such as a video source or a display. The executable code may be stored either in the ROM 1303, the HD 1306 or on a removable digital medium such as a disk.According to a variant, the executable code of the program can be received by means of a communication network, via NET 1304, in order to be stored in one of the storage means of the communication device 1300, such as HD 1306, before being executed. The CPU 1301 is adapted to control and direct the execution of instructions or parts of the software code of a program or group of programs according to an embodiment of the invention stored in one of the aforementioned storage means. After power-on, the CPU 1301 can for example execute instructions from the main RAM memory 1302 relating to a software application after those instructions have been loaded from the program ROM 1303 or from the HD 1306. Such a software application, when executed by the CPU 1301, causes the steps of the method according to the invention to be carried out.

[0212] It is also understood that according to other embodiments of the present invention, a 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, an encoder according to the aforementioned embodiments is provided in an imaging device that also comprises a camera, a digital 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 9 and 10.

[0213] Network Camera FIG. 9 is a diagram illustrating a network camera system 2100 including a network camera 2102 and a client device 2104 .

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

[0215] A network camera 2102 and a client device 2104 are connected to each other via a network 200 so as to be able to communicate with each other.

[0216] 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)) to capture an image of a subject and generate image data based on the image, which may be a still image or a video image.

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

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

[0219] The communication unit 2110 also receives commands from the client device 2104. The commands include commands to set parameters for encoding in the encoding unit 2108.

[0220] The control unit 2112 controls each unit within the network camera 2102 in accordance with the commands received by the communication unit 2110 .

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

[0222] The communication unit 2114 of the client device 2104 sends the command to the network camera 2102 .

[0223] The communication unit 2114 of the client device 2104 also receives the encoded image data from the network camera 2102 .

[0224] The decoding unit 2116 decodes the coded image data using the above-mentioned decoding method.

[0225] The control unit 2118 of the client device 2104 controls other units within the client unit 2104 in accordance with user operations or commands received by the communication unit 2114 .

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

[0227] In addition, the control unit 2118 of the client device 2104 controls the display device 2120 to display a GUI (Graphical User Interface) for designating parameter values ​​of the network camera 2102 including parameters for encoding by the encoding unit 2108 .

[0228] Furthermore, the control unit 2118 of the client unit 2104 controls other units within the client unit 2104 in response to a user operation input to a GUI displayed on a display device 2120 .

[0229] The control unit 2119 of the client device 2104 controls the communication unit 2114 of the client device 2104 to send a command specifying parameter values ​​of the network camera 2102 to the network camera 2102 in response to a user operation input to a GUI displayed by the display device 2120.

[0230] Smartphone FIG. 10 is a diagram showing a smartphone 2200. The smartphone 2200 comprises 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 .

[0231] 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 encoded image data using the above-mentioned decoding method.

[0232] The control unit 2206 controls other units within the smartphone 2200 in response to user operations or 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 .

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

[0234] It will also be understood that any result of the above-mentioned comparisons, determinations, evaluations, selections, executions, performing, or considerations, e.g., selections made during an encoding or filtering process, may be indicated in or determinable / inferable from data in the bitstream, e.g., flags or data indicating the result, such that the indicated or determined / inferred result may be used in processing, e.g., during a decoding process, in lieu of actually performing the comparisons, determinations, evaluations, selections, executions, performing, or considerations.

[0235] In the claims, the word "comprise" 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.

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

Claims

1. 1. A method for decoding a picture from a bitstream, the picture having one or more slices, the bitstream having a picture header, a slice header and an adaptation parameter set; decoding a syntax element related to partitioning and used for intraframe from the picture header when a partition_constraints_override_flag, which is a flag in the picture header related to partitioning, has a value of 1 and a predetermined syntax element in the picture header indicates that all slices of the picture use intraframe; and decoding the one or more slices using the decoded syntax elements; each of the one or more slices includes a plurality of coding tree units (CTUs); If the predetermined syntax element indicates that all slices of the picture use intra, information corresponding to the coding type of the slice is not decoded from the slice header; the information can be decoded from the slice header in response to a value of the predetermined syntax element; The adaptation parameter set may be located after the picture header in the bitstream and may include information about an adaptive loop filter. A method comprising:

2. 2. The method of claim 1, wherein the information is a slice_type.

3. The method of claim 1, wherein if the specified syntax element indicates that all slices in the picture use intra, then mvd_l1_zero_flag, which is information used in inter, is not decoded from the picture header.

4. 2. The method of claim 1, wherein if the value of the partition constraints override flag is 0, the syntax elements related to the partitioning and used for intra are not decoded from the picture header.

5. 2. The method of claim 1, wherein if the predetermined syntax element in the picture header indicates that all slices of the picture use intra, then syntax elements for delta QP and used for intra are decodable from the picture header.

6. 2. The method of claim 1, wherein different slices are capable of using the same adaptation parameter set.

7. 2. The method of claim 1, wherein the syntax element related to partitioning and used for intra is log2_diff_min_qt_min_cb_intra_slice_luma in the picture header.

8. The partition_constraints_override_flag in the picture header indicates, when it has a value of 1, that parameters related to partitions are present in the picture header.

2. The method of claim 1 .

9. 1. A method for encoding a picture into a bitstream, the picture having one or more slices, the bitstream having a picture header, a slice header and an adaptation parameter set; encoding a predetermined syntax element in a picture header capable of indicating that all slices in the picture use intra; encoding syntax elements related to partitioning and for intra into the picture header when a partition_constraints_override_flag, which is a flag in the picture header related to partitioning, has a value of 1 and the predetermined syntax element indicates that all slices in the picture use intra; and encoding the one or more slices, each of the one or more slices includes a plurality of coding tree units (CTUs); If the predetermined syntax element indicates that all slices of the picture use intra, information corresponding to the coding type of the slice is not coded in the slice header; The information may be encoded in the slice header according to a value of the predetermined syntax element; The adaptation parameter set may be located after the picture header in the bitstream and may include information about an adaptive loop filter. A method comprising:

10. 10. The method of claim 9, wherein the information is a slice_type.

11. The method of claim 9, characterized in that if the specified syntax element indicates that all slices in the picture use intra, then mvd_l1_zero_flag, which is information used in inter, is not coded in the picture header.

12. 10. The method of claim 9, wherein if the value of the partition constraints override flag is 0, the syntax elements related to the partitioning and used for intra are not decoded from the picture header.

13. 10. The method of claim 9, wherein if the predetermined syntax element in the picture header indicates that all slices of the picture use intra, then syntax elements for delta QP and used for intra are decodable from the picture header.

14. 10. The method of claim 9, wherein different slices are capable of using the same adaptation parameter set.

15. 10. The method of claim 9, wherein the syntax element related to partitioning and used for intra is log2_diff_min_qt_min_cb_intra_slice_luma in the picture header.

16. The partition_constraints_override_flag in the picture header indicates, when it has a value of 1, that parameters related to partitions are present in the picture header.

10. The method of claim 9.

17. An apparatus for decoding a picture from a bitstream, the picture having one or more slices, the bitstream having a picture header, a slice header and an adaptation parameter set; means for decoding, from the picture header, a syntax element related to partitioning and used for intra, when a partition_constraints_override_flag, which is a flag in the picture header related to partitioning, has a value of 1 and a predetermined syntax element in the picture header indicates that all slices of the picture use intra; means for decoding the one or more slices using the decoded syntax elements; each of the one or more slices includes a plurality of coding tree units (CTUs); If the predetermined syntax element indicates that all slices of the picture use intra, information corresponding to the coding type of the slice is not decoded from the slice header; the information can be decoded from the slice header in response to a value of the predetermined syntax element; The adaptation parameter set may be located after the picture header in the bitstream and may include information about an adaptive loop filter. An apparatus comprising:

18. An apparatus for encoding a picture into a bitstream, the picture having one or more slices, the bitstream having a picture header, a slice header and an adaptation parameter set; means for encoding a predetermined syntax element in a picture header capable of indicating that all slices in the picture use intra frame; means for encoding syntax elements related to partitioning and for intra into the picture header when a partition_constraints_override_flag, which is a flag in the picture header related to partitioning, has a value of 1 and the predetermined syntax element indicates that all slices in the picture use intra; and means for encoding the one or more slices, each of the one or more slices includes a plurality of coding tree units (CTUs); If the predetermined syntax element indicates that all slices of the picture use intra, information corresponding to the coding type of the slice is not coded in the slice header; The information may be encoded in the slice header according to a value of the predetermined syntax element; The adaptation parameter set may be located after the picture header in the bitstream and may include information about an adaptive loop filter. An apparatus comprising:

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

20. A computer program product for causing a computer to carry out the steps of the method according to any one of claims 9 to 16.

Images