Image and video coding and decoding

Abstract

Image data for a plurality of images is encoded or decoded into or from a bitstream. The encoding or decoding method comprises determining a residual subblock comprising an area of a residual block fo

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 The present disclosure provides methods for use in encoding and decoding images of a video sequence. The disclosed methods provide improved mechanisms for filtering that allow filtering operations to be performed in scenarios wherein the transform unit can take any size and position within the block to be encoded or decoded. Conventionally, the boundaries of the transform unit are aligned with the boundaries, and / or can be located at set interval positions within the block (such as aligned to a 4x4, or 8x8 grid within the block). However, recent developments include methods with increased flexibility in relation to the size and position of the transform unit. Examples include the Sub-Block Transform (SBT) and Advanced SubBlock Transform (ASBT). In these scenarios, the boundaries of the transform unit may be positioned at any point within the block. The inventors have appreciated that this could be detrimental to the performance of filtering operations such as the deblocking filter and bilateral filter - where the former is conventionally applied at sample locations falling on a 4x4 (Luma) or 8x8 (Chroma) grid within the block, and the parameters of the latter are dependent on the size of the transform unit. Therefore, the present invention provides mechanisms to adapt the filtering operations, and / or coding processes to improve performance of filtering operations and ensure robustness to variations in TU size and location. The present disclosure defines encoding processes comprising controlling a filtering operation. Controlling a filtering operation may include adjusting one or more parameters associated with a filtering operation, adjusting one or more locations within a block, or image, where a filtering operation is applied, and / or adjusting whether or not the filtering operation is performed. The present disclosure defines encoding processes comprising determining a residual subblock, where the residual subblock is an area of a residual block to be coded, and controlling a filtering operation based on the determined residual subblock. The controlling may be based on the size of the determined residual subblock, and / or the position of the residual subblock. The controlling may also be based on the size and / or location of the transform unit (TU) - the size and / or location of which may itself be determined based on the determined residual subblock, but may also be determined based on other factors, for example where no residual subblock is determined. In some aspects, the method may include adapting the determination of the residual subblock (or other determination of the transform unit), in such a way as to align the resulting transform unit to a predetermined filtering operation, such that the default parameters of the filtering operation need not be changed. In such aspects, controlling the filtering operation may refer to applying the unchanged filtering operation to the resulting transform unit. According to a first aspect of the present invention, there is provided a method of encoding one or more images into a bitstream, the method comprising a process which includes determining a residual subblock comprising an area of a residual block for a block to be encoded, and the method further comprises controlling a filtering operation, for the block to be encoded, based on the determined residual subblock, and encoding transform coefficients, of a transform block to be encoded, based on the residual subblock area. As described above, by controlling one or more filtering operations based on the determined residual subblock, this allows the filtering operation(s) to be adapted to the size and location of the boundaries of the resulting transform unit. According to a second aspect of the present invention, there is provided a method of decoding one or more images from a bitstream, the method comprising a process which includes determining a residual subblock comprising an area of a residual block for a block to be decoded, and the method further comprises decoding transform coefficients, of a transform block to be decoded, based on the residual subblock area, and controlling a filtering operation based on the determined residual subblock. According to a third aspect of the present invention, there is provided a device for encoding one or more images into a bitstream, the device comprising means for determining a residual subblock comprising an area of a residual block for a block to be encoded, means for controlling a filtering operation, for the block to be encoded, based on the determined residual subblock, and means for encoding transform coefficients, of a transform block to be encoded, based on the residual subblock area. According to a fourth aspect of the present invention, there is provided a device for decoding one or more images from a bitstream, the device comprising means for determining a residual subblock comprising an area of a residual block for a block to be encoded, means for decoding transform coefficients, of a transform block to be decoded, based on the residual subblock area, and means for controlling a filtering operation based on the determined residual subblock. According to a fifth aspect of the present invention, there is provided a computer program which is arranged to, upon execution, cause at least one processor of a computer to perform the method according to the first or second aspects. According to a sixth aspect of the present invention, there is provided a computer-readable storage medium carrying the computer program according to the fifth aspect. Optional features will now be set out. These are applicable singly or in any combination with any aspect of the disclosure. Determining a residual subblock may comprise determining a position of the residual subblock within a residual block of a block to be coded, wherein the position of the residual subblock is located on an NxN grid within the residual subblock. As described above, in such aspects the determination of the residual subblock may be controlled such a way that the resulting transform unit (and block boundaries) are aligned with the locations at which filtering operations can be applied. For example, a deblocking filter may, by default, be able to be applied at boundary locations that fall on a 4x4 grid (for Luma blocks) or an 8x8 grid (for Chroma blocks). By determining the residual subblock wherein the position is located on an NxN grid within the block, this may allow filtering operations such as a deblocking filter to be applied without requiring modification to the filter parameters - therefore resulting in a simpler implementation. The value of N (for the NxN grid) may be determined to align the position of the residual subblock with one or more positions at which a filtering operation may be applied within the block to be coded. As set out above, this may allow filtering operations such as a deblocking filter to be applied without requiring modification to the filter parameters -therefore resulting in a simpler implementation. For example, N may be chosen to be 4 to align with a deblocking filter for a Luma block. N may be any suitable positive integer value to align the position of the residual subblock (or transform unit). The filtering operation may comprise a deblocking filter. Controlling the filtering operation may comprise applying the filtering operation to samples of the block to be coded at positions in the block corresponding to the boundaries of the residual subblock. The residual subblock may be determined to be at any location within the block (i.e. the subblock may take any position on a 1x1 grid). On the other hand, filtering operations such as a deblocking filter are conventionally able to be applied at boundary locations falling on a grid that is more sparse (such as a 4x4 grid). This could cause the filter to be applied to samples that are not on the boundary of the resulting transform unit, and therefore reducing the effectiveness of the filtering. Therefore, by controlling the filtering operation (i.e. deblocking filter), based on the determined residual subblock, such that it is applied along the boundaries of the determined residual subblock, this ensures that the filtering operation is effective and results in improved coding performance with reduced artefacts. Controlling the filtering operation may comprise not constraining the deblocking filter to be aligned with an NxN grid within the block to be coded. Typically, deblocking filters are constrained to be applied at boundaries located on a 4x4 (Luma) or 8x8 (Chroma) grid, though other grid sizes are possible. Removing this constraint allows the deblocking filter to be applied at boundaries located at any position within the block, and therefore allows the deblocking filter to be applied where the transform unit has any size and / or position within the block. Controlling the filtering operation may comprise determining, for one or more boundaries of the residual subblock (or transform unit), the distance between the boundary and the NxN grid may be determined, and based on determining that the distance is less than or equal to a predetermined threshold distance, applying the deblocking filter to samples of the block to be coded at positions in the block corresponding to the boundary of the residual subblock. Based on determining that the distance is greater than the predetermined threshold distance, the deblocking filter may not applied to samples of the block to be coded at positions in the block corresponding to the boundary of the residual subblock. By determining the distance between the residual subblock (or transform unit) boundary and the NxN grid (the default grid associated with the deblocking filter or other filtering operation), it may be determined that the boundary is close enough to the NxN grid such that the filtering operation can still be applied at the NxN grid position closest to the boundary, and maintain the effectiveness of the filter. This is particularly advantageous as it can achieve the advantages associated with the flexible transform unit position / size, while still enabling the filtering operation to be applied without modification. On the other hand, if the boundary is too far from the NxN grid for the filter, applied at the grid location, to be effective, the filtering operation may not be applied, or in some aspects either the subblock (or transform unit) position, or the filter location, may be aligned before the filtering operation is applied. The predetermined distance threshold value may be selected based on the range of the filtering operation. For example, if it is determined that the range of the filtering operation is two samples, the predetermined distance threshold may be up to two samples. The NxN grid may be a 4x4 grid or an 8x8 grid. A 4x4 grid and 8x8 grid are examples, and it will be appreciated that the NxN grid may be any size grid - the size of the grid may be dependent on the default locations at which a particular filtering operation may be applied. The block to be coded may be a block of Luma samples and the NxN grid may be a 4x4 grid. The block to be coded may be a block of Chroma samples and the NxN grid may be an 8x8 grid. The filtering operation may comprise a bilateral filter. The output of the bilateral filter may be based on a bilateral filter offset value, the value of the bilateral filter offset value may be based on a scaling factor, and the method may further comprise determining the value of the scaling factor based on the height and width of the determined residual subblock. Conventionally, the scaling factor associated with the bilateral filter is often determined based on the size of the coding unit (or block to be coded), because conventionally the transform unit and coding unit are often the same size - however in scenarios wherein the transform unit can have varying sizes and positions within the block, this may result in the bilateral filter being incorrectly applied. Therefore, determining the scaling factor based on the size of the determined residual subblock (or transform unit), this ensures that the bilateral filter can be correctly applied in such scenarios, thereby improving coding performance and reducing artefacts. According to a further aspect of the present invention, there is provided a method of encoding one or more images into a bitstream, wherein at least two boundaries of a transform unit of a block to be encoded are not collocated with any boundary of the block to be encoded, the method comprising controlling a filtering operation based on the size and / or location of the transform unit within the block to be encoded. According to a further aspect of the present invention, there is provided a method of decoding one or more images from a bitstream, wherein at least two boundaries of a transform unit of a block to be decoded are not collocated with any boundary of the block to be decoded, the method comprising controlling a filtering operation based on the size and / or location of the transform unit within the block to be decoded. According to a further aspect of the disclosure there is provided a method of encoding or decoding one or more images into or from a bitstream, wherein the method comprises a process which includes: determining a transform portion comprising an area of a transform block of a block to be encoded or decoded; the method further comprising: controlling a filtering operation based on the determined transform portion; and encoding or decoding transform coefficients of the transform block to be encoded or decoded based on the determined transform portion. According to a further aspect of the disclosure there is provided a method of performing bilateral filtering on an image, the method comprising: determining a scale factor based on the size of a transform unit of a block to be processed. According to a further aspect of the disclosure there is provided a method of performing deblocking filtering on an image, the method comprising: aligning the boundaries of a deblocking filter with the boundaries of a determined transform unit (or residual subblock), wherein at least two boundaries of the determined transform unit are not aligned with any boundary of a block to be encoded or decoded. The present invention provides the advantage of reducing artefacts and improving image quality when residual data to be encoded and transmitted is based on a portion of the residual block (i.e. a residual subblock). The present invention may therefore be applied to any such methods, for example the Advanced Sub-Block Transform (ASBT) method, or the Sub-Block Transform (SBT) methods, or similar. According to a further aspect of the invention there is provided a computer program executable to carry out the encoding and / or decoding methods of the invention, and a computer-readable storage medium storing said computer program. The process may be an Advanced Sub-Block Transform, ASBT, process or a Sub-Block Transform (SBT) process. Determining the residual subblock may be based on a predictor block of a block to be encoded or decoded. The process may be any suitable coding process wherein a one or more transforms are applied to one or more portions a residual block, and no transforms are applied to the remaining samples of the residual block. In other words, the process may be any process wherein, at the decoder side, a current block is obtained by adding the predictor block and a residual block, where the residual block corresponds to a portion of the current block. Brief Description of the Drawings Reference will now be made, by way of example, to the accompanying drawings, in which: Figure lisa 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 the typical cascade of loop filtering used in the ECM software; Figure 7 illustrates the boundary between two adjacent blocks Bp and Bq on which the deblocking filter is applied; Figure 8 illustrates the 6 possible split modes of VVC; Figure 9 illustrates the possible SBT sub partitioning of VVC; Figure 10 illustrates the filter shape of the Bilateral filter used in the ECM software; Figure 11 is a schematic illustrating entropy encoding; Figure 12 is a schematic illustrating entropy decoding; Figure 13 illustrates the general principle of Advanced Sub-Block Transform; Figure 14 illustrates SBT and ASBT partitions; Figure 15 illustrates the ASBT method; Figure 16 illustrates an algorithm associated with ASBT; Figure 17 illustrates the direction inference principle of ASBT; Figure 18 illustrates a first embodiment according to the invention; Figure 19 illustrates a second embodiment according to the invention; Figure 20 illustrates a third embodiment according to the invention; Figure 21 is a diagram showing a system comprising an encoder or a decoder and a communication network according to embodiments; Figure 22 is a schematic block diagram of a computing device for implementation of one or more embodiments; Figure 23 is a diagram illustrating a network camera system; and Figure 24 is a diagram illustrating a smart phone. Figure 25 illustrates the general principle of the invention. 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 one or more 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 variable-size 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 deblocking filter (DBF), a sample adaptive offset (SAO) loop filter, a bilateral filter (BIF) and / or an Adaptive Loop Filter (ALF) is used. It should be understood that any of these post filtering do not always have to performed, and any one or more of these post filtering operations may be performed in combination. Also, any other type of post filtering may also be performed in addition to, or instead of, the SAO loop filtering. More details are given in Figure 6 about the different loop filtering operations. 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. Figure 6 shows an example of a cascade of in-loop filters that can be used on the reconstructed picture (601). This example of a cascade of filters is the filtering cascade typically used in the ECM exploration software. The different in-loop filtering processes in video coding play an important role in enhancing the visual quality of reconstructed video frames while maintaining efficient compression. It is, in general, applied during the decoding process in a video codec pipeline. It could be however applied after the decoding process to improve the displayed video frames. Deblocking filter The primary purpose of the Deblocking Filter (603) is to reduce blocking artifacts that occur as a result of block-based compression. These artifacts are visible as discontinuities or "blockiness" at the edges of adjacent blocks in a compressed video. Compression methods using Discrete Cosine Transform (DCT), Discrete Sine Transform (DST) or Integer Transform split the video into small blocks. Quantization of these blocks during compression can cause visible discontinuities at block boundaries. The Deblocking Filter smooths the edges of blocks to eliminate abrupt intensity changes. In the VVC standard, the deblocking filter is applied adaptively to the block boundaries of all coding units (CUs), transform units (TUs) and prediction units (PUs). VVC may partition a video frame into coding units (CUs) using binary and ternary splits in addition to quad split. Compared to previous standards, WC also introduces more flexibility to transform units (TUs) by means of Sub-Block Transform (SBT) and Intra Sub-block Partitioning (ISP) and by use of larger transforms (up to 64x64 for luma and 32x32 for chroma). Inter prediction in VVC also takes advantages of more flexible prediction units by introducing multiple Sub-block Temporal Motion Vector Prediction (SbTMVP) within a PU based on affine motion compensated prediction. Intra prediction toolset is also given further enhancements by Combined Intra-Inter prediction (CUP) where inter prediction is weighted with intra prediction and Intra Block Copy (IBC) where prediction involves copying a block from a nearby location in the current picture. These tool additions are a source of many more possible locations for prediction and transform boundaries; and therefore, also a source of corresponding blocking artifacts within a picture coded using VVC. Visible discontinuities can occur at boundaries in many ways due to: (i) non-zero transform coefficients in one of the TUs adjacent to the boundary, (ii) difference in motion vectors in blocks adjacent to the boundary or (iii) use of intra prediction in at least one of the blocks adjacent to the boundary. The visibility of the discontinuities is also dependent on the quantization parameter (QP) used for quantization of the transform coefficients. In a deblocking filtering operation, a first step consists in determining the context and the filter coefficients and then applying the filter on the samples across the boundaries. In VVC, the deblocking filter basically applies adaptively to all block boundaries of the transform units (TUs) and the prediction units (PUs). Figure 7 gives an example of a vertical boundary between a block Bp and its adjacent block Bq. In a very short description, the filter coefficients of the Deblocking Filter to be applied on the boundary represented in Figure 7 are determined based on the four following aspects which are: - the Boundary Strength (BS), - the threshold parameters tc and P, - the pixel value differences from both sides of the considered boundary and - the coding mode of the blocks Bp and Bq: First of all, the boundary strength (BS) is determined. This parameter enables to control whether the deblocking filter is applied or not on the boundary. It also indicates the strength of filtering. The BS parameter is calculated depending on the coding and prediction mode of the considered block. Typically, the following rules applies for the determination of the BS parameter. BS = 2 for intra-coded boundaries (strong filtering). BS = 1 for inter-coded boundaries with different reference pictures. BS = 0 for boundaries where filtering is not required. Then, according to the VVC standard, there are calculations of two thresholds called tc and P which are derived from the quantization parameter (QP). These two parameters decide whether the boundary should be filtered or not. Typically, the tc (threshold for strong deblocking) parameter controls the strength of the filtering applied to block edges. It determines whether a stronger deblocking operation should be applied or if the boundary should be left as it is. The P parameter assesses the level of activity or gradient across block boundaries. It helps decide if filtering is necessary by evaluating whether the pixel differences across the boundary indicate significant detail (where filtering should be avoided) or an artifact (where filtering is required). These two thresholds are determined using lookup tables or by using equations that are based on the QP parameter. For a given boundary, the pixel difference d=|po,x - qo.xl (represented in Figure 7) across the boundary is also computed and it is compared with the threshold tc to decide whether to apply the filtering or not. In this expression of “d”, “x” represents any of the 4 sample lines represented in that Figure 7. Then additional differences (|pi,x - po.xl and |qi,x - qo.xl) are calculated and are compared with the threshold P to refine the decision. These values enable to evaluate the edge smoothness and determine the filtering intensity. The coding mode applied on the blocks Bp and Bq allows Intra and Inter-coded blocks to be handled differently. Then the filtering coefficients of the deblocking filter are derived adaptively based on - the values of local gradients. Smoother areas (low gradients) receive stronger filtering. On the contrary, textured or edge areas (high gradients) are filtered weakly or not at all. - the filter strength. The filter modifies the pixel intensities on both sides of the boundary. The filtering strength decreases with increasing pixel differences. - the weighted averaging: the filter is a weighted average of neighboring pixels. The weights depend on the boundary strength and calculated pixel differences. As an example, a boundary with pixels p2,x, pi.x, po,x, qo,x, qi.x, q2,x, the resulting filtered values p’o,x and q’o,x may be of the form: p’o,x = po + w / 4 (qo,x - po,x) q'o,x = qo,x + w / 4 (p0,x - qo,x) where w is derived from tc, P, and BS. In VVC, the horizontal filtering is applied first for the vertical boundaries and is then followed by the vertical filtering for horizontal boundaries. In the HEVC standard, the deblocking process operates on an 8x8 sample grid which was changed in VVC such as the deblocking filter deblocking is applied on an 4x4 grid for TU boundaries, but on an 8x8 grid for PUs. The reason for introduction of a finer grid for deblocking in VVC is because the boundaries of large blocks may in some cases lie on the 4x4 grid and not the 8x8 grid, thus potentially resulting in visual distortion. It will be appreciated that the present invention may also be applied for filtering operations with grid sizes other than 4x4 or 8x8. Bilateral filter. In a next stage of the filtering cascade, the Sample Adaptive Offset (SAO) filter 605 and the Bilateral filter 607 can operate individually or in cooperation. SAO operates after the deblocking filter and works on the principle of selectively adding or subtracting offsets to pixel values based on their local characteristics. Similarly, the bilateral filter works by modifying the value of each pixel in an image based on a weighted average of neighbouring pixels. The bilateral filter (BIF) and SAO are using samples from the deblocking filter as input. Each filter creates an offset per sample, and these are added to the input sample and then clipped, before proceeding to Adaptive Loop Filtering (ALF) (609). After applying the Adaptive loop filtering, the resulting samples (611) correspond to the final video signal (69) of Figure 5. In more detail, an output sample of the bilateral filter (607) S’o.ois obtained as S’o,o=clip(So,o + 6SA0+ ^bif\ where So.ois the input sample coming from the deblocking filter (603), SBIF is the offset from the bilateral filter, and SSA0 is the offset from SAO. Any encoder can provide the possibility of enabling or disabling the different filtering stages at the CTU and slice level. The encoder takes a decision by evaluating each filtering stage through the evaluation of a Rate Distortion cost. More precisely, the BIF SBIF offset can be equal to a sum of 12 offsets surrounding the sample So.o as schematically illustrated in Figure 10. $BIF = (^TU ’ [Zsign($ij — $0,0 ) ’ FBIF,ij,Qp(l^ij — $0,0 1)] + 128) » 8, where FBIF j7 QP is based on a 26x16 Look-Up Table (LUT) of 8-bit integers denoted by LUTbase qP (for 26 QPs from 17 to 42 and 16 levels of sample differences). Three scale factors (C1;0, C1A and C2,o) are used to pre-compute three LUTs for three different neighbor distances (1,V2, and 2), i.e.: LUTj7 QP(fc) = (Qy • LUTbase Qp(fc) + 4) » 3. Further, the averaging linear interpolation is used to double the number of levels for \Stj — So o| from 16 to 32, i.e.: F^-Qp(d) = (LUTiJ;QP(min{(d + 2) » 3,15}) + LUTiJ;QP(min{(d + 6) » 3,15}) + 1) » 1. The TU-based scale factor CTU in formula of SBIF above is defined as follows: c _ rTU , rTU CTU — Gw, / i CMAD< where is based on the TU shape sizes and C^ad is based on the mean absolute difference (MAD) of the TU. Both and 6mad are calculated using LUTs. It should be noted that, most of the time in video standards, the TU size is equal to the CU size as the transform operations is applied on the entire CU. More precisely, the LUTW h is a 8 x 8 lookup table with non-negative 8-bit integer values, and the LUTmad is a ID 16-entry lookup table with non-negative 8-bit integer values. Then these scale factors are defined as follows: c™h = LUTw / l(log2(widthTU), log2(heightTU)) Cm ad = LUTMAD(min( MADtu » 4,15)) The MAD of a (h x w)-size TU with the channel samples denoted by s(j is defined as follows: h h WC 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, SPLITBTVER -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, SPLITTTVER -the horizontal ternary split, 805, SPLIT TT HOR -The No Split, 806, which terminates a tree node so there is no splitting. VVC Transform Information signaling. The residual coding of VVC is similar to the previous standard. At the encoder side, the residual block is transformed and quantized. At the decoder side, dequantization and inverse transformation is performed to obtain the decoded residual block. But there are a lot of additional tools that may be used to optimize the residual coding, such as Sub-Block Transform (SBT). In VVC specifications, the signaling of the residual coding is performed in accordance with 3 tables of syntax elements. The first one is related to the transform tree coding, and given as example in the following. Please note that a tree exists for intra block, where the transform block can be split in several transform units and each related transform unit as a predictor obtained after the decoding of the neighboring transform unit. For inter block the transform tree is only for the signal of the SBT tools which divides a coding unit (CU) into 2 transform units (TU) as depicted in Figure 9 and explained in following section. transform_tree( xO, yO, tbWidth, tbHeight, treeType, chType ) { Descriptor InferTuCbfLuma = 1 if( IntraSubPartitionsSplitType == ISPNOSPLIT &&!cu_sbt_flag) { if( tbWidth >MaxTbSizeY tbHeight >MaxTbSizeY) { verSplitFirst = (tbWidth >MaxTbSizeY &&tbWidth >tbHeight) ? 1 : 0 trafoWidth = verSplitFirst ? (tbWidth / 2 ): tbWidth trafoHeight = IverSplitFirst ? (tbHeight / 2 ): tbHeight transform_tree( xO, yO, trafoWidth, trafoHeight, treeType, chType ) if( verSplitFirst) transform_tree( xO + trafoWidth, yO, trafoWidth, trafoHeight, treeType, chType ) else transform_tree( xO, yO + trafoHeight, trafoWidth, trafoHeight, treeType, chType ) } else { transform_unit( xO, yO, tbWidth, tbHeight, treeType, 0, chType ) } } else if( cu sbt flag) { if( !cu_sbt_horizontal_flag) { trafoWidth = tbWidth * SbtNumFourthsTbO / 4 transform_unit( xO, yO, trafoWidth, tbHeight, treeType, 0, 0 ) transform_unit( xO + trafoWidth, yO, tbWidth - trafoWidth, tbHeight, treeType, 1, 0 ) } else { trafoHeight = tbHeight * SbtNumFourthsTbO / 4 transform_unit( xO, yO, tbWidth, trafoHeight, treeType, 0, 0 ) transform_unit( xO, yO + trafoHeight, tbWidth, tbHeight - trafoHeight, treeType, 1,0) } } else if( IntraSubPartitionsSplitType = = ISPHORSPLIT) { trafoHeight = tbHeight / NumlntraSubPartitions for( partldx = 0; partldx <NumlntraSubPartitions; partldx++) transform unit( xO, yO + trafoHeight * partldx, tbWidth, trafoHeight, treeType, partldx, 0 ) } else if( IntraSubPartitionsSplitType = = ISP VER SPLIT) { trafoWidth = tbWidth / NumlntraSubPartitions for( partldx = 0; partldx <NumlntraSubPartitions; partldx++) transform unit( xO + trafoWidth * partldx, yO, trafoWidth, tbHeight, treeType, partldx, 0 ) } } As we can see in the transform tree table of syntax elements, the function transform_unit() is 5 called several times. This function is described in the following syntax table of syntax elements: transform_unit( xO, yO, tbWidth, tbHeight, treeType, subTuIndex, chType ) { Descriptor if( IntraSubPartitionsSplitType != ISPNOSPLIT && treeType = = SINGLE TREE &&subTuIndex = = NumlntraSubPartitions - 1) { xC = CbPosX[ chType ][ xO ][ yO ] yC = CbPosY[ chType ][ xO ][ yO ] wC = CbWidth[ chType ][ xO ][ yO ] / SubWidthC hC = CbHeight[ chType ] [ xO ] [ yO ] / SubHeightC } else { xC = xO yC = yO wC = tbWidth / SubWidthC hC = tbHeight / SubHeightC } chromaAvailable = treeType != DUAL TREE LUMA &&spschromaformatidc != 0 && ( IntraSubPartitionsSplitType = = ISP NO SPLIT (IntraSubPartitionsSplitType != ISP NO SPLIT && subTuIndex = = NumlntraSubPartitions - 1)) if( ( treeType = = SINGLE TREE | | treeType = = DUAL TREE CHROMA ) &&spschromaformatidc != 0 && ( ( IntraSubPartitionsSplitType == ISP NO SPLIT &&!(cusbtflag && ( ( subTuIndex = = 0 &&cu_sbt_pos_flag) ( subTuIndex ==1 &&!cu_sbt_pos_flag) ) ) ) ( IntraSubPartitionsSplitType != ISPNOSPLIT && ( subTuIndex = = NumlntraSubPartitions -!)))){ tu_cb_coded_flag[ xC ] [ yC ] ae(v) tu_cr_coded_flag[ xC ] [ yC ] ae(v) } if( treeType = = SINGLE TREE 11 treeType = = DUAL TREE LUMA) { if( ( IntraSubPartitionsSplitType == ISP NO SPLIT &&!(cu sbt flag && ( ( subTuIndex = = 0 &&cu_sbt_pos_flag) (subTuIndex ==1 &&!cu_sbt_pos_flag) ) ) && (( CuPredMode[ chType ][x0][y0] == MODE INTRA && !cu_act_enabled_flag[ xO ][ yO ]) ( chromaAvailable &&(tu_cb_coded_flag[ xC ] [ yC ] tu_cr_coded_flag[ xC ] [ yC ])) CbWidth[ chType ][ xO ][ yO ] >MaxTbSizeY CbHeight[ chType ][ xO ][yO ] >MaxTbSizeY) ) ( IntraSubPartitionsSplitType != ISPNOSPLIT && ( subTuIndex <NumlntraSubPartitions - 1 ! InferTuCbfLuma))) tu_y_coded_flag[ xO ] [ yO ] ae(v) if(IntraSubPartitionsSplitType != ISP NO SPLIT) InferTuCbfLuma = InferTuCbfLuma &&!tu_y_coded_flag[ xO ][y0 ] } if( ( CbWidth[ chType ][ xO ][ yO ]> 64 CbHeight[ chType ][ xO ][ yO ]> 64 tu_y_coded_flag[ xO ] [ yO ] (chromaAvailable && ( tu_cb_coded_flag[ xC ] [ yC ] tu_cr_coded_flag[ xC ][ yC ]))) && treeType != DUALTREECHROMA && pps cu qp delta enabled flag &&!IsCuQpDeltaCoded) { cuqpdeltaabs ae(v) if( cu qp delta abs ) cuqpdeltasignflag ae(v) } if( ( CbWidth[ chType ][ xO ][ yO ]> 64 CbHeight[ chType ][ xO ][ yO ]> 64 ( chromaAvailable &&(tu_cb_coded_flag[ xC ] [yC] tu_cr_coded_flag[ xC ] [ yC ]))) && treeType != DUAL TREE LUMA &&sh_cu_chroma_qp_offset_enabled_flag &&!IsCuChromaQpOffsetCoded) { cuchromaqpoffsetflag ae(v) if( cu chroma qp offset flag &&pps_chroma_qp_offset_list_len_minusl >0 ) cuchromaqpoffsetidx ae(v) } if( spsjointcbcrenabledflag && ( ( CuPredMode[ chType ][xO][yO] == MODEINTRA && ( tu_cb_coded_flag[ xC ] [ yC ] | tu cr coded flagi xC ][ yC ] ) ) ( tu_cb_coded_flag[ xC ] [ yC ] &&tu_cr_coded_flag[ xC ] [ yC ] ) ) && chromaAvailable ) tujoint_cbcr_residual_flag[ xC ][ yC ] ae(v) if( tu_y_coded_flag[ xO ][ yO ] &&treeType != DUAL TREE CHROMA) { if( spstransformskipenabledflag &&!BdpcmFlag[ xO ] [ yO ] [ 0 ] && tbWidth <= MaxTsSize &&tbHeight <= MaxTsSize &&(IntraSubPartitionsSplitType == ISP NO SPLIT) &&!cu sbt flag) transform_skip_flag[ xO ][ yO ][ 0 ] ae(v) if( !transform_skip_flag[ xO ][ yO ][ 0 ] shtsresidualcodingdisabledflag) residual_coding( xO, yO, Log2( tbWidth), Log2( tbHeight), 0 ) else residual_ts_coding( xO, yO, Log2( tbWidth), Log2( tbHeight), 0 ) } if( tu_cb_coded_flag[ xC ] [ yC ] &&treeType != DUAL TREE LUMA) { if( sps transform skip enabled flag &&!BdpcmFlag[ xO ] [ yO ] [ 1 ] && wC <= MaxTsSize &&hC <= MaxTsSize &&!cu sbt flag) transform_skip_flag[ xC ][ yC ][ 1 ] ae(v) if( !transform_skip_flag[ xC ][yC ][ 1 ] sh ts residual coding disabled flag) residual_coding( xC, yC, Log2( wC ), Log2( hC ), 1) else residual_ts_coding( xC, yC, Log2( wC), Log2( hC), 1) } if( tu_cr_coded_flag[ xC ] [ yC ] &&treeType != DUAL TREE LUMA && !(tn cb coded flag[ xC 11 yC 1 &&tn joint cbcr residual flag[ xC 11 yC 1)) { if( sps transform skip enabled flag &&!BdpcmFlag[ xO ] [ yO ] [ 2 ] && wC <= MaxTsSize &&hC <= MaxTsSize &&!cu sbt flag) transform_skip_flag[ xC ][ yC ][ 2 ] ae(v) if( !transform_skip_flag[ xC ][yC ][ 2 ] sh ts residual coding disabled flag) residual_coding( xC, yC, Log2( wC ), Log2( hC ), 2 ) else residual_ts_coding( xC, yC, Log2( wC), Log2( hC), 2 ) } } As we can see, some flags related to the coding of color components are transmitted according to several conditions as tu cb coded flag, tu cr coded flag, as well as the tu y coded flag specifying that the luma residual is coded. The value of the tu_y_coded_flag is mostly inferred thanks the to a syntax element cucodedflag inferred or transmitted at CU level. All these flags correspond to the CBF coding of the previous standards. In this syntax table several other parameters are decoded as some tools for the transform of the color or some delta Quantisation Parameter (QP) or a first type of the transform (transform skip flag), transform SKIP. As we can see in the transform unit table of syntax elements the function residual_coding() is called several times. This function is described in the following syntax table of syntax elements: residual_coding( xO, yO, log2TbWidth, log2TbHeight, cldx ) { Descripto r if( spsmtsenabledflag &&cusbtflag &&cldx ==0 &&log2TbWidth = = 5 &&log2TbHeight <6 ) Log2ZoTb Width = 4 else Log2ZoTbWidth = Min( log2Tb Width, 5 ) if( sps mts enabled flag &&cu sbt flag &&cldx ==0 &&log2TbWidth <6 &&log2TbHeight ==5) Log2ZoTbHeight = 4 else Log2ZoTbHeight = Min( log2TbHeight, 5 ) Log2FullTb Width = log2Tb Width Log2FullTbHeight = log2TbHeight if( log2TbWidth >0 ) last_sig_coeff_x_prefix ae(v) if( log2TbHeight >0 ) last_sig_coeff_y_prefix ae(v) if( last_sig_coeff_x_prefix >3 ) last_sig_coeff_x_suffix ae(v) if( last_sig_coeff_y_prefix >3 ) last_sig_coeff_y_suffix ae(v) remBinsPassl = ((1 « ( Log2ZoTbWidth + Log2ZoTbHeight) ) * 7 ) » 2 log2SbW = (Min( Log2ZoTb Width, Log2ZoTbHeight) <2 ? 1 : 2 ) log2SbH = log2SbW if( Log2ZoTbWidth + Log2ZoTbHeight >3 ) if( Log2ZoTbWidth <2 ) { log2SbW = Log2ZoTb Width log2SbH = 4 - log2SbW } else if( Log2ZoTbHeight <2 ) { log2SbH = Log2ZoTbHeight log2SbW = 4 - log2SbH } numSbCoeff = 1 « (log2SbW + log2SbH) lastScanPos = numSbCoeff lastSubBlock = ( 1 « ( Log2ZoTbWidth + Log2ZoTbHeight - (log2SbW + log2SbH)) )-1 HistValue = sps_persistent_rice_adaptation_enabled_flag ? ( 1 « StatCoeff[ cldx ]): 0 updateHist = sps_persistent_rice_adaptation_enabled_flag ? 1 : 0 do { if( lastScanPos = = 0 ) { lastScanPos = numSbCoeff lastSubBlock— } lastScanPos— xS DiagScanOrder[ Log2ZoTbWidth - log2SbW ][ Log2ZoTbHeight - log2SbH ] [ lastSubBlock ] [ 0 ] yS DiagScanOrder[ Log2ZoTbWidth - log2SbW ][ Log2ZoTbHeight - log2SbH ] [ lastSubBlock ] [ 1 ] xC = ( xS « log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ lastScanPos ][ 0 ] yC = ( yS « log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ lastScanPos ][ 1 ] } while( ( xC != LastSignificantCoeffX ) ( yC ! = LastSignificantCoeffY)) if( lastSubBlock == 0 &&Log2ZoTbWidth >= 2 && Log2ZoTbHeight >= 2 && !transform_skip_flag[ xO ][ yO ][ cldx ] &&lastScanPos >0) LfnstDcOnly = 0 if( ( lastSubBlock >0 &&Log2ZoTbWidth >= 2 && Log2ZoTbHeight >= 2 ) | | ( lastScanPos >7 &&( Log2ZoTbWidth ==2 Log2ZoTb Width == 3 ) && Log2ZoTbWidth == Log2ZoTbHeight ) ) LfnstZeroOutSigCoeffFlag = 0 if( (lastSubBlock >0 lastScanPos >0 ) &&cldx = = 0) MtsDcOnly = 0 Q State = 0 for( i = lastSubBlock; i >= 0; i— ) { startQ State Sb = Q State xS DiagScanOrder[ Log2ZoTbWidth - log2SbW ][ Log2ZoTbHeight - log2SbH ] [ i ][ 0 ] yS DiagScanOrder[ Log2ZoTbWidth - log2SbW ][ Log2ZoTbHeight - log2SbH ] [ i ][ 1 ] inferSbDcSigCoeffFlag = 0 if( i <lastSubBlock &&i >0 ) { sb coded flag[ xS ][ yS ] ae(v) inferSbDcSigCoeffFlag = 1 } if( sb_coded_flag[ xS ][ yS ] &&( xS >3 yS >3 ) &&cldx = = 0) MtsZeroOutSigCoeffFlag = 0 firstSigScanPosSb = numSbCoeff lastSigScanPosSb = -1 firstPosModeO = ( i == lastSubBlock ? lastScanPos : numSbCoeff - 1 ) firstPosModel = firstPosModeO for( n = firstPosModeO; n >= 0 &&remBinsPassl >= 4; n— ){ xC = ( xS « log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 0 ] yC = ( yS « log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 1 ] if( sb coded_flag[xS ][yS ] &&( n>0 !inferSbDcSigCoeffFlag ) && (xC != LastSignificantCoeffX yC ! = LastSignificantCoeffY)) { sigcoeff_flag[ xC ][ yC ] ae(v) remBinsPassl— if( sig_coeff_flag[ xC ][ yC ]) inferSbDcSigCoeffFlag = 0 } if( sig_coeff_flag[ xC ][ yC ]) { abs_level_gtx_flag[ n ][ 0 ] ae(v) remBinsPassl— if( abs_level_gtx_flag[ n ][ 0 ]) { par level_flag[ n ] ae(v) remBinsPassl— abs_level_gtx_flag[ n ][ 1 ] ae(v) remBinsPassl— if( lastSigScanPosSb ==-1) lastSigScanPosSb = n firstSigScanPosSb = n } AbsLevelPassl[ xC ][ yC ] = sig_coeff_flag[ xC ][ yC ] + par_level_flag[ n ] + abs_level_gtx_flag[ n ][ 0 ] + 2 * abs_level_gtx_flag[ n ][ 1 ] if( sh dep quant used flag) Q State = QStateTransTable[ QState ][ AbsLevelPassl[ xC ][ yC ] &1 ] firstPosModel = n - 1 } for( n = firstPosModeO; n >firstPosModel; n— ) { xC = ( xS « log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 0 ] yC = ( yS « log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 1 ] if( abs_level_gtx_flag[ n ][ 1 ]) { abs_remainder[ n ] ae(v) if( updateHist &&abs_remainder[ n ] >0 ) { StatCoeff[ cldx ] = ( StatCoeff[ cldx ] + Floor( Log2( abs_remainder[ n ] ) ) + 2) » 1 updateHist = 0 } } AbsLevel[ xC ][ yC ] = AbsLevelPassl[ xC ][ yC ] +2 * abs_remainder[ n ] } for( n = firstPosModel; n >= 0; n— ) { xC = ( xS « log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 0 ] yC = ( yS « log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 1 ] if( sb_coded_flag[ xS ][ yS ]) { dec_abs_level[ n ] ae(v) if( updateHist &&dec_abs_level[ n ] >0 ) { StatCoeff[ cldx ] = ( StatCoeff[ cldx ] + Floor( Log2( dec_abs_level[ n ]))) » 1 updateHist = 0 } } if( AbsLevel[ xC ][ yC ] >0 ) { if( lastSigScanPosSb ==-1) lastSigScanPosSb = n firstSigScanPosSb = n } if( sh dep quant used flag) Q State = QStateTransTable[ QState ][ AbsLevel[ xC ][ yC ] &1 ] } signHiddenFlag = shsigndatahidingusedflag && (lastSigScanPosSb - firstSigScanPosSb >3 ? 1 : 0) for( n = numSbCoeff - 1; n >= 0; n— ) { xC = ( xS « log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 0 ] yC = ( yS « log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 1 ] if( ( AbsLevel[xC][yC] >0 ) && ( !signHiddenFlag (n != firstSigScanPosSb ) ) ) coeff sign_flag[ n ] ae(v) } if( sh dep quant used flag) { Q State = startQ State Sb for( n = numSbCoeff- 1; n >= 0; n— ) { xC = ( xS « log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 0 ] yC = ( yS « log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 1 ] if( AbsLevel[ xC ][ yC ] >0 ) TransCoeffLevel[ xO ][ yO ][ cldx ][ xC ][ yC ] = ( 2 * AbsLevel[ xC ][ yC ] ( QState >1 ? 1 : 0 ) ) * ( 1 - 2 * coeffsignflagf n ]) QState = QStateTransTable[ QState ][ AbsLevel[ xC ][ yC ] &1 ] } } else { sumAbsLevel = 0 for( n = numSbCoeff - 1; n >= 0; n— ) { xC = ( xS « log2SbW ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 0 ] yC = ( yS « log2SbH ) + DiagScanOrder[ log2SbW ][ log2SbH ][ n ][ 1 ] if( AbsLevel[ xC ][ yC ] >0 ) { TransCoeffLevel[ xO ][ yO ][ cldx ][ xC ][ yC ] = AbsLevel[ xC ][ yC ] * ( 1 - 2 * coeff_sign_flag[ n ] ) if( signHiddenFlag ) { sumAbsLevel += AbsLevel[ xC ][ yC ] if( n == firstSigScanPosSb &&sumAbsLevel % 2 == 1 ) TransCoeffLevel[ xO ][ yO ][ cldx ][ xC ][ yC ] = TransCoeffLevel[ xO ][ yO ][ cldx ][ xC ][ yC ] } } } } } } This function contains the coefficients coding. Especially this function contains the syntax elements of the last coefficient position obtained thanks the variable lastScanPos. These syntax elements are lastsigcoeffxprefix, lastsigcoeffyprefix, last sig coeff x suffix, 5 last_sig_coeff_y_suffix. As we can see the decoding of this syntax elements depends on the size of the transform block. As well as the decoding of each of this syntax element as we can see in the following table from the VVC specifications. residual_coding() last_sig_coeff_x_prefix TR cMax = (Log2ZoTbWidth « 1)-1, cRiceParam = 0 last_sig_coeff_y_prefix TR cMax = (Log2ZoTbHeight « 1)-1, cRiceParam = 0 last_sig_coeff_x_suffix FL cMax ( 1 « ((last_sig_coeff_x_prefix » 1)-1))-1 last_sig_coeff_y_suffix FL cMax ( 1 « ((last_sig_coeff_y _prefix » 1)-1))-1 sb_coded_flag[ ][ ] FL cMax = 1 sig_coeff_flag[ ][ ] FL cMax = 1 par_level_flag[ ] FL cMax = 1 abs_level_gtx_flag[ ][ ] FL cMax = 1 abs_remainder[ ] 9.3.3.11 cldx, current sub-block index i, xO, yO, xC, yC dec_abs_level[ ] 9.3.3.12 cldx, xO, yO, xC, yC coeff_sign_flag[ ] FL cMax = 1 And the context derivation of these variables depends also on the size of the transform block as we can see in the following section of VVC specifications (VVC specification 3rd edition of September 2023: H266 (09 / 23)): 9.3.4.2.4 Derivation process of ctxlnc for the syntax elements last_sig_coeff_x_prefix and last_sig_coeff_y_prefix Inputs to this process are the variable binldx and the colour component index cldx. Output of this process is the variable ctxlnc. The variable log2TbSize is derived as follows: - If the syntax element to be parsed is last_sig_coeff_x_prefix, log2TbSize is set equal to Log2FullTbWidth. - Otherwise (the syntax element to be parsed is last_sig_coeff_y_prefix), log2TbSize is set equal to Log2FullTbHeight. The variables ctxOffset and ctxShift are derived as follows: - If cldx is equal to 0, ctxOffset is set equal to offsetY[ log2TbSize - 1 ] and ctxShift is set equal to (log2TbSize + 1) » 2 with the list offsetY specified as follows: offsetY[ ] = {0, 0, 3, 6, 10, 15} (1549) - Otherwise (cldx is greater than 0), ctxOffset is set equal to 20 and ctxShift is set equal to Clip3( 0, 2, 21og2TbSize » 3 ). The variable ctxlnc is derived as follows: ctxlnc = (binldx » ctxShift) + ctxOffset (1550) Sub-Block Transform (SBT) principle (Figure 9) The distribution of the inter-prediction residual is considered to be very different from that of intra-prediction residual. Statistically, energy of inter-prediction residual increases from the centre of prediction block towards its boundaries. In addition, in many cases, the inter prediction residuals are localized at one side of the block, rather than being distributed around all block boundaries. In order to use a smaller transform block to capture the localized residuals, and further considering the unique distribution of inter-prediction residual, a Sub-Block Transform (SBT) method was developed and included in the VVC standard. In the VVC standard, eight SBT modes are defined and are associated with different configurations of the size and location of transformed blocks. When SBT is used, two transform units are created. The transform unit containing the transformed block is either half or quarter size of the residual block, as illustrated by the greyed area in Figure 9. The residual in the remaining part of the residual block (illustrated by the white area and corresponding to the second transform unit) is not coded and all transformed coefficients are considered as zero. It is important to note that in SBT, the transformed blocks always reside in one boundary of the residual block. In other words, the transformed blocks are adjacent to three boundaries of the residual block. Another feature of SBT design in WC is the adaptive transform kernel, which is selected based on the transform block position, as illustrated in Figure 9. For instance, if the transform block at the left side of the residual block is selected as the best mode, the right side typically contains weaker residual. In this case, DCT-8 is considered as more efficient than a DCT-2 for the horizontal transform since the basis vector decreases from left to right. For the other dimension of the transform block, DST-7 was retained based on experimental results conducted during the standardization process that show marginally higher coding gain than both DCT-2 and DCT-8. In a nutshell, the SBT modes are optimized for the cases that the major residual is localized at a lateral part of the residual block. For implementation consideration, when the width or the height of an SBT transform block exceeds 32 (e.g., a 64 * 64 CU with any SBT mode), both horizontal and vertical transforms are forced to be DCT-2. In this way, it is aligned with the design principle in VVC that DST-7 / DCT-8 is only applied to blocks no larger than 32 x 32. SBT signaling When the SBT transform mode is selected at the encoder side for a given coding unit, some information is encoded in the bitstream in order to select one of the 8 possibilities illustrated by the Figure 9. First of all, and in reference to WC standard, the flag cusbt flag is encoded. In order to indicate that the SBT mode is used for a given CU, this flag is set to 1, otherwise this flag is set to 0. A second flag called cusbtquadflag is then encoded to specify the size of the subblock transform. When this flag is equal to 1, its specifies that for the current coding unit, the subblock transform includes a transform unit of 1 / 4 size of the current coding unit. When cu_sbt_quad_flag is equal to 0, it specifies that for the current coding unit the subblock transform includes a transform unit of 1 / 2 size of the current coding unit. Then a third called cu sbt horizontal flag is used to indicated the direction of the transform units. When cu_sbt_horizontal_flag is equal to 0, this specifies that the current coding unit is split horizontally into 2 transform units, otherwise when cu_sbt_horizontal_flag is equal to 0 specifies that the current coding unit is split vertically into 2 transform units. Finally, a fourth flag called cu_sbt_pos_flag, is used to signal where the position of the transformed coefficients is located inside the possible two transform units. When cu_sbt_pos_flag is equal to 1, this means that no transform coefficient is present in the first transform unit of the current coding unit. When cu_sbt_pos_flag equal to 0, this specifies that the transformed coefficients are not present in the second transform unit in the current coding unit. Additionally, and based on the flags cu_sbt_pos_flag and cu_sbt_quad_flag, the position of the transform unit (sbtPos) containing the transform coefficient (expressed in quarter of transform unit width or height) is determined as follows: sbtPos = cu_sbt_pos_flag ? (4 - sbtMin): sbtMin where sbtMin = cu_sbt_quad_flag ? 1 : 2 Where “?” is the temery conditional operator. The combination of these 3 flags enables to fully represent one of the 8 configurations presented in Figure 9. CAB AC encoder description. Figure 11 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 (1100) in Figure 11. 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 (1101), 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 11: the context modelling (1104), the probability estimation (1106) (with an initialization step (1105)) and the binary arithmetic encoder (1107). First of all, each syntax element (1101) goes through the binarization process (1102) 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 (1101) and this defines two possible encoding paths as illustrated by the switch in (1103). 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 (1104) 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 (1106). 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 (1105) 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 (1106) 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 (1107) without going through steps (1103) and (1106) 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 (1107) 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 (1107) 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 (1107) also includes a fast bypass coding mode for the encoding of bypass bins. Figure 12 corresponds to the reverse operation regarding the entropy encoder presented in Figure 1. It consists in retrieving the syntax elements (1208) for the bitstream (1201). The context-based adaptive binary arithmetic decoding can be considered as the module (1200). As shown in Figure 12, the bitstream is decomposed by the bitstream parser (1202) which enables to respect the order of the syntax elements encoded in the bitstream (1201). Then according to the syntax element and the bin to be decoded (1209), similarly to what was carried out at the encoder, two decoding paths in the module (1206) 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 (1202). When the bin is by-passed coded, it is directly provided through the by-pass decoding engine of the module (1206). Otherwise, the bin is processed through the regular decoding engine of module (1206). 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 (1205). An initialization step is also performed to set the probability to a certain starting value in the module (1204). 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 (1206). The output of the module (1206) 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 (1207) 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 (1208). 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. GPM The Geometric partitioning mode (GPM) algorithm aims to increase the partitioning precision of moving objects using non-rectangular and asymmetric rectangular partitions on top of the conventional rectangular block partitioning structure of VVC. In this mode a split of the current block is transmitted. Each partition has its own motion information and the frontier between these 2 non rectangular blocks is blended. This mode was extended in the ECM software by integrated several modifications. Especially this mode can be split into one inter block and one Intra block. CIIP The Combined Inter Merge / Intra prediction (CIIP) Merge can be considered as a combination of the regular Merge mode and the Intra mode. The block predictor for the current block of this mode is an average between a Merge predictor block and an Intra predictor block. The Merge predictor block is obtained with exactly the same process of the Merge mode so it is a temporal block or bi-predictor of 2 temporal blocks. The Intra predictor block is obtained based on the neighbouring sample of the current block. The amount of available Intra modes for the current block is however limited compared to an Intra block. Moreover, there is no Chroma Intra predictor block signalled for a CIIP block. The Chroma predictor is equal to the Luma predictor. As a consequence, 1, 2 or 3 bits are used to signal the Intra predictor for a CIIP block. The CIIP block predictor is obtained by a weighted average of the Merge block predictor and the Intra block predictor. The weighting of the weighted average depends on the block size and / or the Intra predictor block selected. The obtained CIIP predictor is then added to the residual of the current block to obtain the reconstructed block. It should be noted that the CIIP mode is enabled only for non-Skipped blocks. Indeed, use of the CIIP Skip typically results in losses in compression performance and an increase in encoder complexity. This is because the CIIP mode has often a block residual in opposite to the other Skip mode. Consequently, its signalling for the Skip mode increases the bitrate. - when the current CU is Skip, the CIIP is avoided. A consequence of this restriction is that the CIIP block can’t have a residual containing only 0 value as it is not possible to encode a VVC block residual equal to 0. Indeed, in VVC the only way to signal a block residual equal to 0 for a Merge mode is to use the Skip mode, this is because the CU CBF flag is inferred to be equal to true for Merge modes. And when this CBF flag is true, the block residual can’t be equal to 0. In such a way, CUP should be interpreted in this specification as being a mode which combines features of Inter and Intra prediction, and not necessarily as a label given to one specific mode. IBC In the Screen Content Extension of HEVC, the coding tool called Intra Block Copy (IBC) is signalled as any of those three INTER modes, the difference between IBC and the equivalent INTER mode being made by checking whether the reference frame is the current one. This can be implemented e.g. by checking the reference index of the list L0, and deducing this is Intra Block Copy if this is the last frame in that list. Another way to do is comparing the Picture Order Count of current and reference frames: if equal, this is Intra Block Copy. In VVC, it is also possible to enable the Intra block Copy (IBC) merge mode. IBC has an independent merge candidate derivation process. And also, for a similar Inter mode where motion vector is coded as an Inter merge mode. Palette mode Thanks to the Palette coding mode of HEVC or VVC, it is possible to define a representative block for a given Coding Unit as a block of indexes from a palette: for each pixel location in the Coding Unit, the said representative block contains the index associated with a pixel value in the Palette which is the closest to the value of the pixel having the same location. MTS for Inter The multiple transforms (MTS) tool has been integrated inside VVC for Intra coding. In that case several combinations of transform can be used and signaled inside the bitstream thanks the MTS index. In the ECM software MTS was extended to Inter coding. For Inter 4 possible transform combinations are possible: {(DST7, DST7), (DST7, DCT8), (DCT8, DST7), (DCT8, DCT8)}. For MTS the usage of only one coefficient is not allowed. Indeed, the DC components of all these transforms are redundant and redundant to the regular DCT used when MTS is not enabled. LFNST for Inter The Low-Frequency Non-Separable Transform (LFNST) is a secondary Transform. LFNST is applied to the top-left low-frequency region of primary transform coefficients and it is used for Intra coded blocks that employ DCT-2 in VVC. For the ECM software, LFNST was extended to Inter coding. The main goal of LFNST is to further compress the redundancy between low-frequency primary transform coefficients, which are transform coefficients from a prediction block. For this tool this has no sense to have only one coefficient. So, when there is only one coefficient in the transform residual, LFSNT is disallowed. For the ECM software LFNST was extended to Inter coding. ASBT For each transform unit coded with Advanced Sub-Block Transform (ASBT) a subblock of the initial residual is coded and it is the only part of the residual block transmitted. At the decoder side the reconstructed block of the current block is obtained by adding the predictor block and the residual block, where the residual block corresponds to the sub-block of the initial residual. In contrast to regular SBT, with ASBT the position (and / or the orientation) of the subblock is inferred. The inference of the position and / or orientation may be determined from the Inter predictor block. In further contrast to SBT, with ASBT the position of the residual subblock is not constrained to be located adjacent to three borders of the residual block but may be located at any position along an axis of the block (and in either orientation). This general principle is called Advanced SBT (ASBT) in the following description. It will be appreciated that embodiments of the present invention described herein are not limited to use with ASBT and may be applied to other coding methods wherein a subset (i.e. portion) of the residual block is transformed (and / or transmitted). An advantage of the ASBT method is a coding efficiency improvement, as the residual is reduced thanks to the sub-sampling, a minimum of parameters is transmitted. More generally the ASBT method allows encoding of the full transform block to be avoided. The motion estimation process obtains the motion information for the coding block. If a residual is needed, it is to signal new content or a deformation of the content of the coding block. In general, new content or a deformation appears at the frontier of objects within the block, and therefore along edges. According to the ASBT method, the residual coding is only for the sub part containing these edges. When the block predictor contains also this edge, our proposed method can identify the sub part of the block containing an edge and encode only this part of the residual block. In addition, the ASBT method provides advantages extending beyond those provided by regular SBT. As described above, when using regular SBT, it is necessary to explicitly signal information indicating the location, size, and orientation of the residual subblock, and the residual subblock itself is limited to only eight different configurations of position, size, and orientation (as shown in Figure 9). In contrast, our proposed method provides increased coding efficiency, as the position and orientation of the residual subblock can be identically inferred by the encoder and decoder, and so need not be transmitted. Furthermore, the residual subblock can take any position and orientation within the subblock, as compared to previous methods such as SBT wherein the residual subblock is constrained to be adjacent to three borders (i.e. to be along an edge) of the residual block, and thus can take only a limited number of positions in the residual block. The position and the direction of the transform subblocks are determined based on the corresponding Inter predictor block. This ASBT mode is signalled at Transform Unit level and it can be applied on SBT transform units and other transform units as well. This ASBT mode is only applied for Inter coding blocks. The principle of the Advanced SBT (ASBT) is to determine the position and the direction of a subblock partition thanks to the Inter prediction block. The possible subblock partitions are the same as the ones of SBT in the WC specifications. However, the proposed Advanced SBT infers the position and the direction of the subblock partitioning to save some signalling. Figure 25 depicts this principle at encoder side. For each subblock size and direction, the encoder evaluates the best position of the transform part (grey area). Then, based on the best position, the direction for each subdivision is determined. Eventually the encoder determines the best subdivision. The position selected is the position of the subblock which maximizes the sum of gradients obtained on the corresponding Inter predictor block. And regarding the direction (vertical or horizontal), the selected direction is the one that maximizes the sum of gradients of each best position. Compared to the SBT mode of VVC, only the subblock subdivision is signalled if the enabled flag of the proposed method is true. The proposed Advanced SBT is signalled at TU level and it is also allowed for SBT TU with residual. The enabled flag and the subdivision flags are CABAC-coded and the context probability increment value depends on the use of SBT. The flag information related to the proposed method can be signalled alternatively before the transform skip flag inside the TU coding or after the last significant position, and not coded if there is only one coefficient, according to a flag transmitted in the picture header. The Advanced SBT is not allowed for Intra slices and for some Inter modes as CUP and GPM. It is also disabled for LFNST and MTS and for Screen Content sequences thanks to an SPS flag. The Advanced SBT is applied only for the Luma component. It is important to note that the implementation of this SBT mode has no parsing issue even if the position and the direction is based on the Inter predictor block. To reduce the encoding time, some early encoder terminations are also used to limit the number of evaluations of this proposed ASBT mode. Use of Energy Values For ASBT (and other subblock residual methods) the sub partitioning residual block may be obtained by computing the energy for each sample and, according to these energies, the block position having the maximum sum of energies is selected as the position encoded / decoded. Figure 13 illustrates this aspect. To obtain a regular reconstructed block (1301), the predictor block (1302) is added to the residual block (1303). The residual block is dequantized and inverse transformed at decoder side to obtain a residual block in the samples domain. In the proposed aspect, when the decoder obtains the predictor block (1302), it computes the energy for each sample of this block (1304) in order to obtain a block with the same size as the predictor block with the energy values (1306). Then the decoder detects the subblock position by determining the position which has the maximum energy (1307). This related subblock (1308) is then dequantized and inverse transformed to obtain a residual subblock (1309). This subblock (1309) is added to the predictor block (1302) to obtain the reconstructed block. So, in the residual, with the same size of reconstructed block (1303) (and the same size as the predictor block), contains zero values excepts for the subblock residual (1309). An advantage provided by using energy values to infer the position and / or orientation of the residual subblock is that the energy values of the block can be easily and efficiently determined. Calculating the energy values is a reliable method to identify the portion of the residual block containing where deformation of the content of the block, or new content of the block, is located. In some implementations the energy values may be, for example, gradient values that may be calculated via convolution with a Sobel filter. Position Inference The position of the subblock residual may be determined thanks to the algorithm described previously. For the description of this aspect, it is considered that the size of the subblock residual and its direction are known. So, for a subblock size and direction each possible position in the block containing the energy values is evaluated and the position which maximises the energy value is the position selected for the subblock residual. An advantage of this is a coding efficiency improvement. As shown in Figure 14(a), the regular SBT method has 8 coding possibilities, requiring a minimum of four bits to signal the selected possibility. On the other hand, by inferring the position of the residual subblock, ASBT allows only 4 coding possibilities to be signalled as depicted in Figure 14 (b). This saves one bit or one bin. As set out below, it is in fact possible for the orientation of the subblock to be inferred also, enabling a potential saving of two bits or bins compared to SBT. Furthermore, as shown in Figure 14(b), ASBT allows a greater number of possible positions of the residual subblock to be selected compared to SBT. For example, if we consider the sub division by 2 vertically, the regular SBT has only 2 possible coding (1401) and (1402). This requires a signalling of one bit or one bin. The number of possibilities is equal to width -width / 2, so width / 2 possibilities. Where the width is the width of the initial block. This is represented by 1409. Moreover, only one coding is possible so this cost is 0 bit. By considering the division by 4 vertically, 2 possible sub blocks are possible (1403, 1404) for the regular SBT. The number of possibilities is equal to width - width / 4. So, the ASBT method divides by 2 the amount of subblocks which need to be indicated in the bitstream for the regular SBT and it increases the number of coding possibilities. In some cases, the energy for a sample may be a Gradient value. The gradient may be a Sobel gradient computed thanks to a Sobel filter / kernel. To compute the Sobel gradient, for a current sample, two 3x3 kernels are convolved with the current sample and its neighbouring samples (as set out below, other sizes of kernel may be used to compute the gradient). One corresponds to the horizontal derivative approximation Gx and one to the vertical derivative approximation Gy. The horizontal kernel is given by the following matrix: +1 0 -1 +2 0 -2 +1 0 -1 The vertical kernel is given by the following matrix: +1 +2 +1 0 0 0 -1 -2 -1 The gradient magnitude is equal to square root of the sum of the square horizontal derivative approximation Gx and the square vertical derivative approximation Gy as the following equation: G = + G^ This amplitude is considered as the energy value for a current sample which is set inside the energy value block (1306 The energy computed may be based on Sobel kernels and the sum of the absolute value of the horizontal derivative approximation Gx and the absolute value of vertical derivative approximation Gy as the following equation: G = I GJ + |Gy | The Sobel kernels (or other kernel types) may be larger than the 3x3 kernels. For example, the kernels used may be two 5x5 kernels, one for the absolute value of the horizontal derivative approximation Gx and one the absolute value of the vertical derivative approximation Gy. The larger horizontal kernel is given by the following matrix: +5 +4 0 -4 -5 +8 +10 0 -10 -8 +10 +20 0 -20 -10 +8 +10 0 -10 -8 +5 +4 0 -4 -5 The larger vertical kernel is given by the following matrix: +5 +8 +10 +8 +5 +4 +10 +20 +10 +4 0 0 0 0 0 -5 -8 -10 -8 -5 -4 -10 -20 -10 -4 Problem of block predictor border. As mentioned previously, the Sobel kernels are convolved with current sample and its neighbouring samples. For samples in the border of the current block, the samples outside are not available. As depicted in Figure 15, for ASBT, the Sobel computation can be applied only for the samples inside the current block (a) with all neighbouring samples inside this block. If the kernels are 3x3, all samples in the border can’t be considered as some samples used to determine the horizontal derivative approximation Gx and / or the vertical derivative approximation Gy are outside the current block predictor. Which is represents for an 8x8 block 28 samples without value on 64 samples. And if the kernels are 5x5, all samples in the border with a range of two samples can’t be considered. When the energy value can’t be computed for a sample because some neighbouring samples are not available to compute the horizontal derivative approximation Gx or the vertical derivative approximation Gy, a mirror may be applied around the block and these virtual samples are used to derive the horizontal derivative approximation Gx or the vertical derivative approximation Gy. Figure 15 illustrates this. For example, when the kernels are 3x3, the samples in the border (grey) are copied around the current block predictor (dashed), as depicted in Figure 15 (b). When the kernels are 5x5, the same copying operation is applied and the samples in the border less than 1 sample (dark grey) are copied to two samples around the border as depicted in Figure 15 (c). Alternatively, the positions around the border of the block predictor may have no energy value. Specifically, for positions where not all samples are available for the computation of the energy, the energy value is set to a default value. This default value can be 0 or an average of the values which can be computed. Position determination As mentioned previously, according to the ASBT method, to detect the best subblock position (1307), for a current direction and sub division, the energy of each possible position needs to be determined. It consists in determining, for each position the sum of the energy for each sample. ASBT position determination - Basic algorithm The sum of energy for a current position of subblock is obtained by the sum of the energy of each sample inside this sub block; The following formula gives an example of this sum computation when the subdivision is 4 and the direction is vertical. p-w / 4 Epostpi = / y ^[cij] i=p Where Epos[p] is the sum of energy of position p, and w is the width of the predictor block, h is the height of the predictor block, w / 4 is the width of the subblock residual block. And Eft] [ / ] is the energy corresponding to the sample position (i, j). ASBT position determination - Fast Algorithm determination To obtain the sum of energy values for each possible position of subblock, the algorithm stores the sum already computed to reduce the number of summing operations. When the subdivision is 4 and the direction is vertical the algorithm can be summarized as the following and as depicted in Figure 16: First the sum of energy values (e.g. gradient values) for each row is computed (1601) as the following: h Erow[i] = 7=0 Then the sum of energy values of the first position (position 0) Epos[0] is computed (1602) by summing the w / 4 first Erow[i], Then, (1603) for each row i from 1 to the maximum possible w-w / 4, the sum of energy values for each possible position of the residual subblock is obtained via the following formula (1604): r W 1 Epos[^] Ep0S [i 1] Erow [i 1] "I- Erow p + “ + lj Where the energy for the position [i] is equal to the energy of position [i-1 ] minus the previous row energy (the energy value of the first row of the subblock in position [i], light gray in Figure 16 (c)) plus the energy of the last row of the current subblock position (dark gray in Figure 16 (c)). ASBT Direction inference The direction vertical or horizontal of the transform block may be inferred based on the energy values of the vertical and horizontal sub block partition. Figure 17 illustrates this aspect. For one possible subdivision (i.e. for one size of residual subblock), the energy EVerticai related to the vertical sub partition (1701) is computed or obtained (1703) if the position inference is applied. In the same way, the ^Horizontal related to the horizontal sub partition (1702) is computed or obtained (1704) if the position inference is applied. The sub partitioning direction which maximizes the energy is selected as the best direction (1705). The energy related to the vertical and / or horizontal orientations may be determined to be the sum of energy values corresponding to the position in the vertical / horizontal orientation with the highest sum of energy values. Alternatively, the energy related to the vertical / horizontal orientation may be determined to be the average sum of energy values for each position in the vertical / horizontal orientation. Alternatively, the position horizontally or vertically can be signalled and the direction may be inferred. Consequently, the position is signalled, and the energy value is computed for both vertical and horizontal subblock partition. The position may be coded using a syntax element. This syntax element has a range of values from 0 to the maximum possible position minus 1. The related number of bits or bins for this syntax element is equal to log2 of the range. ASBT - Parsing issue of direction inference For many video applications, as video streaming, the bitstream containing the video is not fully decoded as for the end user. For example, the bitstream may be parsed in such a way that only the syntax elements are extracted and decoded from the bitstream but the reconstructed images of the video are not obtained. To transmit and decode the residual coding several syntax elements are used. As for example, these syntax elements are used to obtain the last significant position, the coefficients, the sign prediction syntax elements. To obtain these syntax elements from the bitstream, the exact size of the transform block including the height and width need to be known. When the direction is inferred via the ASBT method the height and the width are not known until that the algorithm is applied. This implies that the parsing only is not possible. Accordingly, when direction inference algorithm is enabled the full decoding process may be applied. Alternatively or additionally, when the direction inference implies a specific decoding in order that the parsing does not require the usage of the reconstructed samples. The decoder or the parser may determine that the direction inference is allowed for the current transform residual. The decoder or parser decodes from the bitstream the information that the proposed method is applied. Instead of fully applying the method based on a full decoding as in the previous embodiment, the decoder or parser extracts the syntax elements related to the transform block to be decoded whatever the direction of this transform block to be decoded. The transform coefficients may be always transmitted with the same orientation. Accordingly, the transform coefficients block extracted from the bitstream for the proposed method has always the same direction. When the algorithm detects that the extracted decoding transform coefficients has not the correct direction (i.e. the determined direction is different from the orientation in which the transform coefficients block was transmitted) it processes it in order to obtain the correct direction. ASBT and SBT relationship ASBT can be decoded as well as SBT. Both sub sampling transform block modes are allowed. In such cases, ASBT refers to scenarios where at least the position is inferred or at least the direction is inferred (or both are inferred). ABST may be applied to an SBT transform unit. In this aspect, at decoder side the SBT transform mode is obtained as usual. Then, for the related transform unit to be decoded the ASBT method can be applied, if it is signalled. The ASBT process is not changed compared to the traditional usage of ASBT. But as defined in the additional embodiment, some parameters can be adapted. When ABST position obtained is the same as an SBT transform unit position, this position may not be considered to be valid (it is avoided) and the algorithm looks the second position which obtains the maximum energy. Or alternatively the ASBT positions which are the same as an SBT transform unit position are not evaluated. Alternatively, when ABST position is the same as an SBT transform unit position, this position is considered as valid if there is another difference for the coding of ASBT compared to SBT. This difference can, for example, be a different transform or a limitation for the sign prediction. In some cases, when ASBT is enabled for an SBT transform unit, only the position inference is enabled for ASBT. So, the direction inference is not allowed. Additionally, to this aspect the direction selected for ASBT is the same as for SBT. ASBT transforms. As described previously, SBT has a specific transforms combination adapted for each sub partition. The transform selected for an ASBT sub partitioning may be the same as those used for SBT. Alternatively, the transform selected for an ASBT sub partitioning is the DST-7 or DCT-2. According to the SBT transforms selection, the DST-7 should be the more commonly-applied transform. Indeed, compared to SBT the only change of the usage of DST-7 for all possible sub partitions is the usage of DCT-8 (vertically or horizontally) when the sub partition is located at the top left of the CU. Signalling of the ASBT flag The ASBT method may be signalled in the bitstream thanks to a flag which enables, at decoder side the method when it is equal to 1 and disables it when it is equal to 0. The enabled flag of the ASBT method may be transmitted in the transform unit. The following table of syntax elements illustrates this. In this table the tuASBTenabledflag is transmitted 5 after the tu joint cbcr residual flag and before the transform skip flag. And before the residual_coding(). transform_unit( xO, yO, tbWidth, tbHeight, treeType, subTuIndex, chType ) { Descriptor if( spsjointcbcrenabledflag && ( ( CuPredMode[ chType ][ xO ][ yO ] = = MODEINTRA && ( tu_cb_coded_flag[ xC ][ yC ] tu_cr_coded_flag[ xC ][ yC ] ) ) ( tu_cb_coded_flag[ xC ][ yC ] && tu cr coded flagf xC ][ yC ] ) ) && chromaAvailable) tujoint_cbcr_residual_flag[ xC ][ yC ] ae(v) if (ASBTallowed) tuASBTenabledflag ae(v) if (tuASBTenabledflag) tuASB TSub di vi si onflag ae(v) if( tu_cb_coded_flag[ xC ][ yC ] && treeType != DUAL TREE LUMA ) { if( spstransformskipenabledflag && !BdpcmFlag[ xO ][ yO ][ 1 ] && wC <= MaxTsSize &&hC <= MaxTsSize &&!cu_sbt_flag ) transform_skip_flag[ xC ][ yC ][ 1 ] ae(v) if( !transform_skip_flag[ xC ][ yC ][ 1 ] shtsresidualcodingdisabledflag ) residual_coding( xC, yC, Log2( wC ), Log2( hC ), 1 ) else residual_ts_coding( xC, yC, Log2( wC ), Log2( hC ), 1 ) } The decoding of the enabled ASBT flag may depend on the usage of some previous syntax elements or variables. As depicted in the table of syntax elements above, the ASBT enabled flag, tuASBTenabledflag, is not coded based on the value of the variable ASBT allowed. The value of this variable depends on the usage of some previous syntax elements or variables. When ASBT enabled flag is true, the sub division information is transmitted. Additionally, it is coded just after the ASBT enabled flag. The information may be one or more flags, or a unary max code. If a particular sub division is not possible no information is transmitted. If this information is a flag (or a bin), and if one of the subdivisions is not possible, the flag is not transmitted. If the information is represented by multiple flags or bins, at least the flag or bin representing the impermissible subdivision is not transmitted. For example, the subdivision not available may be the division by 4. And it is not considered as available because, the subdivision gives a transform not available. Alternatively, when more than 2 subdivisions are used and one or more are not available the code word is adapted. Signalling of the direction When the direction is not inferred one flag indicates the direction. The direction flag may be signalled after the enabled flag and before the sub division flag or related information. The following table of syntax elements illustrates this, where the direction flag is tu ASBT Direction flag. transform_unit( xO, yO, tbWidth, tbHeight, treeType, subTuIndex, chType ) { Descriptor if( spsjointcbcrenabledflag && ( ( CuPredMode[ chType ][ xO ][ yO ] = = MODE INTRA && ( tu cb coded_flag[ xC ][ yC ] tu_cr_coded_flag[ xC ][ yC ] ) ) ( tu cb coded_flag[ xC ][ yC ] && tucrcoded_flag[ xC ][ yC ] ) ) && chromaAvailable) tujoint cbcr residual_flag[ xC ][ yC ] ae(v) if (ASBTallowed) tuASBTenabledflag ae(v) if (tuASBTenabledflag) tuASB T_Directi onfl ag ae(v) if (tuASBTenabledflag) tuASB TSub di vi si onflag ae(v) if( tu_cb_coded_flag[ xC ][ yC ] && treeType != DUAL TREE LUMA ) { if( spstransformskipenabledflag && !BdpcmFlag[ xO ][ yO ][ 1 ] && wC <= MaxTsSize &&hC <= MaxTsSize &&!cu_sbt_flag ) transform skip_flag[ xC ][ yC ][ 1 ] ae(v) if( !transform_skip_flag[ xC ][ yC ][ 1 ] shtsresidualcodingdisabledflag ) residual_coding( xC, yC, Log2( wC ), Log2( hC ), 1 ) else residual_ts_coding( xC, yC, Log2( wC ), Log2( hC ), 1 ) } The ASBT enabled flag may be CABAC coded. It means that a bin is transmitted, this bin has its own context, so its own probability states which change according to the values encoded as explained previously. EMBODIMENTS According to one aspect of the invention, the in-loop filtering operations illustrated in reference to Figure 6 are modified to take into account new coding methods wherein transform unit size and position has increased flexibility and variability. These new coding processes include, as an example, coding processes such as ASBT wherein a subblock of the residual block is coded and transmitted. The following embodiments are described in the context of the ASBT method described herein, however it will be appreciated that these embodiments may be applied in the context of any other coding process in which the transform unit can have varying sizes and / or positions within the block to be coded - such as those coding processes wherein a region / subblock of the residual block is coded. In a first set of embodiments 1.x below, the deblocking filter processing is modified or adapted in order to apply the deblocking process of the generated TU of the ASBT mode. Embodiment 1.1: The deblocking filter is not restricted to a 4x4 grid. As described above in reference to Figure 6, the deblocking filter is most of the time applied on a 4x4 grid on luma channel. However, in the case of the ASBT mode, the TU generated can be located at any position in the CU (i.e. the residual subblock / TU can take any position at a 1x1 grid resolution within the block to be coded (CU)). As illustrated in Figure 18 representing 3 neighbouring Luma CUs, the ASBT TU position will therefore generate possible boundaries inside the CU (black square) which will not be necessary aligned with the 4x4 grid for the processing of the deblocking filter. In order to remove the potential blocking artefacts generated on the frontiers of the ASBT TU blocks, the deblocking filter should release the constraint of being applied at a 4x4 grid. In that case, this ensures that the filtering process of the boundaries will be really performed at the boundary locations corresponding to the TU frontiers generated by the ASBT mode. The main advantage of this embodiment is to perform the deblocking filter on any boundaries generated by the ASBT mode. The operation of the deblocking filter operations (such as the Boundary Strength determination, tc and P threshold parameters computation, pixel value differences from both sides of the boundary and determination of the coding modes of the blocks Bp and Bq) as presented in reference to Figure 6 is therefore applied on the new 4 boundaries of the TU provided by the ASBT mode. These boundaries for deblocking filtering are illustrated by the rectangle represented in dotted grey lines in the Figure 18. It should be noted that the above embodiment is not limited to the transform unit (TU) generated by the ASBT mode but it may be also extended to any technique that would lead to the creation of transform units that can have any position and any size included in the CU. It means that the TU could be inside the CU and could have no common frontier / boundary with the CU. Embodiment 1.2: The ASBT mode is restricted to a 4x4 grid. Contrary to the previous embodiment, the deblocking filter operation is not changed in this embodiment and the determination of the position for the TU related to the ASBT is restricted so that the position of the generated TU is forced to follow a 4x4 grid. This embodiment is illustrated in reference to the Figure 19. In that case, the deblocking filter can operate normally on the 4x4 grid on which the boundaries of the TU of the ASBT mode are lying. The main advantage of this embodiment is to not change the processing of the deblocking filter. In such a case and in an advantageous way, the computation of the gradient values to determine the position on the TU for the ASBT mode can be limited to a 4x4 grid similar to the deblocking filter. This enables to reduce the number of computation operations to determine the best ASBT positions. Indeed, the number of positions in this embodiment is reduced by 4. In another variant and to get more coding efficiency and accuracy, the gradient computation for the position determination is carried on the full 1x1 grid and the closest position to the maximum gradient value position, on the 4x4 grid, is selected. Embodiment 1.3: The ASBT mode is not restricted a 4x4 grid but the deblocking filter is. In this embodiment the deblocking filter operation is still operating on a 4x4 grid and the determination of the position for the TU related to the ASBT is done on a 1x1 grid as initially described. This embodiment is illustrated in the Figure 20a. In that case, the processing of the deblocking filter is applied on the dotted grey rectangle and it is not aligned to the horizontal boundaries of the ASBT TU (rectangle with black solid line). However, as the deblocking filter can use long filters, these long filters could be used to smooth the ASBT TU boundaries despite they are not fully coinciding with the 4x4 grid. In a variant of this embodiment illustrated in Figure 20b, only the vertical boundaries (vertical dotted grey lines) which are aligned with the 4x4 grid, are filtered while the horizontal boundaries are not filtered at all by the deblocking filter. The decision between the embodiment of Figure 20a and Figure 20b could be done depending on the distance between the TU frontiers and the 4x4 grid. For example, in a case of a short distance between the 4x4 grid and the TU boundary (e.g. when the absolute distance difference <1 pixel), the deblocking filter could be applied. However, when the distance is longer (e.g., when the absolute distance difference >1 pixel, i.e. half of the maximum absolute distance difference), the deblocking filter is not performed. The above embodiments 1 .x are illustrating the Luma component case where the grid used to apply the deblocking filter is set to a 4x4 grid. The above embodiments can be extended to any NxN grid. In particular for the Chroma component, the value of N is most of the time set to 8. In a second set of embodiments 2.x, the bilateral filter steps and parameters for applying the bilateral filtering are modified to handle the TU generated by the ASBT mode. Embodiment 2.1: The bilateral filter is taking into account the size of the TU generated by the ASBT mode. As mentioned in reference to the Figure 6 explaining the different operations of the Bilateral filter, the computation of the TU-based scale factor CTU is adapted to take into account the size of the TU generated by the ASBT mode. In particular, in the following formulae of the scaling factor cw\ = LUTw / l(log2(widthTU), log2(heightTU)) The variable w and h should correspond to the size of the TU generated by the ASBT mode and not the size of the current CU. In a similar way, the scaling factor Cm ad should take into account the TU size generated by the ASBT mode and not the size of the related CU Cm ad — LUTMAD(min( MADtu » 4,15)) where the MAD of a (h x w)-size TU with the channel samples denoted by s^- is defined as follows: h h Similarly, to the deblocking filter, it should be noted that the above embodiment on the Bilateral filter is not limited to the transform unit (TU) generated by the ASBT mode but it may be also extended to any technique that would lead to the creation of transform units that can have any position and size inside the CU. It means that the TU could be inside the CU and could have no common frontier with the CU. General Residual Subblock Methods It will be appreciated that the embodiments of the present invention are not limited to coding processing utilizing the ASBT and SBT methods described above. The present invention may be applied for any encoding and decoding processes where the boundaries of the determined TU do not align with the locations at which filtering operations are applied, such as coding processes wherein only region of the residual block is coded, and said region can take any position within the residual block (i.e. the region can take any position on a 1x1 grid of samples in the residual block). The region may have any configuration may be derived using any suitable method. The region does not need to extend all of the way across the residual block in either dimension. For example, a coding process may involve coding only a region of the residual block corresponding to a quadrant of the residual block (e.g. the upper-left quarter of the residual block), or a smaller / larger region located in one corner of the residual block. Alternatively, the region may be any continuous area of residual samples of any size, located at any position within the residual block. Implementation of the invention Figure 21 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 / streaming, 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 above-described 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 anFPGA (“Field-Programmable Gate Array”) or an ASIC (“Application-Specific Integrated Circuit”). Figure 22 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 23 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 24 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 / 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

1. A method of encoding one or more images into a bitstream, wherein the method comprises a process which includes:determining a residual subblock comprising an area of a residual block for a block to be encoded; the method further comprising:controlling a filtering operation, for the block to be encoded, based on the determined residual subblock; andencoding transform coefficients, of a transform block to be encoded, based on the residual subblock area.

2. The method of claim 1, wherein determining a residual subblock comprises determining a position of the residual subblock within a residual block of the block to be encoded; wherein the position of the residual subblock is located on an NxN grid within the residual block.

3. The method of claim 2, wherein the value of N is determined to align the position of the residual subblock with one or more positions at which the filtering operation may be applied within the block to be encoded.

4. The method of any one of claims 1 to 3, wherein the filtering operation comprises a deblocking filter.

5. The method of claim 4, wherein controlling the filtering operation comprises applying the deblocking filter to samples of the block to be encoded at positions in the block corresponding to the boundaries of the residual subblock.

6. The method of claim 4 or claim 5, wherein controlling the filtering operation comprises not constraining the deblocking filter to be aligned with an NxN grid within the block to be encoded.

7. The method of claim 4, wherein controlling the filtering operation comprises:determining, for one or more boundaries of the residual subblock, the distance between the boundary and an NxN grid within the residual block;based on determining that the distance is less than or equal to a predetermined threshold distance, applying the deblocking filter to samples of the block to be encoded at positions in the block on the NxN grid corresponding to the boundary of the residual subblock.

8. The method of claim 7, further comprising:based on determining that the distance is greater than the predetermined threshold distance, not applying the deblocking filter to samples of the block to be encoded at positions in the block corresponding to the boundary of the residual subblock.

9. The method of any one of claims 2, 3 and 6 to 8, wherein the NxN grid is a 4x4 grid or an 8x8 grid.

10. The method of any one of claims 2, 3, and 6 to 9, wherein the block to be encoded is ablock of Luma samples, and the NxN grid is a 4x4 grid.

11. The method of any one of claims 2, 3, and 6 to 9, wherein the block to be encoded is ablock of Chroma samples, and the NxN grid is an 8x8 grid.

12. The method of any one of claims 1 and 4 to 8 wherein the filtering operation comprises a bilateral filter.

13. The method of claim 12, wherein an output of the bilateral filter is based on a bilateral filter offset value, the value of the bilateral filter offset value is based on a scaling factor; and the method further comprises determining the value of the scaling factor based on the height and width of the determined residual subblock.

14. A method of decoding one or more images from a bitstream, wherein the method comprises a process which includes:determining a residual subblock comprising an area of a residual block for a block to be encoded; the method further comprising:decoding transform coefficients, of a transform block to be decoded, based on the residual subblock area; andcontrolling a filtering operation based on the determined residual subblock.

15. The method of claim 14, wherein determining a residual subblock comprises determining a position of the residual subblock within a residual block of the block to be decoded; wherein the position of the residual subblock is located on an NxN grid within the residual block.

16. The method of claim 15, wherein the value of N is determined to align the position of the residual subblock with one or more positions at which the filtering operation may be applied within the block to be decoded.

17. The method of any one of claims 14 to 16, wherein the filtering operation comprises a deblocking filter.

18. The method of claim 17, wherein controlling the filtering operation comprises applying the deblocking filter to samples of the block to be decoded at positions in the block corresponding to the boundaries of the residual subblock.

19. The method of claim 17 or claim 18, wherein controlling the filtering operation comprises not constraining the deblocking filter to be aligned with an NxN grid within the block to be encoded.

20. The method of claim 17, wherein controlling the filtering operation comprises: determining, for one or more boundaries of the residual subblock, the distance between the boundary and an NxN grid within the residual block;based on determining that the distance is less than or equal to a predetermined threshold distance, applying the deblocking filter to samples of the block to be decoded at positions in the block on the NxN grid corresponding to the boundary of the residual subblock.

21. The method of claim 20, further comprising:based on determining that the distance is greater than the predetermined threshold distance, not applying the deblocking filter to samples of the block to be decoded at positions in the block corresponding to the boundary of the residual subblock.

22. The method of any one of claims 15, 16, and 19 to 21, wherein the NxN grid is a 4x4 grid or an 8x8 grid.

23. The method of any one of claims 15, 16, and 19 to 22, wherein the block to be encoded is a block of Luma samples, and the NxN grid is a 4x4 grid.

24. The method of any one of claims 15, 16, and 19 to 22, wherein the block to be encoded is a block of Chroma samples, and the NxN grid is an 8x8 grid.

25. The method of any one of claims 14 and 17 to 21 wherein the filtering operation comprises a bilateral filter.

26. The method of claim 25, wherein an output of the bilateral filter is based on a bilateral filter offset value, the value of the bilateral filter offset value is based on a scaling factor; and the method further comprises determining the value of the scaling factor based on the height and width of the determined residual subblock.

27. A device for encoding one or more images into a bitstream, the device comprising: means for determining a residual subblock comprising an area of a residual block for a block to be encoded;means for controlling a filtering operation, for the block to be encoded, based on the determined residual subblock; andmeans for encoding transform coefficients, of a transform block to be encoded, based on the residual subblock area.

28. The device of claim 27, further comprising means for performing the method according to any one of claims 2 to 13.

29. A device for decoding one or more images from a bitstream, the device comprising: means for determining a residual subblock comprising an area of a residual block for a block to be encoded;means for decoding transform coefficients, of a transform block to be decoded, based on the residual subblock area; andmeans for controlling a filtering operation based on the determined residual subblock.

30. The device of claim 29, further comprising means for performing the method according to any one of claims 14 to 26.

31. A computer program which is arranged to, upon execution, cause the method of any one 5 of claims 1 to 26 to be performed.

32. A computer-readable storage medium upon which is stored the computer program according to claim 31.A