EP3632113B1 - Procédé et dispositif de codage et de décodage d'image - Google Patents

Procédé et dispositif de codage et de décodage d'image Download PDF

Info

Publication number
EP3632113B1
EP3632113B1 EP18725502.1A EP18725502A EP3632113B1 EP 3632113 B1 EP3632113 B1 EP 3632113B1 EP 18725502 A EP18725502 A EP 18725502A EP 3632113 B1 EP3632113 B1 EP 3632113B1
Authority
EP
European Patent Office
Prior art keywords
filter parameters
adaptive offset
sample adaptive
candidate sets
block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP18725502.1A
Other languages
German (de)
English (en)
Other versions
EP3632113A1 (fr
Inventor
Philippe Bordes
Ya CHEN
Fabien Racape
Franck Galpin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Madison Patent Holdings SAS
Original Assignee
InterDigital Madison Patent Holdings SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP17305626.8A external-priority patent/EP3410723A1/fr
Application filed by InterDigital Madison Patent Holdings SAS filed Critical InterDigital Madison Patent Holdings SAS
Priority to EP24153925.3A priority Critical patent/EP4336840A3/fr
Publication of EP3632113A1 publication Critical patent/EP3632113A1/fr
Application granted granted Critical
Publication of EP3632113B1 publication Critical patent/EP3632113B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/117—Filters, e.g. for pre-processing or post-processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/147—Data rate or code amount at the encoder output according to rate distortion criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/186—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/80—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation
    • H04N19/82—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation involving filtering within a prediction loop

Definitions

  • the present principles generally relate to a method and a device for encoding and decoding blocks of a picture part, and more particularly, to a method and a device for picture encoding and decoding with in-loop sample adaptive offset filtering.
  • video coding schemes usually employ prediction and transform to leverage spatial and temporal redundancy in the video content.
  • intra or inter prediction is used to exploit the intra or inter frame correlation, then the differences between group of samples in the original image and in the predicted image, often denoted as residuals, are transformed, quantized and entropy coded.
  • residuals the differences between group of samples in the original image and in the predicted image, often denoted as residuals.
  • the compressed data is decoded by inverse processes corresponding to the prediction, transform, quantization and entropy coding.
  • In-loop filtering may comprise several filtering processes such as Deblocking Filtering (DF), Sample Adaptive Offset (SAO) filtering as in HEVC, and/or Adaptive Loop Filtering ALF such as Wiener filters. These filters may be applied successively in this order or in a different order.
  • DF Deblocking Filtering
  • SAO Sample Adaptive Offset
  • ALF Adaptive Loop Filtering
  • the Sample Adaptive Offset filtering process is described in section 8.7.3 of the document ITU-T H.265 entitled "High Efficiency Video Coding" (version of April 2015).
  • the SAO filtering comprises adding offsets to some reconstructed samples in order to reduce coding artifacts, e.g. ringing or banding artifact.
  • Two types of filtering may be performed when the SAO filtering is enabled (or activated): Edge Offset (EO) type or Band Offset (BO) type.
  • the SAO filtering reduces sample distortion by first classifying the samples of one CTB (Coding Tree Block) into multiple categories and adding a specific offset to each sample depending on its category.
  • Sets of SAO parameters (a set of SAO parameters comprising for example offsets, possibly offsets signs, filter type, etc) for each color component are thus determined on the encoder side and encoded at a CTU (Coding Tree Unit) level after other syntax elements of the CTU.
  • a CTU may thus inherit its SAO parameters from a neighboring CTU.
  • This decoding mode of SAO parameters is known as the merge mode. More precisely, in HEVC, a CTU may inherit its SAO parameters from a CTU located just above it (merge up) or just to the left (merge left) as depicted on Figure 1 . On this figure, a set of SAO parameters is effectively encoded for CTU 0, 2 and 6. The other CTUs inherit their SAO parameters. As an example, CTUs 1, 4 and 5 inherit their SAO parameters from CTU 0, CTU 3 inherits its SAO parameters from CTU 2 and CTU 7 inherits its SAO parameters from CTU 6.
  • CTU 3 can only inherit its SAO parameters from CTU 2
  • CTUs 1, 4, 5 can only inherit their SAO parameters from CTU 0.
  • CTU 7 may inherit its SAO parameters directly from CTU 6 (merge left) or indirectly (i.e. via CTU 3, merge up) from CTU 2. This method is thus inefficient since most of the CTUs of figure 1 may only inherit their SAO parameters from a single CTU while 3 sets of SAO parameter were encoded in the bitstream (namely one set of SAO parameters per CTU 0, 2 and 6).
  • a picture is an array of luma samples in monochrome format or an array of luma samples and two corresponding arrays of chroma samples in 4:2:0, 4:2:2, and 4:4:4 colour format or more generally an array of three color components such as Green, Red, Blue.
  • a "block” addresses a specific area in a sample array (e.g., luma Y), and a "unit” includes the collocated block of all color components (luma Y and possibly chroma Cb and chroma Cr for example).
  • a slice is an integer number of basic coding units such as HEVC coding tree units or H.264 macroblock units.
  • a slice may consist of a complete picture as well as part thereof. Each slice may include one or more slice segments.
  • the word “reconstructed” and “decoded” can be used interchangeably. Usually but not necessarily “reconstructed” is used on the encoder side while “decoded” is used on the decoder side. It should be noted that the term “decoded” or “reconstructed” may mean that a bitstream is partially “decoded” or “reconstructed,” for example, the signals obtained after deblocking filtering but before SAO filtering, and the reconstructed samples may be different from the final decoded output that is used for display. We may also use the terms “image,” “picture,” and “frame” interchangeably.
  • HEVC High Efficiency Video Coding
  • present principles are not limited to HEVC, and can be applied to other standards, recommendations, and extensions thereof, including for example HEVC or HEVC extensions like Format Range (RExt), Scalability (SHVC), Multi-View (MV-HEVC) Extensions and H.266.
  • HEVC or HEVC extensions like Format Range (RExt), Scalability (SHVC), Multi-View (MV-HEVC) Extensions and H.266.
  • the various embodiments are described with respect to the encoding/decoding of blocks of a picture part, e.g. blocks of a slice. They may be applied to encode/decode a whole picture or a whole sequence of pictures.
  • each of the methods comprises one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for proper operation of the method, the order and/or use of specific steps and/or actions may be modified or combined.
  • Figure 2 represents an exemplary architecture of a transmitter 1000 configured to encode a picture in a bitstream according to a specific and non-limiting embodiment.
  • the transmitter 1000 comprises one or more processor(s) 1005, which could comprise, for example, a CPU, a GPU and/or a DSP (English acronym of Digital Signal Processor), along with internal memory 1030 (e.g. RAM, ROM, and/or EPROM).
  • the transmitter 1000 comprises one or more communication interface(s) 1010 (e.g. a keyboard, a mouse, a touchpad, a webcam), each adapted to display output information and/or allow a user to enter commands and/or data; and a power source 1020 which may be external to the transmitter 1000.
  • the transmitter 1000 may also comprise one or more network interface(s) (not shown).
  • Encoder module 1040 represents the module that may be included in a device to perform the coding functions. Additionally, encoder module 1040 may be implemented as a separate element of the transmitter 1000 or may be incorporated within processor(s) 1005 as a combination of hardware and software as known to those skilled in the art.
  • the picture may be obtained from a source.
  • the source can be, but is not limited to:
  • the bitstream may be sent to a destination.
  • the bitstream is stored in a remote or in a local memory, e.g. a video memory or a RAM, a hard disk.
  • the bitstream is sent to a storage interface, e.g. an interface with a mass storage, a ROM, a flash memory, an optical disc or a magnetic support and/or transmitted over a communication interface, e.g. an interface to a point to point link, a communication bus, a point to multipoint link or a broadcast network.
  • the transmitter 1000 further comprises a computer program stored in the memory 1030.
  • the computer program comprises instructions which, when executed by the transmitter 1000, in particular by the processor 1005, enable the transmitter 1000 to execute the encoding method described with reference to Figures 6A to 6C .
  • the computer program is stored externally to the transmitter 1000 on a non-transitory digital data support, e.g. on an external storage medium such as a HDD, CD-ROM, DVD, a read-only and/or DVD drive and/or a DVD Read/Write drive, all known in the art.
  • the transmitter 1000 thus comprises a mechanism to read the computer program. Further, the transmitter 1000 could access one or more Universal Serial Bus (USB)-type storage devices (e.g., "memory sticks.") through corresponding USB ports (not shown).
  • USB Universal Serial Bus
  • the transmitter 1000 can be, but is not limited to:
  • Figure 3 illustrates an exemplary video encoder 100, e.g. a HEVC video encoder, adapted to execute the encoding method of Figures 6A to 6C .
  • the encoder 100 is an example of a transmitter 1000 or part of such a transmitter 1000.
  • a picture is usually partitioned into basic coding units, e.g. into coding tree units (CTU) in HEVC or into macroblock units in H.264.
  • CTU coding tree units
  • a set of possibly consecutive basic coding units is grouped into a slice.
  • a basic coding unit contains the basic coding blocks of all color components.
  • CTB luma coding tree block
  • the smallest luma coding tree block (CTB) size 16x16 corresponds to a macroblock size as used in previous video coding standards.
  • a CTB is the root of a quadtree partitioning into Coding Blocks (CB), and a Coding Block is partitioned into one or more Prediction Blocks (PB) and forms the root of a quadtree partitioning into Transform Blocks (TBs).
  • a Coding Unit includes the Prediction Units (PUs) and the tree-structured set of Transform Units (TUs)
  • PUs Prediction Units
  • TUs Tree-structured set of Transform Units
  • a PU includes the prediction information for all color components
  • a TU includes residual coding syntax structure for each color component.
  • the size of a CB, PB and TB of the luma component applies to the corresponding CU, PU and TU.
  • block or “picture block” can be used to refer to any one of a CTU, a CU, a PU, a TU, a CB, a PB and a TB.
  • block or “picture block” can be used to refer to a macroblock, a partition and a sub-block as specified in H.264/AVC or in other video coding standards, and more generally to refer to an array of samples of various sizes.
  • a picture is encoded by the encoder elements as described below.
  • the picture to be encoded is processed in units of CUs.
  • Each CU is encoded using either an intra or inter mode.
  • intra prediction 160
  • inter mode motion estimation (175) and compensation (170) are performed.
  • the encoder decides (105) which one of the intra mode or inter mode to use for encoding the CU, and indicates the intra/inter decision by a prediction mode flag. Residuals are calculated by subtracting (110) a predicted sample block (also known as a predictor) from the original picture block.
  • CUs in intra mode are predicted from reconstructed neighboring samples within the same slice.
  • a set of 35 intra prediction modes is available in HEVC, including a DC mode, a planar mode and 33 angular prediction modes.
  • the intra prediction reference is reconstructed from the row and column adjacent to the current block. The reference extends over two times the block size in horizontal and vertical direction using available samples from previously reconstructed blocks.
  • an angular prediction mode is used for intra prediction, reference samples can be copied along the direction indicated by the angular prediction mode.
  • the applicable luma intra prediction mode for the current block can be coded using two different options. If the applicable mode is included in a constructed list of three most probable modes (MPM), the mode is signaled by an index in the MPM list. Otherwise, the mode is signaled by a fixed-length binarization of the mode index.
  • the three most probable modes are derived from the intra prediction modes of the top and left neighboring blocks.
  • the corresponding coding block is further partitioned into one or more prediction blocks. Inter prediction is performed on the PB level, and the corresponding PU contains the information about how inter prediction is performed.
  • the precision of the motion information for motion compensation is one quarter-sample for the luma component and one eighth-sample for the chroma components.
  • a 7-tap or 8-tap interpolation filter is used for interpolation of fractional-sample sample positions, i.e., 1/4, 1/2 and 3/4 of full sample locations in both horizontal and vertical directions can be addressed for luma.
  • the residuals are transformed (125) and quantized (130).
  • the quantized transform coefficients, as well as motion vectors and other syntax elements, are entropy coded (145) to output a bitstream.
  • the encoder may also skip the transform and apply quantization directly to the non-transformed residual signal on a 4x4 TU basis.
  • the encoder may also bypass both transform and quantization, i.e., the residual is coded directly without the application of the transform or quantization process. In direct PCM coding, no prediction is applied and the coding unit samples are directly coded into the bitstream.
  • the encoder comprises a decoding loop and thus decodes an encoded block to provide a reference for further predictions.
  • the quantized transform coefficients are de-quantized (140) and inverse transformed (150) to decode residuals.
  • a picture block is reconstructed by combining (155) the decoded residuals and the predicted sample block.
  • An in-loop filter (165) is applied to the reconstructed picture, for example, to perform deblocking/SAO (Sample Adaptive Offset) filtering to reduce coding artifacts.
  • the filtered picture may be stored in a reference picture buffer (180) and used as reference for other pictures.
  • SAO filtering may be activated or de-activated at video level, slice level and CTB level.
  • Two SAO modes are specified: edge offset (EO) and band offset (BO).
  • EO edge offset
  • BO band offset
  • the sample classification is based on local directional structures in the picture to be filtered.
  • the parameters for EO or BO may be explicitly coded or derived from the neighborhood (merge up or merge left).
  • SAO can be applied to the luma and chroma components, where the SAO mode is the same for Cb and Cr components.
  • the SAO parameters are configured individually for each color component. More precisely, a set of SAO parameters (i.e. the offsets, the SAO types EO, BO and inactivated, the class in case of EO and the band position in case of BO) is encoded at a CTU level.
  • BO absolute offset values and signs are decoded.
  • EO only absolute offset values are decoded, the signs being inferred from the category (positive sign for categories 1 and 2, and negative sign for categories 3 and 4).
  • EO uses four 1-D directional patterns for sample classification: horizontal, vertical, 135° diagonal, and 45° diagonal, as shown in Figure 4 where the label "p c " represents a current sample and the labels "p 0 " and "pi" represent two neighboring samples.
  • Four EO classes are specified based on the directions, and each EO class corresponds to one direction. The selected EO class, only one for each CTB that enables EO, is signaled in the bitstream as side information.
  • the categorization rules for a sample are summarized in Table 1. Categories 1 and 4 are associated with a local valley and a local peak along the selected 1-D pattern, respectively, categories 2 and 3 are associated with concave and convex corners along the selected 1-D pattern, respectively. Positive offsets are used for categories 1 and 2, and negative offsets are used for categories 3 and 4.
  • the current sample value does not belong to categories 1- 4 (i.e., the current sample value is the same as its two neighbors, or if p 0 ⁇ p c ⁇ p 1 or p 0 > p c > pi), then it is in category 0 and SAO is not applied (i.e., offset is 0).
  • offsets are encoded. More precisely, the absolute values of four offsets are signaled by the encoder, one absolute value for each category. The signs of the offsets are not encoded but implicitly derived from the corresponding EO categories.
  • the range of sample values (for example, 0 - 255 in 8-bit) is uniformly split into 32 bands. One offset is added to all samples whose value belong to the same band.
  • only offsets of (NC - 1) 4 consecutive bands and the starting band position are signaled to the decoder as illustrated on Figure 5 .
  • the starting band is the eighteenth band and the encoded offsets value are 10, 0, 2, 3 ⁇ .
  • the starting band position (i.e. an index) indicates the position of the first band with an encoded offset within the 32 bands.
  • One offset is coded for each of the (NC - 1) bands and the remaining bands have an offset equal to zero.
  • the offset values may correspond to non-consecutive bands since the bands are managed as a circular buffer.
  • those four signaled bands can be considered as four categories, and the remaining bands can be considered as another category.
  • band and “category” interchangeably.
  • offsets are encoded for four bands. More precisely, the absolute values of four offsets are signaled by the encoder, one absolute value for each of the 4 bands. The signs of the offsets are also signaled by the encoder.
  • Figure 6A represents a flowchart of a method for encoding blocks of a picture part in a bitstream according to a specific and non-limiting embodiment.
  • the picture part may be the whole picture or a sub-part of it, e.g. a slice.
  • a transmitter 1000 e.g. such as the encoder 100, accesses a current block of a picture part.
  • the transmitter determines a reconstructed version of the accessed block also named reconstructed block.
  • the reconstructed block usually comprises a luma block, i.e. block of luma samples and chroma blocks, i.e. blocks of chroma samples.
  • Determining the reconstructed block usually but not necessarily comprises partial encoding (possibly without entropy coding) followed by decoding.
  • Partial encoding comprises subtracting a predictor from the accessed block to obtain a block of residuals, transforming the block of residuals into a block of transform coefficients, quantizing the block of coefficients with a quantization step size to obtain a quantized block of transform coefficients.
  • Decoding a block on the encoder side usually but not necessarily comprises de-quantizing and inverse transforming the quantized block of transform coefficients to obtain a block of residuals and adding the predictor to the block of residuals to obtain the reconstructed block.
  • the method may loop steps S110 and S120 over all blocks of the picture part in order to obtain a reconstructed picture part composed of all reconstructed blocks before continuing to step S130.
  • the transmitter obtains a plurality of candidate sets of filter parameters relating to both components luma and chroma and further determines an index (merge_idx) for each block of the picture part that identifies one candidate set among the plurality of candidate sets to be used for filtering the reconstructed block at step S140.
  • a set of filter parameters comprises at least one filter parameter.
  • the plurality of candidate sets of filter parameters may be determined off-line and thus obtained from a memory.
  • the plurality of candidate sets of filter parameters are determined on the fly by Rate-Distortion Optimization known as RDO as illustrated by Figure 9 from the content of the picture part.
  • the different variants e.g. re-ordering of the candidate sets in the list as disclosed for step S250 of Figure 13A
  • the list of candidate sets resulting in the best rate-distortion trade-off is selected.
  • the list of candidate sets comprises a specific candidate set of filter parameters known as the OFF candidate set.
  • the OFF candidate is put at a predefined position, e.g. the second position, in the list of candidate sets.
  • An index is also determined for each block of the picture part, said index identifying one candidate set among the plurality of candidate sets to be used for filtering the reconstructed block.
  • the index may also be determined by RDO.
  • the determination of the index is done after the list re-ordering.
  • the transmitter filters the reconstructed block with the candidate set of filter parameters identified by the index determined at step S130.
  • the block is not filtered at step S140.
  • the filter is a SAO filter and the filtering steps disclosed with reference to Figure 3 apply.
  • the method may loop step S140 over all blocks of the picture part in order to filter all these blocks before continuing to step S150.
  • the transmitter encodes the plurality of candidate sets of filter parameters in the bitstream.
  • three candidate sets of filter parameters are encoded (c-0, c-1 and c-2).
  • Each block of the picture part on the right side of Figure 7 inherits its filter parameters from one of the three candidate sets.
  • blocks Blk_0, Blk_1, Blk_4 and Blk_5 have the same filter parameters, i.e. the filter parameters of the candidate set c-0
  • the blocks Blk_2 and Blk_3 have the same filter parameters, i.e. the filter parameters of the candidate set c-1
  • the blocks Blk_6 and Blk_7 have the same filter parameters, i.e.
  • the filter parameters of the candidate set c-2 The OFF candidate if present in the list obtained at step S130 is not encoded in the bitstream but will be added in the list of candidate sets on the decoder side.
  • the candidate set used is referred by its number in the original candidate set list order.
  • the value of coded index (merge_idx) may be different for two blocks, even if these two blocks use the same candidate set for filtering.
  • two blocks may have the same value of coded index which corresponds to two different candidate sets because of the re-ordering of the list before determining the value of the indices.
  • the plurality of candidate sets of filter parameters are encoded in a header of a slice.
  • the plurality of candidate sets of filter parameters are encoded at the level of the first block (e.g. Blk_0 on Figure 7 ) of the picture part in the encoded order.
  • the three candidate sets of filter parameters are encoded with the syntax elements of the first block, Blk_0.
  • the transmitter encodes in said bitstream a data representative of a number of candidate sets of filter parameters.
  • the encoded data num_sao_cand_minus 1 is the number of candidate sets of filter parameters to be encoded minus one. Since the value of num_sao_cand_minus1 is necessarily inferior to the number of blocks in one picture part, e.g. in one slice, minus one, the number of bits representing the syntax element num_sao_cand_minus 1 is inferior to log2(number of blocks in one picture part minus one).
  • Table 2 An example of syntax of the HEVC type for SAO filtering is provided by tables 2 and 3.
  • Table 2 once num_sao_cand_minus1 is encoded, each candidate set of SAO parameters is encoded.
  • a candidate set here the OFF candidate, is inferred and thus not coded.
  • the syntax is modified as illustrated by Table 3.
  • Table 4 illustrates the encoding of a candidate set of SAO parameters according to the present principles.
  • slice_sao_luma_flag encoded in a slice header
  • slice_sao_luma_flag 0 specifies that SAO is disabled for the luma component in the current slice and SAO parameters for luma component are not present.
  • sao_type_idx_luma specifies the offsets type for the luma component.
  • sao_type_idx_chroma specifies the offsets type for the chroma components.
  • SaoTypeIdx[ cIdx ][ idxCand ] specifies the offset type (0 Not applied, Band offset or Edge Offset) for the candidate set idxCand for the colour component cIdx. As an example, a value 0 indicates that the SAO filtering is not applied, a value 1 indicates that the SAO filtering is applied with Band offset and a value 2 indicates that the SAO filtering is applied with Edge Offset.
  • SaoTypeIdx[ cIdx ][ idxCand ] is derived from sao_type_idx_luma and sao_type_idx_chroma syntax elements.
  • sao_offset_abs [ cIdx ][ idxCand ][ i ] specifies the offset value of i-th category for the candidate set idxCand for the colour component cIdx.
  • sao_offset_sign [ cIdx ][ idxCand][ i ] specifies the sign of the offset value of i-th category for the candidate set idxCand for the colour component cIdx.
  • sao_band_position [ cIdx ][ idxCand] specifies the value of the first band offset of the sample range when SaoTypeIdx[ cIdx ][ idxCand] is equal to band offset.
  • sao_eo_class_luma specifies the edge offset class for the luma component.
  • sao_eo_class_chroma specifies the edge offset class for the chroma components.
  • the transmitter encodes, in the bitstream, the current block and the index (merge_idx) determined at step S130.
  • Encoding here refers to entropy coding. Consequently, the current block, more precisely the transform coefficients obtained at step S120 with the coding parameters (e.g. coding modes, possibly motion vectors, etc), is entropy coded in the bitstream, e.g. using for example Context-adaptive binary arithmetic coding (CABAC) or Context-adaptive variable-length coding (CAVLC).
  • CABAC Context-adaptive binary arithmetic coding
  • CAVLC Context-adaptive variable-length coding
  • the encoding of the index merge_idx for a block of coordinate (rx, ry) is illustrated by Table 5 in the case where the OFF candidate set is present in the list of candidate sets or by Table 6 in the case where the OFF candidate set is not present the list of candidate sets.
  • idx_max is determined in the same way as in the decoder side.
  • idx_max represents the largest possible value of index for a given block.
  • an index is encoded for each block (merge_idx). This index identifies one of the candidate sets of filter parameters.
  • all the blocks are in merge mode, i.e. all blocks inherit their filter parameters from one of the candidate sets of filter parameters. This makes it possible to save some bits since there is no more need to encode for a block a flag indicating whether the block is in merge mode or not, i.e. whether or not it inherits its filter parameters from neighbors or not.
  • the method may loop step S160 over all blocks of the picture part in order to encode all blocks of the picture part with their corresponding indices.
  • the method ends at step S180.
  • the present principles may be applied to SAO filter but are not restricted to this type of filters and may be applied to other filter for which a set of at least one filter parameter has to be defined at the block level.
  • a single index is encoded that identifies a candidate set of luma and chroma filter parameters in a single list of candidate sets of filter parameters.
  • a candidate set of filter parameters contains the parameters (e.g. sao_offset_abs [ 0 ][ idxCand ][ i ]) relating to the luma component and the parameters (e.g. sao_offset_abs [ 1 ][ idxCand ][ i ]) relating to the chroma component.
  • a variant of the method of Figure 6A is depicted on Figure 6B . In this variant, luma and chroma components are handled separately.
  • This mode of operation is called dual mode.
  • a first index and a second index are encoded.
  • the first index identifies a candidate set of luma filter parameters in a first list of candidate sets of filter luma parameters and the second index identifies a candidate set of chroma filter parameters in a second list of candidate sets of filter chroma parameters.
  • the steps of Figure 6B identical to the steps of figure 6A are identified by the same numerical references.
  • a transmitter 1000 e.g. such as the encoder 100, accesses a current block of a picture part.
  • the transmitter determines a reconstructed version of the accessed block, i.e. a reconstructed luma block and reconstructed chroma block(s).
  • the transmitter obtains a first plurality of candidate sets of filter luma parameters and further determines a first index (merge_idx_luma) for each block of the picture part.
  • the first index identifies one candidate set among the first plurality of candidate sets.
  • the transmitter obtains a second plurality of candidate sets of filter chroma parameters and further determines a second index (merge_idx_chroma) for each block of the picture part.
  • the second index identifies one candidate set among the second plurality of candidate sets.
  • the transmitter filters the reconstructed luma block with the candidate set of filter luma parameters identified by the first index.
  • the transmitter filters the reconstructed chroma block(s) with the candidate set of filter chroma parameters identified by the second index.
  • the method may loop step S142 and S144 over all blocks of the picture part in order to filter all these blocks.
  • the variants disclosed for S140 apply to steps S142 and S144.
  • the transmitter encodes the first plurality of candidate sets of filter luma parameters and the second plurality of candidate sets of filter chroma parameters in the bitstream.
  • the variants disclosed for S150 apply to step S155.
  • the transmitter encodes, in the bitstream, the current block (more precisely the luma and chroma components) and the first and second indices (merge_idx_luma and merge_idx_chroma) determined at step S132 and S134.
  • the re-ordering of the lists of candidate sets may be done separately for luma and chroma components. In a variant, the re-ordering is common. For example, re-ordering is done first with the list of candidate sets relating to the luma component and the list of candidate sets relating to the chroma component(s) is re-ordered in the same way.
  • a flag is encoded indicating whether dual mode is enabled or not for the current sequence (e.g. it is encoded in the SPS, English acronym of Sequence Parameter Set), for the current picture (e.g. it is encoded in the PPS, English acronym of Picture Parameter Set) or for the current slice (e.g. it is encoded in a slice header or encoded in the first block of the slice).
  • An example of such flag is the slice_dual_merge mentioned in Table 9.
  • no flag is encoded indicating whether dual mode is enabled or not for the current sequence, the current picture, the current slice and dual mode is enabled by default for all slices.
  • step S1600 in the case where dual mode is indicated as enabled for the current sequence, the current picture or the current slice, another flag (dual_mode_block_enabled in Table 9) is encoded at step S1600 indicating whether dual mode is enabled for the current block (e.g. it is encoded before the indices).
  • merge_idx_1 and merge_idx_2 are encoded at step S1610 for the current block. Otherwise, i.e. dual_mode_block_enabled is false or equal 0, a single index is encoded at step S1620 for the current block that identifies one candidate set in the first plurality of candidate sets and one candidate set in the second plurality of candidate sets.
  • the encoding method sets dual_mode_block_enabled to false. If the indices are different, the encoding method sets dual_mode_block_enabled to true. In this latter case, a value is never used for merge_idx_chroma, i.e. the value ofmerge_idx_luma. This information may be used to save 1 bit. In this case, we may encode a same value for both indices but this same value would be interpreted on the decoder side as two different values, one for merge_idx_luma and one for merge_idx_chroma.
  • merge_idx_chroma is set equal to the decoded value incremented by one. Consequently, if the decoded value corresponding to merge_idx_chroma is superior or equal to merge_idx_luma, then merge_idx_chroma is set equal to the decoded value incremented by one (as depicted in Table 9).
  • slice_dual_merge indicates if dual mode is enabled in the current slice.
  • merge_idx_1 corresponds to the first index position in the list of candidate sets once re-ordered for this block. If not present, sao_merge_idx_1 is inferred to be (-1).
  • dual_mode_block_enabled indicates if dual merge is enabled for the block, i.e. if syntax element merge_idx_2 is present. If not present (dual mode is indicated as disabled for the current sequence, the current picture or the current slice), dual_mode_block_enabled is inferred to be equal to 0.
  • merge_idx_2 corresponds to the second index position in the list of candidate sets once re-ordered for this block. If not present, sao_merge_idx_2 is inferred to be equal to sao_merge_idx_1.
  • slice_sao_luma_flag is equal to 1
  • merge_idx_luma is the index identifying in the list of candidates sets of filter luma parameters to be used for filtering the reconstructed luma block.
  • slice_sao_chroma_flag is the index identifying in the list of candidate sets of filter chroma parameters the filter chroma parameters to be used for filtering the reconstructed chroma block(s).
  • Figure 9 represents a flowchart of a method for obtaining a plurality of candidate sets of filter parameters and for determining an index for each block of the picture part identifying one candidate set to be used for filtering the block according to a specific and non-limiting embodiment.
  • the list of candidate sets of filter parameters is either empty or comprises the OFF candidate only.
  • the transmitter determines filter parameters for each block of the picture part using RDO.
  • each block of the picture part has the choice of selecting a candidate set of filter parameters already in the current list of candidate sets (merge mode with encoding of an index merge_idx) or of defining a new candidate set of filter parameters (new mode with encoding of a new set of filter parameters) to be added to the current list of candidate sets.
  • new mode i.e. a new candidate set is defined
  • the RD-cost is based on a distortion reduction of the current block and on the coding rate of the filter parameters.
  • the RD-cost is based on the distortion reduction of the current block and on the coding rate of the index merge_idx.
  • a list of candidate sets of filter parameters is obtained referred to as the best list of candidate sets.
  • the blocks in the picture part may be scanned according to different scanning orders in order to determine a current list of candidate sets of filter parameters.
  • Figure 10 is a pictorial example illustrating different scanning of blocks of a picture part.
  • a RD-cost is calculated on the picture part for a current scanning order and is compared at step S1302 with the best RD-cost obtained so far. If the RD-cost for the current scanning order is lower than the best RD-cost obtained so far, the current candidate sets is stored at step S1304 as the best list of candidate sets, otherwise the best list of candidate sets remains unchanged and the method continues until all scanning orders are tested.
  • a list of candidate sets of filter parameters named best list of candidate sets, corresponding to the best RD-cost trade-off is thus obtained for a given scanning order.
  • the best list of candidate sets is re-ordered in raster scan order in the case where the best list of candidate set was obtained for a scanning order that is different from the raster scan order.
  • all blocks of the picture part are in mode new, i.e. the mode merge is disabled but only during the determination of the plurality of candidate sets, i.e. only during step S1300.
  • a new candidate set of filter parameters is determined for each block of the picture part.
  • an index is determined for each block of the picture part by selecting an index offering a best RD-cost for this block in merge mode using the best list of candidate sets obtained at previous step. This index refers to one of the candidate sets of the best list of candidate sets.
  • all blocks of the picture part are in merge mode.
  • the indices obtained are stored and a RD-cost is computed on the picture part with the indices determined at step S1306.
  • the value of best RD-cost is set to this computed RD-cost value. In this step, the best list of candidate sets remains unchanged.
  • the filter parameters of the candidate sets are refined (e.g. SAO type and offsets in case of SAO filtering) by RDO.
  • the filter parameters of a candidate set are refined based on a distortion reduction computed on all the blocks of the picture part using this candidate set for filtering.
  • the region of the picture part using this candidate set comprise all the samples of the blocks that use this candidate set, i.e. whose merge_idx refers to this candidate set.
  • step S1306 After refinement of the candidate sets, new indices are determined for the blocks of the picture part by RDO using the refined candidate sets. This step is identical to step S1306.
  • a RD-cost may be computed on the picture part with the refined candidate sets determined at step S1308 and possibly with the new indices. This RD-cost value is compared with the best RD-cost obtained so far. If the current RD-cost is lower than the best RD-cost obtained so far, the refined candidate sets and the new indices are stored for being used in the next steps, otherwise the best list of candidate sets remains unchanged and the indices obtained before step S1308 are kept as input for the next step.
  • two candidate sets of filter parameters C1 and C2 corresponding to regions R1 and R2 may be merged into a single candidate set if the sum of the corresponding RD-costs computed on each region (RDcost1+RDcost2) is larger than the RD-cost obtained when using a single candidate set whose filter parameters are determined on the region R composed of the union of R1 and R2.
  • the region R1 comprises all the samples of the blocks in the picture part that use C1, i.e. whose merge_idx refers to C1
  • R2 comprises all the samples of the blocks in the picture part that use C2, i.e. whose merge_idx refers to C2.
  • the filter parameters of the single candidate set are determined based on a distortion reduction computed on all the blocks of both region R.
  • the indices of the blocks are updated.
  • all pair of candidate sets may be tested for merging.
  • the pair of candidate sets offering the largest RD-cost reduction is merged and the method may return to step S 1308 for refining the filter parameters of the candidate sets.
  • a RD-cost is calculated on the picture part and is compared at step S1312 with the best RD-cost obtained so far.
  • the current candidate sets with the merged candidate sets and the updated indices are stored at step S1314 otherwise the best list of candidate sets and the indices remains unchanged and the method may continue with a new pair of candidate sets or may continue to step S1316.
  • step S1316 we test the removal of one candidate set from the current list of candidate sets and we evaluate if RD-cost decreases or not.
  • the indices of the blocks are updated.
  • the method may then go back to step S1308, in order to refine the filter parameters.
  • a RD-cost is calculated on the picture part and is compared at step S1318 with the best RD-cost obtained so far. If RD-cost is higher than the best RD-cost obtained so far, the candidate set is not removed from the current list of candidate sets. In this case, the best list of candidate set and the indices remain unchanged. Otherwise, the current list of candidate sets obtained after removal of one candidate set and the updated indices are stored at step S1320. This may be done for all the candidate sets except the OFF candidate when it is inferred.
  • step S1322 one decides to validate or not the filtering for the picture part based the RD-cost values obtained for each component individually.
  • the RD-cost was computed considering all components, namely luma and chroma components.
  • the RD-cost is computed individually for each component. If filtering the blocks of the picture part with filter parameters determined previously provides a decrease of the RD-cost for one component compared to not filtering the blocks, then the filtering is validated for the picture part and for this component. Otherwise, the filtering is not validated for this component. This decision is made per component (e.g. independently for luma and chroma). In the specific case of SAO filtering, the flags slice_sao_luma_flag/slice_sao_chroma_flag are enforced to true in the case where filtering is validated.
  • the list of candidates is re-ordered in the order of use.
  • the steps S1306 to S1316 may be repeated iteratively until a stop condition is met.
  • the stop conditions may be (but not limited to) that:
  • the order of the steps may be arranged different. For example, one can perform S1316 before S1310, and/or S1308 before S1306. Some of the steps may be optional, such as S1310, and S1316.
  • steps S1300, S1308, S1310 and S1316filter parameters are determined for one block or for one region composed of several blocks.
  • the filter parameters may be determined as disclosed in the document from Fu et al entitled Sample Adaptive Offset for HEVC published in MMSP in 2011 .
  • the SAO parameters are the values of type -t , the category- c and the offsets a i,t,c for the 3 components and R i,t,c is the (estimated) number of bits used for coding these data.
  • the region -i is composed of the blocks that use this candidate set for filtering.
  • R i,t,c is the (estimated) number of bits used for coding the index merge-idx.
  • the region- i is the block.
  • the distortion reduction is the sum of the distortion reductions of all the candidates and the rate is the sum of the candidate rates (coding of SAO parameters types and offsets) and the block rates (coding of merge indices).
  • Figure 11 represents an exemplary architecture of a receiver 2000 configured to decode a picture from a bitstream to obtain a decoded picture according to a specific and non-limiting embodiment.
  • the receiver 2000 comprises one or more processor(s) 2005, which could comprise, for example, a CPU, a GPU and/or a DSP (English acronym of Digital Signal Processor), along with internal memory 2030 (e.g. RAM, ROM and/or EPROM).
  • the receiver 2000 comprises one or more communication interface(s) 2010 (e.g. a keyboard, a mouse, a touchpad, a webcam), each adapted to display output information and/or allow a user to enter commands and/or data (e.g. the decoded picture); and a power source 2020 which may be external to the receiver 2000.
  • the receiver 2000 may also comprise one or more network interface(s) (not shown).
  • the decoder module 2040 represents the module that may be included in a device to perform the decoding functions. Additionally, the decoder module 2040 may be implemented as a separate element of the receiver 2000 or may be incorporated within processor(s) 2005 as a combination of hardware and software as known to those skilled in the art.
  • the bitstream may be obtained from a source.
  • the source can be, but is not limited to:
  • the decoded picture may be sent to a destination, e.g. a display device.
  • the decoded picture is stored in a remote or in a local memory, e.g. a video memory or a RAM, a hard disk.
  • the decoded picture is sent to a storage interface, e.g. an interface with a mass storage, a ROM, a flash memory, an optical disc or a magnetic support and/or transmitted over a communication interface, e.g. an interface to a point to point link, a communication bus, a point to multipoint link or a broadcast network.
  • the receiver 2000 further comprises a computer program stored in the memory 2030.
  • the computer program comprises instructions which, when executed by the receiver 2000, in particular by the processor 2005, enable the receiver to execute the decoding method described with reference to Figure 13A to 13C .
  • the computer program is stored externally to the receiver 2000 on a non-transitory digital data support, e.g. on an external storage medium such as a HDD, CD-ROM, DVD, a read-only and/or DVD drive and/or a DVD Read/Write drive, all known in the art.
  • the receiver 2000 thus comprises a mechanism to read the computer program. Further, the receiver 2000 could access one or more Universal Serial Bus (USB)-type storage devices (e.g., "memory sticks.”) through corresponding USB ports (not shown).
  • USB Universal Serial Bus
  • the receiver 2000 can be, but is not limited to:
  • Figure 12 illustrates a block diagram of an exemplary video decoder 200, e.g. an HEVC video decoder, adapted to execute the decoding method of Figure 13A or 13B .
  • the video decoder 200 is an example of a receiver 2000 or part of such a receiver 2000.
  • a bitstream is decoded by the decoder elements as described below.
  • Video decoder 200 generally performs a decoding pass reciprocal to the encoding pass as described in Figure 2 , which performs video decoding as part of encoding video data.
  • the input of the decoder includes a video bitstream, which may be generated by the video encoder 100.
  • the bitstream is first entropy decoded (230) to obtain transform coefficients, motion vectors, and other coded information.
  • the transform coefficients are de-quantized (240) and inverse transformed (250) to decode residuals.
  • the decoded residuals are then combined (255) with a predicted sample block (also known as a predictor) to obtain a decoded/reconstructed picture block.
  • the predicted sample block may be obtained (270) from intra prediction (260) or motion-compensated prediction (i.e., inter prediction) (275).
  • AMVP and merge mode techniques may be used during motion compensation, which may use interpolation filters to calculate interpolated values for sub-integer samples of a reference block.
  • An in-loop filter (265) is applied to the reconstructed picture.
  • the in-loop filter may comprise a deblocking filter and a SAO filter.
  • the filtered picture is stored at a reference picture buffer (280).
  • Figure 13A represents a flowchart of a method for decoding blocks of a picture part from a bitstream according to a specific and non-limiting embodiment.
  • the picture part may be the whole picture or a sub-part of it, e.g. a slice.
  • the method starts at step S200.
  • a receiver 2000 such as the decoder 200 accesses a bitstream.
  • the receiver decodes a plurality of candidate sets of filter parameters from the bitstream.
  • the plurality of candidate sets are thus ordered according to the order in which they are decoded.
  • three candidate sets of filter parameters are decoded (c-0, c-1 and c-2).
  • Each block of the picture part on the right side of Figure 7 inherits its filter parameters from one of the three candidate sets.
  • blocks Blk_0, Blk_1, Blk_4 and Blk_5 have the same filter parameters, i.e.
  • the blocks Blk_2 and Blk_3 have the same filter parameters, i.e. the filter parameters of the candidate set c-1 and the blocks Blk_6 and Blk_7 have the same filter parameters, i.e. the filter parameters of the candidate set c-2.
  • a specific candidate set of filter parameters known as the OFF candidate set is added to the list of decoded candidate sets.
  • the OFF candidate is inserted between the decoded candidate sets at a predefined position, e.g. the second position.
  • the OFF candidate is not decoded from the bitstream. It is used to indicate that a block is not filtered.
  • the plurality of candidate sets of filter parameters are decoded from a header of a slice.
  • the plurality of candidate sets of filter parameters are decoded at the level of the first block (e.g. Blk_0 on Figure 7 ) of the picture part in the decoding order.
  • the three candidate sets of filter parameters are encoded with the syntax elements of the first block, Blk_0.
  • the receiver decodes from said bitstream a data representative of a number of candidate sets of filter parameters.
  • the decoded data num_sao_cand_minus1 is the number of candidate sets of filter parameters to be decoded minus 1. Since the value of num_sao_cand_minus1 is necessarily inferior to the number of blocks in one picture part, e.g. in one slice, minus one, the number of bits representing the syntax element num_sao_cand_minus1 is inferior to log2(number of blocks in one picture part minus one).
  • Table 1 An example of syntax of the HEVC type for SAO filtering is provided by tables 1 and 2.
  • Table 2 once num_sao_cand_minus1 is decoded, each candidate set of SAO parameters is decoded by calling sao_cand(idxCand).
  • Table 3 illustrates the decoding of a set of SAO parameters according to the present principles.
  • SAO parameters are decoded: slice_sao_luma_flag, slice_sao chroma flag, sao_type_idx_luma, sao_type_idx_chroma, sao_offset_abs [ cIdx ][ idxCand ][ i ], sao_offset_sign [ cIdx ][ idxCand] [ i ], sao_band_position [ cIdx ][ idxCand], sao_eo_class_luma,sao_eo_class_chroma.
  • the receiver decodes for a current block of said picture an index (merge_idx) identifying one of the decoded candidate sets of filter parameters from said bitstream.
  • index merge_idx for a block of coordinate (rx, ry) is illustrated by Table 5 in the case where the OFF candidate set is added to the list of decoded candidate sets or by Table 6 in the case where the OFF candidate set is not added to the list of decoded candidate sets.
  • an index is decoded for each block (merge_idx). This index identifies one of the candidate sets of filter parameters.
  • all the blocks are in merge mode, i.e. all blocks inherit their filter parameters from one of the candidate sets of filter parameters. This makes it possible to save some bits since there is no more need to decode for a block a flag indicating whether the block is in merge mode or not, i.e. whether or not it inherits its filter parameters from neighbors or not.
  • the plurality of candidate sets of filter parameters are decoded from the bitstream in the same order as their order of first use.
  • the largest possible value of index (idx_max) for a given block increases with the block number. More precisely, idx_max is incremented only if the merge index corresponds to a candidate set not yet used by any block previously decoded.
  • the index for blk_0 is equal to 0, i.e.
  • blk_0 uses the filter parameters defined in c_0, if the index for blk_1 is also equal to 0, then idx_max is not incremented for blk_2, while if the index for blk_1 is equal to 1, i.e. blk_1 uses the filter parameters defined in c_1 which is a candidate set not yet used, then idx_max is incremented for blk_2.
  • merge_idx corresponds to a candidate not yet used by previously decoded blocks
  • the value of idx_max is incremented only if the parsed value of merge_idx is non-zero because the first candidate in the list is necessarily a candidate already used (except for the first block).
  • Truncated Rice (TR) binarization as specified in 9.3.3.2 of HEVC standard, the value of cMax is idx_max.
  • the value idx_max is another increasing function of the number of candidate sets of filter parameters used for filtering blocks decoded prior to the current block.
  • the receiver decodes said current block from said bitstream.
  • the decoded block usually comprises a luma block and chroma blocks.
  • Decoding a block usually but not necessarily comprises entropy decoding a portion of the bitstream representative of the block to obtain a block of transform coefficients, de-quantizing and inverse transforming the block of transform coefficients to obtain a block of residuals and adding a predictor to the block of residuals to obtain a decoded block.
  • the order of S230 and S240 may be permuted.
  • the candidate sets of filter parameters are re-ordered before the index decoded at step S230 is used to retrieve the set of filter parameters from the list of candidate sets.
  • the candidate sets of filter parameters are re-ordered each time a block of the picture part is decoded. The re-ordering is achieved before the block is filtered.
  • the candidate sets of filter parameters are re-ordered such that the set of filter parameters used for a block located immediately to the left of the current block when such a block is available is put at the first position in the list of candidate sets of filtering parameters.
  • the candidate sets of filter parameters are re-ordered such that the candidate sets of filter parameters that have been used for filtering blocks decoded prior to the current block, referred to as prior blocks, are listed in an order which depends on a spatial distance of this prior block to the current block.
  • the candidate sets of filter parameters are re-ordered such that the parameters which were already used by the spatially closest neighboring blocks appear on top of the list of candidate sets of filter parameters. In the case where several blocks use the same candidate sets, only the block that is spatially the closest to the current block is taken into account. This can be done by building a map of used candidate sets. An example of dynamically re-ordering the list of candidate sets of filtering parameters is shown in Table 10 in relation to Figure 14 .
  • the candidate sets are re-ordered each time a current block is decoded.
  • the next not yet used candidate is put at the end of the list.
  • the process of list re-ordering is illustrated with Figure 15 for decoding a current block Blk_5.
  • the last used candidate sets are ⁇ c_0,c_1,c_2, c_3 ⁇ .
  • c_0 was used by Blk_0 and Blk_4
  • c_1 was used by Blk_1
  • c_2 was used by Blk_2
  • c_3 was used by Blk_3.
  • the smaller square Euclidian distance of Blk_5 to the blocks Blk_4, Blk_1, Blk_2, Blk_3 are ⁇ 1,1,2,5 ⁇ respectively.
  • the spatial distance of Blk_4 to Blk_5 is taken into account and not the distance of Blk_0 to Blk_5 because Blk_4 is spatially closer to Blk_5 than Blk_0.
  • the closest used candidate sets are thus c_0 (left), c_1 (top), c_2 (top-right) and c_3 (top-right-right).
  • the candidate c_4 has not been used yet and thus is put at the end of the list.
  • At least one candidate set of filter parameters not used for filtering blocks decoded prior to the current block is inserted at a position pos_first_new that is before the position of the last candidate set of filter parameters used for filtering said blocks decoded prior to the current block.
  • the value of pos_first_new is known a-priori at the decoder side.
  • pos_first_new may be set to 2 or may be encoded in the bitstream. This variant is illustrated by Table 11. In this example, the candidate not yet used that is to be used next is put at position 2 (highlighted in italics in Table 11).
  • candidate c_4 is put at position 2 in the list while in Table 10 it was put at the end of the list.
  • the position of the first candidate set not used for filtering prior decoded blocks may be inserted before pos_first_new.
  • Prior decoded blocks are blocks decoded prior the current block.
  • Tables 10 and 11 illustrate the case where the OFF candidate set is not added to the list of decoded candidate sets.
  • the merge_idx is not inferred for the first block but is decoded.
  • the value of idx_max is incremented by 1 in the tables 10 and 11.
  • pos_first_new is function of the number of blocks remaining to decode after the current block in the picture part and of the number of candidate sets not yet used for filtering prior decoded blocks.
  • the position pos_first_new is derived from the probability of occurrence of using a new candidate set.
  • a specific candidate set of filter parameters known as the OFF candidate is added to the list of candidate sets but is not decoded. In the case where an index for a block identifies this specific candidate, the corresponding block is not filtered.
  • the position pos_off of the OFF candidate in the list is not modified in case where the list is re-ordered.
  • its position is not fixed, i.e. it follows the same re-ordering rules as the other candidate sets with a restriction. The restriction is that the position of the OFF candidate in the list cannot be beyond a fixed position, e.g. the position 2.
  • the receiver filters the decoded current block with the candidate set of filter parameters identified by the decoded index.
  • the index merge_idx identifies the OFF candidate
  • the block is not filtered at step S260.
  • the filter is a SAO filter and the filtering steps disclosed with reference to figure 3 apply.
  • the method may loop over steps S230 to S260 in order to decode and filter all blocks in the picture part.
  • all the blocks of the picture part may be decoded before beginning to filter these blocks.
  • the filtering of some blocks of the picture part may begin before all the blocks of the picture part are decoded.
  • the method ends at step S280.
  • the encoding and decoding method and apparatus according to the present principles are not limited to SAO filtering.
  • the method may be applied to any filter defined by filter parameters that may be applied locally, e.g. at block level.
  • a single index is decoded that identifies a candidate set of luma and chroma filter parameters in a single list of candidate sets of filter parameters.
  • a variant of the method of Figure 13A is depicted on Figure 13B .
  • luma and chroma components are handled separately. This mode of operation is called dual mode.
  • dual mode a first index and a second index are decoded. The first index identifies a candidate set of luma filter parameters in a first list of candidate sets of filter luma parameters and a second index identifies a candidate set of chroma filter parameters in a second list of candidate sets of filter chroma parameters.
  • the method starts at step S200.
  • a receiver 2000 such as the decoder 200 accesses a bitstream.
  • the receiver decodes a first plurality of candidate sets of filter luma parameters from the bitstream.
  • the receiver decodes a second plurality of candidate sets of filter chroma parameters from the bitstream.
  • the receiver decodes for a current block of said picture a first index (merge_luma_idx) identifying one of the decoded candidate sets of filter luma parameters from said bitstream.
  • the receiver decodes for the current block a second index (merge_chroma_idx) identifying one of the decoded candidate sets of filter chroma parameters from said bitstream.
  • the receiver decodes said current block from said bitstream.
  • the candidate sets of filter luma parameters are re-ordered before using the first index for identifying a set of filter luma parameters from the list of candidate sets.
  • the candidate sets of filter chroma parameters are re-ordered before the second index is used for identifying a set of filter chroma parameters from the list of candidate sets.
  • the re-ordering of the lists of candidate sets may be done separately for luma and chroma components.
  • the re-ordering is common. For example, re-ordering is done first with the list of candidate sets relating to the luma component and the list of candidate sets relating to the chroma component(s) is re-ordered in the same way.
  • the receiver filters the decoded current block with the candidate set of filter luma parameters and with the candidate set of filter chroma parameters identified by the decoded first and second indices respectively. More precisely, the decoded luma block is filtered with the candidate set of filter luma parameters identified by the first index and the decoded chroma block(s) are filtered with the candidate set of filter chroma parameters identified by the second index.
  • a flag is decoded indicating whether dual mode is enabled or not for the current sequence (e.g. it is decoded from the SPS, English acronym of Sequence Parameter Set), for the current picture (e.g. it is decoded from the PPS, English acronym of Picture Parameter Set) or for the current slice (e.g. it is decoded from a slice header or encoded in the first block of the slice).
  • An example of such flag is the slice_dual_merge mentioned in Table 9.
  • no flag is decoded indicating whether dual mode is enabled or not for the current sequence, the current picture, the current slice and dual mode is enabled by default for all slices.
  • step S231 in the case where dual mode is enabled for the current sequence, the current picture or the current slice, another flag (dual_mode_block_enabled in Table 9) is decoded at step S231 indicating whether dual mode is enabled for the current block (e.g. it is decoded before the indices).
  • dual_mode_block_enabled In the case where dual mode is enabled for the current block (dual_mode_block_enabled is true or equal 1), then two indices (one for luma and one for chroma) are decoded at steps S232 and S234 for the current block. Otherwise, i.e. dual_mode_block_enabled is false or equal 0, a single index is decoded at step S235 for the current block that identifies one candidate set in the first plurality of candidate sets and one candidate set in the second plurality of candidate sets.
  • merge_idx_chroma is set equal to the decoded value incremented by one (see NOTE-1 in Table 9).
  • the method may loop over steps S232 to S265 in order to decode and filter all blocks in the picture part.
  • the method ends at step S280.
  • the filter block size e.g. the SAO block size
  • the filter parameters are applied on a region of the reconstructed picture that is different from the CTU size.
  • the picture or slice is sub-divided into multiple regions, each corresponding to a filter block.
  • the filter parameters are determined for each filter block and are constant on this filter block.
  • the filter block size is the size of the smallest region for which the filter parameters cannot change.
  • the SAO block size is the size of this region. In H.265, the SAO block size is equal to the size of one CTB.
  • the filter block size can be specified in the slice header, in the picture parameter set or in the sequence parameter set with an index indicating the filter block size and shape to use with current slice.
  • Examples of square or rectangular filter block sizes are depicted in figure 16 .
  • the horizontal and vertical filter block sizes are derived from CTU size with right (division by power of 2) or left (multiplication by power of 2) shifts.
  • the filter blocks are represented in grey.
  • a flag is encoded (decoded respectively), e.g. in the slice header, to indicate whether the filter block size is equal to the CTU size or if it is smaller (e.g. reduced by two both horizontally and vertically).
  • the derivation of the spatial distance may take into account the vertical and horizontal filter block sizes which are different.
  • the spatial distance is proportional to the distance expressed in number of samples.
  • the derivation of the spatial distance does not consider the actual vertical and horizontal filter block sizes but the horizontal and vertical filter block position only.
  • the spatial distance is proportional to the distance expressed in filter block map as depicted in Figure 17 .
  • the filter block map is built with the values of the index identifying each of the candidate sets of filter parameters, for each filter region (or SAO filter region).
  • the filter block map X (or Y axis) coordinate corresponds to the number of the filter region in the horizontal (or vertical respectively) direction, independently to the SAO filter region size/shape.
  • the implementations described herein may be implemented in, for example, a method or a process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method or a device), the implementation of features discussed may also be implemented in other forms (for example a program).
  • An apparatus may be implemented in, for example, appropriate hardware, software, and firmware.
  • the methods may be implemented in, for example, an apparatus such as, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, such as, for example, computers, cell phones, portable/personal digital assistants ("PDAs”), and other devices that facilitate communication of information between end-users.
  • PDAs portable/personal digital assistants
  • Implementations of the various processes and features described herein may be embodied in a variety of different equipment or applications, particularly, for example, equipment or applications.
  • equipment examples include an encoder, a decoder, a post-processor processing output from a decoder, a pre-processor providing input to an encoder, a video coder, a video decoder, a video codec, a web server, a set-top box, a laptop, a personal computer, a cell phone, a PDA, and other communication devices.
  • the equipment may be mobile and even installed in a mobile vehicle.
  • the methods may be implemented by instructions being performed by a processor, and such instructions (and/or data values produced by an implementation) may be stored on a processor-readable medium such as, for example, an integrated circuit, a software carrier or other storage device such as, for example, a hard disk, a compact diskette (“CD"), an optical disc (such as, for example, a DVD, often referred to as a digital versatile disc or a digital video disc), a random access memory (“RAM”), or a read-only memory (“ROM”).
  • the instructions may form an application program tangibly embodied on a processor-readable medium. Instructions may be, for example, in hardware, firmware, software, or a combination.
  • a processor may be characterized, therefore, as, for example, both a device configured to carry out a process and a device that includes a processor-readable medium (such as a storage device) having instructions for carrying out a process. Further, a processor-readable medium may store, in addition to or in lieu of instructions, data values produced by an implementation.
  • implementations may produce a variety of signals formatted to carry information that may be, for example, stored or transmitted.
  • the information may include, for example, instructions for performing a method, or data produced by one of the described implementations.
  • a signal may be formatted to carry as data the rules for writing or reading the syntax of a described embodiment, or to carry as data the actual syntax-values written by a described embodiment.
  • Such a signal may be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal.
  • the formatting may include, for example, encoding a data stream and modulating a carrier with the encoded data stream.
  • the information that the signal carries may be, for example, analog or digital information.
  • the signal may be transmitted over a variety of different wired or wireless links, as is known.
  • the signal may be stored on a processor-readable medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Claims (28)

  1. Procédé comprenant :
    - le décodage d'une première partie de données vidéo consistant en un ensemble d'informations, l'ensemble d'informations consistant en des informations représentatives d'une pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon, un ensemble de paramètres de décalage adaptatif d'échantillon comprenant au moins une information représentative d'un décalage à ajouter à une valeur d'échantillon d'un bloc courant ;
    - le décodage à partir des données vidéo, pour le bloc courant, d'un premier élément de syntaxe représentant un indice utilisé pour identifier l'un des ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon de la pluralité parmi lesdites données vidéo ;
    - le décodage du bloc courant à partir desdites données vidéo d'une deuxième partie des données vidéo différente de la première partie ; et
    - le filtrage du bloc courant décodé à l'aide de l'ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon identifié par ledit indice décodé ;
    dans lequel ladite première partie est signalée par des éléments de syntaxe au niveau d'un bloc d'un groupe de blocs comprenant le bloc courant décodé en premier dans l'ordre de décodage.
  2. Procédé selon la revendication 1, comprenant le décodage d'au moins un deuxième élément de syntaxe à partir de l'ensemble d'informations représentatif d'un nombre d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon.
  3. Procédé selon l'une quelconque des revendications 1 à 2, dans lequel les ensembles candidats de la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont décodés à partir de l'ensemble d'informations dans leur ordre d'utilisation.
  4. Procédé selon l'une quelconque des revendications 1 à 3, comprenant en outre la réorganisation des ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon avant le filtrage du bloc courant.
  5. Procédé selon la revendication 4, dans lequel les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont réorganisés de sorte que l'ensemble de paramètres de filtre à décalage adaptatif d'échantillon utilisé pour filtrer un bloc situé immédiatement à gauche du bloc courant, lorsqu'un tel bloc est disponible, soit répertorié en premier.
  6. Procédé selon la revendication 4 ou 5, dans lequel les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont réorganisés de sorte que les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon utilisés pour filtrer les blocs décodés avant le bloc courant soient répertoriés selon un ordre qui dépend d'une distance spatiale entre ledit bloc décodé avant le bloc courant et le bloc courant.
  7. Procédé selon l'une quelconque des revendications 4 à 6, dans lequel les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont réorganisés de sorte qu'au moins un ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon non utilisé pour filtrer les blocs décodés avant le bloc courant soit inséré avant un dernier ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon utilisé pour filtrer lesdits blocs décodés avant le bloc courant.
  8. Procédé selon l'une quelconque des revendications 4 à 6, dans lequel les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont réorganisés de sorte qu'un ensemble candidat de paramètres de filtre non utilisé par les blocs décodés avant le bloc courant et qui est le premier candidat qui sera utilisé ensuite soit inséré à une position qui dépend du nombre de blocs à décoder après ledit bloc courant et du nombre d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon non encore utilisés par les blocs décodés avant le bloc courant.
  9. Procédé selon l'une quelconque des revendications 1 à 8, comprenant en outre l'insertion, dans la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon, d'un ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon spécifiant qu'un bloc n'est pas filtré.
  10. Procédé selon la revendication 9, dans lequel l'ensemble candidat de paramètres de filtre spécifiant qu'un bloc n'est pas filtré est inséré entre les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon à une position prédéfinie.
  11. Procédé comprenant :
    - la détermination d'une version reconstruite d'un bloc courant, appelée bloc reconstruit ;
    - l'obtention d'une pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon et la détermination d'un indice pour le bloc courant utilisé pour identifier l'un des ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon, un ensemble candidats de paramètres de filtre à décalage adaptatif d'échantillon comprenant au moins une information représentative d'un décalage à ajouter à une valeur d'échantillon d'un bloc courant ;
    - le filtrage dudit bloc reconstruit avec l'ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon de la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon identifiés par ledit indice ; et
    - la signalisation d'une première partie de données vidéo avec des éléments de syntaxe au niveau d'un bloc d'un groupe de blocs comprenant le bloc courant codé en premier dans l'ordre de codage, ladite première partie des données vidéo consistant en un ensemble d'informations consistant en des informations représentatives de la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon et une deuxième partie des données vidéo comprenant des données représentatives du bloc courant et un premier élément de syntaxe représentatif de l'indice déterminé.
  12. Procédé selon la revendication 11, comprenant le codage d'un deuxième élément de syntaxe dans ledit ensemble d'informations représentatif d'un nombre d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon dans la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon.
  13. Procédé selon l'une quelconque des revendications 11 ou 12, dans lequel les ensembles candidats de ladite pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont codés dans l'ensemble d'informations dans leur ordre d'utilisation.
  14. Procédé selon l'une quelconque des revendications 11 à 13, comprenant en outre la réorganisation des ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon avant le codage dudit bloc courant.
  15. Décodeur comprenant :
    - un moyen pour décoder une première partie de données vidéo consistant en un ensemble d'informations, l'ensemble d'informations consistant en des informations représentatives d'une pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon, un ensemble de paramètres de décalage adaptatif d'échantillon comprenant au moins une information représentative d'un décalage à ajouter à une valeur d'échantillon d'un bloc courant ;
    - un moyen pour décoder à partir des données vidéo, pour le bloc courant, un premier élément de syntaxe représentant un indice utilisé pour identifier l'un des ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon de la pluralité parmi lesdites données vidéo ;
    - un moyen pour décoder le bloc courant à partir desdites données vidéo d'une deuxième partie des données vidéo différente de la première partie ; et
    - un moyen pour filtrer le bloc courant décodé à l'aide de l'ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon identifié par ledit indice décodé ;
    dans lequel ladite première partie est signalée par des éléments de syntaxe au niveau d'un bloc d'un groupe de blocs comprenant le bloc courant décodé en premier dans l'ordre de décodage.
  16. Décodeur selon la revendication 15, comprenant un moyen pour décoder un deuxième élément de syntaxe à partir de l'ensemble d'informations représentatif d'un nombre d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon dans la pluralité de paramètres de filtre à décalage adaptatif d'échantillon.
  17. Décodeur selon l'une quelconque des revendications 15 à 16, dans lequel les ensembles candidats de ladite pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont décodés à partir de l'ensemble d'informations dans leur ordre d'utilisation.
  18. Décodeur selon l'une quelconque des revendications 15 à 17, comprenant en outre un moyen pour réorganiser les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon avant le filtrage du bloc courant.
  19. Décodeur selon la revendication 18, dans lequel les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont réorganisés de sorte que l'ensemble de paramètres de filtre à décalage adaptatif d'échantillon utilisé pour filtrer un bloc situé immédiatement à gauche du bloc courant, lorsqu'un tel bloc est disponible, soit répertorié en premier.
  20. Décodeur selon la revendication 18 ou 19, dans laquelle les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont réorganisés de sorte que les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon utilisés pour filtrer les blocs décodés avant le bloc courant soient répertoriés selon un ordre qui dépend d'une distance spatiale entre ledit bloc décodé avant le bloc courant et le bloc courant.
  21. Décodeur selon l'une quelconque des revendications 18 à 20, dans lequel les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont réorganisés de sorte qu'au moins un ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon non utilisé pour filtrer les blocs décodés avant le bloc courant soit inséré avant un dernier ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon utilisé pour filtrer lesdits blocs décodés avant le bloc courant.
  22. Décodeur selon l'une quelconque des revendications 18 à 20, dans lequel les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont réorganisés de sorte qu'un ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon non utilisé par les blocs décodés avant le bloc courant et qui est le premier candidat qui sera utilisé ensuite soit inséré à une position qui dépend du nombre de blocs à décoder après ledit bloc courant et du nombre d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon non encore utilisés par les blocs décodés avant le bloc courant.
  23. Décodeur selon l'une quelconque des revendications 15 à 22, comprenant en outre un moyen pour insérer, dans la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon, un ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon spécifiant qu'un bloc n'est pas filtré.
  24. Décodeur selon la revendication 23, dans lequel l'ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon spécifiant qu'un bloc n'est pas filtré est inséré entre les ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon à une position prédéfinie.
  25. Encodeur comprenant :
    - un moyen pour déterminer une version reconstruite d'un bloc courant, appelée bloc reconstruit ;
    - un moyen pour obtenir une pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon et déterminer un indice pour le bloc courant utilisé pour identifier l'un des ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon, un ensemble de paramètres de filtre à décalage adaptatif d'échantillon comprenant au moins une information représentative d'un décalage à ajouter à une valeur d'échantillon d'un bloc courant ;
    - un moyen pour filtrer ledit bloc reconstruit avec l'ensemble candidat de paramètres de filtre à décalage adaptatif d'échantillon de la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon identifiés par ledit indice ; et
    - un moyen pour signaler une première partie de données vidéo avec des éléments de syntaxe au niveau d'un bloc d'un groupe de blocs comprenant le bloc courant codé en premier dans l'ordre de codage, ladite première partie des données vidéo consistant en un ensemble d'informations consistant en des informations représentatives de la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon et une deuxième partie des données vidéo comprenant des données représentatives du bloc courant et un premier élément de syntaxe représentatif de l'indice déterminé.
  26. Encodeur selon la revendication 25, comprenant un moyen pour coder un deuxième élément de syntaxe dans ledit ensemble d'informations représentatif d'un nombre d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon dans la pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon.
  27. Encodeur selon l'une quelconque des revendications 25 à 26, dans lequel les ensembles candidats de ladite pluralité d'ensembles candidats de paramètres de filtre à décalage adaptatif d'échantillon sont codés dans l'ensemble d'informations dans leur ordre d'utilisation.
  28. Encodeur selon l'une quelconque des revendications 25 à 27, comprenant en outre un moyen pour réorganiser les ensembles candidats de paramètres de filtre avant le codage dudit bloc courant.
EP18725502.1A 2017-05-31 2018-05-17 Procédé et dispositif de codage et de décodage d'image Active EP3632113B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP24153925.3A EP4336840A3 (fr) 2017-05-31 2018-05-17 Procédé et dispositif de codage et de décodage d'image

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
EP17305626.8A EP3410723A1 (fr) 2017-05-31 2017-05-31 Procédé et dispositif de codage et de décodage d'image
EP17306011 2017-07-28
EP18305335 2018-03-26
EP18305386 2018-03-30
PCT/EP2018/062876 WO2018219663A1 (fr) 2017-05-31 2018-05-17 Procédé et dispositif destinés au codage et décodage d'image

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP24153925.3A Division EP4336840A3 (fr) 2017-05-31 2018-05-17 Procédé et dispositif de codage et de décodage d'image

Publications (2)

Publication Number Publication Date
EP3632113A1 EP3632113A1 (fr) 2020-04-08
EP3632113B1 true EP3632113B1 (fr) 2024-02-28

Family

ID=62196587

Family Applications (2)

Application Number Title Priority Date Filing Date
EP24153925.3A Pending EP4336840A3 (fr) 2017-05-31 2018-05-17 Procédé et dispositif de codage et de décodage d'image
EP18725502.1A Active EP3632113B1 (fr) 2017-05-31 2018-05-17 Procédé et dispositif de codage et de décodage d'image

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP24153925.3A Pending EP4336840A3 (fr) 2017-05-31 2018-05-17 Procédé et dispositif de codage et de décodage d'image

Country Status (6)

Country Link
US (2) US11811975B2 (fr)
EP (2) EP4336840A3 (fr)
JP (2) JP7179023B2 (fr)
CN (3) CN110870319B (fr)
MX (1) MX2019014443A (fr)
WO (1) WO2018219663A1 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190090731A (ko) * 2018-01-25 2019-08-02 주식회사 윌러스표준기술연구소 비디오 신호 처리 방법 및 장치
US11876957B2 (en) * 2018-12-18 2024-01-16 Lg Electronics Inc. Method and apparatus for processing video data
JP2022525235A (ja) * 2019-03-24 2022-05-11 オッポ広東移動通信有限公司 フィルタリング方法及び装置、コンピュータ記憶媒体
KR20220019243A (ko) * 2019-07-08 2022-02-16 엘지전자 주식회사 인루프 필터링 기반 비디오 또는 영상 코딩
EP3991435A4 (fr) * 2019-08-07 2022-08-31 Huawei Technologies Co., Ltd. Procédé et appareil de filtre en boucle à décalage adaptatif d'échantillon avec contrainte de taille de région d'application
CN114157874A (zh) * 2021-12-03 2022-03-08 北京达佳互联信息技术有限公司 环路滤波方法和环路滤波装置
US20230308658A1 (en) * 2022-03-25 2023-09-28 Tencent America LLC Methods of parameter set indication in video streaming
WO2023192332A1 (fr) * 2022-03-28 2023-10-05 Beijing Dajia Internet Information Technology Co., Ltd. Filtre à boucle non locale pour codage vidéo

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8208564B2 (en) * 2005-06-24 2012-06-26 Ntt Docomo, Inc. Method and apparatus for video encoding and decoding using adaptive interpolation
KR101709358B1 (ko) * 2009-03-12 2017-02-22 톰슨 라이센싱 디-아티팩트 필터링을 위한 영역-기반 필터 파라미터 선택 방법들 및 장치들
US9078008B2 (en) * 2009-04-20 2015-07-07 Dolby Laboratories Licensing Corporation Adaptive inter-layer interpolation filters for multi-layered video delivery
EP2515541A4 (fr) * 2009-12-18 2015-08-26 Sharp Kk Filtre d'image, dispositif de codage, dispositif de décodage, et structure de données
EP2988503A1 (fr) 2010-01-14 2016-02-24 Dolby Laboratories Licensing Corporation Filtres adaptatifs mis en tampon
EP2661879B1 (fr) 2011-01-03 2019-07-10 HFI Innovation Inc. Procédé de filtrage en boucle basé sur des unités de filtre
JP5763210B2 (ja) * 2011-04-21 2015-08-12 メディアテック インコーポレイテッド 改良されたループ型フィルタリング処理のための方法と装置
US20120294353A1 (en) 2011-05-16 2012-11-22 Mediatek Inc. Apparatus and Method of Sample Adaptive Offset for Luma and Chroma Components
PL3280144T3 (pl) 2011-06-14 2021-06-14 Lg Electronics Inc. Sposób kodowania i dekodowania informacji o obrazie
CN107426579B (zh) 2011-06-24 2020-03-10 Lg 电子株式会社 图像信息编码和解码方法
US10070152B2 (en) * 2011-08-24 2018-09-04 Texas Instruments Incorporated Sample adaptive offset (SAO) parameter signaling
WO2013094960A1 (fr) * 2011-12-23 2013-06-27 한국전자통신연구원 Procédé et appareil pour la définition d'un indice d'image de référence d'un candidat à la fusion temporelle
US9380302B2 (en) * 2012-02-27 2016-06-28 Texas Instruments Incorporated Sample adaptive offset (SAO) parameter signaling
KR101638720B1 (ko) 2012-05-29 2016-07-20 미디어텍 인크. 샘플 어댑티브 오프셋 정보를 부호화하는 방법 및 장치
EP3297283B1 (fr) * 2012-06-11 2019-09-04 Samsung Electronics Co., Ltd. Codage et décodage des vidéos partageant des paramètres sao en fonction d'un composant de couleur
JP6094408B2 (ja) * 2013-07-12 2017-03-15 株式会社Ｊｖｃケンウッド 画像符号化装置、画像符号化方法及び画像符号化プログラム
CN105723713A (zh) 2013-12-19 2016-06-29 夏普株式会社 合并候选导出装置、图像解码装置以及图像编码装置
US10057574B2 (en) 2015-02-11 2018-08-21 Qualcomm Incorporated Coding tree unit (CTU) level adaptive loop filter (ALF)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"AHG6: Baseline options for ALF", no. JCTVC-I0157, 27 April 2012 (2012-04-27), XP030233668, Retrieved from the Internet <URL:http://phenix.int-evry.fr/jct/doc_end_user/documents/9_Geneva/wg11/JCTVC-I0157-v3.zip JCTVC-I0157_r1.doc> [retrieved on 20120427] *

Also Published As

Publication number Publication date
US20200296388A1 (en) 2020-09-17
JP7179023B2 (ja) 2022-11-28
JP2020522170A (ja) 2020-07-27
EP3632113A1 (fr) 2020-04-08
CN110870319B (zh) 2022-12-06
CN110870319A (zh) 2020-03-06
MX2019014443A (es) 2020-02-10
US11811975B2 (en) 2023-11-07
CN115714862A (zh) 2023-02-24
EP4336840A2 (fr) 2024-03-13
US20240048731A1 (en) 2024-02-08
WO2018219663A1 (fr) 2018-12-06
JP2023025054A (ja) 2023-02-21
EP4336840A3 (fr) 2024-05-29
CN115767099A (zh) 2023-03-07

Similar Documents

Publication Publication Date Title
EP3632113B1 (fr) Procédé et dispositif de codage et de décodage d&#39;image
CN110999291B (zh) 用于划分视频数据的帧间预测片段中的视频块的系统和方法
US10440396B2 (en) Filter information sharing among color components
EP3383043A1 (fr) Procédés et appareil de codage et de décodage d&#39;image
CN112204967A (zh) 用于划分视频数据的帧间预测片段中的视频块的系统和方法
US11228757B2 (en) Method and a device for picture encoding and decoding
CN117956149A (zh) 自适应环路滤波器
US11032542B2 (en) Method and a device for image encoding and decoding
US20220141465A1 (en) Method and device for processing video signal
US11695962B2 (en) Encoding and decoding methods and corresponding devices
EP3364656A1 (fr) Procédé de codage d&#39;un décalage adaptatif d&#39;échantillon
US20180098065A1 (en) Peak sample adaptive offset
EP3410723A1 (fr) Procédé et dispositif de codage et de décodage d&#39;image
US20240040143A1 (en) Method and apparatus for decoding image using interpicture prediction
US20190191187A1 (en) A method and an apparatus for image block encoding and decoding
EP3410711A1 (fr) Procédé et dispositif de codage et de décodage d&#39;images
EP3349465A1 (fr) Procédé et dispositif de codage d&#39;image avec filtrage de décalage adaptatif d&#39;échantillon en plusieurs passes
EP3349466A1 (fr) Procédé et appareil de codage vidéo avec filtrage de décalage adaptatif d&#39;échantillon multipasse
CN118118666A (zh) 自适应环路滤波器

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20191119

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210205

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: INTERDIGITAL MADISON PATENT HOLDINGS, SAS

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: INTERDIGITAL MADISON PATENT HOLDINGS, SAS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20230927

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20240122

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602018065838

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: NL

Ref legal event code: FP