Advanced Syntax for Video Coding and Decoding

Abstract

A method for decoding video data from a bitstream is disclosed. The bitstream includes video data corresponding to a plurality of slices, wherein the video bitstream includes a picture header. The method includes: determining an encoding mode for at least one slice; determining a set of syntax elements to be used for the encoding mode from the picture header; and decoding the at least one slice using the determined syntax elements. A corresponding encoding method, apparatus, and computer program are also disclosed.

Description

Technical Field

[0001] The present invention relates to video encoding and decoding, and more particularly to advanced syntax for video encoding and decoding. Background Art

[0002] Recently, the Joint Video Exploration Team (JVET) (a collaborative team consisting of MPEG and ITU-T Study Group 16 VCEG) has started to study a new video coding standard called Versatile Video Coding (VVC). The goal of VVC is to provide a significant improvement in compression performance (i.e., typically double that of the previous) over the existing HEVC standard and to be completed in 2020. The main target applications and services include but are not limited to 360-degree and high dynamic range (HDR) video. In summary, JVET used formal subjective tests conducted by independent test laboratories to evaluate feedback from 32 organizations. Some of the suggestions indicate that the compression efficiency is generally improved by 40% or more when compared to using HEVC. Specific effects were shown on ultra-high definition (UHD) video test materials. Therefore, for the final standard, we can expect the improvement in compression efficiency to far exceed the targeted 50%.

[0003] The JVET Exploration Model (JEM) uses all HEVC tools and has introduced several new tools. These changes require a change in the structure of the bitstream, especially the advanced syntax that may affect the total bit rate of the bitstream.

[0004] An important change in the advanced syntax is the introduction of a "picture header" into the bitstream. The picture header is a header for specifying the syntax elements to be used when decoding each slice in a particular picture (or frame). Therefore, the picture header is placed in the bitstream before the data related to the slices, and each slice has its own "slice header". This structure is described in more detail below with reference to Figure 6 Describe this structure in more detail.

[0005] The document JVET-P0239, titled "AHG 17: PictureHeader" at the 16th meeting (1 - 11 October 2019, Geneva, Switzerland), proposed the introduction of a mandatory picture header into VVC, and this was adopted as the Common Video Coding (Draft 7) and uploaded as the file 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 transmission bit rate (especially for low bit rate instances).

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

[0007] Broadly, the inventors have recognized that the flexibility built into recently adopted advanced syntax is only rarely used, thus unnecessarily increasing the bit rate. In particular, most pictures only include strips using one strip coding mode (e.g., inter-frame or intra-frame), while the advanced syntax allows different types of strips in each picture. The present invention relates to taking advantage of the fact that most images only use one type of coded strip, and thus the bit rate can be reduced.

[0008] An optional feature of reintroducing the flexibility of multiple coding types within a single picture is also contemplated. Specific syntax elements and / or additional constraints on syntax elements are added to reduce the bit rate compared to recently adopted advanced syntax. These "added" features may increase the bit rate, but since they are rarely used, the average bit rate of a given video sequence will be reduced compared to the prior art.

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

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

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

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

[0013] Optionally, a single coding mode is one of inter - frame and intra - frame.

[0014] Optionally, a single coding mode is inter - frame.

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

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

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

[0018] Optionally, the coding type is determined based on the value of the AU delimiter.

[0019] Optionally, determining the coding mode includes decoding one or more override flags.

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

[0021] In one aspect of the present invention, there is provided a method for decoding video data from a bitstream, the bitstream including video data corresponding to one or more slices, wherein a picture includes one or more slices, and wherein the video bitstream includes a picture header, the method comprising: 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.

[0022] In one aspect of the present invention, there is provided a method for encoding video data into a bitstream, the bitstream including video data corresponding to one or more slices, wherein a picture includes one or more slices, and wherein the video bitstream includes a picture header, the method comprising: 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.

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

[0024] Optionally, the encoding mode is inter-frame, and encoding the picture header includes encoding the inter-frame syntax elements in the picture header.

[0025] Optionally, the encoding mode is intra-frame, and encoding the picture header includes encoding the intra-frame syntax elements in the picture header.

[0026] In another aspect of the present invention, there is provided a decoder adapted to decode a bitstream by performing a method according to the decoding method aspect described above.

[0027] In another aspect of the present invention, there is provided an encoder adapted to encode a bitstream by performing a method according to the encoding method aspect described above.

[0028] According to one aspect of the present invention, there is provided a method for decoding video data from a bitstream, the bitstream including video data corresponding to a plurality of strips, wherein the video bitstream includes a picture header; the method includes: determining an encoding mode for at least one strip; determining a set of syntax elements to be used for the encoding mode from the picture header; and decoding the at least one strip using the determined syntax elements.

[0029] This allows for a reduction in the bit rate, thus enabling more efficient decoding overall.

[0030] Optionally, determining the encoding mode for at least one strip depends on the syntax elements in the picture header.

[0031] Optionally, the encoding mode is one of inter-frame and intra-frame.

[0032] For flexibility, the encoding mode is one of inter-frame, intra-frame, and a combination of inter-frame and intra-frame.

[0033] For additional flexibility, the inter-frame encoding mode is one of inter-frame B and inter-frame P.

[0034] Optionally, determining the set of syntax elements specific to the encoding mode includes enabling and / or disabling at least one syntax element in the picture header.

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

[0036] Optionally, the method further includes inferring the value of the AU delimiter based on the determined coding type. Optionally, the value of the AU delimiter is inferred if the stream is determined to contain only one layer.

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

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

[0039] These aspects reduce the rate associated with the headers, especially for pictures that contain only inter slices (which are most pictures in many video sequences).

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

[0041] Optionally, the intra syntax elements are restricted to values corresponding to the corresponding inter values.

[0042] Optionally, the method further includes predicting the syntax elements of the slice based on the values of previous syntax elements.

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

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

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

[0046] In one example, the determined coding mode is inter. In another example, the determined coding mode is intra.

[0047] Optionally, determining the coding mode includes decoding one or more override flags.

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

[0049] According to another aspect of the present invention, there is provided a method for decoding video data from a bitstream, the bitstream including video data corresponding to a plurality of slices, wherein the video bitstream includes a picture header; the method comprising: decoding one or more override flags; and decoding coded 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.

[0050] This aspect provides the advantage of rate reduction and additional flexibility in being able to override default situations.

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

[0052] Optionally, the method further comprises decoding two override flags from the picture header before coding-related syntax elements, the first override flag indicating that inter-frame elements are overridden and the second override flag indicating that intra-frame elements are overridden.

[0053] Optionally, the syntax elements to be used for the determined coding mode are agnostic to the coding mode.

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

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

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

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

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

[0059] Optionally, the method further comprises: decoding an override flag that determines whether to decode coded specific syntax elements from the slice header.

[0060] Optionally, the syntax element in the strip header has a value that is restricted to the equivalent syntax element in the picture header.

[0061] Optionally, the method further includes predicting one or more syntax elements in the strip header based on the value of a previous syntax element in the strip header.

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

[0063] According to another aspect of the present invention, there is provided a method of encoding video data into a bitstream, the bitstream including video data corresponding to a plurality of strips, wherein one or more strips include pictures; wherein, the video bitstream includes a picture header; the method includes: defining an encoding mode for the picture; encoding a syntax element into the picture header; wherein, the value of the syntax element depends on the defined encoding mode.

[0064] According to another aspect of the present invention, there is provided a method of encoding video data into a bitstream, the bitstream including video data corresponding to a plurality of strips, wherein one or more strips include pictures; wherein, the video bitstream includes a picture header; the method includes: defining an encoding mode for all strips within the picture; encoding the picture header with syntax elements according to the defined encoding mode.

[0065] According to another aspect of the present invention, there is provided a method of encoding video data into a bitstream, the bitstream including video data corresponding to a plurality of strips, wherein the video bitstream includes a picture header; the method includes: encoding a picture using the syntax elements from the picture header; wherein, all syntax elements correspond to the same strip encoding mode.

[0066] Optionally, the encoding mode is inter-frame, and encoding the picture header includes encoding the inter-frame syntax elements in the picture header.

[0067] Optionally, the encoding mode is intra-frame, and encoding the picture header includes encoding the intra-frame syntax elements in the picture header.

[0068] Optionally, the method further includes: if the defined encoding mode is intra-frame, encoding the inter-frame syntax elements into the picture header and encoding the intra-frame syntax elements into the strip header.

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

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

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

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

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

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

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

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

[0077] 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

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

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

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

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

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

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

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

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

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

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

[0088] Figure 10 is a diagram showing a smart phone. Detailed Description

[0089] Figure 1 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 such digital image is represented by one or more matrices. Matrix coefficients represent pixels.

[0090] The images 2 of the sequence can be segmented into strips 3. In some cases, a strip can constitute the whole image. These strips are segmented into non-overlapping Coding Tree Units (CTUs). A Coding Tree Unit (CTU) is the basic processing unit of the High Efficiency Video Coding (HEVC) video standard and conceptually corresponds in structure to the macroblock unit used in several previous video standards. A CTU is sometimes also referred to as a Largest Coding Unit (LCU). A CTU has a luminance and a chrominance component part, and each component part is called a Coding Tree Block (CTB). These different color components are not shown in Figure 1 herein.

[0091] The CTU is typically 64 pixels by 64 pixels in size. Quadtree decomposition can be used to iteratively divide each CTU into smaller variable-size coding units (CUs) 5.

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

[0093] Each slice is embedded in a network abstraction layer (NAL) unit. Additionally, the coding parameters of the video sequence are stored in dedicated NAL units called parameter sets. In HEVC and H.264 / AVC, two types of parameter set NAL units are adopted: first, the sequence parameter set (SPS) NAL unit, which collects all the parameters that remain unchanged during the entire video sequence. Typically, it deals with the coding profile, the size of the video frames, and other parameters. Second, the picture parameter set (PPS) NAL unit, which includes parameters that can change from one image (or frame) of the sequence to another. HEVC also includes a video parameter set (VPS) NAL unit, which contains parameters that describe the overall structure of the bitstream. The VPS is a new type of parameter set defined in HEVC and applies to all layers of the bitstream. A layer can contain multiple temporal sub-layers, and all version 1 bitstreams are limited to a single layer. HEVC has certain hierarchical extensions for scalability and multi-view, and these extensions will allow multiple layers with a backward-compatible version 1 base layer.

[0094] Figure 2 An example of a data communication system that can implement one or more embodiments of the present invention is illustrated. The data communication system includes a transmitting device (in this case, server 201), which is operable to transmit data packets of a data stream to a receiving device (in this case, client terminal 2*2) via a data communication network 200. The data communication network 200 can be a wide area network (WAN) or a local area network (LAN). Such a network can be, for example, a wireless network (Wifi / 802.11a or b or g), an Ethernet network, an Internet network, or a hybrid network consisting of several different networks. In a particular embodiment of the present invention, the data communication system can be a digital television broadcast system, where the server 201 sends the same data content to multiple clients.

[0095] The data stream 204 provided by the server 201 may consist 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 stream 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 to provide a compressed bitstream for transmission, which is a more compact representation of the data presented as the input to the encoder.

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

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

[0098] Although a streaming scenario is considered in the example of Figure 2 , it will be appreciated that in some embodiments of the present invention, data communication between the encoder and the decoder may be performed using, for example, a media storage device (such as an optical disc, etc.).

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

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

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

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

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

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

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

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

[0107] - A disk drive 305 for a disk 306, which is adapted to read data from or write data to the disk 306;

[0108] - A screen 309, which is used to display data and / or serve as a graphical interface for interacting with the user by means of a keyboard 310 or any other indicating device.

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

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

[0111] Disk 306 may be replaced by any information medium such as a rewritable or non-rewritable compact disc (CD-ROM), ZIP disk, or memory card, and generally, by an information storage component readable by a microcomputer or microprocessor, which may or may not be integrated into the device, may be removable, and is adapted to store one or more programs for executing methods for encoding a digital image sequence and / or decoding a bitstream according to the present invention.

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

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

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

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

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

[0117] After implementing the encoding process, the encoder 400 outputs a bitstream 410. The bitstream 410 includes a plurality of coding units or strips, each strip including a strip header for transmitting the coded values of the coding parameters used for strip coding, and a strip body including coded video data.

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

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

[0120] The time prediction is implemented by the motion estimation module 404 and the motion compensation module 405. First, a reference image from the reference image set 416 is selected, and a part of the reference image (also referred to as a reference region or image portion), which is the region closest to the given block to be encoded, is selected by the motion estimation module 404. Then the motion compensation module 405 uses the selected region to predict the block to be encoded. The difference between the selected reference region and the given block (also called the residual block) is calculated by the motion compensation module 405. The selected reference region is indicated by a motion vector.

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

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

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

[0124] The encoder 400 also includes a selection module 406, which is used to select an encoding mode by applying an encoding cost criterion (such as the rate - distortion criterion, etc.). To further reduce redundancy, a transform (such as DCT, etc.) is applied to the residual block by the transform module 407, and then the obtained transform data is quantized by the quantization module 408 and entropy - encoded by the entropy encoding module 409. Finally, the encoded residual block of the currently - encoded current block is inserted into the bitstream 410.

[0125] The encoder 400 also decodes the encoded image to generate a reference image for the motion estimation of subsequent images. This enables the encoder and decoder receiving the bitstream to have the same reference frames. The inverse quantization module 411 performs the inverse quantization of the quantized data, followed by the inverse transform of 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 the module 412 to the reference region obtained from the reference image set 416.

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

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

[0128] The decoder 60 receives a bitstream 61 including coding units. Each coding unit consists of a header containing information related to the encoded parameters and a body containing the encoded video data. The structure of the bitstream in VVC is described in more detail below with reference to Figure 6 As illustrated with respect to Figure 4 For a given block, the encoded video data is entropy encoded on a predetermined number of bits, and the index of the motion vector predictor is encoded. The received encoded video data is entropy decoded by module 62. Then the residual data is dequantized by module 63, and then an inverse transform is applied by module 64 to obtain pixel values.

[0129] The mode data for indicating the coding mode is also entropy decoded, and based on this mode, the encoded blocks of the image data are decoded into an intra type or an inter type.

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

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

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

[0133] Finally, a decoded block is obtained. Post-filtering is applied by post-filtering module 67. Decoder 60 finally provides a decoded video signal 69.

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

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

[0136] NAL units are split into video coding layer (VCL) NAL units and non-VCL NAL units. VCL NAL units contain the actual encoded video data. Non-VCL NAL units contain additional information. This additional information can be parameters required to decode the encoded video data or supplementary data that can enhance the usability of the decoded video data. NAL unit 606 corresponds to a slice and constitutes a VCL NAL unit of the bitstream.

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

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

[0139] Picture Parameter Set (PPS) NAL unit 604, where the PPS contains parameters defined for a picture or group of pictures. Adaptive Parameter Set (APS) NAL unit 605 contains parameters for a loop filter, which is typically an Adaptive Loop Filter (ALF) or a shaper model (or a Luminance Mapping with Chroma Scaling (LMCS) model) or a scaling matrix used at the slice level.

[0140] The syntax of the PPS as proposed in the current version of VVC includes syntax elements that specify the size of the picture in terms of luminance samples and the partitioning of each picture into tiles and slices.

[0141] The PPS contains syntax elements that enable the determination of slice positions in a frame. Since sub-pictures form rectangular regions in a frame, it is possible to determine the set of slices, tile parts, or tiles belonging to a sub-picture based on the parameter set NAL unit. The PPS as APS has an ID mechanism to limit the amount of the same PPS sent.

[0142] The main difference between the PPS and the picture header lies in its transmission. The PPS is typically sent for a group of pictures, as opposed to the PH which is sent systematically for each individual image. Thus, compared to the PH, the PPS contains parameters that can be constant for several pictures.

[0143] The bitstream may also contain Supplemental Enhancement Information (SEI) NAL units ( Figure 6 not shown in ). The occurrence period of these parameter sets in the bitstream is variable. The VPS defined for the entire bitstream can occur only once in the bitstream. In contrast, the APS defined for a slice can occur once for each slice in each picture. In fact, different slices can depend on the same APS, and thus there are typically fewer APSs than slices in each picture. In particular, the APS is defined in the picture header. However, the ALF APS can be refined in the slice header.

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

[0145] Table 1 Explanation of pic_type

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

[0147] Picture Header

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

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

[0150] The picture header is sent at the start of each picture. The relevant syntax elements that can be decoded involve:

[0151] · Whether to use the picture, reference frames

[0152] · Output frames

[0153] · Use of sub-pictures (if required)

[0154] · Reference picture lists (if required)

[0155] · Color planes (if required)

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

[0157] · Delta QP parameters (if required)

[0158] · Motion information parameters (if required)

[0159] · ALF parameters (if required)

[0160] · SAO parameters (if required)

[0161] · Quantization parameters (if required)

[0162] · LMCS parameters (if required)

[0163] · Scaling list parameters (if required)

[0164] · Picture header extensions (if required)

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

[0166] This structure at the picture header provides flexibility in terms of all the tools that may be required in a given image. Thus, this structure substantially defines the "worst case" for decoding a picture, which is typically a key consideration for hardware decoders. However, there is significant redundancy in this structure, which results in an increase in bit rate.

[0167] The problem solved by the present invention relates to the set of parameters in this picture header that are related to a specific coding mode. For certain sets of parameters, a set of syntax elements is sent for both inter-frame stripes and intra-frame stripes. This increases the rate when all stripes in a picture are of the same type.

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

[0169] Table 2 Partial Picture Header

[0170]

[0171]

[0172]

[0173] In some cases, three specific sets of parameters in the above header may be redundant. These three sets are considered in turn below.

[0174] The first set of parameters is related to partitions. The following are only useful for inter-frame stripes:

[0175] · pic_log2_diff_min_qt_min_cb_inter_slice

[0176] · pic_max_mtt_hierarchy_depth_inter_slice [[ID=�4]]

[0177] · pic_log2_diff_max_bt_min_qt_inter_slice

[0178] · pic_log2_diff_max_tt_min_qt_inter_slice

[0179] And the following are only for intra-frame stripes:

[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 description for luma and chroma intra 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 to equal 1 in the picture header.

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

[0192] The second set of parameters relates to delta 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 the cu_qp_delta_enabled_flag in the PPS is set to equal 1.

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

[0200] The third set of parameters relates to 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 can be decoded (or not decoded) based on an "enable flag" or an "override flag" signaled at the SPS or PPS header. However, each of these parameters is always sent, which helps increase the bit rate.

[0211] This increase in rate is particularly noticeable when the encoded picture uses only one type of slice (inter or intra), because 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 of unnecessary syntax elements.

[0213] Picture type indicated in the picture header

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

[0215] This picture type can be defined as follows:

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

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

[0218] · When the picture type is set to equal B (or 2), all slices of the picture have the same slice type, inter B (bidirectional 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 only decodes the syntax elements related to that coding mode (or ignores the syntax elements only related to different coding modes).

[0220] In an example, picture_type_pic_header is used to enable and disable some of the unnecessary syntax elements by conditioning 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 of implementing this conditional decoding; the notable changes have been underlined. It should be noted that this table represents a partial header and has been reordered for reasons of clarity and conciseness. A larger header in a different order may be more appropriate in practice.

[0222] Table 3 - Picture Header with Conditional Decoding

[0223]

[0224]

[0225]

[0226] The "condition" relates to the coding 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 as follows:

[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] Therefore, only specific syntax elements of I, P, or B pictures are decoded from the picture header, thus reducing the rate of each picture.

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

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

[0265] In this table, slice_type is never sent. And its value has been replaced by the syntax element picture_type_pic_header. Based on this flag, num_ref_idx_active_override_flag can be sent when the picture contains only inter slices and is never sent for intra. In the same way, the table num_ref_idx_active_minus1[i] is not decoded for pictures containing intra slices.

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

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

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

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

[0270] The advantage of this embodiment is that, compared with the current design, the rate related to the transmission of this slice type is saved.

[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 that are not needed 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] Slice type constraints in the picture header

[0277] This feature represents a modification to the above example, where instead of picture_type_pic_header, the syntax element "pic_slice_type_constraint" is sent at the start of the picture header. This syntax element indicates constraints on the coding modes used in the individual slices within the picture. This is different 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 of pic_slice_type_constraint and their corresponding definitions are as follows:

[0279] · Equal to 0 indicates that all slices of the picture are intra.

[0280] · Equal to 1 indicates that all slices of the picture are inter.

[0281] · Equal to 2 indicates that the slices of the picture can have 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 P.

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

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

[0287] · Equal to 1 indicates that all slices of the picture are inter P.

[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 have different types.

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

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

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

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

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

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

[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 can 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] Such values can be used for streaming applications where IRAP and GDR pictures are more relevant. In fact, these pictures provide intra random access points, which can be used, for example, to change the first picture of the sequence or synchronize the stream for real-time applications, etc.

[0300] In fact, 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 width level to avoid pictures having a mixed coding type.

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

[0302] For the above example of 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] For additional features that provide additional improvements, the slice type of the slice header can be inferred and / or decoded with fewer bits than the current design.

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

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

[0309] Compared with 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 when all slices of a frame are intra-frame or all slices are inter-frame, the rate of slice_type can be reduced.

[0311] Table 5 - Modified slice header with pic_slice_type_constraint

[0312]

[0313]

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

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

[0316] Modification to the 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 flags 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 reduce the rate.

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

[0320] AU NAL pic_type for setting the set of syntax elements to be decoded

[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, the picture type or picture type constraint is not 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). Thus, 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, the "conditions" relate to the coding type of pic_type and allow conditional decoding of certain syntax elements as defined in the previous embodiments, where the elements do not need to skip decoding. This improves the decoding performance.

[0323] An example of the conditions is as follows:

[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, it is inferred that the pic_type of the AU NAL unit is equal to 2.

[0328] Merged syntax elements

[0329] Similar syntax elements used in both the inter-frame mode and the intra-frame mode can be merged to reduce the 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 in inter-frame or intra-frame. This is possible because most pictures contain only slices that require one type of coding mode (inter-frame or intra-frame) and thus do not require two sets of syntax elements.

[0330] Therefore, merging the intra-frame and inter-frame syntax elements avoids redundant coding of these syntax elements, especially when all slices in the picture have the same type (I, P, or B). When both inter-frame and intra-frame slices are present in the picture, there is less flexibility, but the impact on intra-frame slices can be compensated by adjusting the coding selection.

[0331] Syntax elements that differ only by the "coding type" label are particularly suitable for merging.

[0332] When following the same design as discussed above, the following syntactic elements can be merged, as shown in Table 6 below:

[0333] Table 6 - Merged Syntactic Elements

[0334]

[0335]

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

[0337] Picture Header with Merged Syntactic Elements

[0338]

[0339]

[0340] Common Values of Syntactic Elements

[0341] In an 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 at the slice header), the intra-slice value is set to be equal to the common value, and when the slice is inter, the inter-slice value is set to be equal to the common value.

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

[0343] In an additional example, the intra value can be updated at the slice level according to a variable in the slice header.

[0344] For example, the parameters in the slice header for intra are:

[0345] ·slice_log2_diff_min_qt_min_cb_intra_slice_luma

[0346] ·slice_max_mtt_hierarchy_depth_intra_slice_luma

[0347] ·slice_log2_diff_max_bt_min_qt_intra_slice_luma

[0348] [[ID=4८]]·slice_log2_diff_max_tt_min_qt_intra_slice_luma

[0349] ·slice_log2_diff_min_qt_min_cb_intra_slice_chroma

[0350] ·slice_max_mtt_hierarchy_depth_intra_slice_chroma

[0351] ·slice_log2_diff_max_bt_min_qt_intra_slice_chroma

[0352] ·slice_log2_diff_max_tt_min_qt_intra_slice_chroma

[0353] ·slice_cu_qp_delta_subdiv_intra_slice

[0354] ·slice_cu_chroma_qp_offset_subdiv_intra_slice

[0355] The advantage compared to the initial example is the increased flexibility. In fact, with this additional feature, the same flexibility as the current design can be obtained. And greater flexibility is obtained by adjusting these parameters for each slice.

[0356] Override flags at PPS / SPS

[0357] To provide additional flexibility, both intra and inter values can be sent in the slice header. These parameters can 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 bitrate required for these syntax elements within the slice header.

[0358] 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, the parameter will not be updated in the inter slice and log2_diff_min_qt_min_cb_slice_inter_override_flag is set to be equal to 0.

[0359] In a similar way, the override flag log2_diff_min_qt_min_cb_slice_intra_override_flag can be sent for the intra slice.

[0360] Optionally, when a parameter is sent in the slice header, the value of the parameter is constrained by the value of its equivalent syntax element in the picture header. More precisely, these values are restricted to avoid an increase in complexity.

[0361] 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_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 the slice cannot use a block size smaller than that defined in the picture header.

[0362] The advantage of this example is that the decoder can set its complexity parameter for each picture. Then, there is no need to increase this complexity for each new slice.

[0363] 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 encoded value.

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

[0365] Only repeat inter-frame parameters

[0366] In another example, all parameters that are only related to intra-stripes are removed from the picture header. Table 8 shows this example. Compared with the current design, the following syntax elements are not present in the picture header:

[0367] ·pic_log2_diff_min_qt_min_cb_intra_slice_luma

[0368] ·pic_max_mtt_hierarchy_depth_intra_slice_luma

[0369] ·pic_log2_diff_max_bt_min_qt_intra_slice_luma

[0370] ·pic_log2_diff_max_tt_min_qt_intra_slice_luma

[0371] ·pic_log2_diff_min_qt_min_cb_intra_slice_chroma

[0372] ·pic_max_mtt_hierarchy_depth_intra_slice_chroma

[0373] ·pic_log2_diff_max_bt_min_qt_intra_slice_chroma

[0374] ·pic_log2_diff_max_tt_min_qt_intra_slice_chroma

[0375] ·pic_cu_qp_delta_subdiv_intra_slice

[0376] ·pic_cu_chroma_qp_offset_subdiv_intra_slice

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

[0378] Table 8 Picture header with intra-syntax removed

[0379]

[0380]

[0381] Alternatively, when the sequence only contains intra-pictures (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 an all-intra sequence, where the impact of this adjustment should be more significant.

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

[0383] In an additional embodiment, when the slice type is intra, the set of intra-syntax elements is sent in the slice header. Compared to the main embodiment, the advantage of this embodiment is greater flexibility because the intra can be adjusted. Additionally, for the adjustment of intra-slices, the impact on the rate is lower because fewer intra-slices are sent in the video.

[0384] Substantially, when it is determined that a picture only has slices encoded in one of these modes, the picture header is modified to remove the intra / inter elements. In this way, the picture header only contains the syntax elements related to the encoding mode used for the entire picture. For most pictures, this will be inter-encoding (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 encoding modes, the syntax elements for that slice / picture as a whole can be determined from different headers such as the slice header.

[0385] For example, the parameters in the slice header for intra are:

[0386] · slice_log2_diff_min_qt_min_cb_intra_slice_luma

[0387] ·slice_max_mtt_hierarchy_depth_intra_slice_luma

[0388] ·slice_log2_diff_max_bt_min_qt_intra_slice_luma

[0389] ·slice_log2_diff_max_tt_min_qt_intra_slice_luma

[0390] ·slice_log2_diff_min_qt_min_cb_intra_slice_chroma

[0391] ·slice_max_mtt_hierarchy_depth_intra_slice_chroma

[0392] ·slice_log2_diff_max_bt_min_qt_intra_slice_chroma

[0393] ·slice_log2_diff_max_tt_min_qt_intra_slice_chroma

[0394] ·slice_cu_qp_delta_subdiv_intra_slice

[0395] ·slice_cu_chroma_qp_offset_subdiv_intra_slice

[0396] To reduce complexity, when sending a parameter in an intra slice, the value of the parameter may be constrained by the value of its equivalent inter-frame syntax element. More precisely, these values are restricted to avoid an increase in complexity.

[0397] 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_inter_slice sent in the picture header. More precisely, the value of the minimum QT size (which gives the minimum block size) in the current slice 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.

[0398] The advantage of this feature is that the decoder can set its complexity parameter for each picture; then, it is not necessary to increase this complexity for each new slice, since the "worst case" complexity is set in the picture header.

[0399] This constraint can also be applied if the inter - frame parameters can be sent in the slice header.

[0400] To further reduce the number of encoded bits, when a slice syntax element is constrained by its equivalent inter - frame value in the picture header, its value can be predicted by its equivalent inter - frame 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.

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

[0402] Intra / Inter override flag

[0403] Picture header syntax elements defined only for intra or inter slices can be decoded (or not decoded) according to 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.

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

[0405] Based on partition_constraints_override_enabled_flag_intra, decode the new flag syntax element partition_constraints_override_flag_intra, and if it is set to equal 1, decode the following partition syntax elements for intra prediction, or they can be decoded according to other constraints:

[0406] ·pic_log2_diff_min_qt_min_cb_intra_slice_luma

[0407] ·pic_max_mtt_hierarchy_depth_intra_slice_luma

[0408] ·pic_log2_diff_max_bt_min_qt_intra_slice_luma

[0409] ·pic_log2_diff_max_tt_min_qt_intra_slice_luma

[0410] ·pic_log2_diff_min_qt_min_cb_intra_slice_chroma

[0411] ·pic_max_mtt_hierarchy_depth_intra_slice_chroma

[0412] ·pic_log2_diff_max_bt_min_qt_intra_slice_chroma

[0413] ·pic_log2_diff_max_tt_min_qt_intra_slice_chroma

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

[0415] In the same way, if the relevant override flag is set to equal 1 in the SPS, decode partition_constraints_override_flag_inter. If this picture header syntax element is true, use the partition syntax elements for inter prediction.

[0416] ·pic_log2_diff_min_qt_min_cb_inter_slice

[0417] ·pic_max_mtt_hierarchy_depth_inter_slice

[0418] ·pic_log2_diff_max_bt_min_qt_inter_slice

[0419] ·pic_log2_diff_max_tt_min_qt_inter_slice

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

[0421] In the same way, for the syntax elements related to the 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 the PPS or SPS, and they are sent only when no_qp_delta_constraint_flag is equal to 0.

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

[0423] For the picture header syntax elements related to the motion parameters, motion_parameters_override_enabled_flag is sent in the SPS. If it is enabled, the motion_parameters_override_flag is decoded. If it is equal to true, all the syntax elements related to these parameters can be decoded. When it is equal to false, these parameters take the values of their corresponding PPS or SPS values. For the flags, the value can be only the SPS or PPS value, for example:

[0424] pic_temporal_mvp_enabled_flag = sps_temporal_mvp_enabled_flag

[0425] mvd_l1_zero_flag =!pps_mvd_l1_zero_idc

[0426] pic_fpel_mmvd_enabled_flag = sps_fpel_mmvd_enabled_flag

[0427] pic_disable_bdof_flag = sps_bdof_pic_present_flag

[0428] pic_disable_dmvr_flag = sps_dmvr_pic_present_flag

[0429] pic_disable_prof_flag = sps_prof_pic_present_flag

[0430] In one example, at least a default value can be sent to one of the defined ones of these default values at the SPS or PPS header.

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

[0432] pic_six_minus_max_num_merge_cand and pic_max_num_merge_cand_minus_max_num_triangle_cand can depend on pps_six_minus_max_num_merge_cand_plus1 and pps_max_num_merge_cand_minus_max_num_triangle_cand_plu respectively.

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

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

[0435] In an additional embodiment, specific parameters can be sent in the SPS or PPS header to set the value.

[0436] The advantages of using override flags are the same as those discussed above, but offer greater flexibility (at the cost of sending and decoding the flags), since intra parameters can be sent if the specified override flag has been set to equal true.

[0437] Table 9 Picture Header with Override Flags

[0438]

[0439]

[0440]

[0441] It should be noted that the positions of these new override flags can be modified. For example, the inter flag can be moved above the intra flag. This can be beneficial since more pictures are encoded inter, and thus this flag may be more relevant.

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

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

[0444] Fewer additional override flags are required compared to the previous example.

[0445] Override Flags and Merged Syntax Elements

[0446] Particularly interesting combinations are those that use override flags (e.g., Table 9) and merged syntax elements (e.g., Table 6). Additionally, as mentioned above (e.g., Table 8), some parameters can be removed from the picture header.

[0447] For example, the syntax elements that can be merged are merged. In this case, the CU delta QP parameter and the partition flags related to intra and inter luminance are particularly interesting. 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 Picture Header with Feature Combinations

[0449]

[0450]

[0451]

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

[0453] Implementation of the present invention

[0454] Figure 7Systems 191, 195 according to embodiments of the present invention are shown, which include at least one of an encoder 150 or a decoder 100 and a communication network 200. According to an embodiment, system 195 is used to process and provide content to a user (e.g., video and audio content for display / output or streaming of video / audio content), and the user accesses decoder 100, for example, through a user interface of a user terminal including decoder 100 or a user terminal communicable with decoder 100. Such a user terminal can be a computer, a mobile phone, a tablet computer, or any other type of device capable of providing / displaying (provided / streamed) content to the user. System 195 obtains / receives bitstream 101 via communication network 200 (in the form of a continuous stream or signal (e.g., when displaying / outputting earlier video / audio)). According to an embodiment, system 191 is used to process content and store the processed content, e.g., video and audio content processed for display / output / streaming at a later time. System 191 obtains / receives content including original image sequence 151, which is received and processed by encoder 150 (including filtering using a deblocking filter according to the present invention), and encoder 150 generates bitstream 101 that will be transmitted to decoder 100 via communication network 200. Then, bitstream 101 is transmitted to decoder 100 in various ways. For example, it can be pre-generated by encoder 150 and stored as data in a storage device in communication network 200 (e.g., on a server or cloud storage device) until the user requests the content (i.e., the bitstream data) from the storage device, at which time the data is transmitted / streamed from the storage device to decoder 100. System 191 may also include a content providing device for providing / streaming to the user content information (e.g., the title of the content and other meta / storage location data for identifying, selecting, and requesting the content) of the content stored in the storage device (e.g., by transmitting data of the user interface to be displayed on the user terminal), and for receiving and processing the user's request for the content so that the requested content can be transmitted / streamed from the storage device to the user terminal. Alternatively, encoder 150 generates bitstream 101 and directly transmits / streams it to decoder 100 when the user requests the content. Then, decoder 100 receives bitstream 101 (or signal) and filters it using a deblocking filter according to the present invention to obtain / generate a video signal 109 and / or an audio signal, and then the user terminal uses the video signal 109 and / or the audio signal 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 can be implemented by hardware, software, firmware, or any combination thereof. If implemented in software, the steps / functions can be stored as one or more instructions or code or programs or computer-readable media on one or more hardware-based processing units or transmitted via one or more hardware-based processing units and executed by one or more hardware-based processing units, such as programmable computing machines, which can be a PC ("personal computer"), DSP ("digital signal processor"), circuit, circuitry, processor and memory, general microprocessor or central processing unit, microcontroller, ASIC ("application specific integrated circuit"), field programmable logic array (FPGA), or other equivalent integrated or discrete logic circuitry. Thus, as used herein, the term "processor" can refer to any one of the foregoing structures or any other structure suitable for implementing the techniques described herein.

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

[0457] Embodiments of the present invention can be implemented by a computer that reads and executes computer-executable instructions (e.g., one or more programs) recorded on a storage medium to perform one or more of the modules / units / functions in the above embodiments and / or a system or device including one or more processing units or circuits for performing one or more of the functions in the above embodiments, and can be implemented by a method performed by the computer of the system or device, e.g., reading and executing computer-executable instructions from a storage medium to perform one or more of the functions in the above embodiments and / or controlling one or more processing units or circuits to perform one or more of the functions in the above embodiments. The computer can include a single computer or a network of individual processing units to read and execute the computer-executable instructions. The computer-executable instructions can be provided to the computer, for example, via a network or a tangible storage medium from a computer-readable medium such as a communication medium. The communication medium can be a signal / bitstream / carrier wave. The tangible storage medium is a "non-transitory computer-readable storage medium", which can include (e.g.) one or more of a hard disk, random access memory (RAM), read-only memory (ROM), storage devices of a distributed computing system, optical discs (e.g., compact disc (CD), digital versatile disc (DVD) or Blu-ray disc (BD) TM ), flash memory devices, memory cards, etc. At least some of the steps / functions can also be implemented in hardware by a machine or a dedicated component such as an FPGA ("field programmable gate array") or an ASIC ("application specific integrated circuit").

[0458] Figure 8FIG. 1300 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 embodiments of the present invention and registers suitable for recording variables and parameters required to implement a method for encoding or decoding at least a part of an image according to an embodiment of the present invention, and its storage capacity may be extended, for example, by an optional RAM connected to an expansion port; - a read-only memory (ROM) 1303 for storing a computer program for implementing an embodiment of the present invention; - a network interface (NET) 1304, which is generally connected to a communication network, and digital data to be processed is transmitted or received through the communication network. The network interface (NET) 1304 may be a single network interface or consist of a set of different network interfaces (for example, wired and wireless interfaces, or different types of wired or wireless interfaces). Under the control of a software application running in the CPU 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 may be used to receive input from a user or display information to the user; - a hard disk (HD) 1306, which may be set as a mass storage device; - an input / output module (IO) 1307, which may be used to receive / send data from / to an external device (such as a video source or a display). The executable code may be stored in the ROM 1303, on the HD 1306, or on a removable digital medium such as a disk. According to a variant, the executable code of the program may be received via the NET 1304 by means of a communication network and stored in one of the storage components (such as the HD 1306, etc.) of the communication device 1300 before being executed. The CPU 1301 is adapted to control and direct the execution of instructions or parts of the software code of one or more programs according to an embodiment of the present invention, and the instructions are stored in one of the aforementioned storage components. For example, after power-on, the CPU 1301 is capable of executing those instructions related to the software application from the main RAM memory 1302 after loading instructions from the program ROM 1303 or the HD 1306. Such a software application, when executed by the CPU 1301, causes the steps of the method according to the present invention to be performed.

[0459] It should also be understood that, according to other embodiments of the present invention, a decoder according to the above embodiments is provided in a user terminal such as a computer, a mobile phone (cellular phone), a tablet, or any other type of device capable of providing / displaying content to a user (e.g., a display device). According to yet another embodiment, an encoder according to the above embodiments is provided in an image capture device, which further includes a camera, a video camera, or a network camera (e.g., a closed-circuit television or video surveillance camera) for capturing and providing content for the encoder to encode. The following refers to Figure 9 and 10 Two such examples are provided.

[0460] Network camera

[0461] Figure 9 FIG. Figure 9 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 interconnected via a network 200 to be able to communicate with each other.

[0464] The imaging unit 2106 includes a lens and an image sensor (e.g., a charge-coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS)), and captures an image of an object and generates image data based on the image. The image can be a still image or a video image.

[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 the encoding of 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 211

[0471] In addition, 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 inputs to the GUI displayed on 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 inputs to the GUI displayed on the display device 2120, so as to transmit a command for specifying a value of a parameter of the network camera 2102 to the network camera 2102.

[0478] Smartphone

[0479] Figure 10 is a diagram illustrating the 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 smart phone 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 should be understood that the present invention is not limited to the disclosed embodiments. Those skilled in the art will understand that various changes and modifications can be made without departing from the scope of the present invention defined by the appended claims. All features disclosed in this specification (including any appended claims, abstract and drawings), and / or all steps of any method or process disclosed, can be combined in any combination, except for combinations in which at least some of such features and / or steps are mutually exclusive. Unless otherwise expressly stated, each feature disclosed in this specification (including any appended claims, abstract and drawings) may be replaced by an alternative feature serving the same, equivalent or similar purpose. Therefore, unless otherwise expressly stated, each disclosed feature is only an example of a general series of equivalent or similar features.

[0487] It should also be understood that any result of the above comparison, determination, evaluation, selection, execution, performance or consideration (e.g., a selection made during an encoding or filtering process) may be indicated in the data in the bitstream (e.g., a flag or data indicating the result) or determinable / inferable from the data in the bitstream, such that the indicated or determined / inferred result can be used for processing rather than actually performing the comparison, determination, evaluation, selection, execution, performance or consideration, e.g., 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 these features cannot be used advantageously in combination.

[0489] The reference signs appearing in the claims are for illustration only and should not limit the scope of the claims.

Claims

1. A method for decoding a picture from a bitstream, wherein, The picture includes one or more stripes, and wherein, the bitstream includes a picture header and an adaptive parameter set, The method includes: when the following conditions are met, decoding, from the picture header, a first syntax element related to partitioning and to be used for intra stripes: (a) the value of the partitioning constraint override flag related to partitioning in the picture header is 1, and (b) a predetermined syntax element with a value of 0 in the picture header indicates that all stripes in the picture have an intra coding type; and decoding the one or more stripes using the decoded first syntax element, wherein, according to the value of the partitioning constraint override flag and the value of the predetermined syntax element, a second syntax element related to partitioning and to be used for inter stripes can be decoded from the picture header, wherein, even if the value of the partitioning constraint override flag is 1, when the predetermined syntax element with a value of 0 in the picture header indicates that all stripes in the picture have the intra coding type, the second syntax element is not decoded from the picture header, and wherein, the adaptive parameter set can be located after the picture header in the bitstream and can include information related to an adaptive loop filter.

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

3. The method according to claim 1, wherein When the partitioning constraint override flag in the picture header has a value of 1, the partitioning constraint override flag in the picture header indicates that parameters related to partitioning exist in the picture header.

4. The method according to claim 1, wherein The bitstream further includes a stripe header, wherein, according to the value of the predetermined syntax element, information corresponding to the coding type of the stripe can be decoded from the stripe header, and wherein, when the predetermined syntax element in the picture header indicates that all stripes in the picture have the intra coding type, the information is not decoded from the stripe header.

5. A method for encoding an image into a bitstream, wherein, The picture includes one or more stripes, and wherein, the bitstream includes a picture header and an adaptive parameter set, The method includes: when the following conditions are met, encoding a first syntax element related to partitioning and to be used for intra stripes into the picture header: (a) the value of the partitioning constraint override flag related to partitioning in the picture header is 1, and (b) a predetermined syntax element with a value of 0 in the picture header indicates that all stripes in the picture have an intra coding type; and encoding the one or more stripes, ​ ​ ​ 6. The method according to claim 5, wherein, ​ 7. The method according to claim 5, wherein, In a case where the partition constraint overwrite flag has a value of 1, the partition constraint overwrite flag in the picture header indicates that parameters related to a partition are present in the picture header.

8. The method according to claim 5, Among them, The bitstream further includes a slice header, wherein, according to a value of the predetermined syntax element, information corresponding to an encoding type of a 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 encoding type, the information is not encoded into the slice header.

9. A decoder adapted to decode a bitstream by performing the method according to any one of claims 1 to 4.

10. An encoder adapted to encode a bitstream by performing the method according to any one of claims 5 to 8.

11. 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 8.

12. A computer-readable storage 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 any one of claims 1 to 8.

Images