Method of decoding picture from bitstream, method of encoding picture in bitstream, decoder, encoder, computer program product and computer readable medium

Abstract

The present invention relates to a method of decoding a picture from a bitstream, a method of encoding a picture in a bitstream, a decoder, an encoder, a computer program product and a computer readable medium. Disclosed is a method of decoding video data from a bitstream, the bitstream comprising video data corresponding to a plurality of slices, where the video bitstream comprises a picture header, the method comprising: determining an encoding mode for at least one slice; determining, from the picture header, a set of syntactic elements to be used for the encoding mode; and decoding the at least one slice using the determined syntax element. A corresponding encoding method, apparatus and computer program are also disclosed.

Description

[0001] (This application is a divisional application of application No. 2020800970726, filed December 18, 2020, entitled “HIGH-LEVEL SYNTAX FOR VIDEO ENCODING AND DECODING.”) Technical Field

[0002] The present invention relates to video encoding and decoding, and in particular to high-level syntax for video encoding and decoding. Background Art

[0003] Recently, the Joint Video Experts Team (JVET) (a collaboration between MPEG and ITU-T Study Group 16, VCEG) began 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 fast as before) and to be completed in 2020. Key target applications and services include, but are not limited to, 360-degree and high dynamic range (HDR) video. In total, JVET evaluated feedback from 32 organizations using formal subjective tests conducted by independent test labs. Some proposals showed compression efficiency improvements of 40% or more, typically when compared to using HEVC. Particular improvements were shown on ultra-high-definition (UHD) video test material. Therefore, we can expect compression efficiency improvements far exceeding the targeted 50% for the final standard.

[0004] The JVET Exploration Model (JEM) uses all HEVC tools and has introduced several new tools. These changes require changes to the structure of the bitstream, especially the high-level syntax, which may have an impact on the overall bitrate of the bitstream.

[0005] An important change in the high-level syntax is the introduction of a "picture header" into the bitstream. A picture header is a header that specifies the syntax elements to be used when decoding the individual slices in a particular picture (or frame). Therefore, the picture header is placed before the slice-related data in the bitstream, and each slice has its own "slice header". Figure 6 This structure is described in more detail.

[0006] The document JVET-P0239 entitled "AHG 17: PictureHeader" of the 16th meeting (October 1-11, 2019, Geneva, Switzerland) proposed the introduction of a mandatory picture header into VVC, and this was adopted as Universal Video Coding (Draft 7), uploaded as document JVET_P2001. However, while this structure provides flexibility when using all VVC tools, the amount of syntax elements signaled in the bitstream increases, which affects the bit rate of transmission (especially for low bit rate examples).

[0007] Therefore, a solution to at least one of the above problems is desired.

[0008] Broadly, the inventors have recognized that the flexibility built into recently adopted high-level syntax is only rarely used, thereby unnecessarily increasing the bit rate. In particular, most pictures only include slices using 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 exploiting the fact that most pictures use only one type of slice coding and, therefore, can reduce the bit rate.

[0009] Optional features are also being considered to reintroduce the flexibility of multiple coding types within a single picture. Certain syntax elements and / or additional constraints on syntax elements are being added to reduce bitrate compared to the more advanced syntaxes recently adopted. These "added" features may increase bitrate, but because they are rarely used, the average bitrate for a given video sequence will be lower than in the prior art.

[0010] This invention proposes modifications to picture header signaling to avoid the extra signaling of some picture header parameters that are not needed when the entire image contains only one slice type (I, P, B). Specifically, the parameters related to delta QP signaling for inter and intra frames are merged into a single parameter. The override flag for partition parameters is changed to two override flags: one for inter slices and one for intra slices. In addition, an override flag is added for motion information parameters in inter slices. Compared to the current design, these modifications provide almost the same flexibility but increase coding efficiency. Summary of the Invention

[0011] In one aspect of the present invention, a decoder only has to decode one set of syntax elements from a picture header, which is defined by the slice coding mode (e.g., inter or intra) of the picture. Alternatively, the syntax elements in the picture header are agnostic to the coding mode and include a merged set of syntax elements. In this way, the bit rate is reduced because the decoder can skip unnecessary syntax elements.

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

[0013] Optionally, determining the coding mode for the one or more slices depends on at least one syntax element in the picture header.

[0014] Optionally, the single coding mode is one of inter and intra.

[0015] Optionally, the single coding mode is inter.

[0016] Optionally, the inter coding mode is one of Inter-B and Inter-P.

[0017] Optionally, determining the set of syntax elements to be used for the single coding mode comprises enabling and / or disabling at least one syntax element in a picture header.

[0018] Optionally, determining the set of syntax elements to be used for the single coding mode comprises enabling and / or disabling at least one syntax element in a slice header.

[0019] Optionally, the encoding type is determined based on the value of the AU delimiter.

[0020] Optionally, determining the encoding mode comprises decoding one or more overwrite flags.

[0021] Optionally, the one or more overwrite flags include a first flag indicating whether to use inter-frame mode and a second flag indicating whether to use intra-frame mode.

[0022] In one aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein a picture includes the one or more slices, and wherein the video bitstream includes a picture header, the method including: determining a coding mode for the one or more slices in the picture; determining a set of syntax elements to be used for the coding mode from the picture header; and decoding the one or more slices using the determined syntax elements.

[0023] According to one aspect of the present invention, a method of encoding video data into a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein a picture includes the one or more slices, and wherein the video bitstream includes a picture header, the method including: defining a single coding mode for the at least one slice in the picture; encoding a set of syntax elements to be used for the single coding mode into the picture header; and encoding the one or more slices using the determined syntax elements.

[0024] According to one aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream including video data corresponding to one or more slices, wherein a picture includes the one or more slices, and wherein the video bitstream includes a picture header, the method including: determining a coding mode for the one or more slices in the picture; determining a set of syntax elements to be used for the coding mode into the picture header; and encoding the one or more slices using the determined syntax elements.

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

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

[0027] In another aspect of the present invention, a decoder is provided, which is adapted to decode a bit stream by performing a method according to the above-mentioned decoding method aspect.

[0028] In another aspect of the present invention, an encoder is provided, which is adapted to encode a bit stream by performing the method of the above encoding method aspect.

[0029] According to one aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to a plurality of slices, wherein the video bitstream includes a picture header; the method comprising: determining a coding mode for at least one slice; determining a set of syntax elements to be used for the coding mode from the picture header; and decoding the at least one slice using the determined syntax elements.

[0030] This allows for a reduction in bit rate, resulting in overall more efficient decoding.

[0031] Optionally, determining the coding mode for at least one slice depends on a syntax element in the picture header.

[0032] Optionally, the coding mode is one of inter and intra.

[0033] For flexibility, the coding mode is one of inter, intra, and a combination of inter and intra.

[0034] For additional flexibility, the inter coding mode is one of Inter-B and Inter-P.

[0035] Optionally, determining the set of syntax elements specific to the coding mode comprises enabling and / or disabling at least one syntax element in a picture header.

[0036] Optionally, determining the set of syntax elements specific to the coding mode comprises enabling and / or disabling at least one syntax element in a slice header.

[0037] Optionally, the method further comprises inferring a value of an AU delimiter based on the determined encoding type. Optionally, inferring the value of the AU delimiter is performed if the stream is determined to contain only one layer.

[0038] According to another aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to a plurality of slices, wherein the video bitstream includes 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.

[0039] According to another aspect of the present invention, a method for decoding video data from a bitstream is provided, the bitstream including video data corresponding to a plurality of slices, wherein the video bitstream includes a picture header; the method comprising: decoding a picture using the syntax elements from the picture header; wherein all syntax elements correspond to the same slice coding mode.

[0040] These aspects reduce the rate associated with the header, especially for pictures containing only inter slices (which is the majority of pictures in many video sequences).

[0041] Optionally, if the determination is not true, intra coding parameters of intra slices in the picture are inferred from corresponding inter syntax elements in the picture header.

[0042] Optionally, the intra syntax elements are restricted to values ​​of corresponding inter values.

[0043] Optionally, the method further comprises predicting a syntax element for the slice based on values ​​of previous syntax elements.

[0044] Optionally, determining the coding mode for at least one slice depends on a syntax element in a header different from a picture header.

[0045] In one example, the header different from the picture header is a sequence header.

[0046] In another example, the header different from the picture header is an AUD NAL unit.

[0047] In one example, the determined coding mode is inter-frame. In another example, the determined coding mode is intra-frame.

[0048] Optionally, determining the encoding mode comprises decoding one or more overwrite flags.

[0049] Optionally, the one or more overwrite flags are in a header at a higher level than the picture header.

[0050] According to another aspect of the present invention, there is provided a method for decoding video data from a bitstream, the bitstream comprising video data corresponding to a plurality of slices, wherein the video bitstream comprises a picture header; the method comprising: decoding one or more override flags; and decoding coding-specific syntax elements from the picture header according to the one or more override flags; wherein the one or more override flags are in a header at a higher level than the picture header.

[0051] This aspect provides the advantage of rate reduction, with the added flexibility of being able to override the defaults.

[0052] Optionally, the higher level header is an SPS or a PPS.

[0053] Optionally, the method further comprises decoding two override flags from the picture header before encoding the relevant syntax element, the first override flag indicating that the inter-frame element is overwritten, and the second override flag indicating that the intra-frame element is overwritten.

[0054] Optionally, the syntax element to be used for the determined encoding mode is agnostic to the encoding mode.

[0055] According to another aspect of the present invention, a method is provided for decoding video data from a bitstream, the bitstream including video data corresponding to a plurality of slices; wherein the video bitstream includes a picture header; wherein the picture header includes only syntax elements that are agnostic to the coding mode; and decoding each slice in the picture using the syntax elements.

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

[0057] Optionally, the method further comprises determining, from a header different from the picture header, syntax elements specific to the determined coding mode.

[0058] Optionally, the header different from the picture header is a slice header.

[0059] For flexibility, inter-frame and intra-frame syntax elements may be provided in the slice header.

[0060] Optionally, the method further comprises: decoding an overwrite flag, the overwrite flag determining whether to decode an encoding specific syntax element from the slice header.

[0061] Optionally, the syntax element in the slice header has a value constrained to be an equivalent syntax element in a picture header.

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

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

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

[0065] According to another aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream including video data corresponding to a plurality of slices, wherein one or more of the slices include a picture; wherein the video bitstream includes a picture header; the method comprising: defining a coding mode for all slices within the picture; and encoding the picture header using syntax elements according to the defined coding mode.

[0066] According to another aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream including video data corresponding to a plurality of slices, wherein the video bitstream includes a picture header; the method comprising: encoding a picture using the syntax elements from the picture header; wherein all syntax elements correspond to the same slice coding mode.

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

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

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

[0070] According to another aspect of the present invention, a method for encoding video data into a bitstream is provided, the bitstream including video data corresponding to a plurality of slices, wherein the video bitstream includes a picture header; the method comprising: encoding one or more override flags; and encoding coding-specific syntax elements into the picture header according to the one or more override flags; wherein the one or more override flags are in a header at a higher level than the picture header.

[0071] As described above, these encoding methods can enable more efficient decoding.In some instances, the encoding is less complex because fewer syntax elements are encoded into the corresponding header and / or there is less redundancy in the bitstream.

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

[0073] Further aspects of the present invention relate to a program that, when executed by a computer or processor, causes the computer or processor to perform any of the aforementioned method aspects of the present invention. The program may be provided separately, or may be carried by or on a carrier medium. The carrier medium may be non-transitory, such as a storage medium, in particular a computer-readable storage medium. The carrier medium may also be transient, such as a signal or other transmission medium. The signal may be transmitted via any suitable network, including the Internet.

[0074] Further characteristics of the invention are characterized by the other independent and dependent claims.

[0075] Any features in 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.

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

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

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

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

[0080] Figure 1 is a diagram for explaining the coding structure used in HEVC and VVC;

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

[0082] Figure 3 is a block diagram illustrating components of a processing device that may implement one or more embodiments of the present invention;

[0083] Figure 4 is a flow chart illustrating the steps of an encoding method according to an embodiment of the present invention;

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

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

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

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

[0088] Figure 9 is a diagram showing a network camera system; and

[0089] Figure 10 is a diagram showing a smartphone. DETAILED DESCRIPTION

[0090] Figure 1 The present invention relates to a coding structure used in the High Efficiency Video Coding (HEVC) video standard. A video sequence 1 consists of a series of digital images i. Each of these digital images is represented by one or more matrices. The matrix coefficients represent pixels.

[0091] The images 2 of the sequence may be partitioned into slices 3. In some cases, one slice may constitute the entire image. These slices are partitioned into non-overlapping Coding Tree Units (CTUs). The Coding Tree Unit (CTU) is the basic processing unit of the High Efficiency Video Coding (HEVC) video standard and conceptually corresponds in structure to the macroblock unit used in several previous video standards. A CTU is sometimes also called a Largest Coding Unit (LCU). A CTU has luminance and chrominance component parts, each of which is called a Coding Tree Block (CTB). These different color components are not Figure 1 Shown in.

[0092] A CTU is typically 64 pixels by 64 pixels in size. Each CTU can be iteratively partitioned into smaller, variable-sized coding units (CUs) using a quadtree decomposition.

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

[0094] Each slice is embedded in a network abstraction layer (NAL) unit. In addition, the coding parameters of the 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: first, 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 frame, and other parameters. Second, the picture parameter set (PPS) NAL unit, which includes parameters that can change from one image (or frame) of the sequence to other images (or frames). HEVC also includes a video parameter set (VPS) NAL unit, which contains parameters that describe the overall structure of the bitstream. VPS is a new type of parameter set defined in HEVC and applies to all layers of the bitstream. A layer can contain multiple temporal sublayers, and all version 1 bitstreams are limited to a single layer. HEVC has certain layered extensions for scalability and multi-view, and these extensions will allow multiple layers with a backward-compatible version 1 base layer.

[0095] Figure 2 The data communication system in which one or more embodiments of the present invention may be implemented is illustrated. 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, b, or g), an Ethernet network, an Internet network, or a hybrid network consisting of several different networks. In a specific embodiment of the present invention, the data communication system may be a digital television broadcast system in which the server 201 transmits the same data content to multiple clients.

[0096] The data stream 204 provided by the server 201 may be composed of multimedia data representing video and audio data. In some embodiments of the present invention, the audio and video data streams may 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 received by the server 201 from other data providers, or generated at the server 201. The server 201 is provided with an encoder for encoding the video and audio streams, in particular for providing a compressed bit stream for transmission, which is a more compact representation of the data presented as input to the encoder.

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

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

[0099] Despite Figure 2 A streaming scenario is considered in the examples of FIG, but it will be appreciated that in some embodiments of the invention, data communication between the encoder and decoder may be performed using, for example, a media storage device such as an optical disc.

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

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

[0102] - a central processing unit 311 denoted as CPU, such as a microprocessor;

[0103] - a read-only memory 306 denoted as ROM, for storing the computer program implementing the invention;

[0104] a random access memory 312, represented as a RAM, for storing executable codes of the method according to an embodiment of the present invention, and registers suitable for recording variables and parameters required for implementing the method for encoding a digital image sequence and / or the method for decoding a bit stream according to an embodiment of the present invention; and

[0105] A communication interface 302 connected to a communication network 303, via which digital data to be processed are transmitted or received.

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

[0107] - a data storage component 304, such as a hard disk, for storing a computer program for implementing the method of one or more embodiments of the present invention and data used or generated during the implementation of one or more embodiments of the present invention;

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

[0109] - A screen 309 for displaying data and / or serving as a graphical interface for interaction with the user by means of a keyboard 310 or any other pointing means.

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

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

[0112] The disk 306 may be replaced by any information medium, such as a rewritable or non-rewritable compact disk (CD-ROM), a ZIP disk or a memory card, and in general by an information storage element that can be read by a microcomputer or a microprocessor, the disk 306 being integrated into the device or not, possibly removable and suitable for storing one or more programs whose execution enables the implementation of the method for encoding a digital image sequence and / or the method for decoding a bit stream according to the invention.

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

[0114] The central processing unit 311 is adapted to control and direct the execution of instructions or portions of software code for executing one or more programs according to the present invention, instructions stored in one of the aforementioned storage means. Upon power-up, one or more programs stored in non-volatile memory (e.g., on the hard disk 304 or in the read-only memory 306) are transferred to the random access memory 312 (which then contains the executable code of the one or more programs) and registers for storing variables and parameters necessary for the implementation of the present invention.

[0115] In this embodiment, the device is a programmable device that implements the invention using software. Alternatively, however, the invention may be implemented in hardware (for example in the form of an application specific integrated circuit or ASIC).

[0116] Figure 4 A block diagram illustrating an encoder according to at least one embodiment of the present invention. The encoder is represented by connected modules, each module being adapted to implement at least one corresponding step of at least one embodiment of a method for encoding an image of a sequence of images according to one or more embodiments of the present invention, e.g., in the form of programming instructions executed by a CPU 311 of an apparatus 300.

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

[0118] After implementing the encoding process, the encoder 400 outputs a bitstream 410. The bitstream 410 includes a plurality of coding units or slices, each slice including a slice header for transmitting encoded values ​​of encoding parameters used for slice encoding, and a slice body including encoded video data.

[0119] Module 402 inputs digital images i0 to i n 401 is divided into pixel blocks. A block corresponds to an image portion and can have a variable size (e.g., 4×4, 8×8, 16×16, 32×32, 64×64, 128×128 pixels, and several rectangular block sizes are also considered). A coding mode is selected for each input block. Two families of coding modes are provided: coding modes based on spatial prediction coding (intra-frame prediction) and coding modes based on temporal prediction (inter-frame coding, merge, skip). Possible coding modes are tested.

[0120] Module 403 implements an intra-frame prediction process in which a given block to be coded is predicted by a predictor calculated from its neighboring pixels. If intra-frame coding is selected, the selected intra-frame predictor and an indication of the difference between the given block and its predictor are encoded to provide a residual.

[0121] Temporal prediction is implemented by the motion estimation module 404 and the motion compensation module 405. First, a reference image is selected from the reference image set 416, and the motion estimation module 404 selects a portion of the reference image (also called a reference region or image portion) that is closest to the given block to be encoded. The motion compensation module 405 then uses the selected region to predict the block to be encoded. The motion compensation module 405 calculates the difference between the selected reference region and the given block (also called the residual block). The selected reference region is indicated by a motion vector.

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

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

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

[0125] The encoder 400 further includes 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 DCT) is applied to the residual block by a transform module 407, and the resulting transformed data is then quantized by a quantization module 408 and entropy encoded by an entropy coding module 409. Finally, the encoded residual block of the current block being encoded is inserted into a bitstream 410.

[0126] The encoder 400 also decodes the encoded image to generate a reference image for 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 an inverse transform by the inverse transform module 412. The inverse intra prediction module 413 uses the prediction information to determine which predictor to use for a given block, and the inverse motion compensation module 414 actually adds the residual obtained by module 412 to the reference region obtained from the reference image set 416.

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

[0128] Figure 5 A block diagram of a decoder 60 according to an embodiment of the present invention is shown, which can be used to receive data from an encoder. The decoder is represented by connected modules, each module being adapted to implement the corresponding steps of the method implemented by the decoder 60, for example in the form of programming instructions to be executed by the CPU 311 of the device 300.

[0129] The decoder 60 receives a bitstream 61 comprising coding units, each consisting of a header containing information about the coded parameters and a body containing the coded video data. Figure 6 The structure of the bitstream in VVC is described in more detail. Figure 4 As illustrated, for a given block, the coded video data is entropy coded on a predetermined number of bits and the index of the motion vector predictor is encoded. The received coded video data is entropy decoded by module 62. The residual data is then dequantized by module 63, after which an inverse transform is applied by module 64 to obtain pixel values.

[0130] Mode data indicating an encoding mode is also entropy-decoded, and based on the mode, an encoding block of image data is subjected to intra-type decoding or inter-type decoding.

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

[0132] 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 the motion vector by the motion vector decoding module 70.

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

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

[0135] Figure 6 The organization of the bitstream in the exemplary coding system VVC as described in JVET_P2001-VE is shown.

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

[0137] NAL units are divided into video coding layer (VCL) NAL units and non-VCL NAL units. VCL NAL units contain the actual coded video data. Non-VCL NAL units contain additional information. This additional information can be parameters required to decode the coded video data or supplementary data that can enhance the usability of the decoded video data. NAL units 606 correspond to slices and constitute the VCL NAL units of the bitstream.

[0138] Different NAL units 601-605 correspond to different parameter sets, which are non-VCL NAL units. The decoder parameter set (DPS) NAL unit 301 contains parameters that are constant for a given decoding process. The video parameter set (VPS) NAL unit 602 contains parameters defined for the entire video and therefore the entire bitstream. The DPS NAL unit can define parameters that are more static than those in the VPS. In other words, the parameters of the DPS change less frequently than those of the VPS.

[0139] The sequence parameter set (SPS) NAL unit 603 contains parameters defined for a video sequence. Specifically, the SPS NAL unit may define the sub-picture layout and associated parameters of the video sequence. Parameters associated with each sub-picture specify the coding constraints applied to the sub-picture. Specifically, a flag is included to indicate that temporal prediction between sub-pictures is restricted to data from the same sub-picture. Another flag may enable or disable loop filters across sub-picture boundaries.

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

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

[0142] The PPS contains syntax elements that allow the location of slices within a frame to be determined. Since a sub-picture forms a rectangular area within a frame, the set of slices, tile portions, or tiles belonging to a sub-picture can be determined from the parameter set NAL unit. The PPS, as an APS, has an ID mechanism to limit the number of identical PPSs sent.

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

[0144] The bitstream may also contain Supplemental Enhancement Information (SEI) NAL units ( Figure 6 (Not shown in the image). The periodicity of these parameter sets in the bitstream is variable. A VPS defined for the entire bitstream may appear only once in the bitstream. Conversely, an APS defined for a slice may appear once for each slice in each picture. In practice, different slices may rely on the same APS, and therefore there are typically fewer APSs than slices in each picture. Specifically, the APS is defined in the picture header. However, the ALF APS can be refined in the slice header.

[0145] The Access Unit Delimiter (AUD) NAL unit 607 separates two access units. An access unit is a collection of NAL units that may include one or more coded pictures with the same decoding timestamp. This optional NAL unit contains only one syntax element from the current VVC specification: pic_type, which indicates that the slice_type value is used for all slices of the coded pictures in the AU. If pic_type is set to 0, the AU contains only intra slices. If it is 1, it contains P and I slices. If it is 2, it contains B, P, or intra slices, as shown in Table 1 below.

[0146] Table 1 Explanation of pic_type

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

[0148] Image header

[0149] The PH NAL unit 608 is a picture header NAL unit that groups common parameters for a set of slices of one coded picture.A picture may refer to one or more APSs to indicate the AFL parameters, shaper models, and scaling matrices used by the slices of the picture.

[0150] Each VCL NAL unit 606 contains a slice. A slice can correspond to an entire picture or a sub-picture, a single block, or multiple blocks or a fragment of a block. For example, Figure 6 A slice comprises a number of blocks 620 . A slice consists of a slice header 610 and a raw byte sequence payload RBSP 611 , which contains coded pixel data encoded as coded blocks 640 .

[0151] A picture header is sent at the beginning of each picture. The relevant syntax elements that can be decoded are:

[0152] ●Whether to use the image or reference frame

[0153] Output frame

[0154] ●Use of sub-images (if necessary)

[0155] ● Reference image list (if needed)

[0156] Color plane (if needed)

[0157] Partition update (if overwrite flag is enabled)

[0158] Incremental QP parameters (if needed)

[0159] Motion information parameters (if necessary)

[0160] ALF parameters (if needed)

[0161] SAO parameters (if needed)

[0162] Quantization parameters (if needed)

[0163] LMCS parameters (if required)

[0164] Scale list parameters (if needed)

[0165] Image header expansion (if necessary)

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

[0167] This structure of the picture header provides flexibility in providing all the tools that may be needed for a particular image. Thus, the structure essentially defines the "worst-case" decoding scenario for the picture, which is often a key consideration for hardware decoders. However, there is significant redundancy in this structure, which results in an increase in bit rate.

[0168] The problem addressed by the present invention relates to parameter sets in the picture header related to specific coding modes. For certain parameter sets, a set of syntax elements is sent for both inter and intra slices. This increases the rate when all slices in a picture are of the same type.

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

[0170] Table 2 Part of the picture header

[0171]

[0172]

[0173] In some cases, the three specific parameter sets in the above header may be redundant. Let's consider these three sets in turn.

[0174] The first parameter set is related to partitioning. The following is only useful for inter slices:

[0175] ·pic_log2_diff_min_qt_min_cb_inter_slice

[0176] ·pic_max_mtt_hierarchy_depth_inter_slice

[0177] ·pic_log2_diff_max_bt_min_qt_inter_slice

[0178] ●pic_log2_diff_max_tt_min_qt_inter_slice

[0179] And the following is for intra slices only:

[0180] ●pic_log2_diff_min_qt_min_cb_intra_slice_luma

[0181] ●pic_max_mtt_hierarchy_depth_intra_slice_luma

[0182] ·pic_log2_diff_max_bt_min_qt_intra_slice_luma

[0183] ●pic_log2_diff_max_tt_min_qt_intra_slice_luma

[0184] ·pic_log2_diff_min_qt_min_cb_intra_slice_chroma

[0185] ·pic_max_mtt_hierarchy_depth_intra_slice_chroma

[0186] ●pic_log2_diff_max_bt_min_qt_intra_slice_chroma

[0187] ·pic_log2_diff_max_tt_min_qt_intra_slice_chroma

[0188] These parameters are equivalent to those for inter picture descriptions, for intra and chroma, respectively.

[0189] As defined in Table 2, the chroma parameters are enabled only if the flag qtbtt_dual_tree_intra_flag (SPS level) is set equal to 1.

[0190] As depicted in Table 2, these partition parameters (inter, intra, and chroma) are updated only if partition_constraints_override_enabled_flag is enabled and partition_constraints_override_flag is set equal to 1 in the picture header.

[0191] The flag partition_constraints_override_enabled_flag is sent in the SPS.

[0192] The second parameter set involves incremental QP parameters. The following two parameters are required only for inter slices:

[0193] ·pic_cu_qp_delta_subdiv_inter_slice

[0194] ·pic_cu_chroma_qp_offset_subdiv_inter_slice

[0195] and the following two for intra slices:

[0196] ·pic_cu_qp_delta_subdiv_intra_slice

[0197] ·pic_cu_chroma_qp_offset_subdiv_intra_slice

[0198] pic_cu_qp_delta_subdiv_inter_slice and pic_cu_qp_delta_subdiv_intra_slice are sent only if cu_qp_delta_enabled_flag of the PPS is set equal to 1.

[0199] In the same way, pic_cu_chroma_qp_offset_subdiv_intra_slice and pic_cu_chroma_qp_offset_subdiv_intra_slice are decoded only if pps_cu_chroma_qp_offset_list_enabled_flag is enabled in the PPS.

[0200] The third parameter set concerns motion parameters, and they are used only in inter slices:

[0201] ●pic_temporal_mvp_enabled_flag

[0202] mvd_l1_zero_flag

[0203] ·pic_six_minus_max_num_merge_cand

[0204] ●pic_five_minus_max_num_subblock_merge_cand

[0205] pic_fpel_mmvd_enabled_flag

[0206] pic_disable_bdof_flag

[0207] pic_disable_dmvr_flag

[0208] pic_disable_prof_flag

[0209] ·pic_max_num_merge_cand_minus_max_num_triangle_cand

[0210] Each of these parameters may be decoded (or not) based on an "enable flag" or "overwrite flag" signaled at the SPS or PPS header. However, each of these parameters is always sent, which helps increase the bit rate.

[0211] This rate increase is particularly noticeable when the coded picture uses only one type of slice (inter or intra), since several parameters are defined but never used.

[0212] The first way to improve this problem is to signal the coding type in the picture header and only decode the syntax elements related to that coding type. Most pictures have a single coding type (e.g., inter or intra), so this represents an effective way to reduce the bit rate as unnecessary syntax elements.

[0213] The image type indicated in the image header

[0214] In one example of the general concept, the picture type syntax element "picture_type_pic_header" is sent at the beginning of the picture header.

[0215] The image type can be defined as follows:

[0216] • When picture type is set equal to 1 (or 0), all slices of the picture have the same slice type, intra.

[0217] • When the picture type is set equal to P (or 1), all slices of the picture have the same slice type, inter-P (unidirectional prediction).

[0218] • When the picture type is set equal to B (or 2), all slices of the picture have the same slice type, inter-B (bi-directional prediction).

[0219] Therefore, a decoder receiving a picture header specifying picture_type_pic_header initially determines the coding mode corresponding to the picture type and decodes only syntax elements related to that coding mode (or ignores syntax elements related only to a different coding mode).

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

[0221] Table 3 below shows an example modification to the picture header that indicates one way to implement this conditional decoding; notable changes are underlined. It should be noted that this table represents a partial header and has been reordered for clarity and conciseness. A larger header, perhaps in a different order, may be more appropriate in practice.

[0222] Table 3 - Picture header with conditional decoding

[0223]

[0224]

[0225]

[0226] "Conditional" refers to the encoding type and allows conditional decoding of certain syntax elements, where elements that do not need to be decoded are skipped. This improves decoding performance.

[0227] An example of a condition is:

[0228] Condition 1: picture_type_pic_header==P or picture_type_pic_header==B

[0229] Condition 2: picture_type_pic_header==I

[0230] Condition 3: picture_type_pic_header==B

[0231] When condition 1 is false, all slices are intra and the following syntax elements are not decoded:

[0232] ·pic_max_mtt_hierarchy_depth_inter_slice

[0233] ●pic_log2_diff_max_bt_min_qt_inter_slice

[0234] ·pic_log2_diff_max_tt_min_qt_inter_slice

[0235] ·pic_cu_qp_delta_subdiv_inter_slice

[0236] ●pic_cu_chroma_qp_offset_subdiv_inter_slice

[0237] ·pic_temporal_mvp_enabled_flag

[0238] mvd_l1_zero_flag

[0239] ·pic_six_minus_max_num_merge_cand

[0240] ·pic_five_minus_max_num_subblock_merge_cand

[0241] pic_fpel_mmvd_enabled_flag

[0242] pic_disable_bdof_flag

[0243] pic_disable_dmvr_flag

[0244] pic_disable_prof_flag

[0245] ·pic_max_num_merge_cand_minus_max_num_triangle_cand

[0246] When condition 2 is false, all slices are inter and the following syntax elements are not decoded:

[0247] ●pic_log2_diff_min_qt_min_cb_intra_slice_luma

[0248] ·pic_max_mtt_hierarchy_depth_intra_slice_luma

[0249] ·pic_log2_diff_max_bt_min_qt_intra_slice_luma

[0250] ·pic_log2_diff_max_tt_min_qt_intra_slice_luma

[0251] ·pic_log2_diff_min_qt_min_cb_intra_slice_chroma

[0252] ·pic_max_mtt_hierarchy_depth_intra_slice_chroma

[0253] ●pic_log2_diff_max_bt_min_qt_intra_slice_chroma

[0254] ·pic_log2_diff_max_tt_min_qt_intra_slice_chroma

[0255] ·pic_cu_qp_delta_subdiv_intra_slice

[0256] ·pic_cu_chroma_qp_offset_subdiv_intra_slice

[0257] When condition 3 is false, all slices are not B pictures and the following syntax elements are not decoded:

[0258] mvd_l1_zero_flag

[0259] pic_disable_bdof_flag

[0260] pic_disable_dmvr_flag

[0261] ·pic_max_num_merge_cand_minus_max_num_triangle_cand

[0262] Thus, only specific syntax elements of an I, P or B picture are decoded from the picture header, thus reducing the rate of the individual pictures.

[0263] Enable / disable syntax elements in the stripe header

[0264] In one example, picture_type_pic_header is used to enable or disable some unneeded syntax elements. This is shown in the modified picture header in Table 4.

[0265] In this table, slice_type is never sent. 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 is never sent for intra slices. In the same way, the num_ref_idx_active_minus1[i] table is not decoded for pictures containing intra slices.

[0266] Both parameters num_ref_idx_active_override_flag and num_ref_idx_active_minus1[i] are related to the number of reference frames. If the parameter num_ref_idx_active_minus1[i] indicating the number of reference frames needs to be decoded, num_ref_idx_active_override_flag is signaled.

[0267] Similarly, when a picture contains intra slices, cabac_init_flag is not decoded. This parameter is related to initializing the CABAC context.

[0268] When a picture contains intra slices, collocated_from_l0_flag, collocated_ref_idx are not decoded. These parameters are related to the selection of collocated reference frames for the temporal motion predictor.

[0269] Finally, when a picture contains intra slices, pred_weight_table() is not decoded.

[0270] An advantage of this embodiment is that it saves the rate associated with this type of stripe transmission compared to current designs.

[0271] Table 4 - Modified slice header with pic_type_pic_header

[0272]

[0273]

[0274]

[0275] In a particularly advantageous example, the above features can be combined. In this case, picture_type_pic_header is used to enable and disable some syntax elements not required in the picture header, and slice_type is not specified in the slice header and is replaced by picture_type_pic_head to decode or not decode some syntax elements in the slice header.

[0276] Strip type constraints in image headers

[0277] This feature represents a modification of the above example, where instead of picture_type_pic_header, a syntax element "pic_slice_type_constraint" is sent at the beginning of the picture header. This syntax element indicates the constraints on the coding mode used in each slice within the picture. This differs from picture_type_pic_header in that it does not necessarily require all slices to be the same and allows a wider range of values.

[0278] Example values ​​and corresponding definitions for pic_slice_type_constraint are as follows:

[0279] A value of 0 indicates that all slices of the picture are intra.

[0280] A value of 1 indicates that all slices of the picture are inter

[0281] Equal to 2 indicates that the slices of the picture can be of different types

[0282] Two additional definitions can be added:

[0283] Equal to 3 indicates that all slices of the picture are inter B

[0284] Equal to 4 indicates that all slices of the picture are inter-frame P

[0285] In an alternative example, the pic_slice_type_constraint definition is defined as follows:

[0286] Equal to 0 indicates that all slices of the picture are inter B

[0287] =1 indicates that all slices of the picture are inter-frame

[0288] Equal to 2 indicates that all slices of the picture are intra

[0289] Equal to 3 indicates that the slices of the picture can be of different types

[0290] Equal to 4 indicates that all slices of the picture are inter

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

[0292] Other characteristics of pic_slice_type_constraint that could be incorporated into the above list include:

[0293] -The picture is an Instantaneous Decoder Refresh (IDR) picture

[0294] -The image is a Clean Random Access (CRA) image

[0295] -The image is a Gradual Decoding Refresh (GDR) image

[0296] -The picture is a non-intra random access point (non-IRAP), non-GDR picture, and contains only I slices

[0297] - The picture is a non-IRAP, non-GDR picture and may contain only P slices and I slices

[0298] - The picture is a non-IRAP, non-GDR picture and contains any of B slices, P slices and / or I slices

[0299] This value can be used for streaming applications where IRAP and GDR pictures are more relevant. In fact, these pictures provide intra-frame random access points, which can be used for example to change the first picture of a sequence or synchronize streams for real-time applications.

[0300] In practice, streaming applications are more likely to require at least one intra slice to "refresh" the stream in case of network packet loss. In a simple implementation, this can be done at the picture-wide level to avoid pictures having mixed coding types.

[0301] This example provides the same rate reduction as the previous embodiment, but allows for more flexibility at the decoder by allowing differently coded slices in the same picture directly via the picture header.

[0302] For the example above about pic_type_pic_header, pic_slice_type_constraint is used to enable and disable some unnecessary syntax elements. This corresponds to setting conditions 1, 2 and 3 of Table 3 as follows:

[0303] Condition 1: pic_slice_type_constraint! = 0

[0304] Condition 2: pic_slice_type_constraint==0 or pic_slice_type_constraint==2

[0305] Condition 3: pic_slice_type_constraint==3 or pic_slice_type_constraint==2

[0306] As an additional feature providing additional improvement, the slice type of the slice header can be inferred and / or decoded with fewer bits than current designs.

[0307] As depicted in Table 5, slice_type is decoded only when pic_slice_type_constraint is set to 2. In this case, slice_type can have one of three values: I, P, and B. When pic_slice_type_constraint is set to 1, slice_type is partially decoded. In practice, due to pic_slice_type_constraint, it is guaranteed that the slice is inter (P or B), so only one bit needs to be decoded to know whether slice_type is P or B.

[0308] When pic_slice_type_constraint is set equal to 0, slice_type is determined to be equal to 1. When pic_slice_type_constraint is set equal to 0, slice_type is determined to be equal to B. Otherwise, it is set equal to P.

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

[0310] The advantage of this feature is that the rate of slice_type can be reduced when all slices of a frame are intra or all slices are inter.

[0311] Table 5 - Modified slice header with pic_slice_type_constraint

[0312]

[0313]

[0314] In one further modification, 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 of the slice header is inferred completely or partially based on the pic_slice_type_constraint value.

[0315] The picture type "pic_type" of the AU delimiter NAL unit may be set according to the value of pic_slice_type_constraint. Thus, when pic_type is set equal to 1, all pic_slice_type_constraints of the layer are set equal to 0. When pic_type is set equal to 2 (P, I), all pic_slice_type_constraints of the layer may be equal to 0 or 3. Otherwise, all pic_slice_type_constraints of the layer may take any value (e.g., one of the five values ​​discussed above).

[0316] Modifications to AU NAL

[0317] When using the features described above, the syntax element "pic_type" of the AU delimiter NAL unit does not need to be decoded when the stream contains only one layer, or its decoding is optional depending on the flag sent in the VPS or SPS. In fact, in this case, sending this syntax element is redundant because similar information exists in the picture header.

[0318] This feature helps in rate reduction.

[0319] Optionally, the AU delimiter NAL unit is not decoded when the stream contains only one layer and is inferred based on information in the picture header. In fact, in this case, the information contained in the AU delimiter is not needed because it is redundant with the syntax elements of the picture header. This feature further contributes to rate reduction.

[0320] AU NAL pic_type used to set the syntax element set for decoding

[0321] In a 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 constraints are set in the picture header. However, the conditions "Condition 1, Condition 2, Condition 3" depicted in Table 3 are determined based on the pic_type of the AU NAL unit (when signaled). Therefore, the decoding of the picture header is conditional 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.

[0322] In this example, "conditional" relates to the encoding type of pic_type and allows conditional decoding of certain syntax elements as defined in the previous embodiment, where the elements do not need to skip decoding. This improves decoding performance.

[0323] An example of a condition is:

[0324] Condition 1: pic_type == 1 or pic_type == 2

[0325] Condition 2: pic_type == 0

[0326] Condition 3: pic_type == 2

[0327] When the pic_type of the AU NAL unit is not signaled, the pic_type of the AU NAL unit is inferred to be equal to 2.

[0328] Merged syntactic elements

[0329] Similar syntax elements used in both inter and intra modes can be merged to reduce redundancy of elements in the picture header and / or reduce the number of conditions that need to be verified before decoding. In one example, the picture header contains only syntax elements that are agnostic to the coding mode to be used. That is, the same syntax elements can be used for both inter and intra frames. This is possible because most pictures only contain slices that require one type of coding mode (inter or intra), and therefore do not require two sets of syntax elements.

[0330] Therefore, merging intra and inter syntax elements 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 coding choices can be adjusted to compensate for the impact on intra slices.

[0331] Syntactic elements that differ only by their "encoding type" tag are particularly suitable for merging.

[0332] When following the same design as discussed above, the following syntax elements may be incorporated as shown in Table 6 below:

[0333] Table 6 - Merged Syntax Elements

[0334]

[0335] Table 7 gives an example of this simplification of the picture header syntax table.

[0336] Table 7 Picture header with merged syntax elements

[0337]

[0338]

[0339] Common values ​​of syntactic elements

[0340] In one alternative, each pair of parameters still exists and the common value is decoded in the picture header, and when the slice is intra (as defined in the slice header), the value for the intra slice is set equal to the common value, and when the slice is inter, the value for the inter slice is set equal to the common value.

[0341] In an additional example, there is at least one flag at the upper level (PPS, SPS) that indicates whether the intra slices and / or inter slices use a common value or retain the value given at the upper value (SPS, PPS). This allows for increased flexibility.

[0342] In an additional example, intra values ​​may be updated at the slice level according to a variable in the slice header.

[0343] For example, the parameters in the slice header for an intra-frame are:

[0344] ·slice_log2_diff_min_qt_min_cb_intra_slice_luma

[0345] ·slice_max_mtt_hierarchy_depth_intra_slice_luma

[0346] ·slice_log2_diff_max_bt_min_qt_intra_slice_luma

[0347] ·slice_log2_diff_max_tt_min_qt_intra_slice_luma

[0348] ·slice_log2_diff_min_qt_min_cb_intra_slice_chroma

[0349] ·slice_max_mtt_hierarchy_depth_intra_slice_chroma

[0350] ·slice_log2_diff_max_bt_min_qt_intra_slice_chroma

[0351] ·slice_log2_diff_max_tt_min_qt_intra_slice_chroma

[0352] ·slice_cu_qp_delta_subdiv_intra_slice

[0353] ·slice_cu_chroma_qp_offset_subdiv_intra_slice

[0354] The advantage over the initial example is the increased flexibility. In fact, with this additional feature, you can get the same flexibility as the current design, and get even more flexibility by adjusting these parameters for each strip.

[0355] Override flag at PPS / SPS

[0356] To provide additional flexibility, both intra and inter values ​​may be sent in the slice header. These parameters may be signaled (or not signaled) in the slice header depending on one or more override flags sent in the PPS and / or SPS or picture header to reduce the additional rate required for these syntax elements in the slice header.

[0357] For example, if the parameter pic_log2_diff_min_qt_min_cb_slice is sent in the picture header, the override flag log2_diff_min_qt_min_cb_slice_inter_override_flag is decoded to determine whether the slice_log2_diff_min_qt_min_cb_inter_slice_luma value is updated in the inter slice. When pic_log2_diff_min_qt_min_cb_slice is not decoded, this parameter will not be updated in the inter slice and log2_diff_min_qt_min_cb_slice_inter_override_flag is set equal to 0.

[0358] In a similar manner, an override flag log2_diff_min_qt_min_cb_slice_intra_override_flag may be sent for intra slices.

[0359] Optionally, when parameters are sent in a slice header, the parameter's value is constrained by the value of its equivalent syntax element on the picture header. More precisely, the values ​​are restricted to avoid increased complexity.

[0360] For example, slice_log2_diff_min_qt_min_cb_intra_slice_luma in the slice header is restricted 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 cannot be lower than pic_log2_diff_min_qt_min_cb_slice. The effect of this restriction is that a slice cannot use a smaller block size than the size defined in the picture header.

[0361] The advantage of this example is that the decoder can set its complexity parameter for each picture and then does not need to increase the complexity for each new slice.

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

[0363] It should be understood that the "merging" of syntax elements described above can be combined with other features to reduce the total number of different syntax elements. As an example, in such a combination, the picture header would contain a syntax element that is always decoded that is agnostic to the coding mode (i.e., a "merged syntax element"), an indication of the coding type (e.g., pic_type_pic_header or pic_slice_type_constraint), and then a syntax element that is conditionally decoded based on the coding type.

[0364] Repeat only inter-frame parameters

[0365] In another example, all parameters related only to intra slices are removed from the picture header. Table 8 shows this example. Compared with the current design, the following syntax elements do not exist in the picture header:

[0366] ·pic_log2_diff_min_qt_min_cb_intra_slice_luma

[0367] ·pic_max_mtt_hierarchy_depth_intra_slice_luma

[0368] ·pic_log2_diff_max_bt_min_qt_intra_slice_luma

[0369] ·pic_log2_diff_max_tt_min_qt_intra_slice_luma

[0370] ·pic_log2_diff_min_qt_min_cb_intra_slice_chroma

[0371] ·pic_max_mtt_hierarchy_depth_intra_slice_chroma

[0372] ·pic_log2_diff_max_bt_min_qt_intra_slice_chroma

[0373] ·pic_log2_diff_max_tt_min_qt_intra_slice_chroma

[0374] ·pic_cu_qp_delta_subdiv_intra_slice

[0375] ·pic_cu_chroma_qp_offset_subdiv_intra_slice

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

[0377] Table 8 removes the picture header of the intra-frame syntax

[0378]

[0379]

[0380] Alternatively, when the sequence contains only intra pictures (as signaled in the sequence header or SPS), the above intra parameters are sent in the picture header. The advantage of this embodiment is that the intra parameters can be adjusted for a full intra sequence, where the impact of the adjustment should be more important.

[0381] Similarly, when the sequence contains only intra pictures, no set of inter syntax elements is sent. The advantage is that there is no additional rate associated with unused intra parameters.

[0382] In an additional embodiment, when the slice type is intra, a set of intra syntax elements is sent in the slice header. This embodiment offers greater flexibility compared to the primary embodiment, as intraslices can be adjusted. Furthermore, adjusting intra slices has a lower impact on the rate, as fewer intra slices are sent in the video.

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

[0384] For example, the parameters used in the slice header within a frame are:

[0385] ·slice_log2_diff_min_qt_min_cb_intra_slice_luma

[0386] ·slice_max_mtt_hierarchy_depth_intra_slice_luma

[0387] ·slice_log2_diff_max_bt_min_qt_intra_slice_luma

[0388] ·slice_log2_diff_max_tt_min_qt_intra_slice_luma

[0389] ·slice_log2_diff_min_qt_min_cb_intra_slice_chroma

[0390] ·slice_max_mtt_hierarchy_depth_intra_slice_chroma

[0391] ·slice_log2_diff_max_bt_min_qt_intra_slice_chroma

[0392] ·slice_log2_diff_max_tt_min_qt_intra_slice_chroma

[0393] ·slice_cu_qp_delta_subdiv_intra_slice

[0394] ·slice_cu_chroma_qp_offset_subdiv_intra_slice

[0395] To reduce complexity, when parameters are sent in intra slices, the values ​​of the parameters may be constrained by the values ​​of their equivalent inter syntax elements. More precisely, the values ​​are restricted to avoid an increase in complexity.

[0396] For example, slice_log2_diff_min_qt_min_cb_intra_slice_luma in the slice header is constrained to the value of pic_log2_diff_min_qt_min_cb_inter_slice sent in the picture header. More precisely, the minimum QT size (which gives the minimum block size) value in the current slice cannot be lower than the minimum QT size value defined in the PH. Therefore, slice_log2_diff_min_qt_min_cb_intra_slice_luma cannot be lower than pic_log2_diff_min_qt_min_cb_inter_slice.

[0397] The advantage of this feature is that the decoder can set its complexity parameters for each picture; then, there is no need to increase the complexity for each new slice, since the "worst case" complexity is set in the picture header.

[0398] This constraint may also apply if inter-frame parameters can be sent in the slice header.

[0399] To further reduce the number of coded bits, when a slice syntax element is constrained by its equivalent syntax element inter value in a picture header, its value can be predicted by its equivalent syntax element inter value. For example, the value can be decoded and slice_log2_diff_min_qt_min_cb_intra_slice_luma is equal to this value + pic_log2_diff_min_qt_min_cb_inter_slice.

[0400] To provide additional flexibility, a set of intra syntax elements is sent in the slice header when the slice type is intra and if the override flag signals its use or not. The override flag is signaled at the SPS or PPS level. An additional override flag may be sent in the slice header as well as the current override flag in the picture header for these parameters.

[0401] Intra / inter frame overwrite flag

[0402] Picture header syntax elements defined only for intra or inter slices can be decoded (or not decoded) based on one or more override flags specific to intra and inter. This allows greater flexibility while avoiding decoding unnecessary syntax elements. Table 9 shows this feature.

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

[0404] 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 equal to 1, the following partition syntax elements within the frame are decoded, or they may be decoded according to other constraints:

[0405] ·pic_log2_diff_min_qt_min_cb_intra_slice_luma

[0406] ·pic_max_mtt_hierarchy_depth_intra_slice_luma

[0407] ·pic_log2_diff_max_bt_min_qt_intra_slice_luma

[0408] ·pic_log2_diff_max_tt_min_qt_intra_slice_luma

[0409] ·pic_log2_diff_min_qt_min_cb_intra_slice_chroma

[0410] ·pic_max_mtt_hierarchy_depth_intra_slice_chroma

[0411] ·pic_log2_diff_max_bt_min_qt_intra_slice_chroma

[0412] ·pic_log2_diff_max_tt_min_qt_intra_slice_chroma

[0413] When the override flag is set equal to 0, the default values ​​set in the SPS are used to set these values.

[0414] In the same way, partition_constraints_override_flag_inter is decoded if the relevant override flag is set equal to 1 in the SPS. If this picture header syntax element is true, the partition syntax element for inter is used.

[0415] ·pic_log2_diff_min_qt_min_cb_inter_slice

[0416] ·pic_max_mtt_hierarchy_depth_inter_slice

[0417] ·pic_log2_diff_max_bt_min_qt_inter_slice

[0418] ·pic_log2_diff_max_tt_min_qt_inter_slice

[0419] When the override flag is set equal to 0, the default values ​​set in the SPS are used to set these values.

[0420] In the same way, for the syntax elements related to delta QP, cu_qp_delta_enabled_flag is split into 2 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 they are only sent when no_qp_delta_constraint_flag is equal to 0.

[0421] pps_cu_chroma_qp_offset_list_enabled_flag is split into 2 flags, one for intra frame and one for inter frame: pps_cu_chroma_qp_offset_list_enabled_flag_intra, pps_cu_chroma_qp_offset_list_enabled_flag_inter. These flags are sent in PPS and replace pps_cu_chroma_qp_offset_list_enabled_flag.

[0422] For picture header syntax elements related to motion parameters, the motion_parameters_override_enabled_flag is sent in the SPS. If it is 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. When it is equal to false, these parameters take the value of their corresponding PPS or SPS value. For flags, the value can only be the SPS or PPS value, for example:

[0423] pic_temporal_mvp_enabled_flag=sps_temporal_mvp_enabled_flag

[0424] mvd_l1_zero_flag=! pps_mvd_l1_zero_idc

[0425] pic_fpel_mmvd_enabled_flag=sps_fpel_mmvd_enabled_flag

[0426] pic_disable_bdof_flag=sps_bdof_pic_present_flag

[0427] pic_disable_dmvr_flag=sps_dmvr_pic_present_flag

[0428] pic_disable_prof_flag=sps_prof_pic_present_flag

[0429] In one example, at least a default value may be sent at an SPS or PPS header to a defined one of the default values.

[0430] For non-sign values: the maximum value set in SPS or PPS can be used, for example:

[0431] pic_six_minus_max_num_merge_cand and pic_max_num_merge_cand_minus_max_num_triangle_cand may depend on pps_six_minus_max_num_merge_cand_plus1 and pps_max_num_merge_cand_minus_max_num_triangle_cand_plu, respectively.

[0432] pic_five_minus_max_num_subblock_merge_cand is not defined at SPS level, but the default value can be set by 5-(sps_sbtmvp_enabled_flag&&pic_temporal_mvp_enabled_flag).

[0433] In an embodiment, the SPS and / or PPS values ​​are sent to fix the default values.

[0434] In an additional embodiment, a specific parameter may be sent in the SPS or PPS header to set this value.

[0435] The advantages of using the override flag are the same as discussed above, but provide greater flexibility (at the expense of sending and decoding the flag) since intra-frame parameters may be sent if the specified override flag has been set equal to true.

[0436] Table 9 Picture header with overwrite flag

[0437]

[0438]

[0439]

[0440]

[0441] It should be noted that the position of these new overwrite flags can be modified, for example, the inter-frame flag can be moved above the intra-frame flag. This can be beneficial because more pictures use inter-frame coding, so the flag may be more relevant.

[0442] Similarly, the previous flag partition_constraints_override_flag may be retained and checked to see if the inter or intra flag should also be checked.

[0443] In one embodiment, two overwrite flags are sent before these different syntax elements. One specifies whether the inter-frame element is overwritten or not, and one specifies whether the intra-frame element is overwritten. These overwrite flags can be defined in the same way in the upper layer.

[0444] Compared to the previous example, fewer additional override flags are required.

[0445] Override flags and merged syntax elements

[0446] A particularly interesting combination is the combination of using the override flag (eg, Table 9) and the merged syntax elements (eg, Table 6). Additionally, as described above (eg, Table 8), some parameters may be removed from the picture header.

[0447] For example, syntax elements that can be merged are merged. In this case, the CU delta QP parameters and the partition flags related to intra and inter luma are of particular interest. Otherwise, the chroma partition parameters can be removed as described above, and the motion parameters can be set (or not set) according to one or more override flags. Table 10 shows an example of such a combination:

[0448] Table 10 Image header with feature combination

[0449]

[0450]

[0451]

[0452] It should be understood that the above features can be provided in combination with each other. As with the specific combinations discussed above, doing so can provide specific advantages tailored to a particular implementation; for example, increased flexibility, or specifying a "worst case" example. In other examples, complexity requirements may have a higher priority than (for example) rate reduction, and therefore features may be implemented individually.

[0453] Implementation of the Invention

[0454] Figure 7Systems 191 and 195 according to embodiments of the present invention are shown, comprising at least one of encoder 150 or decoder 100 and communication network 200. According to embodiments, system 195 is configured to process and provide content (e.g., video and audio content for display / output or streaming) to a user, who accesses decoder 100, for example, via a user terminal including decoder 100 or a user interface of a user terminal capable of communicating with decoder 100. Such a user terminal may be a computer, mobile phone, tablet computer, or any other type of device capable of providing / displaying (provided / streamed) content to a user. System 195 obtains / receives bitstream 101 (in the form of a continuous stream or signal (e.g., when displaying / outputting earlier video / audio)) via communication network 200. According to embodiments, system 191 is configured to process content and store processed content, such as video and audio content processed for display / output / streaming at a later time. System 191 obtains / receives content comprising a raw image sequence 151, which is received and processed by encoder 150 (including filtering using a deblocking filter according to the present invention), and encoder 150 generates a bitstream 101 to be transmitted to decoder 100 via communication network 200. Bitstream 101 is then transmitted to decoder 100 in a variety of ways. For example, it can be pre-generated by encoder 150 and stored as data in a storage device in communication network 200 (e.g., on a server or cloud storage device) until a user requests content (i.e., bitstream data) from the storage device, at which point the data is transmitted / streamed from the storage device to decoder 100. System 191 may also include a content providing device for providing / streaming content information (e.g., the title of the content and other metadata / storage location data used to identify, select, and request the content) of the content stored in the storage device to the user (e.g., by transmitting data for a user interface to be displayed on a user terminal), and for receiving and processing user requests for content so that the requested content can be transmitted / streamed from the storage device to the user terminal. Alternatively, the encoder 150 generates the bitstream 101 and transmits / streams it directly to the decoder 100 when the user requests content. The decoder 100 then receives the bitstream 101 (or signal) and filters it using the deblocking filter according to the present invention to obtain / generate a video signal 109 and / or an audio signal, which the user terminal then uses to provide the requested content to the user.

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

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

[0457] The embodiments of the present invention can be implemented by a computer of a system or device that reads and executes computer-executable instructions (e.g., one or more programs) recorded on a storage medium to perform one or more modules / units / functions in the above-described embodiments and / or includes one or more processing units or circuits for performing one or more functions in the above-described embodiments, and can be implemented by a method performed by a computer of the system or device, for example, reading and executing computer-executable instructions from a storage medium to perform one or more functions in the above-described embodiments and / or controlling one or more processing units or circuits to perform one or more functions in the above-described embodiments. The computer may include a network of separate computers or separate processing units to read and execute 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. Tangible storage media are “non-transitory computer-readable storage media” and may include, for example, a hard disk, random access memory (RAM), read-only memory (ROM), a storage device of a distributed computing system, an optical disk (such as a compact disk (CD), a digital versatile disk (DVD), or a Blu-ray disk (BD)). TM ), one or more of a flash memory device, a memory card, etc. At least some steps / functions may also be implemented in hardware by a machine or dedicated components such as an FPGA (“field programmable gate array”) or an ASIC (“application-specific integrated circuit”).

[0458] Figure 813 is a schematic block diagram of a computing device 1300 for implementing one or more embodiments of the present invention. The computing device 1300 may be a device such as a microcomputer, a workstation, or a lightweight portable device. The computing device 1300 includes a communication bus connected to the following: - 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 embodiment of the present invention and registers suitable for recording variables and parameters required to implement the method for encoding or decoding at least a portion of an image according to the embodiment of the present invention, the storage capacity of which may be expanded, for example, by an optional RAM connected to an expansion port; - a read-only memory (ROM) 1303 for storing computer programs for implementing the embodiment of the present invention; - a network interface (NET) 1304, which is typically connected to a communication network through which the 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 group of different network interfaces (e.g., wired and wireless interfaces, or different kinds of wired or wireless interfaces), which are connected to the CPU. Under the control of the software application in 1301, data packets are written to the network interface for transmission or read from the network interface for reception; - a user interface (UI) 1305, which can be used to receive input from the user or display information to the user; - a hard disk (HD) 1306, which can be configured as a mass storage device; - an input / output module (IO) 1307, which can be used to receive and send data from / to external devices (such as a video source or display). Executable code can be stored in ROM 1303, on HD 1306, or on removable digital media such as a disk. According to a variation, the executable code of the program can be received via NET 1304 via a communication network and stored in one of the storage components of communication device 1300 (such as HD 1306) before being executed. CPU 1301 is suitable for controlling and directing the execution of instructions or portions of the software code of one or more programs according to embodiments of the present invention, which instructions are stored in one of the aforementioned storage components. For example, after power-up, CPU 1301 is capable of executing those instructions relating to a software application from main RAM memory 1302 after loading instructions from program ROM 1303 or HD 1306. Such a software application, when executed by CPU 1301, causes the steps of the method according to the invention to be performed.

[0459] It will also be appreciated that, according to other embodiments of the present invention, a decoder according to the above-described embodiments is provided in a user terminal such as a computer, a mobile phone (cellular phone), a tablet, or any other type of apparatus capable of providing / displaying content to a user (e.g., a display device). According to yet another embodiment, an encoder according to the above-described embodiments is provided in an image capture device that also includes a camera, a video camera, or a webcam (e.g., a closed-circuit television or video surveillance camera) for capturing and providing content for encoding by the encoder. See below. Figure 9 and 10 Two such examples are provided.

[0460] Web camera

[0461] Figure 9 21 is a diagram illustrating a network camera system 2100 including a network camera 2102 and a client device 2104 .

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

[0463] The network camera 2102 and the client device 2104 are connected to each other via the network 200 so as to be able to communicate with each other.

[0464] The camera unit 2106 includes a lens and an image sensor (eg, a charge coupled device (CCD) or a complementary metal oxide semiconductor (CMOS)), and captures an image of a subject and generates image data based on the image. The image may be a still image or a video image.

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

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

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

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

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

[0470] The communication unit 2114 of the client device 2104 transmits a command to the network camera 2102 .

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

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

[0473] The control unit 2118 of the client device 2104 controls other units in the client device 2104 according to user operations or commands received by the communication unit 2114 .

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

[0475] The control unit 2118 of the client device 2104 also controls the display device 2120 to display a GUI (Graphical User Interface) for specifying values ​​of parameters of the network camera 2102 (including parameters for encoding by the encoding unit 2108 ).

[0476] The control unit 2119 of the client device 2104 also controls other units in the client device 2104 according to user operation input to the GUI displayed by the display device 2120 .

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

[0478] smartphone

[0479] Figure 10 2 is a diagram illustrating a smartphone 2200 .

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

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

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

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

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

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

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

[0487] It should also be understood that any results of the above-described comparisons, determinations, evaluations, selections, performance, performance, or considerations (e.g., selections made during an encoding or filtering process) may be indicated in data in the bitstream (e.g., a flag or data indicating the results) or may be determined / inferred from data in the bitstream, such that the indicated or determined / inferred results may be used in processing rather than actually being compared, determined, evaluated, selected, performed, performed, or considered, for example, during a decoding process.

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

[0489] 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. A method for decoding a picture from a bitstream, wherein: The picture includes one or more slices, and wherein the bitstream includes a picture header and an adaptation parameter set, the method comprising: The first syntax element related to partitions and to be used for intra slices is decoded from the picture header if: (a) the partition constraint override flag associated with the partition in the picture header has a value of 1, and (b) a predetermined syntax element in the picture header has a value of 0 and indicates that all slices in the picture have an intra coding type; and decoding the one or more slices using the decoded first syntax element, wherein each of the one or more stripes can include a block having a size of 64×64, wherein, according to the value of the partition constraint override flag and the value of the predetermined syntax element, a second syntax element related to partitions and to be used for inter-frame slices can be decoded from the picture header, wherein, even if the value of the partition constraint override flag is 1, if the predetermined syntax element in the picture header has a value of 0 and indicates that all slices in the picture have the intra coding type, the second syntax element is not decoded from the picture header, and The adaptation parameter set can be located after the picture header in the bitstream and can include information related to the adaptive loop filter.

2. The method according to claim 1, wherein The inter slice is one of a B slice and a P slice.

3. The method according to claim 1 or 2, wherein: In case the partition constraint override flag has a value of 1, the partition constraint override flag in the picture header indicates that parameters related to partitions are present in the picture header.

4. The method according to any one of claims 1 to 3, wherein The bitstream also includes a slice header, wherein, according to the value of the predetermined syntax element, information corresponding to the encoding type of the slice can be decoded from the slice header, and Wherein, in a case where the predetermined syntax element in the picture header indicates that all slices in the picture have the intra coding type, the information is not decoded from the slice header.

5. The method according to any one of claims 1 to 4, wherein The predetermined syntax element has a given integer value different from 0 and indicates that one or more than one slices in the picture can have an inter coding type.

6. A method of encoding a picture into a bitstream, wherein: The picture includes one or more slices, and wherein the bitstream includes a picture header and an adaptation parameter set, the method comprising: The first syntax element related to partitioning and to be used for intra slices is coded into the picture header if: (a) the partition constraint override flag associated with the partition in the picture header has a value of 1, and (b) a predetermined syntax element in the picture header has a value of 0 and indicates that all slices in the picture have an intra coding type; and encoding the one or more slices, wherein each of the one or more stripes can include a block having a size of 64×64, According to the value of the partition constraint override flag and the value of the predetermined syntax element, a second syntax element related to the partition and to be used for the inter-frame slice can be encoded into the picture header, wherein, even if the value of the partition constraint override flag is 1, if the predetermined syntax element in the picture header has a value of 0 and indicates that all slices in the picture have the intra coding type, the second syntax element is not encoded into the picture header, and The adaptation parameter set can be located after the picture header in the bitstream and can include information related to the adaptive loop filter.

7. The method according to claim 6, wherein: The inter-frame slice is a B slice or a P slice.

8. The method according to claim 6 or 7, wherein: In case the partition constraint override flag has a value of 1, the partition constraint override flag in the picture header indicates that parameters related to partitions are present in the picture header.

9. The method according to any one of claims 6 to 8, in, The bitstream also includes a slice header, According to the value of the predetermined syntax element, information corresponding to the encoding type of the slice can be encoded into the slice header, and Wherein, in a case where the predetermined syntax element in the picture header indicates that all slices in the picture have the intra coding type, the information is not encoded into the slice header.

10. The method according to any one of claims 6 to 9, wherein The predetermined syntax element has a given integer value different from 0 and indicates that one or more than one slices in the picture can have an inter coding type.

11. A decoder adapted to decode a bit stream by performing the method according to any one of claims 1 to 5.

12. An encoder adapted to encode a bit stream by performing the method according to any one of claims 6 to 10.

13. A computer program product comprising a program which, when executed by a computer or a processor, causes the computer or the processor to perform the method according to any one of claims 1 to 10. 14 . A computer-readable medium storing a program which, when executed by a computer or a processor, causes the computer or the processor to perform the method according to claim 1 .

Images