Image and video coding and decoding

Abstract

Encoding and decoding a plurality of images into a bitstream, comprising: a bitstream, comprising: coded image data and data indicating a partitioning of the image data into a plurality of blocks, her

Description

Field of invention The present invention relates to encoding and decoding of image and video data and particularly, but not exclusively, image and video partitioning data. Background The Joint Video Experts Team (JVET), a collaborative team formed by MPEG and ITU-T Study Group 16’s VCEG, released a new video coding standard referred to as Versatile Video Coding (VVC). The goal of WC is to provide significant improvements in compression performance over the existing HEVC standard (i.e., typically twice as much as before). The main target applications and services include — but not limited to — 360-degree and high-dynamic-range (HDR) videos. Particular effectiveness was shown on ultra-high definition (UHD) video test material. Thus, we may expect compression efficiency gains well-beyond the targeted 50% for the final standard. Since the end of the standardisation of VVC vl, JVET has launched an exploration phase by establishing an exploration software (ECM). It gathers additional tools and improvements of existing tools on top of the VVC standard to target better coding efficiency. Summary of Invention According to an aspect of the invention there is provided a method of encoding image data for a plurality of images into a bitstream, the bitstream including data indicating a partitioning of the image data into a plurality of blocks according to a coding tree, wherein blocks in the coding tree may be partitioned according to a plurality of split modes, each split mode being indicated by a partitioning syntax element, the method comprising: encoding at least one bit of a partitioning syntax element corresponding to a split mode using CAB AC coding for a current block to be encoded, wherein the CABAC coding uses a context variable derived based on a first value associated with at least one area from another frame. According to further aspect of the invention, there is provided a method of decoding image data for a plurality of images into a bitstream, the bitstream including data indicating a partitioning of the image data into a plurality of blocks according to a coding tree, wherein blocks in the coding tree may be partitioned according to a plurality of split modes, each split mode being indicated by a partitioning syntax element, the method comprising: decoding at least one bit of a partitioning syntax element corresponding to a split mode using CAB AC coding for a current block to be decoded, wherein the CABAC coding uses a context variable derived based on a first value associated with at least one area from another frame. Advantages include a coding efficiency increase due to the fact that the determination of the context values takes into account temporal correlation between the current partitioning and a temporal one. The context variable may be determined based on the first value and a second value associated with one or more blocks neighbouring the current block. The first value may be multiplied by the second value. The first value may be used in combination with the second value. The first value may be determined by comparing the quad tree depth of the current block to the quad tree depth associated with the at least one area of another frame. The first value may be dependent on the value of the multi tree depth associated with the at least one area from another frame. The context variable may be determined using the first value and the second value based on a comparison of the quad tree depth of the current block to the quad tree depth value associated with the at least one area of another frame. The context variable may be determined using the first value when blocks neighbouring the current block are not available. The context variable may be determined using only the second value. The context variable may be determined using the first value based on a flag, wherein the flag may be transmitted in a sequence parameter set, a picture parameter set, a picture header or a slice header. The first value may be signalled in a block, wherein the block may correspond to a coding tree unit. The first value may be signalled in a set of blocks, wherein each block in the set of blocks may correspond to a coding tree unit. The first value may correspond to one or more of: an average quad tree depth associated with the at least one area from another frame; a minimum quad tree depth associated with the at least one area from another frame; and a maximum quad tree depth associated with the at least one area from another frame. The first value may correspond to one or more of: an average multi tree depth associated with the at least one area from another frame; a minimum multi tree depth associated with the at least one area from another frame; and a maximum multi tree depth associated with the at least one area from another frame. The first value may correspond to a binary tree depth value associated with the at least one area from another frame. The first value may correspond to one or more of: an average binary tree depth associated with the at least one area from another frame; a minimum binary tree depth associated with the at least one area from another frame; and a maximum binary tree depth associated with the at least one area from another frame. The first value may correspond to a ternary tree depth value associated with the at least one area from another frame. The first value may correspond to one or more of: an average ternary tree depth associated with the at least one area from another frame; a minimum ternary tree depth associated with the at least one area from another frame; and a maximum ternary tree depth associated with the at least one area from another frame. The context variable may be determined based on a comparison of the height and / or width or an average of the height and / or width of at least one block associated with the another frame to the height and / or width of the current block. The at least one area of another frame may be an area that is collocated with the current block. The at least one area of another frame may comprise a plurality of blocks at different positions. The center position of the current block may be used to determine the at least one area of another frame. The at least one area of another frame may encompass an entire area of a reference frame. The another frame may be a frame with a same temporal ID as the current frame that includes the current block. The frame with the same temporal ID may be the closest frame with a same temporal ID. The another frame may be a frame with the same quantization parameter as the current frame that includes the current block. The another frame may be a frame that is used for temporal motion vector prediction. The another frame may be a frame which is the closest reference frame to the current frame that includes the current block. The at least one area may include a first area from a first another frame and a second area from a second another frame. According to a further aspect of the invention, there is provided a method of decoding image data for a plurality of images into a bitstream, the bitstream including data indicating a partitioning of the image data into a plurality of blocks according to a coding tree, wherein blocks in the coding tree may be partitioned according to a plurality of split modes, each split mode being indicated by a partitioning syntax element, the method comprising: decoding at least one bit of a partitioning syntax element corresponding to a split mode using CAB AC coding for a current block to be encoded, wherein the CABAC coding uses a context variable derived based on at least one parameter transmitted in a header or parameter set. Advantages include a coding efficiency increase as there is no dependency on others frame for the parsing compared to a solution which uses temporal variables. The parameter set may be a picture parameter set or a sequence parameter set. The at least one parameter may be associated with at least one area of another frame. The at least one area of another frame may be an area that is collocated with the current block. The at least one area of another frame may comprise a plurality of blocks at different positions. The center position of the current block may be used to determine the at least one area of another frame. The at least one area of another frame may encompass an entire area of a reference frame. The another frame may be a frame with a same temporal ID as the current frame that includes the current block. The frame with the same temporal ID may be the closest frame with a same temporal ID. The another frame may be a frame with the same quantization parameter as the current frame that includes the current block. The another frame may be a frame that is used for temporal motion vector prediction. The another frame may be a frame which is the closest reference frame to the current frame that includes the current block. The at least one area may include a first area from a first another frame and a second area from a second another frame. The at least one parameter may be signalled in a block. The block may correspond to a coding tree unit. The at least one parameter may be signalled in a set of blocks. Each block in the set of blocks may correspond to a coding tree unit. According to another aspect of the invention, there is provided a method of encoding image data for a plurality of images into a bitstream, the bitstream including data indicating a partitioning of the image data into a plurality of blocks according to a coding tree, wherein blocks in the coding tree may be partitioned according to a plurality of split modes, each split mode being indicated by a partitioning syntax element, the method comprising: encoding at least one bit of a partitioning syntax element corresponding to a split mode using CAB AC coding for a current block to be decoded, wherein the CABAC coding uses a context variable derived based on at least one parameter transmitted in a header or parameter set. In the aspects and embodiments we refer to a binary split. Such a binary split may include horizontal binary splitting and / or vertical binary splitting. In the aspects embodiments we refer to a ternary split. Such a ternary split may include horizontal ternary splitting and / or vertical ternary splitting. Further, although the above embodiments refer to binary tree (horizontal and vertical), ternary tree (horizontal and vertical), quad tree and no split being possible splits of a coding unit or CTU, it would be understood that the invention is not so limited and other modes may be considered. For example, other geometrical splits may be considered into different numbers of blocks and restricted according to one or more criteria mentioned in the aspects and embodiments above. In further embodiments, the methods described above may be disabled for screen content coded image data or video data, for a low delay configuration, using at least one flag (e.g. transmitted in a header). Whether the image or video data to be encoded or decoded is screen content coded image data may be determined based on whether a number of blocks in an area of the frame including the current block or an (e.g. collocated or temporal) area of another frame which are Intra block coded or are palette mode coded crosses a threshold (is above a predetermined value or alternatively is below a predetermined value). Alternatively, whether the image or video data is screen content coded may be indicated by whether the palette mode has been enabled for the image data or video data (e.g. by the setting of a flag in a header). Other aspects of the invention relate to corresponding, an encoding device, a decoding device, and a computer program operable to carry out the decoding and / or encoding methods of the invention. In a further aspect according to the present invention, there is provided device for encoding image data into a bitstream, the device being configured to perform the method according to any of the aspects and embodiments mentioned above. In another aspect according to the present invention, there is provided device for decoding image data from a bitstream, the device being configured to perform the method of any of the embodiments and aspects mentioned above. In a yet further aspect, there is provided a computer program which is arranged to, upon execution, cause the method of any of the aspects and embodiments to be performed. The computer program may be provided on its own or may be carried on, by or in a carrier medium. The carrier medium may be non-transitory, for example a storage medium, in particular a computer-readable storage medium. The carrier medium may also be transitory, for example a signal or other transmission medium. The signal may be transmitted via any suitable network, including the Internet. Further features of the invention are characterised by the independent and dependent claims. Any feature 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. Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory. It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and / or supplied and / or used independently. Brief Description of the Drawings Reference will now be made, by way of example, to the accompanying drawings, in which: Figure 1 is a diagram which illustrates a coding structure used in HEVC; Figure 2 is a block diagram schematically illustrating a data communication system in which one or more embodiments of the invention may be implemented; Figure 3 is a block diagram illustrating components of a processing device in which one or more embodiments of the invention may be implemented; Figure 4 is a schematic illustrating functional elements of an encoder according to embodiments of the invention; Figure 5 is a schematic illustrating functional elements of a decoder according to embodiments of the invention; Figures 6 shows blocks positioned relative to a current block including a collocated block; Figure 7 illustrates a temporal random-access GOP (group of pictures) structure for 33 frames with the related Temporal ID and POC (picture order count); Figure 8 illustrates the 6 possible split modes of VVC; Figure 9 illustrates an example of MinQTSize variable; Figure 10 illustrates the MaxBTSize and MaxMttDepth;; Figure 11 illustrates partitioning constraints; Figure 12 illustrates incomplete CTUs in the borders of a frame; Figure 13 illustrates an encoding by settings of MaxMttDepth based on the temporal ID; Figure 14 illustrates several temporal positions; Figure 15 is a schematic illustrating entropy encoding according to an example; Figure 16 is a schematic illustrating entropy decoding according to an example; Figure 17 is a diagram showing a system comprising an encoder or a decoder and a communication network according to embodiments; Figure 18 is a schematic block diagram of a computing device for implementation of one or more embodiments; Figure 19 is a diagram illustrating a network camera system; and Figure 20 is a diagram illustrating a smart phone. Detailed description Figure 1 relates to a coding structure used in the High Efficiency Video Coding (HEVC) video and Versatile Video Coding (VVC) standards. A video sequence 1 is made up of a succession of digital images i. Each such digital image is represented by one or more matrices. The matrix coefficients represent pixels. An image 2 of the sequence may be divided into slices 3. A slice may in some instances constitute an entire image. These slices are divided into non-overlapping Coding Tree Units (CTUs). A Coding Tree Unit (CTU) is the basic processing unit of the High Efficiency Video Coding (HEVC) and Versatile Video Coding (VVC) video standards and conceptually corresponds in structure to macroblock units that were used in several previous video standards. A CTU is also sometimes referred to as a Largest Coding Unit (LCU). A CTU has luma and chroma component parts, each of which component parts is called a Coding Tree Block (CTB). These different color components are not shown in Figure 1. A CTU is generally of size 64 pixels x 64 pixels for HEVC, yet for VVC this size can be 128 pixels x 128 pixels. Each CTU may in turn be iteratively divided into smaller variablesize Coding Units (CUs) 5 using a quadtree (QT) decomposition. Coding units are the elementary coding elements and are constituted by two kinds of sub-unit called a Prediction Unit (PU) and a Transform Unit (TU). The maximum size of a PU or TU is equal to the CU size. A Prediction Unit corresponds to the partition of the CU for prediction of pixels values. Various different partitions of a CU into PUs are possible as shown by 6 including a partition into 4 square PUs and two different partitions into 2 rectangular PUs. A Transform Unit is an elementary unit that is subjected to spatial transformation using discrete cosine transform (DCT). A CU can be partitioned into TUs based on a quadtree representation 7. Each slice is embedded in one Network Abstraction Layer (NAL) unit. In addition, the coding parameters of the video sequence are stored in dedicated NAL units called parameter sets. In HEVC and H.264 / AVC two kinds of parameter sets NAL units are employed: first, a Sequence Parameter Set (SPS) NAL unit that gathers all parameters that are unchanged during the whole video sequence. Typically, it handles the coding profile, the size of the video frames and other parameters. Secondly, a Picture Parameter Set (PPS) NAL unit includes parameters that may change from one image (or frame) to another of a sequence. HEVC also includes a Video Parameter Set (VPS) NAL unit which contains parameters describing the overall structure of the bitstream. The VPS is a type of parameter set defined in HEVC, and applies to all of the layers of a bitstream. A layer may contain multiple temporal sub-layers, and all version 1 bitstreams are restricted to a single layer. HEVC has certain layered extensions for scalability and multiview and these will enable multiple layers, with a backwards compatible version 1 base layer. Other ways of splitting an image have been introduced in VVC including subpictures, which are independently coded groups of one or more slices. Figure 2 illustrates a data communication system in which one or more embodiments of the invention may be implemented. The data communication system comprises a transmission device, in this case a server 201, which is operable to transmit data packets of a data stream to a receiving device, in this case a client terminal 202, via a data communication network 200. The data communication network 200 may be a Wide Area Network (WAN) or a Local Area Network (LAN). Such a network may be for example a wireless network (Wifi / 802.1 la or b or g), an Ethernet network, an Internet network or a mixed network composed of several different networks. In a particular embodiment of the invention the data communication system may be a digital television broadcast system in which the server 201 sends the same data content to multiple clients. The data stream 204 provided by the server 201 may be composed of multimedia data representing video and audio data. Audio and video data streams may, in some embodiments of the invention, be captured by the server 201 using a microphone and a camera respectively. In some embodiments data streams may be stored on the server 201 or received by the server 201 from another data provider, or generated at the server 201. The server 201 is provided with an encoder for encoding video and audio streams in particular to provide a compressed bitstream for transmission that is a more compact representation of the data presented as input to the encoder. In order to obtain a better ratio of the quality of transmitted data to quantity of transmitted data, the compression of the video data may be for example in accordance with the HEVC format or H.264 / AVC format or VVC format or the format of data generated by the ECM. The client 202 receives the transmitted bitstream and decodes the reconstructed bitstream to reproduce video images on a display device and the audio data by a loud speaker. Although a streaming scenario is considered in the example of Figure 2, it will be appreciated that in some embodiments of the invention the data communication between an encoder and a decoder may be performed using for example a media storage device such as an optical disc. In one or more embodiments of the invention a video image is transmitted with data representative of compensation offsets for application to reconstructed pixels of the image to provide filtered pixels in a final image. Figure 3 schematically illustrates a processing device 300 configured to implement at least an embodiment of the present invention. The processing device 300 may be a device such as a micro-computer, a workstation or a light portable device. The device 300 comprises a communication bus 313 connected to: -a central processing unit 311, such as a microprocessor, denoted CPU; -a read only memory 307, denoted ROM, for storing computer programs for implementing the invention; -a random access memory 312, denoted RAM, for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method of encoding a sequence of digital images and / or the method of decoding a bitstream according to embodiments of the invention; and -a communication interface 302 connected to a communication network 303 over which digital data to be processed are transmitted or received Optionally, the apparatus 300 may also include the following components: -a data storage means 304 such as a hard disk, for storing computer programs for implementing methods of one or more embodiments of the invention and data used or produced during the implementation of one or more embodiments of the invention; -a disk drive 305 for a disk 306, the disk drive being adapted to read data from the disk 306 or to write data onto said disk; -a screen 309 for displaying data and / or serving as a graphical interface with the user, by means of a keyboard 310 or any other pointing means. The apparatus 300 can be connected to various peripherals, such as for example a digital camera 320 or a microphone 308, each being connected to an input / output card (not shown) so as to supply multimedia data to the apparatus 300. The communication bus provides communication and interoperability between the various elements included in the apparatus 300 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the apparatus 300 directly or by means of another element of the apparatus 300. The disk 306 can be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables the method of encoding a sequence of digital images and / or the method of decoding a bitstream according to the invention to be implemented. The executable code may be stored either in read only memory 306, on the hard disk 304 or on a removable digital medium such as for example a disk 306 as described previously. According to a variant, the executable code of the programs can be received by means of the communication network 303, via the interface 302, in order to be stored in one of the storage means of the apparatus 300 before being executed, such as the hard disk 304. The central processing unit 311 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, instructions that are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 304 or in the read only memory 307, are transferred into the random access memory 312, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention. In this embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Figure 4 illustrates a block diagram of an encoder according to at least an embodiment of the invention. The encoder is represented by connected modules, each module being adapted to implement, for example in the form of programming instructions to be executed by the CPU 311 of device 300, at least one corresponding step of a method implementing at least an embodiment of encoding an image of a sequence of images according to one or more embodiments of the invention. An original sequence of digital images iO to in 401 is received as an input by the encoder 400. Each digital image is represented by a set of samples, sometimes also referred to as pixels (hereinafter, they are referred to as pixels). A bitstream 410 is output by the encoder 400 after implementation of the encoding process. The bitstream 410 comprises a plurality of encoding units or slices, each slice comprising a slice header for transmitting encoding values of encoding parameters used to encode the slice and a slice body, comprising encoded video data. The input digital images io to in 401 are divided into blocks of pixels by module 402. The blocks correspond to image portions and may be of variable sizes (e.g. 4x4, 8x8, 16x16, 32x32, 64x64, 128x128 pixels and several rectangular block sizes can be also considered). A coding mode is selected for each input block. Two families of coding modes are provided: coding modes based on spatial prediction coding (Intra prediction), and coding modes based on temporal prediction (Inter coding, Merge, SKIP). The possible coding modes are tested. Module 403 implements an Intra prediction process, in which the given block to be encoded is predicted by a predictor computed from pixels of the neighbourhood of said block to be encoded. An indication of the selected Intra predictor and the difference between the given block and its predictor is encoded to provide a residual if the Intra coding is selected. Temporal prediction is implemented by motion estimation module 404 and motion compensation module 405. Firstly, a reference image from among a set of reference images 416 is selected, and a portion of the reference image, also called reference area or image portion, which is the closest area (closest in terms of pixel value similarity) to the given block to be encoded, is selected by the motion estimation module 404. Motion compensation module 405 then predicts the block to be encoded using the selected area. The difference between the selected reference area and the given block, also called a residual block, is computed by the motion compensation module 405. The selected reference area is indicated using a motion vector. Thus, in both cases (spatial and temporal prediction), a residual is computed by subtracting the predictor from the original block. In the INTRA prediction implemented by module 403, a prediction direction is encoded. In the Inter prediction implemented by modules 404, 405, 416, 418, 417, at least one motion vector or data for identifying such motion vector is encoded for the temporal prediction. Information relevant to the motion vector and the residual block is encoded if the Inter prediction is selected. To further reduce the bitrate, assuming that motion is homogeneous, the motion vector is encoded by difference with respect to a motion vector predictor. Motion vector predictors from a set of motion information predictor candidates is obtained from the motion vectors field 418 by a motion vector prediction and coding module 417. The encoder 400 further comprises a selection module 406 for selection of the coding mode by applying an encoding cost criterion, such as a rate-distortion criterion. In order to further reduce redundancies a transform (such as DCT) is applied by transform module 407 to the residual block, the transformed data obtained is then quantized by quantization module 408 and entropy encoded by entropy encoding module 409. Finally, the encoded residual block of the current block being encoded is inserted into the bitstream 410. The encoder 400 also performs decoding of the encoded image in order to produce a reference image (e.g. those in Reference images / pictures 416) for the motion estimation of the subsequent images. This enables the encoder and the decoder receiving the bitstream to have the same reference frames (reconstructed images or image portions are used). The inverse quantization (“dequantization”) module 411 performs inverse quantization (“dequantization”) of the quantized data, followed by an inverse transform by inverse transform module 412. The intra prediction module 413 uses the prediction information to determine which predictor to use for a given block and the motion compensation module 414 actually adds the residual obtained by module 412 to the reference area obtained from the set of reference images 416. Post filtering is then applied by module 415 to filter the reconstructed frame (image or image portions) of pixels. In some embodiments of the invention a sample adaptive offset (SAO) loop filter is used in which compensation offsets are added to the pixel values of the reconstructed pixels of the reconstructed image. However, it should be understood that post filtering does not always have to performed. Also, any other type of post filtering may also be performed in addition to, or instead of, the SAO loop filtering. Figure 5 illustrates a block diagram of a decoder 60 which may be used to receive data from an encoder according an embodiment of the invention. The decoder is represented by connected modules, each module being adapted to implement, for example in the form of programming instructions to be executed by the CPU 311 of device 300, a corresponding step of a method implemented by the decoder 60. The decoder 60 receives a bitstream 61 comprising encoded units (e.g. data corresponding to a block or a coding unit), each one being composed of a header containing information on encoding parameters and a body containing the encoded video data. As explained with respect to Figure 4, the encoded video data is entropy encoded, and the motion vector predictors’ indexes are encoded, for a given block, on a predetermined number of bits. The received encoded video data is entropy decoded by module 62. The residual data are then dequantized by module 63 and then an inverse transform is applied by module 64 to obtain pixel values. The mode data indicating the coding mode are also entropy decoded and based on the mode, an INTRA type decoding or an INTER type decoding is performed on the encoded blocks (units / sets / groups) of image data. In the case of INTRA mode, an INTRA predictor is determined by intra prediction module 65 based on the intra prediction mode specified in the bitstream. If the mode is INTER, the motion prediction information is extracted from the bitstream so as to find (identify) the reference area used by the encoder. The motion prediction information comprises the reference frame index and the motion vector residual. The motion vector predictor is added to the motion vector residual by motion vector decoding module 70 in order to obtain the motion vector. The various motion predictor tools used in VVC are discussed in more detail below with reference to Figures 6-10. Motion vector decoding module 70 applies motion vector decoding for each current block encoded by motion prediction. Once an index of the motion vector predictor for the current block has been obtained, the actual value of the motion vector associated with the current block can be decoded and used to apply motion compensation by module 66. The reference image portion indicated by the decoded motion vector is extracted from a reference image 68 to apply the motion compensation 66. The motion vector field data 71 is updated with the decoded motion vector in order to be used for the prediction of subsequent decoded motion vectors. Finally, a decoded block is obtained. Where appropriate, post filtering is applied by post filtering module 67. A decoded video signal 69 is finally obtained and provided by the decoder 60. Random Access configuration Figure 7 shows a temporal random-access GOP structure for 33 consecutive frames 0 to 32. The length of the vertical line representing each frame corresponds their temporal ID. (e.g. the longest length corresponds temporal ID 0 and the shortest length for temporal ID 5). The frames with a temporal ID 0 are the highest in the temporal hierarchy because they can be decoded independently to all others frames with a higher temporal ID value. In the same way, the frames with a temporal ID 1 are in the second in the temporal hierarchy and they can be decoded independently to all others frames with a higher temporal ID value and so on for the other temporal IDs. In other words, a frame with a particular temporal ID can be decoded independently from frames with temporal IDs higher in value but may be dependent on frames with lower temporal IDs. This is what is known as temporal scalability. This parameter is similar to the hierarchy depth but the hierarchy depth does not imply the independence decoding to all other frames with a higher depth. VVC Partitioning The VVC Partitioning has a specific block partitioning. For one tree node, 6 possible splits are possible as depicted in Figure 8: -The quad split QT, 801, which divides a block into 4 equally sized square blocks -The binary split BT with its two possible subdivisions 802, 803: -the vertical binary split, 802, SPLIT BT VER -the horizontal binary split, 803, SPLIT BT HOR -The ternary split TT with its two possible subdivisions 804, 805 where the block is split into 3 blocks with a larger block in the middle: -the vertical ternary split, 804, SPLIT TT VER -the horizontal ternary split, 805, SPLITTTHOR -The No Split, 806, which terminates a tree node so there is no splitting. VVC splitting control variables For a current block not all the possible splits are not always permitted. Which splits are available depends on several conditions. These conditions depend on several splitting control variables which have been defined. A first set of variables define the maximum and the minimum block / node size: • CTU size: it corresponds to the root node size of a quadtree (for example 256x256, 128x128, 64x64, 32x32, 16'16 luma samples); • MaxBTSize: is the maximum allowed binary tree root node size, i.e., the maximum size of a leaf quadtree node that may be partitioned by binary splitting. A current block can be split thanks to a BT split if both height and width of the current block are less than or equal to MaxBTSize. Figure 10 illustrates the concept of MaxBTSize where the MaxBTSize is the size of the quad tree leaf nodes 1002 of a CTU 1001 • MinBTSize: is the minimum allowed binary tree leaf node size; i.e., the minimum width or height of a binary leaf node. So, a current block can be split thanks to a horizontal BT split if its height is greater than MinBTSize. And a current block can be split thanks to a vertical BT split if its width is greater than MinBTSize. • MaxTTSize: is the maximum allowed ternary tree root node size, i.e., the maximum size of a leaf quadtree node that may be partitioned by ternary splitting. A current block can be split thanks to a TT split if both height and width of the current block are less than or equal to MaxTTSize. • MinTTSize: represents the minimum allowed ternary tree (TT) leaf node size; i.e., the minimum width or height of a binary leaf node. But in contrast to the BT Split, to be allowed a minimum TT partition size is considered. So, a current block can be split thanks to a horizontal TT split if its height is greater than twice the MinTTSize. And a current block can be split thanks to a vertical TT split if its width is strictly greater than twice the MinTTSize. • MinQTSize: is the minimum allowed quadtree (QT) leaf node size; So, for the current block, if the current block width is not greater than the MinQTSize, the QT split mode is not allowed. Figure 9 illustrates an example of MinQTSize. By considering a CTU 128, in the illustrated example the MinQTsize is equal to 16. There is no definition of a MaxQTSize, so it corresponds to the CTU size. The minimum allowed block size for the width and the height is 4. A set of depths are also defined. • Depth: is the depth in the tree. In VVC specification a leaf is a terminating node of a tree that is a root node of a tree of depth 0. It means that for each split this value is incremented (by 1). • MttDepth: it is the depth of multi tree. The multi tree includes BT splits and TT splits. • The MaxMttDepth is defined in VVC specification which is the maximum allowed multi tree depth. So, MttDepth is greater than or equal to maxMttDepth. Figure 10 illustrates the concept of maxMttDepth. In VVC these variables are defined independently for Luma and Chroma. In the VVC Test Model (VTM) software and ECM software, there is several other variables corresponding to depths. The variable currBtDepth is the current number of BT splits used to reach the current tree node (or the current block). The variable currMttDepth is the current number of BT splits and TT splits used to reach the current tree node (or the current block). The variable MaxBtDepth corresponds to the variable MaxMttDepth of the VVC specification. The currQtDepth is the current number of QT splits used to reach the current tree node (or the current block).MaxBtDepth: is the maximum allowed binary tree depth, i.e., the lowest level at which binary splitting may occur, where the quadtree leaf node is the root (e.g., 3). VVC splitting control syntax elements 5 To set the values of these different variables, some high-level syntax elements are transmitted in the SPS as depicted in the following table of SPS syntax elements seq_parameter_set_rbsp() { Descriptor spsloglminluniacodingblocksizeniinusl ue(v) sps_partition_constraints_ovcrridc_enabled_flag u(l) sps_log2_diff_min_qt_min_cb_intra_slice_luma ue(v) sps_max_mtt_hierarchy_depth_intra_slice_luma ue(v) if( sps_max_mtt_hierarchy_depth_intra_slice_luma != 0 ) { sps_log2_diff_inax_bt_min_qt_intra_slice_liuna ue(v) sps_log2_diff_max_tt_min_qt_intra_slice_luma ue(v) } if( sps^chroma^fonnatjdc != 0 ) sps_qtbtt_dual_tree_intra_flag u(D if( sps_qtbtt_dual_tree_intra_flag) { sps_log2_diff_min_qt_niiii_cb_intra_slice_chroma ue(v) sps_max_mtt_hierarchy_depth_intra_slice_chroma ue(v) if( sps_max_mtt_hierarchy_depth_intra_slice_chroma != 0 ) { sps_log2_diff_max_bt_min_qt_intra_slice_chroma ue(v) spslog2diffmaxttminqtintrasliccchroma ue(v) } } sps_log2_diff_min_qt_inin_cb_inter_slice ue(v) sps_max_mtt_hierarchy_depth_inter_slice ue(v) if( sps_max_mtt_hierarchy_depth_inter_slice != 0 ) { sps_log2_diff_max_bt_min_qt_inter_slice ue(v) sps_log2_diff inax tt min qt inter slice ue(v) } When the sps_partition_constraints_override_enabled_flag is enabled in the SPS, some 10 picture header syntax elements are transmitted to update the partitioning variables as depicted in the following table of PH syntax elements. picture d ) { Descriptor if( sps_partition_constraints_override_enabled flag) ph partition constraints override flag u(l) if( ph intra slice allowed flag) { if( ph_partition_constraints_override_flag) { ph_log2_diff_inin_qt_min_cb_intra_slice_luma ue(v) ph_max_mtt_hierarchy_depth_iiitra_slice_luma ue(v) if(phjnaxjnUjiicrarchy^depthJntra^sliceJuma != 0){ ph_log2_dlff_max_bt_min_qt_intra_slice_luma ue(v) ph_log2_diff_inax_tt_min_qt_intra_slice_luma ue(v) } if( sps qtbtt dual tree intra flag) { ph_Iog2_diff_min_qt_min_cb_intra_slice_chroma ue(v) ph_max_mtt_hierarchy_depth_intra_slice_chroma ue(v) if( phjnaxjnttJiicrarchyjicpihJntrajdiccj:hroma != 0 ) { P*1_l°g2_diff_n’ax_bt_min_qt_intra_slice_chroma ue(v) ph_log2_diff_max_tt_min_qt_intra_slice_chroma ue(v) } } } } if( phJnter^slice aho\\vdn) { if( ph_partition_constraints_override flag) { ph_log2_diff_inin_qt_min_cb_inter_slice ue(v) phmaxmtthierarchydepthinterslice ue(v) if( ph_max_mtt_hierarchy_depth_inter_slice != 0 ) { ph_log2_diff_max_bt_min_qt_inter_slice ue(v) ph_log2_diff_max_tt_min_qt_inter_slice ue(v) } } VVC splitting restrictions The VVC partitioning has several restrictions. These restrictions are mainly to avoid the same partitioning after several consecutive splits. Figure 11 illustrates some of these 5 constraints. The idea is to avoid the same partitioning with BT and TT. As depicted in Figure 11(a) two consecutive vertical BT split are allowed but a vertical TT followed by a vertical BT split in the center block is not allowed as depicted in Figure 11 (b). In the same way, As depicted in Figure 11 (c) two consecutive horizontal BT split are allowed but a horizontal TT followed by a horizontal BT split in the center block is not allowed 10 as depicted in Figure 11 (d). In VVC there are additional constraints for the minimum chroma block size and for the TT and BT maximum block size for inter block size. These constraints have been removed for the ECM software. Chroma partitioning In VVC, the Chroma partitioning may be inferred based on the Luma partitioning but this can be disabled. When the Dual tree mode is enabled, the partitioning tree of Chroma is independent to the tree of Luma. But some restrictions exist. The tree can be also partially dependent to the Luma partitioning for the crosscomponent linear model (CCLM) mode, otherwise it is independent. Picture boundary The frame resolution is not always equal to an integer multiple of CTU size. Consequently, there can be incomplete CTUs in the borders of the frame as depicted in Figure 12 where CTUs 1201-1206 are incomplete due to the bottom and right boundaries 1207, 1208 of the frame. In VVC, in contrast to the previous standards, the signaling of the split is allowed at the picture boundary. The splitting process in the boundary is applied until that the coding tree node represents a CU located entirely within a picture. But some splits are inferred (not transmitted). Consequently, the different variables such as MaxMttDepth, MinQtDepth MinQTsize, are increased or decreased according to the possible splits not in the boundary. QT BT TT Encoding choice In the VTM and ECM software several encoder side optimizations are used for the QT BT TT encoding choice. One such optimization includes determining if the QT split is tested before the BT split. The condition is that at least one CU on the left or above the current coding tree node has a QT depth larger than the QT depth of the current coding tree node; and if the CU width represented by the current coding tree node is greater than MinQTSize * 2. If this condition is true then the QT is before BT and the splits will be treated as the following order: -No Split -QT -BT Horizontal -BT Vertical -TT Horizontal -TT Vertical Otherwise, the order will be: -No Split -BT Horizontal -BT Vertical -TT Horizontal -TT Vertical -QT This order is important as according to some optimizations, several splits will not be tested depending on results of the first tested modes. So, when QT is tested last there is a lot of occasions where it will not be evaluated. MaxMttDepth The maximum MTT depth has a significant impact on the encoder complexity. The common test conditions for the ECM have been updated to reduce the encoding by settings different MaxMttDepth as depicted in Figure 13. In this setting, the MaxMttDepth is lower for some temporal ID for large resolutions or small QP (quantization parameter) settings. Adaptive MaxBTSize In the VTM and ECM, there is a frame level encoding choice which sets the MaxBTSize according to the average block sizes of the previous encoded frames with the same depth (=> same temporal ID within common test conditions (CTC) random access (RA) case). The average block size is compared to thresholds as the following pseudo code: if( dBlkSize <AMAXBTTH32 ) { newMaxBtSize = 32; } else if( dBlkSize <AMAXBT TH64 ) newMaxBtSize = 64; } else if( dBlkSize <AMAXBTTH128 ) { newMaxBtSize = 128; } 5 else newMaxBtSize = 256; } Where AMAXBTTH32 is equal to 15, AMAXBTTH64 is equal to 30 and 10 AMAXBTJTH128 is equal to 60. This method decreases the maximum BT size when the average block size is small and increases it when it is large. VVC Coding split mode In VVC, the coding split modes are transmitted in the coding tree as depicted in the 15 following syntax table where the conditionally parsed flags, split cu flag, splitqtflag, mtVsplit^cu^vertical^flag, mtt^spliVcu^binary flag define the splitting of a CU. coding_tree( xO, yO, cbWidth, cbHeight, qgOnY, qgOnC, cbSubdiv, cqtDepth, mttDepth, depthOffset, partldx, treeTypeCurr, modeTypeCurr) { Descriptor if( (allowSplitBtVer 11 allowSplitBtHor 11 allowSplitTtVer allowSplitTtHor allowSplitQt) &&(xO + cbWidth <= pps_pic_width_in_luma_samples) && (yO + cbHeight <= pps_pic_height_in_luma_samples)) split_cu_flag ae(v) if( ppscuc^ &&qgOnY &&cbSubdiv <= CuQpDeltaSubdiv) { IsCuQpDeltaCoded = 0 CuQpDeltaVal = 0 CuQgTopLeftX = xO CuQgTopLeftY = yO } if( sh_cu_chronia_qp_offsct_cnabled_flag &&qgOnC &&cbSubdiv <= CuChromaQpOffsetSubdiv ) { IsCuChromaQpOffsetCoded = 0 CuQpOffsetcb = 0 CuQpOffsetcr = 0 CuQpOffsetcbcr = 0 } if( split cu flag) { if( (allowSplitBtVer allowSplitBtHor 11 allowSplitTtVer allowSplitTtHor) &&allowSplitQt) splitqtflag ae(v) if( ! split qt flag) { if( (allowSplitBtHor allowSplitTtHor) &&(allowSplitBtVer allowSplitTtVer)) mttsplitcuverticalflag ae(v) if( ( allowSplitBtVer &&allowSplitTtVer &&mttsplitcuverticalflag) (allowSplitBtHor &&allowSplitTtHor &&!mtt_split_cu_vertical_flag)) mtt_split_cu_binary_flag ae(v) I if( ModeTypeCondition ==1) modeType = MODETYPEINTRA else if( ModeTypeCondition = = 2 ) { noninterflag ae(v) modeType = non inter flag ? MODE TYPE INTRA : MODETYPEINTER } else modeType = modeTy peCurr The VVC specifications contains the following definitions for these syntax elements: splitcuflag equal to 0 specifies that a coding unit is not split, splitcuflag equal to 1 specifies that a coding unit is split into four coding units using a quad split as indicated by the syntax element splitqtflag, or into two coding units using a binary split or into three coding units using a ternary split as indicated by the syntax element mtls^ The binary or ternary split can be either vertical or horizontal as indicated by the syntax element mttsplitcuverticalflag. When split_cu_flag is not present, the value of splitcuflag is inferred as follows: - If one or more of the following conditions are true, the value of split cu flag is inferred to be equal to 1: - xO - cbWidth is greater than pps pic^widthjnjuma samples. - yO + cbHeight is greater than pps_pic_height_in_luma_samples. - Otherwise, the value of split cu flag is inferred to be equal to 0. split qt flag specifies whether a coding unit is split into coding units with half horizontal and vertical size. When split qt flag is not present, the following applies: - If all of the following conditions are true, split qt flag is inferred to be equal to 1: - split cu flag is equal to 1. - allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor and allowSplitTtVer are equal to FALSE. - Otherwise, if allowSplitQt is equal to TRUE, the value of split qt flag is inferred to be equal to 1. - Otherwise, the value of split qt flag is inferred to be equal to 0. mtt split cu vertical flag equal to 0 specifies that a coding unit is split horizontally, mttsplitcuverticalflag equal to 1 specifies that a coding unit is split vertically When mttsplitcuverticalflag is not present, it is inferred as follows: If allowSplitBtHor is equal to TRUE or allowSplitTtHor is equal to TRUE, the value of mtt split cu vertical flag is inferred to be equal to 0. - Otherwise, the value of mtt split cu vertical flag is inferred to be equal to 1. nittsplitcubinaryflag equal to 0 specifies that a coding unit is split into three coding units using a ternary split. mttjspliUcuJiinaryJlag equal to 1 specifies that a coding unit is split into two coding units using a binary split. When nitt split cu binary flag is not present, it is inferred as follows: - If allowSplitBtVer is equal to FALSE and allowSplitBtHor is equal to FALSE, the value of mtt_split_cu_binary_flag is inferred to be equal to 0. Otherwise, if allowSplitTtVer is equal to FALSE and allowSplitTtHor is equal to FALSE, the value of nitt split cu binary flag is inferred to be equal to 1. - Otherwise, if allowSplitBtHor is equal to TRUE and allowSplitTtVer is equal to TRUE, the value of nitt split cu binary flag is inferred to be equal to 1 - mtt split cu vertical flag. - Otherwise (allowSplitBtVer is equal to TRUE and allowSplitTtHor is equal to TRUE), the value of mtUspliUcuJiinaryJlag is inferred to be equal to mtt^spliUcu^vertical^flag. To summarize this description, the split cu flag specifies if the current block is split or not. And this flag is signalled only if at least one other split is allowed for the current block and if the no split is possible for the current block. The split qt flag specifies that the current block is split thanks to the QT split. It is signalled when the splitjmjlag was equal to 0 and when the QT split is available and when at least one MTT split is available. When the current block is not a no split or a QT split, it is split thanks to an MTT split. Two flags are defined to signal the four MTT splits. When at least one horizontal split and at least one vertical split are allowed, the mtUspliUcuj / ertical Jlag is signalled. And it signals, if the MTT split is vertical or horizontal. According to the availability of the MTT splits, and the value of mtt split cu vertical flag, the flag nitt split cu binary flag is decoded to know if the current split is BT or TT. Of course, the checks before decoding these flags avoid an extra signalling of these flags when it is not needed. CAB AC encoder description. Figure 15 corresponds to the classical module of entropy coder in a video codec where syntax elements of elementary information called syntax elements of a video encoder are encoded to produce a bitstream. One of the most popular entropy coding scheme is the context-based adaptive binary arithmetic coding (CABAC) that can be summarized by the diagram (1500) in Figure 15. It was originally designed for the video compression standard H.264 / AVC and is also now part of its successors H.265 / HEVC and H.266 / VVC video standards with some evolutions. The elementary information, to be encoded with CABAC, is given as a sequence of syntax elements (1501), which may be of various type of information related to intra and inter coding modes (motion vector, ...), residual information (transform coefficients, ...) and filtering parameter information of a video codec. The context-based adaptive binary arithmetic coding can be summarized by 3 main steps as depicted in the Figure 15: the context modelling (1504), the probability estimation (1506) (with an initialization step (1505)) and the binary arithmetic encoder (1507). First of all, each syntax element (1501) goes through the binarization process (1502) which consists in converting non-binary-valued syntax elements (e.g., a transform coefficient, motion vector values, ...) into a binary code or a bin string, only composed of “0” and “1”, prior to apply the binary arithmetic coding. In recent video coding standards, the well-known binarization processes comprise the truncated Rice binarization, the truncated binary (TB) binarization, the k-th order Exp-Golomb (EGk) binarization and the fixed-length (FL) binarization. Two different types of binary symbols can be then considered: the bin and the by-pass bin. These two different types of binary symbols are known by definition in advance for each bin of each syntax element (1501) and this defines two possible encoding paths as illustrated by the switch in (1503). It is important to note that bypass bins, context models and binarization schemes for each syntax element are predefined in the video coding standard text describing the specifications. If the bin of the syntax element is not by-passed, the context modelling (1504) associates to each bin, one of the pre-defined context models which is identified by a context model index. The objective of associating bin with context model is to group bins with similar statistical properties in order to reduce the overall bit rate allocated to represent that bin. Then, for each context model index, a probability estimation is derived for the bin in step (1506). It is performed by a transition process between generally 64 separate probability states. This probability is first initialized at a certain given probability value, in step (1505) for example at the beginning of each coded slice. This initialization is carried out based on predefined information related the context modelling step. Then this probability estimation (1506) module is also used to update the probability according to the current bin value under processing. This probability is then also used for the subsequent binary arithmetic encoder. In the case where the bins are by-passed, the bins are directly encoded by the binary arithmetic encoder (1507) without going through steps (1503) and (1506) as they are either assumed to be uniformly distributed. The by-pass path is generally used when for a particular bin, the value ”0” and “1” are equiprobable. It is also used to get a faster encoding (and decoding) process for certain high-end applications which require a very higher throughput. The binary arithmetic encoder (1507) includes a fast arithmetic module that involves a tablebased recursive probability interval subdivision for the encoding of the regular bins. The principle is to divide the current interval into sub-intervals, each representing a fraction of the current interval proportional to the probability of the current bin. Whichever interval corresponds to the actual symbol that is next to be encoded becomes the interval used in the next step. When all bins have been encoded, the resulting interval unambiguously identifies the sequence of binary information that produced it. Different implementations of the binary arithmetic encoder module (1507) are known in the literature and the most popular ones are the Q coder [1] and its derivatives known as QM and MQ coder [2], The binary arithmetic encoder (1507) also includes a fast bypass coding mode for the encoding of bypass bins. Figure 16 corresponds to the reverse operation regarding the entropy encoder presented in Figure 1. It consists in retrieving the syntax elements (1608) for the bitstream (1601). The context-based adaptive binary arithmetic decoding can be considered as the module (1600). As shown in Figure 16, the bitstream is decomposed by the bitstream parser (1602) which enables to respect the order of the syntax elements encoded in the bitstream (1601). Then according to the syntax element and the bin to be decoded (1609), similarly to what was carried out at the encoder, two decoding paths in the module (1606) are possible to decode either using a by-pass bin or a regular bin. These two different paths for the binary symbols are known by definition for each bin of each syntax element from the bitstream (1602). When the bin is by-passed coded, it is directly provided through the by-pass decoding engine of the module (1606). Otherwise, the bin is processed through the regular decoding engine of module (1606). In that case, the context modelling of this particular bin is determined in module (163) and the context model index is provided to the probability estimation module (1605). An initialization step is also performed to set the probability to a certain starting value in the module (1604). Similar to the encoder side, the initialization is performed at some particular locations of the video data structure, for example, at the beginning of a slice. Then the estimated probability is used to retrieve from the bitstream the encoded bin through the regular decoding engine of the binary arithmetic decoder (1606). The output of the module (1606) is a bin of value “0“ or “1”. The regular decoding engine applies the same table-based recursive probability interval subdivision process to unambiguously identifies the sequence of bins from the bitstream. Then according to the syntax element being decoded, outputted bins are accumulated before the inverse binarization module (1607) thanks to the loop over the bins. The bin string is then inputted in the inverse binarization process to reconstruct the true value of the decoded syntax elements (1608). In the WC, each syntax element which is CAB AC coded has its own context. For many syntax elements, several contexts are considered. They are obtained by deriving a context increment which gives the number of the context for this syntax element. And each of this context value has its own initialization values and are updated independently. VVC Context derivation for split modes signalling The four flags for the split signaling are CABAC context coded. The contexts for these flags depend on one block Left and one block Above, the availabilities of the current splits, the size of the current block and the size of the Left and Up block, the current QT value and on the QT values of the Left and Up block, the ratio between the width and the height of the current block and the neighboring Left and Up block. The block Above block and the Left block are respectively the blocks at the positions B3 and A2 as depicted in Figure 6. For splitqtflag and splitcuflag the context increment value ctxlnc, is obtained according to the following formula: ctxlnc = (condL &&availableL) + (condA &&availableA) + ctxSetldx * 3 where availableL and availableA are the availaibility of Left and Above blocks. The variables condL, condA and ctxSetldx are defined differently for split qt flag and splitcuflag. For splitcufl the variable condL is defined as the following: CbHeight[ chType ][ xNbL ][ yNbL ] <cbHeight Where CbHeight[ chType ][ xNbL ][ yNbL ] is the height of the Left block. And cbHeight is the height of the current block. So, condL is set equal to 1, if the height of the left block is strictly inferior to the height of the current block. So, the context for split cu flag is incremented if the left block has a smallest height than the current block. The variable chType corresponds to Luma or Chroma Chanel. Indeed, for Intra frames, the split of the Luma and chroma can be different as mentioned previously. In the same way, condA is defined as the following: CbWidth[ chType ][ xNbA ][ yNbA ] <cbWidth Where CbWidth[ chType ][ xNbA ][ yNbA ] is the width of the Above block. And cbWidth is the width of the current block. So, condA is set equal to 1, if the width of the above block is strictly inferior to the width of the current block. So, the context for split cu flag is incremented if the above block has a smallest width than the current block. The variable ctxSetldx, for split cu flag, is set according to the following formula: ctxSetldx = (allowSplitBtVer + allowSplitBtHor + allowSplitTtVer + allowSplitTtHor + 2 * allowSplitQt -1) / 2 where allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, allowSplitQt are respectively, the allowances of vertical BT split, horizontal BT split, vertical TT split, horizontal TT and QT split. So, the context, for splitcuflag, changes according to the number of allowed splits for the current block. For split cu flag, the variable condL is defined as the following: CbHeight[ chType ][ xNbL ][ yNbL ] <cbHeight Where CbHeight [ chType ][ xNbL ][ yNbL ] is the height of the Left block and cbHeight is the height of the current block. So, when the height of the current block is larger than the height of the left block, the context value is incremented. In the same way, condA is defined as the following: CbWidth[ chType ][ xNbA ][ yNbA ] <cbWidth Where CbWidth[ chType ][ xNbA ][ yNbA ] is the width of the up block and cbWidth is the width of the current block. So, when the width of the current block is larger than the width of the up block, the context increment value is incremented. For splitqtflag, the variable condL is defined as the following: CqtDepth[ chType ][ xNbL ][ yNbL ] >cqtDepth Where CqtDepth[ chType ][ xNbL ][ yNbL ] is the QT depth of the Left block and cqtDepth is the current QT depth. So, when the QT depth is larger for the left block than for the current block (before the decoding of the flag), the context value is incremented. In the same way, condA is defined as the following: CqtDepth[ chType ][ xNbA ][ yNbA ] >cqtDepth Where CqtDepth[ chType ][ xNbA ][ yNbA ] is the QT depth of the Above block and cqtDepth is the current QT depth. So, when the QT depth is larger for the above block than for the current block (before the decoding of the flag), the context value is incremented. The variable ctxSetldx, for splitqtflag, is set according to the following formula: ctxSetldx = cqtDepth >= 2 So when, the current QT depth is at least equal to 2, the context variables are different to the context variables when the QT depth is equal to 0 or 1 whatever the left and above block. The context increment ctxlnc for the mttsplitcuverticalflag is defined as the following in VVC specifications: The assignment of ctxlnc is specified as follows: - If allowSplitBtVer + allowSplitTtVer is greater than allowSplitBtHor + allowSplitTtHor, ctxlnc is set equal to 4. - Otherwise, if allowSplitBtVer + allowSplitTtVer is less than allowSplitBtHor + allowSplitTtHor, ctxlnc is set equal to 3. - Otherwise, the following applies: The variables dA and dL are derived as follows dA = cbWidth I (availableA ? CbWidth[ chType ][ xNbA ][ yNbA ] : 1 ) dL = cbHeight / ( availableL ? CbHeight[ chType ][ xNbL ][ yNbL ] : 1 ) - If one or more of the following conditions are true, ctxlnc is set equal to 0: dA is equal to dL, availableA is equal to FALSE, availableL is equal to FALSE. - Otherwise, if dA is less than dL, ctxlnc is set equal to 1. - Otherwise, ctxlnc is set equal to 2. In this specification, the Above block and the Left block are at the same positions as for the other split flag. So, the context increment value depends on the number of vertical splits and horizontal splits. And also, on the widths of the current block and the above block as well the heights of the current block and the above block. The context increment ctxlnc for the mtvsplivcujrinaryjlag is defined as the following formula: ctxlnc = ( 2 * mtt split cu vertical flag ) + ( mttDepth <= 171:0) So, the probabilities are separated according to the value of mttsplitcuverticalflag. So according to the horizontal and Vertical. And depending on that the mttDepth is superior to 1 or not. Previous work In previous work, the availability of split modes is determined by some rules including the minimum QT depth, an average QT depth obtained from a temporal area. In another previous work the maximum MTT depth for a current block is determined based on the value of maximum MTT depth obtained from a temporal area. This value can be incremented or decremented compared to the value for the current picture. In another previous the order of the partitioning syntax element is changed according to some variables including some temporal variables. EMBODIMENTS In an embodiment, at least one temporal variable is used to determine a context value for partitioning syntax elements. An advantage of this embodiment is a coding efficiency increase as the context values determination takes into account temporal correlation between the current partitioning and a temporal one. Multiply the spatial context value by a value obtained by at least one temporal variable. In an embodiment, the context increment value of a partitioning syntax element is obtained by multiplying the value of the context increment obtained with spatial values by a temporal context increment factor obtained from temporal variables. An advantage is an increase of the coding efficiency. Indeed, the temporal context increment factor, tempoFactor, can exploit the temporal correlations between partitioning of the current frame and the temporal frame thanks to the split of contexts without impacting the spatial correlation exploited by the traditional context. Temporal factor for splitqtflag and splitcuflag In embodiment, for splitqtflag and splitcuflag of VVC, the context increment, ctxlnc, is obtained by multiplying the spatial context increment by a temporal factor according to the following formula: ctxlnc = tempoFactor * (( condL &&availableL ) + ( condA &&availableA ) + ctxSetldx * 3) where tempoFactor is the temporal context increment factor. An advantage is a coding efficiency improvement for the split qt flag and split cu flag coding. Temporal factor for mttsplitcuverticalflag In another embodiment, for mttsplitcuverticalflag, the context increment, ctxlnc, is obtained as follows: ctxlnc = tempoFactor * ctxIncSpa where ctxIncSpa is the spatial context increment which can be obtained thanks to the conditions as defined for VVC and tempoFactor is the temporal context increment factor. An advantage is a coding efficiency improvement for the mtt split cu vertical flag coding. Temporal factor for mttsplitcubinaryflag In another embodiment, for mtt ^ the context increment, ctxlnc, is obtained as follows: ctxlnc = tempoFactor * ( 2 * mtt split cu vertical flag ) + ( mttDepth <= 171:0) An advantage is a coding efficiency improvement for the mtt_split_cu_binary_flag coding. Formulas for Temporal factor The temporal factor is obtained by comparing the current QT depth to the temporal QT depth In an embodiment, the value of the temporal factor is obtained by comparing the current QT depth to the temporal QT depth as follows: tempoFactor = QTDepth <TempoQTDepth So, the temporal factor is equal to 1 if the QT depth of the current block is less than the temporal QT depth obtained from a temporal area. Otherwise, it is equal to 0. An advantage is a coding efficiency improvement as the division of the context takes into account the QT depth and the temporal QT depth which are correlated. Alternatively, the temporal factor can be obtained with according to the following formulas: tempoFactor = QTDepth <= TempoQTDepth tempoFactor = QTDepth <= TempoQTDepth-1 tempoFactor = QTDepth <= TempoQTDepth+1 or other equivalent formulas based on the above two variables (current QT depth (QTDepth) and temporal QT (TemporalQTDepth)). Applied to splitqtJlag and splitcuflag In one embodiment, the temporal factor is used as the temporal factor for split qt flag and / or additionally for splitcuflag. An advantage of using this temporal factor for these syntax elements is that they are used to signal the QT split so these variables splitqt and splitcuflag. are highly correlated to the value of QT split. Applied to split cu flag when MTT depth=0 In one alternative embodiment, the temporal factor for the split cu flag depends on the temporal QT depth and the current QT depth only when MTT depth is equal to 0. Indeed, as mentioned previously, when the MTT partitioning has been selected there is no additional QT split. Consequently, the value of the split cu flag is less corelated to the QT depth value when the QT can’t be used. The temporal factor depends on the temporal MTT depth In one embodiment, the temporal factor depends on the value of the temporal MTT depth. An advantage is a coding efficiency improvement as the temporal MTT depth is correlated to the current MTT depth. TempoFactor = TempoMttDepth In one embodiment, the temporal factor for the nitt split cu biiiary llag depends on the value of temporal MTT depth. For example, the temporal factor is set equal to the temporal MTT depth: tempoFactor = TempoMttDepth An advantage of using this embodiment is a coding efficiency improvement as the temporal QT depth is correlated to the selection of the MTT partitioning. For example, the TT partitioning is mainly selected when the Temporal MTT Depth is low and the BT partitioning has high selection when the temporal MT Depth is high. (For example, MTT depth with value equals to 0 or 1 is low and MTT depth with value equals to 2 or 3 is high). The temporal factor for the mtt_split_cu_binary^lag depends on the value of temporal MTT depth compared to the current MTT depth In one embodiment, the temporal factor for the mtt split cu binary flag depends on the value of temporal MTT depth compared to the current MTT depth. For example, the temporal factor is set as follows: tempoFactor = (MttDepth >TempoMttDepth) + 1 where MttDepth >TempoMttDepth is set equal to 1 when MttDepth is strictly superior to TempoMttDepth, and to 0 otherwise. Compared to the previous embodiment, this one is more efficient as it depends on both the temporal MTT Depth and the current MT Depth value and also because less contexts are needed which offers a faster convergence of the optimal probabilities. Moreover, it is less complex as only one context is needed. The temporal factor for the mttsplitcuverticalJlag depends on the value of temporal height and the value of temporal width In one embodiment, the temporal factor for the depends on the value of temporal height and the value of temporal width. For example, the temporal factor can be set as follows: tempoFactor = (TempoHeight >TempoWidth) + 1 where, for example, TempoHeight is an average of heights of temporal blocks from a temporal area and TempoWidth is an average of widths of temporal blocks from a temporal area. An advantage of this embodiment is a coding efficiency improvement as the partitioning of a current block is correlated to the partitioning of the temporal area, so, the usage of the temporal height and width is efficient to split the contexts for the mttsplitcuverti calfl ag. Derived temporal context values only In an embodiment, the context increments of partitioning syntax elements are obtained by deriving temporal variables only or variables for the current block. In this embodiment the neighbouring blocks are excluded. The advantage of this embodiment is a coding efficiency improvement. Indeed, sometimes, the correlation between the current partitioning and the temporal one is better than the spatial correlation. This can happen for example when frames contain small slices for some applications. In that case, the number of neighbouring blocks is not enough to use the spatial correlations between blocks. splitqtJlag and splitcu_Jlag In one embodiment, the context increment of the split_cu_flag and split qt flag is obtained by considering a temporal condition and its availability as in the following formula: ctxlnc = (condTempo &&availableTempo )+ ctxSetldx * 2 In this embodiment the ctxSetldx is multiplied by 2 instead of 3 in the regular spatial context increment derivation, and the number of contexts is reduced by 50%. Temporal condition for split cu_flag In an example, for split_cu_flag, the variable condTempo is defined by the comparison of the height and the width of the current block to respectively the temporal height and width as shown in the following formulae: (CbHeight[ chType ][ xNbL ][ yNbL ] <TempoHeight) AND (CbWidth[ chType ][ xNbA ][ yNbA ] <TempoWidth) Or alternatively, (CbHeight[ chType ][ xNbL ][ yNbL ] <TempoHeight) OR (CbWidth[ chType ][ xNbA ][ yNbA ] <TempoWidth) In an example, TempoHeight and TempoWidth can be defined as mentioned above i.e., TempoHeight is an average of heights of temporal blocks from a temporal area and TempoWidth is an average of widths of temporal blocks from a temporal area. Temporal condition for splitqtjlag In an example, for splitqtflag, the variable condTempo is defined by the comparison of the current QT depth to the temporal QT depth as follows: CqtDepth[ chType ][ xNbL ][ yNbL ] >TempoQtDepth where TempoQtDepth is the average temporal QT depth obtained from the temporal area. This condition condTempo can be also considered for splitcuflag as the temporal prediction of the QT depth is very efficient. More adaptively this condition can be considered when the QT partitioning is available. Otherwise (when QT partitioning is not allowed) the previously defined conditions are considered. ctxSetldx, for splitqtJlag In an example, the variable ctxSetldx, for split qt flag, is obtained by comparing the temporal QT depth to 2 according to the following formula: ctxSetldx = TempoQtDepth >= 2 ctxSetldx, for splitcuflag as split qt Jlag In an example, the above derivation of ctxSetldx can be also considered for the splitcuflag. As previously defined, this can be applied only when the QT split is allowed and the regular derivation of ctxSetldx when the QT split is not allowed. ctxSetldx,for splitcuflag as splitqtJlag only when QT split allowed As previously defined, this can be applied only when the QT split is allowed and the regular derivation of ctxSetldx when the QT split is not allowed. Temporal condition for mttsplitcubinaryJlag In an alternative embodiment, the context increment assignment of ctxlnc for the rnttsjjlitc Jlag can be defined by defined temporal conditions and allowance of temporal variables, as for example, the temporal height and width as the following: - If allowSplitBtVer + allowSplitTtVer is greater than allowSplitBtHor + allowSplitTtHor, ctxlnc is set equal to 4. - Otherwise, if allowSplitBtVer + allowSplitTtVer is less than allowSplitBtHor + allowSplitTtHor, ctxlnc is set equal to 3. - Otherwise, the following applies: - The variables dTempoH and dTempoW are derived as follows dTempoH = cbWidth / ( availableTempo ? TempoWidth: 1) dTempoW = cbHeight / ( availableTempo? TempoHeight: 1) - If one or more of the following conditions are true, ctxlnc is set equal to 0: dTempoH is equal to dTempoW, availableTempo is equal to FALSE, - Otherwise, if dTempoH is less than dTempoW, ctxlnc is set equal to 1. - Otherwise, ctxlnc is set equal to 2. Temporal condition for mttsplitcubinaryJlag In another embodiment, the context increment ctxlnc for the mtt split cu binary flag is defined by considering the average temporal MTT depth or another metric representing the temporal MTT depth as shown in the following formula: ctxlnc = (2 * mtjspli t_cu jverti cal Jlag ) + ( mttDepth <= TempoMttDepth -1 ? 1 : 0 ) Switch between spatial and temporal context derivation Signaled in a header In one additional embodiment, the temporal context derivation as defined previously is enabled and it replaces the regular spatial context derivations when a header flag enables the temporal context derivation. The header flag may be transmitted at SPS, PPS, Picture header or Slice level. An advantage is that encoder can select the best context derivation between temporal context derivation or spatial context derivation. So, it increases the coding efficiency as well as the flexibly for implementation. Smaller granularity Alternatively, it may be transmitted at another smaller granularity as tiles or CTU. An advantage compared to previous embodiment is a coding efficiency improvement as the context derivation can be selected at a finer granularity. In this embodiment, we can consider that the context increment value given by the temporal or spatial derivation refers to the same context. Indeed, this is more efficient and it reduces the total number of contexts. When spatial blocks are not available In one additional embodiment, the temporal derivation is enabled when the two spatial neighbouring blocks are not available. Otherwise, the regular derivation is used. In this embodiment, we can consider that the context increment value given by the temporal or spatial derivation refers to the same context. Indeed, this is more efficient and it reduces the total number of contexts. An advantage is that context derivation can be achieved regardless of the availability of the neighbouring blocks. In addition, compared to previous embodiment there is a coding efficiency improvement as the context derivation can be selected at a finer granularity. Derived spatio-temporal context values. In an embodiment, the context increments of partitioning syntax elements are obtained by deriving temporal variables and spatial variables for the current block. This embodiment is different to the embodiment related to the multiplication by a temporal factor in the sense that the temporal variables are jointly used with the spatial variables. More precisely these temporal variables are derived as the spatial variables. An advantage of this embodiment is a reduction of contexts needed to exploit the spatiotemporal correlations of the partitioning compared to the multiplication of temporal factor. This reduces the memory needed to store the initial values as well as the contexts value during encoding and decoding process. In one embodiment, the context increment of the splitcuflag and splitqtflag is obtained by adding a temporal condition and its availability as shown in the following formula: ctxlnc = ( condL &&availableL ) + ( condA &&availableA) + ( condTempo &&availableTempo ) + ctxSetldx * 4 Please note that the ctxSetldx is multiplied by 4 instead of 3 in the regular derivation as the number of contexts should be increased to consider the additional temporal condition. This increase consequently increases the number of contexts for split cu flag by 33%. The variables condTempo and availableTempo can be set as described for the embodiment where only temporal variables are considered. Temporal condition for splitcu^flag In an example, for split cu flag, the variable condTempo is defined by the comparison of the height and the width of the current block to respectively the temporal height and width as follows: (CbHeight[ ch Type ][ xNbL ][ yNbL ] <TempoHeight) AND (CbWidth[ chType ][ xNbA ][ yNbA ] <TempoWidth) Or alternatively, (CbHeight[ chType ][ xNbL ][ yNbL ] <TempoHeight) OR (CbWidth[ chType ][ xNbA ][ yNbA ] <TempoWidth) In an example, TempoHeight and TempoWidth can be defined as mentioned above, i.e., TempoHeight is an average of heights of temporal blocks from a temporal area and TempoWidth is an average of widths of temporal blocks from a temporal area. Temporal condition for splitq In an example, for splitqtflag, the variable condTempo is defined by the comparison of the current QT depth to the temporal QT depth as follows: CqtDepth[ chType ][ xNbL ][ yNbL ] >TempoQtDepth Temporal condition for splitcu_Jlag as split_qt_flag based on QT allowance In one embodiment the condition for the split cu flag is based on QT being enabled. Otherwise the condition is based on the temporal height and width as described previously. Alternatively, the contexts are separated based on if QT is enabled or not. For example, the formula for the split cu llag can be: ctxlnc = (allowSplitQt +1) * (( condL &&availableL) + (condA &&availableA) + ( condTempo &&availableTempo ) + ctxSetldx * 4) Temporal condition for split cu_flag as splitqtflag based on QT depth In one alternative embodiment the switch depends on the current QT depth and the average temporal QT depth. For example, the context increment for the sjjlitciitLi can be obtained based on the following formula: ctxlnc = ((cqtDepth >= TempoQtDepth)+l) * (( condL &&availableL ) + ( condA &&availableA) + (condTempo &&availableTempo) + ctxSetldx * 4) ctxSetldx, for splitqtJlag In one embodiment, the variable ctxSetldx, for split qt flag, is obtained by comparing the current QT depth to the temporal QT depth as shown in the following formula: ctxSetldx = cqtDepth >= TempoQtDepth where the TempoQtDepth is the average temporal QT depth from the temporal area. ctxSetldx, for splitqtJlag In one alternative embodiment, the variable ctxSetldx, for splitqtflag, is obtained by comparing the temporal QT depth to 2 according to the following formula: ctxSetldx = TempoQtDepth >= 2 Temporal condition for mttsplitcubinaryflag In one embodiment, the context increment assignment of ctxlnc for the mtt split cu vertical flag can be defined by the division of current width by the temporal height and the division of current height by the temporal width, as described in the following: - If allowSplitBtVer + allowSplitTtVer is greater than allowSplitBtHor + allowSplitTtHor, ctxlnc is set equal to 4. - Otherwise, if allowSplitBtVer + allowSplitTtVer is less than allowSplitBtHor + allowSplitTtHor, ctxlnc is set equal to 3. Otherwise, the following applies: The variables dA, dL, dTempoH and dTempoW are derived as follows dA = cbWidth / ( availableA ? CbWidth[ chType ][ xNbA ][ yNbA ] : 1 ) dL = cbHeight / ( availableL ? CbHeight[ chType ][ xNbL ][ yNbL ] : 1 ) dTempoH = cbWidth / ( availableTempo ? TempoWidth: 1 ) dTempoW = cbHeight / ( availableTempo? TempoHeight: 1) - If one or more of the following conditions are true, ctxlnc is set equal to 0: dA is equal to dL, availableA is equal to FALSE, availableL is equal to FALSE. dTempoH is equal to dTempoW, availableTempo is equal to FALSE, - Otherwise, if dA is less than dL and if dTempoH is less than dTempoW, ctxlnc is set equal to 1. - Otherwise, ctxlnc is set equal to 2. Temporal condition for mttsplitcubinary_Jlag In one embodiment, similarly to the embodiment where only temporal variables are considered, the context increment ctxlnc for the mtt split cu binary flag is defined by considering the average temporal MTT depth or another metric representing the temporal MTT depth as shown in the following formula: ctxlnc = ( 2 * mttsplitcuverticalflag) + (mttDepth <= TempoMttDepth -1 ? 1 : 0) Same number of contexts when using temporal variables In one embodiment, when the temporal variables are used, the number of contexts is not increased compared to a solution when only spatial variable are used. For example, Intra frame have no temporal reference frames. In the previous embodiment, for spatio-temporal derivation, there is an increase of the number of contexts compared to a spatial only solution. An advantage of this embodiment is a complexity reduction as less memory is needed for the initial context values and for the contexts updates. splitqtJlag and split cu flag In one embodiment, the context increment of the split cu^fl and S]31itqtllag is obtained by computing the sum of the condition for the left block, the above block and the temporal condition plus 1 and this sum is divided by 2 in order that this value can’t be larger than 3. The following formula illustrates this embodiment: ctxlnc = ((condL &&availableL) + (condA &&availableA) + (condTempo &&availableTempo )+1) / 2 + ctxSetldx * 3 split qt Jlag and splitcuflag alternative In one alternative embodiment, the sum is divided by 1 + the availability of the temporal area instead of 2 as in the following: ctxlnc = ((condL &&availableL) + (condA &&availableA) + (condTempo &&availableTempo )+1) / (1 + availableTempo) + ctxSetldx * 3 In that case when the temporal area is not available, the same value of context increment as spatial only derivation is obtained. splitqtJlag and splitcu_jlag alternative In one alternative embodiment, for split cu flag, the temporal variable is used directly in the derivation of the condition left (condL) and in the derivation of condition above (condA). The equation can be as follows: ctxlnc = ( condL &&(availableL || availableTempo ) + ( condA &&(availableA || availableTempo)) + ctxSetldx * 3 where the variable condL can be defined by adding to the regular condition condL, the comparison of the left height value to the temporal height value can be defined as the following: (CbHeight[ chType ][ xNbL ][ yNbL ] <cbHeight) OR (CbHeight[ chType ][ xNbL ][ yNbL ] <TempoHeight) And, similarly, the variable condA can be defined by adding to the regular condition condA, the comparison of the above width value to the temporal width value, as the following: (CbWidth[ chType ][ xNbA ][ yNbA ] <cbWidth) OR (CbWidth[ chType ][ xNbA ][ yNbA ] <TempoWidth) Regular context increment derivation when the temporal is not available In one embodiment combined to all previous embodiments, when the temporal is not available, the regular spatial increment is applied. An advantage is that the context increment value is determined based on an efficient spatial derivation when temporal variables are not available. Derived context value according to a comparison of spatial and temporal variables. In one embodiment, the context increment value is obtained by comparing spatial and temporal variables. This is the case for several examples and embodiments presented before. And this is particularly efficient in term of coding efficiency increase. Use separated contexts depending on the coding order. In our previous work, we modified the order of the partitioning syntax elements when the current QT depth is strictly inferior to the average temporal QT depth from a temporal area. More precisely, the split qt flag is coded first when the current QT depth is strictly inferior to the average temporal QT depth and after otherwise. In one embodiment the contexts are separated when the current QT depth is strictly inferior to the average temporal QT depth from a temporal area and not separated when it is superior or equal to the average temporal QT depth from a temporal area. In that case, the 2 sets of context values are considered. This can be obtained for example for split cu flag and split qt flag by adding a temporal factor which compares the current QT depth to the temporal QT depth as the following: ctxlnc = ((cqtDepth <TempoQtDepth)+l) * (( condL &&availableL ) + ( condA &&availableA ) + ctxSetldx * 3) This embodiment can be limited to these 2 syntax elements. An advantage is a coding efficiency improvement, as the temporal correlation is important between partitioning especially for these 2 syntax elements. Temporal variables At least one parameter is a temporal parameter In an embodiment, at least one parameter is a temporal parameter, to exploit temporal correlations. The temporal parameter or parameters are derived from a temporal area. The temporal area is defined later in description of the invention. An advantage is a coding efficiency improvement, as the context derivation is adapted to take into account the temporal correlations between a temporal partitioning and the current one. But in opposite to the spatial correlations, this can’t be exploited for the first intra frame of a sequence or a GOP. The QT Depth value of a temporal area In an embodiment, the QT depth value computed from a temporal area is considered to change the context increment value. An advantage is coding efficiency improvement as the QT depth obtained from a temporal area is correlated to the QT depth of the current block. The average / minimum / maximum QT of a temporal area In an embodiment, instead of considering only the QT depth of the temporal area, the average QT depth, and / or the minimum and / or the maximum are considered or also considered to determine the best context increment value of the split qt_flag or split_cu_flag or all flags. An advantage is coding efficiency improvement as the average, the minimum and the maximum are more relevant to determine the correlation. The MTT depth value of a temporal area In an embodiment, the MTT depth value of a temporal area is considered to change the context increment value. In an another example, its value is converted in order to be compared to the QT depth. In one example, the conversion is a division by 2 and for example, it is added to the value of the temporal QT depth. An advantage is coding efficiency improvement as the MTT depth of the current block is correlated to the MTT depth of a temporal area. The average / minimum / maximum MTT depth of a temporal area In an embodiment, instead of considering only the MTT depth of a temporal area, the average MTT depth, and / or the minimum or the maximum are also considered to determine the best context increment of all flags. An advantage is coding efficiency improvement as the average, the minimum and the maximum are more relevant to determine the temporal correlation. The BT or TT Depth values / average / minimum / maximum. In an embodiment, the BT depth and / or the TT depth or the average, the minimum, the maximum of BT depth and / or the TT depth can be considered to compute the context increment of partitioning syntax elements. An advantage is coding efficiency improvement as a finer granularity to set a context increment value to improve the coding efficiency. The height and the width or a ratio of a temporal area In an embodiment, the height and the width or an average of the height or the width of the blocks from a temporal area are compared to the current height and width of the current block to determine the context increment of the partitioning syntax elements for the current block. An average or minimum or a maximum of a ratio between the height and width of the blocks from a temporal area can be alternatively or additionally also considered. Alternatively, or additionally, the ratio between the height and width of the temporal is compared to the ratio of the height and the width of the current block. An advantage is coding efficiency improvement as the ratio gives the information of the direction of the temporal area compared to the current block. So, when it used, it is useful to determine a context increment for the MTT split flag values. Temporal Area Collocated In an embodiment, the block considered to determine a temporal value of the QT depth or block size is the QT depth value or the block size of the temporal collocated block or a temporal block shifted by a motion vector value obtained from a neighboring block, for example. Similarly, the MaxMttDepth can be the MttDepth of the temporal collocated block or a temporal block shifted by a motion vector value obtained from a neighboring block, for example. A plurality of positions In an embodiment, several positions of blocks are considered to determine a temporal value of the QT depth or block size or for the maximum MTT depth or for the average MTT depth. For example, the positions C, TL, TR, BL, BR, of Figure 14 can be considered. In this figure the position C is the center of the temporal collocated block. Positions TL, TR, BL, BR are respectively, the Top Left, Top right, Bottom Left and Bottom Right position around the temporal collocated block. Compared to the previous embodiment, the current one increases the coding efficiency as the temporal QT depth determined or the temporal block size or the average temporal MTT depth or the maximum MTT depth is more often reliable. A higher area In an embodiment, a temporal value of the QT depth or block size or the average temporal MTT depth or the maximum MTT depth is determined based on a temporal area. For example, the temporal area is a collocated CTU. Compared to the two previous embodiments, more blocks can be considered, so the coding efficiency increases. The center of the current block is used to determine the temporal positions In an embodiment, to determine the collocated block or several temporal blocks or a temporal area, the center of the current block is considered. An advantage is an increase of coding efficiency as the center is the best position to represent the current block. Alternatively, when the center of the block is outside the current frame, the top left position is considered. A whole frame In an embodiment, a temporal value of the QT depth or the block size or the average temporal MTT depth or the maximum MTT depth is determined based on all blocks of a temporal frame. An advantage of this embodiment is a simplification of the process to determine the temporal QT depth or block size or the average temporal MTT depth or the maximum MTT depth value, but it is less efficient because it is less adapted to the content compared to the previous embodiments. A frame with the same temporal ID In an embodiment, the collocated block or several temporal blocks or a temporal area, come from a frame with the same temporal ID. For the example of the Random Access, configuration as represented in Figure 7, if the current frame has a temporal ID equal to 4, another encoded / decoded frame with the same temporal ID equal to 4 is used to determine the values of the proposed method. The frames with the same temporal ID often have the same coding parameters. In particular, they often have the same or similar QP and the same spatial distances to their reference frames. So, they are very useful to predict the QT depth or the average temporal MTT depth or the maximum MTT depth, as this data is correlated to the QP and the spatial distance between frames. The closest frame with the same temporal ID In an embodiment, the collocated block or several temporal blocks or a temporal area, come from the closest frame with the same temporal ID. For the example of the Random Access configuration, as represented in Figure 7, the closest frame with the same temporal ID is (generally) more correlated than the others. So, the result is better. A frame or a reference frame with the same QP In an embodiment, the collocated block or several temporal blocks or a temporal area, come from a frame or a reference frame with the same QP. Ideally, a reference frame with the same QP. As mentioned above, the QP has an important influence on the block partitioning. So, with a frame with the same QP, the temporal QT depth or block size or the average temporal MTT depth or the maximum MTT depth is a better predictor. A reference frame which is the same as those used for the temporal Motion vector prediction In an embodiment, the collocated block or several temporal blocks or a temporal area, come from the reference frame which is used for the temporal motion vector prediction. This can be the first reference of the reference List 0 or the first reference frame of List 1 according to a flag transmitted in the picture header or in the slice header. Surprisingly, this embodiment gives the best coding efficiency even if this reference frame has a lower QP. Yet, it is closer to the current frame compared to all frames with the same temporal ID. The closest reference frame In an embodiment, the collocated block or several temporal blocks or a temporal area, come from the closest reference frame. As explained for the previous embodiment, the distance to the current frame provides a useful compromise between encoder time reduction and coding efficiency, even if the frames with the same QP have statistically more correlations between their QP depths and MTT depth. More than one reference frame In an embodiment, two reference frames are considered and two temporal areas or two sets of several blocks or two collocated blocks are used to determine two temporal QT depths or two block sizes. These are then used to determine one QT depth or one block size or one MTT depth. For example, the minimum of QT depth from the two temporal areas can be considered. More than two reference frames can also be considered. An advantage is a better compromise between encoder time reduction and coding efficiency as the QT depth value or the MTT depth value is computed from more data. This is particularly efficient when both reference frames have the same temporal distance, but it increases the number of memory accesses. Use parameters transmitted in one or more Header (SPS, PPS, PH, SH? etc...) for the context derivation of the partitioning syntax elements. In one embodiment, at least one parameter is transmitted in a header and it is used to determine the context increment value for partitioning syntax elements. This at least one parameter can be transmitted in the SPS, PPS, Picture header or Slice header. An advantage of this embodiment is that there is no dependency on others frame for the parsing compared to a solution which uses temporal variables. Consequently, it simplifies the parsing and the parsing of the bitstream corresponding to the current frame doesn’t need the parsing of other frames. ctxSetldx of split_qtJlag In one embodiment, the determination of the ctxSetldx value of splitqtflag is determined by comparing the current QT depth to a slice header QT depth, as the following formula: ctxSetldx = cqtDepth >= shqtDepth, instead of the regular formula where the current QT depth is compared to 2: ctxSetldx = cqtDepth >= 2 In this formula, sh qtDepth is a parameter transmitted in the slice header. It represents a slice header QT depth. Of course, alternatively and additionally, this parameter can be ph qtDepth, transmitted in the picture header, and / or pps q transmitted in the picture parameters set (PPS), and / or sps qtDepth, transmitted in the sequence parameters set (SPS). ctxSetldx of splitqtflag alternative In one embodiment, by considering that the values of these parameters are set equal to 0 when not transmitted and transmitted in the lowest available level the formula can be: ctxSetldx = cqtDepth >= sps^qtDepth + pps qtDepth + phqtDepth + sh qtDepth ctxlnc of intt spHt cu binary flug In one other embodiment, the determination of the context increment ctxlnc value of mtt split cu binary flag is determined by comparing the current MTT depth to a slice header MTT depth from the slice header as in the following formula: ctxlnc = (2 * mtt_split_cu_vertical_flag ) + ( mttDepth <= sh m instead of the regular formula where the current MTT depth is compared to 1: ctxlnc = ( 2 * mtt_split_cu_vertical_flag ) + ( mttDepth <= 171:0) In this formula, sh mttDepth is a parameter transmitted in the slice header. It represents a slice header MTT depth. Of course, alternatively and additionally, this parameter can be ph_mttDepth, transmitted in the picture header, and / or pps mttDepth, transmitted in the picture parameters set (PPS), and / or sps mttDepth, transmitted in the sequence parameters set (SPS). Header values determination at encoder side These parameters need to be determined at encoder side. Based a re-encoding In one embodiment, after the coding of the granularity which is selected for the transmission of the at least one parameter, the encoder evaluates the possible values of the at least one parameter to find the best one. And it transmits it in the related header. An advantage of this embodiment is an optimal selection of the at least one parameter value to obtain the best possible rate. Based a temporal value In one alternative embodiment of the previous one, the value of at least one parameter transmitted in a header is determined based on temporal value at encoder side. For example, when the at least one parameter is defined at slice header, the encoder determined the related temporal value for the current slice and used it for the coding. An advantage of this embodiment compared to the previous one is a complexity reduction as the encoder can determine easily the temporal value. Another advantage is the reduction of the latency at encoder side as the encoder doesn’t need to wait until the end of the encoding to determine the best parameters and can transmit for example the slice header before the end of the encoding of the slice. Another advantage is a coding efficiency increase compared to the previous embodiment, indeed when the RD criterion is computed with this at least one parameter the coding efficiency is better. Finer granularity In one embodiment, the at least parameter is transmitted in the tiles or CTU level. This at least one parameter can be determined based on temporal variables at encoder side. One advantage of this embodiment is that more parameters can be considered to use in the context increment determination. An advantage of this embodiment is a coding efficiency increase compared to the previous embodiments where the parameters are transmitted in the header. Indeed, as the CTU are large the related rate per sample is low and it is not so far to the related rate per sample than the slice header. As this offers more flexibility and can be used for higher number of parameters this embodiment gives a coding efficiency increase. In one example, a CTU factor is determined. Similarly, to the embodiments where the context increment is multiplied by a temporal factor the regular context increment can be multiply by this CTU factor. splitqtJlag and splitcu_flag alternative In one embodiment for splitqtflag and splitcuflag of VVC, the context, ctxlnc, is obtained according thanks to a ctuFactor as in the following formula: ctxlnc = ctuFactor * (( condL &&availableL ) + ( condA &&availableA) + ctxSetldx * 3) where ctuFactor is the CTU context increment factor transmitted which can be determined at encoder side by a temporal value mtt split cu binary_Jlag For another embodiment for rntt split^c the context increment, ctxlnc, is obtained by multiplying the CTU factor to the regular context increment as follows: ctxlnc = ctuFactor * ctxIncSpa where ctxIncSpa is the spatial context increment which can be obtained thanks to the conditions as defined for VVC. For another example of mtt_split_cu_binary_flag the context increment, ctxlnc, is obtained as follows: ctxlnc = ctuFactor * ( 2 * mtt_split_cu_vertical_flag ) + ( mttDepth <= 1 ? 1 : 0 ) An advantage is an increase of the coding efficiency. Indeed, the ctuFactor can exploit the temporal correlations between partitioning of the current frame and the partitioning of temporal frame thanks to the split of contexts without impacting the spatial correlation exploited by the traditional context when this value is determined at encoder side by temporal variables. Of course, the embodiment with the temporal factor is more efficient but it imposes a parsing constraint for the parsing to used previous parsed frames which can be not desirable for some applications. splitqtflag and split cu_flag alternative In another example, the context increment of the split cu flag and split qt flag is obtained by adding a CTU condition as the following formula: ctxlnc = ( condL &&availableL ) + ( condA &&availableA ) + ( condCTU &&availableCTU) + ctxSetldx * 4 Please note that the ctxSetldx is multiply by 4 instead of 3 in the regular derivation as the number of contexts should be increased to consider that additional CTU variables. This increase consequently increases the number of contexts for splitcuflag by 33% The variables condCTU and availableCTU can be set at encoder side based on temporal values. This can include of course the switch for the split cu flag when the QT is enabled or not. splitqtJlag and splitcuflag alternative Alternatively, the contexts are separated based on whether QT is enabled or not. For example, the formula for the splitcuflag can be: ctxlnc = (allowSplitQt +1) * (( condL &&availableL ) + ( condA &&availableA ) + ( condCTU &&availableCTU)+ ctxSetldx * 4) splitcuJlag alternative based on QT allowance In one alternative embodiment the switch depends on the current QT depth and the average temporal QT depth. For example, the context increment for the split cu flag can be obtained as follows: ctxlnc = ((cqtDepth >= ctuQtDepth)+l) * (( condL &&availableL ) + ( condA &&availableA) + (condCTU &&availableCTU) + ctxSetldx * 4) The variable ctxSetldx, for spliUqtJlag, is set according to the following formula: ctxSetldx = cqtDepth >= ctuQtDepth where the ctuQtDepth is transmitted at CTU level. The following derivation can be also used: ctxSetldx = ctuQtDepth >= 2 mttsplitcuverticalJlag In another embodiment, the context increment assignment of ctxlnc for the mttsplitcuverticalflag can be defined based on height and width value transmitted for the CTU and these values can be determined based on temporal values at encoder side, as shown in the following: - If allowSplitBtVer + allowSplitTtVer is greater than allowSplitBtHor + allowSplitTtHor, ctxlnc is set equal to 4. - Otherwise, if allowSplitBtVer + allowSplitTtVer is less than allowSplitBtHor + allowSplitTtHor, ctxlnc is set equal to 3. Otherwise, the following applies: The variables dA, dL, dTempoH and dTempoW are derived as follows dA = cbWidth / ( availableA ? CbWidth[ chType ][ xNbA ][ yNbA ] : 1 ) dL = cbHeight / ( availableL ? CbHeight[ chType ][ xNbL ][ yNbL ] : 1 ) dCtuH = cbWidth / ( availableCtu ? CtuWidth: 1 ) dCtuW = cbHeight / (availableCtu? CtuHeight: 1) If one or more of the following conditions are true, ctxlnc is set equal to 0: dA is equal to dL, availableA is equal to FALSE, availableL is equal to FALSE. dCtuH is equal to dCtuW, availableCtu is equal to FALSE, Otherwise, if dA is less than dL and if dCtuH is less than dCtuW, ctxlnc is set equal to 1. - Otherwise, ctxlnc is set equal to 2. mtt spHt cu binary_Jlag In another embodiment, the context increment ctxlnc for the mtvsplitj:ujtinary Jlag is defined as follows: ctxlnc = (2 * mtt split cu vertical flag ) + ( mttDepth <= CtuMttDepth -1 ? 1 : 0 ) In this formula, the current MTT depth is compared to a transmitted CTU MTT depth which can be determined by temporal values at encoder side. Implementation of the invention Figure 17 shows a system 191 195 comprising at least one of an encoder 150 or a decoder 100 and a communication network 200 according to embodiments of the present invention. According to an embodiment, the system 195 is for processing and providing a content (for example, a video and audio content for displaying / outputting or streaming video / audio content) to a user, who has access to the decoder 100, for example through a user interface of a user terminal comprising the decoder 100 or a user terminal that is communicable with the decoder 100. Such a user terminal may be a computer, a mobile phone, a tablet or any other type of a device capable of providing / displaying the (provided / streamed) content to the user. The system 195 obtains / receives a bitstream 101 (in the form of a continuous stream or a signal - e.g. while earlier video / audio are being displayed / output) via the communication network 200. According to an embodiment, the system 191 is for processing a content and storing the processed content, for example a video and audio content processed for displaying / outputting / streaming at a later time. The system 191 obtains / receives a content comprising an original sequence of images 151, which is received and processed (including filtering with a deblocking filter according to the present invention) by the encoder 150, and the encoder 150 generates a bitstream 101 that is to be communicated to the decoder 100 via a communication network 191. The bitstream 101 is then communicated to the decoder 100 in a number of ways, for example it may be generated in advance by the encoder 150 and stored as data in a storage apparatus in the communication network 200 (e.g. on a server or a cloud storage) until a user requests the content (i.e. the bitstream data) from the storage apparatus, at which point the data is communicated / streamed to the decoder 100 from the storage apparatus. The system 191 may also comprise a content providing apparatus for providing / strearning, to the user (e.g. by communicating data for a user interface to be displayed on a user terminal), content information for the content stored in the storage apparatus (e.g. the title of the content and other meta / storage location data for identifying, selecting and requesting the content), and for receiving and processing a user request for a content so that the requested content can be delivered / streamed from the storage apparatus to the user terminal. Alternatively, the encoder 150 generates the bitstream 101 and communi cate s / streams it directly to the decoder 100 as and when the user requests the content. The decoder 100 then receives the bitstream 101 (or a signal) and performs filtering with a deblocking filter according to the invention to obtain / generate a video signal 109 and / or audio signal, which is then used by a user terminal to provide the requested content to the user. Any step of the method / process according to the invention or functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the steps / functions may be stored on or transmitted over, as one or more instructions or code or program, or a computer-readable medium, and executed by one or more hardware-based processing unit such as a programmable computing machine, which may be a PC (“Personal Computer”), a DSP (“Digital Signal Processor”), a circuit, a circuitry, a processor and a memory, a general purpose microprocessor or a central processing unit, a microcontroller, an ASIC (“Application-Specific Integrated Circuit”), a field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques describe herein. Embodiments of the present invention can also be realized by wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of JCs (e.g. a chip set). Various components, modules, or units are described herein to illustrate functional aspects of devices / apparatuses configured to perform those embodiments, but do not necessarily require realization by different hardware units. Rather, various modules / units may be combined in a codec hardware unit or provided by a collection of interoperative hardware units, including one or more processors in conjunction with suitable software / firmware. Embodiments of the present invention can be realized by a computer of a system or apparatus that reads out and executes computer executable instructions (e.g., one or more programs) recorded on a storage medium to perform the modules / units / functions of one or more of the above-described embodiments and / or that includes one or more processing unit or circuits for performing the functions of one or more of the above-described embodiments, and by a method performed by the computer of the system or apparatus by, for example, reading out and executing the computer executable instructions from the storage medium to perform the functions of one or more of the above-described embodiments and / or controlling the one or more processing unit or circuits to perform the functions of one or more of the abovedescribed embodiments. The computer may include a network of separate computers or separate processing units to read out and execute the computer executable instructions. The computer executable instructions may be provided to the computer, for example, from a computer-readable medium such as a communication medium via a network or a tangible storage medium. The communication medium may be a signal / bitstream / carrier wave. The tangible storage medium is a “non-transitory computer-readable storage medium” which may include, for example, one or more of a hard disk, a random-access memory (RAM), a read only memory (ROM), a storage of distributed computing systems, an optical disk (such as a compact disc (CD), digital versatile disc (DVD), or Blu-ray Disc (BD)™), a flash memory device, a memory card, and the like. At least some of the steps / functions may 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”). Figure 18 is a schematic block diagram of a computing device 3600 for implementation of one or more embodiments of the invention. The computing device 3600 may be a device such as a micro-computer, a workstation or a light portable device. The computing device 3600 comprises a communication bus connected to: - a central processing unit (CPU) 3601, such as a microprocessor; - a random access memory (RAM) 3602 for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method for encoding or decoding at least part of an image according to embodiments of the invention, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example; - a read only memory (ROM) 3603 for storing computer programs for implementing embodiments of the invention; - a network interface (NET) 3604 is typically connected to a communication network over which digital data to be processed are transmitted or received. The network interface (NET) 3604 can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data packets are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU 3601; - a user interface (UI) 3605 may be used for receiving inputs from a user or to display information to a user; - a hard disk (HD) 3606 may be provided as a mass storage device; - an Input / Output module (IO) 3607 may be used for receiving / sending data from / to external devices such as a video source or display. The executable code may be stored either in the ROM 3603, on the HD 3606 or on a removable digital medium such as, for example a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the NET 3604, in order to be stored in one of the storage means of the communication device 3600, such as the HD 3606, before being executed. The CPU 3601 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 3601 is capable of executing instructions from main RAM memory 3602 relating to a software application after those instructions have been loaded from the program ROM 3603 or the HD 3606, for example. Such a software application, when executed by the CPU 3601, causes the steps of the method according to the invention to be performed. It is also understood that according to another embodiment of the present invention, a decoder according to an aforementioned embodiment is provided in a user terminal such as a computer, a mobile phone (a cellular phone), a table or any other type of a device (e.g. a display apparatus) capable of providing / displaying a content to a user. According to yet another embodiment, an encoder according to an aforementioned embodiment is provided in an image capturing apparatus which also comprises a camera, a video camera or a network camera (e.g. a closed-circuit television or video surveillance camera) which captures and provides the content for the encoder to encode. Two such examples are provided below with reference to Figures 19 and 20. Figure 19 is a diagram illustrating a network camera system 3700 including a network camera 3702 and a client apparatus 202. The network camera 3702 includes an imaging unit 3706, an encoding unit 3708, a communication unit 3710, and a control unit 3712. The network camera 3702 and the client apparatus 202 are mutually connected to be able to communicate with each other via the network 200. The imaging unit 3706 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. This image can be a still image or a video image. The encoding unit 3708 encodes the image data by using said encoding methods explained above, or a combination of encoding methods described above. The communication unit 3710 of the network camera 3702 transmits the encoded image data encoded by the encoding unit 3708 to the client apparatus 202. Further, the communication unit 3710 receives commands from client apparatus 202. The commands include commands to set parameters for the encoding of the encoding unit 3708. The control unit 3712 controls other units in the network camera 3702 in accordance with the commands received by the communication unit 3712. The client apparatus 202 includes a communication unit 3714, a decoding unit 3716, and a control unit 3718. The communication unit 3714 of the client apparatus 202 transmits the commands to the network camera 3702. Further, the communication unit 3714 of the client apparatus 202 receives the encoded image data from the network camera 3712. The decoding unit 3716 decodes the encoded image data by using said decoding methods explained above, or a combination of the decoding methods explained above. The control unit 3718 of the client apparatus 202 controls other units in the client apparatus 202 in accordance with the user operation or commands received by the communication unit 3714. The control unit 3718 of the client apparatus 202 controls a display apparatus 2120 so as to display an image decoded by the decoding unit 3716. The control unit 3718 of the client apparatus 202 also controls a display apparatus 2120 so as to display GUI (Graphical User Interface) to designate values of the parameters for the network camera 3702 includes the parameters for the encoding of the encoding unit 3708. The control unit 3718 of the client apparatus 202 also controls other units in the client apparatus 202 in accordance with user operation input to the GUI displayed by the display apparatus 2120. The control unit 3718 of the client apparatus 202 controls the communication unit 3714 of the client apparatus 202 so as to transmit the commands to the network camera 3702 which designate values of the parameters for the network camera 3702, in accordance with the user operation input to the GUI displayed by the display apparatus 2120. Figure 20 is a diagram illustrating a smart phone 3800. The smart phone 3800 includes a communication unit 3802, a decoding unit 3804, a control unit 3806 and a display unit 3808. The communication unit 3802 receives the encoded image data via network 200. The decoding unit 3804 decodes the encoded image data received by the communication unit 3802. The decoding I encoding unit 3804 decodes / encodes the encoded image data by using said decoding methods explained above. The control unit 3806 controls other units in the smart phone 3800 in accordance with a user operation or commands received by the communication unit 3806. For example, the control unit 3806 controls a display unit 3808 so as to display an image decoded by the decoding unit 3804. The smart phone 3800 may also comprise sensors 3812 and an image recording device 3810. In such a way, the smart phone 3800 may record images, encode the images (using a method described above). The smart phone 3800 may subsequently decode the encoded images (using a method described above) and display them via the display unit 3808 - or transmit the encoded images to another device via the communication unit 3802 and network 200. Alternatives and modifications While the present invention has been described with reference to embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. It is also understood that any result of comparison, determination, assessment, selection, execution, performing, or consideration described above, for example a selection made during an encoding or filtering process, may be indicated in or determinable / inferable from data in a bitstream, for example a flag or data indicative of the result, so that the indicated or determined / inferred result can be used in the processing instead of actually performing the comparison, determination, assessment, selection, execution, performing, or consideration, for example during a decoding process. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

CLAIMS1. A method of encoding image data for a plurality of images into a bitstream, the bitstream including data indicating a partitioning of the image data into a plurality of blocks according to a coding tree, wherein blocks in the coding tree may be partitioned according to a plurality of split modes, each split mode being indicated by a partitioning syntax element, the method comprising:encoding at least one bit of a partitioning syntax element corresponding to a split mode using CAB AC coding for a current block to be encoded, wherein the CABAC coding uses a context variable derived based on a first value associated with at least one area from another frame.

2. A method of decoding image data for a plurality of images into a bitstream, the bitstream including data indicating a partitioning of the image data into a plurality of blocks according to a coding tree, wherein blocks in the coding tree may be partitioned according to a plurality of split modes, each split mode being indicated by a partitioning syntax element, the method comprising:decoding at least one bit of a partitioning syntax element corresponding to a split mode using CABAC coding for a current block to be decoded, wherein the CABAC coding uses a context variable derived based on a first value associated with at least one area from another frame.

3. The method according to claim 1 or claim 2, wherein the context variable is determined based on the first value and a second value associated with one or more blocks neighbouring the current block.

4. The method according to claim 3, wherein the first value is multiplied by the second value.

5. The method according to claim 3, wherein the first value is used in combination with the second value.

6. The method according to any of claims 1 to 5, wherein the first value is determined by comparing the quad tree depth of the current block to the quad tree depth associated with the at least one area of another frame.

7. The method according to any of claims 1 to 6, wherein the first value is dependent on the value of the multi tree depth associated with the at least one area from another frame.

8. The method according to claim 3, wherein the context variable is determined using the first value and the second value based on a comparison of the quad tree depth of the current block to the quad tree depth value associated with the at least one area of another frame.

9. The method according to any preceding claim, wherein the context variable is determined using the first value when blocks neighbouring the current block are not available.

10. The method according to any preceding claim, wherein the context variable is determined using only the second value.

11. The method according to any of claims 1 to 9, wherein the context variable is determined using the first value based on a flag.

12. The method according to 11, wherein the flag is transmitted in a sequence parameter set, a picture parameter set, a picture header or a slice header.

13. The method according to any of claims 1 to 9, wherein the first value is signalled in a block.

14. The method according to claim 13, wherein the block corresponds to a coding tree unit.

15. The method according to any of claims 1 to 9, wherein the first value is signalled in a set of blocks.

16. The method according to claim 15, wherein each block in the set of blocks corresponds to a coding tree unit.

17. The method according to any of claims 1 to 16, wherein the first value corresponds to one or more of: an average quad tree depth associated with the at least one area from another frame; a minimum quad tree depth associated with the at least one area from another frame; and a maximum quad tree depth associated with the at least one area from another frame.

18. The method according to any of claims 1 to 17, wherein the first value corresponds to one or more of: an average multi tree depth associated with the at least one area from another frame; a minimum multi tree depth associated with the at least one area from another frame; and a maximum multi tree depth associated with the at least one area from another frame.

19. The method according to any of claims 1 to 18, wherein the first value corresponds to a binary tree depth value associated with the at least one area from another frame.

20. The method according to any of claims 1 to 19, wherein the first value corresponds to one or more of: an average binary tree depth associated with the at least one area from another frame; a minimum binary tree depth associated with the at least one area from another frame; and a maximum binary tree depth associated with the at least one area from another frame.

21. The method according to any of claims 1 to 20, wherein the first value corresponds to a ternary tree depth value associated with the at least one area from another frame.

22. The method according to any of claims 1 to 21, wherein the first value corresponds to one or more of: an average ternary tree depth associated with the at least one area from another frame; a minimum ternary tree depth associated with the at least one area from another frame; and a maximum ternary tree depth associated with the at least one area from another frame.

23. The method according to any of claims 1 to 22, wherein the context variable is determined based on a comparison of the height and / or width or an average of the height and / or width of at least one block associated with the another frame to the height and / or width of the current block.

24. The method according to any of claims I to 23, wherein the at least one area of another frame is an area that is collocated with the current block.

25. The method according to any of claims 1 to 24, wherein the at least one area of another frame comprises a plurality of blocks at different positions.

26. The method according to any of claims 1 to 25, wherein the center position of the current block is used to determine the at least one area of another frame.

27. The method according to any of claims 1 to 26, wherein the at least one area of another frame encompasses an entire area of a reference frame.

28. The method according to any of claims 1 to 27, wherein another frame is a frame with a same temporal ID as the current frame that includes the current block.

29. The method according to claim 28, wherein the frame with the same temporal ID is the closest frame with a same temporal ID.

30. The method according to any of claims 1 to 29, wherein another frame is a frame with a same quantization parameter as the current frame that includes the current block.

31. The method according to any of claims 1 to 30, wherein another frame is a frame that is used for temporal motion vector prediction.

32. The method according to any of claims 1 to 31, wherein another frame is a frame which is the closest reference frame to the current frame that includes the current block.

33. The method according to any of claims 1 to 32, wherein the at least one area includes a first area from a first another frame and a second area from a second another frame.

34. A method of decoding image data for a plurality of images into a bitstream, the bitstream including data indicating a partitioning of the image data into a plurality of blocks according to a coding tree, wherein blocks in the coding tree may be partitioned according to a plurality of split modes, each split mode being indicated by a partitioning syntax element, the method comprising:decoding at least one bit of a partitioning syntax element corresponding to a split mode using CABAC coding for a current block to be encoded, wherein the CABAC coding uses a context variable derived based on at least one parameter transmitted in a header or parameter set.

35. The method according to claim 34, wherein the parameter set is a picture parameter set.

36. The method according to claim 34, wherein the parameter set is a sequence parameter set.

37. The method according to any of claims 34 to 36, wherein the at least one parameter is associated with at least one area of another frame.

38. The method according to any of claim 37, wherein the at least one area of another frame is an area that is collocated with the current block.

39. The method according to any of claims 37 to 38, wherein the at least one area of another frame comprises a plurality of blocks at different positions.

40. The method according to any of claims 37 to 39, wherein the center position of the current block is used to determine the at least one area of another frame.

41. The method according to any of claims 37 to 40, wherein the at least one area of another frame encompasses an entire area of a reference frame.

42. The method according to any of claims 37 to 41, wherein another frame is a frame with a same temporal ID as the current frame that includes the current block.

43. The method according to claim 42, wherein the frame with the same temporal ID is the closest frame with a same temporal ID.

44. The method according to any of claims 37 to 43, wherein another frame is a frame with a same quantization parameter as the current frame that includes the current block.

45. The method according to any of claims 37 to 44, wherein another frame is a frame that is used for temporal motion vector prediction.

46. The method according to any of claims 37 to 45, wherein another frame is a frame which is the closest reference frame to the current frame that includes the current block.

47. The method according to any of claims 37 to 46, wherein the at least one area includes a first area from a first another frame and a second area from a second another frame.

48. The method according to any of claims 34 to 47, wherein the at least one parameter is signalled in a block.

49. The method according to claim 48, wherein the block corresponds to a coding tree unit.

50. The method according to any of claims 34 to 47, wherein the at least one parameter is signalled in a set of blocks.

51. The method according to claim 50, wherein each block in the set of blocks corresponds to a coding tree unit52. A method of encoding image data for a plurality of images into a bitstream, the bitstream including data indicating a partitioning of the image data into a plurality of blocks according to a coding tree, wherein blocks in the coding tree may be partitioned according to a plurality of split modes, each split mode being indicated by a partitioning syntax element, the method comprising:encoding at least one bit of a partitioning syntax element corresponding to a split mode using CABAC coding for a current block to be decoded, wherein the CAB AC coding uses a context variable derived based on at least one parameter transmitted in a header or parameter set.

53. A device for encoding image data into a bitstream, the device being configured to perform the method of claim 52.

54. A device for decoding image data from a bitstream, the device being configured to perform the method of any of claims 1 to 51.

55. A computer program which is arranged to, upon execution, cause the method of any of claims 1 to 52 to be performed.

56. A computer-readable carrier medium upon which is stored the computer program according to claim 55.66

Images