Multi-feature sample offset filtering system for video encoding and decoding

Abstract

The present disclosure relates to a multi-feature sample offset filtering system for video encoding and decoding. A filtering system for video encoders and decoders is disclosed, the filtering system comprising: a feature detector having an input for samples reconstructed from encoded video data representing a color component of a source video, and having an output for data identifying features identified from the data; an offset calculator having an input for feature identification data from the feature detector and having an output for a filter offset, and a filter having an input for the filter offset from the offset calculator and an input for reconstructed samples, and having an output for filtered samples. The filtering system contemplates improving the operation of a video encoder / decoder filtering system by selecting a filtering offset from an analysis of recovered video data in a common color plane with the samples to be filtered.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit under 35 U.S.C. § 119(e) to provisional U.S. Patent Application No. 63 / 277,319, filed November 9, 2021, the contents of which are incorporated herein in their entirety. TECHNICAL FIELD

[0003] The present disclosure relates to techniques for video encoding and decoding for bandwidth-limited communication channels, and in particular to techniques for loop filtering for such applications. BACKGROUND

[0004] Video encoding / decoding applications generally exploit spatial and / or temporal redundancies in video data to generate an encoded representation of the video data that has reduced bandwidth compared to the source video data from which the video data was generated. These techniques generally apply prediction algorithms that predict video content from earlier encoded content, determine differences between the actual video content and its predicted content, and then encode the residuals representing these differences. In this way, video encoding devices and video decoding devices employ algorithms to maintain a synchronized representation of the prediction data.

[0005] Video encoding / decoding techniques are generally “lossy” processes, meaning that the recovered video data generated by decoding the encoded video data will exhibit errors compared to the source video data from which the video data was generated. Since the video decoder does not have access to the source video data, the prediction algorithms operate in the domain of the recovered video data.

[0006] Decoding algorithms can apply filtering to the recovered video data prior to employing the recovered video data for prediction to improve the quality of the recovered video data. The filtering algorithms can be applied in the “loop” of prediction, meaning that the filtering algorithms are applied by the video encoder and the video decoder in the same way, such that they remain synchronized. Filtering algorithms that impact the quality of the recovered video data are naturally undesirable. Thus, the video encoder and decoder are designed to dynamically adjust the filtering operations to improve the overall quality of the video. BRIEF DESCRIPTION OF DRAWINGS

[0007] Figure 1 Block diagram of a video encoding system in accordance with embodiments of the present disclosure.

[0008] Figure 2 Block diagram of a video encoder in accordance with embodiments of the present disclosure.

[0009] Figure 3 Block diagram of a video decoder in accordance with embodiments of the present disclosure.

[0010] Figure 4 A block diagram of a multi-feature sample offset filter according to embodiments of the present disclosure.

[0011] Figure 5 An exemplary sample array suitable for use with embodiments of the present disclosure is shown.

[0012] Figure 6 An exemplary sample array suitable for use with embodiments of the present disclosure is shown.

[0013] Figure 7 An exemplary set of candidate directional blocks suitable for use with embodiments of the present disclosure is shown.

[0014] Figure 8 An exemplary set of filter taps suitable for use with embodiments of the present disclosure is shown.

[0015] Figure 9 An exemplary set of filter taps suitable for use with embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0016] Embodiments of the present disclosure provide a filtering system for video encoders and decoders, the filtering system comprising a feature detector having an input for samples reconstructed from encoded video data representing a color component of a source video and having an output for data identifying features identified from the data, an offset calculator having an input for the feature identification data from the feature detector and having an output for a filter offset, and a filter having an input for the filter offset from the offset calculator and an input for reconstructed samples and having an output for filtered samples. The filtering system contemplates improving the operation of a video encoder / decoder filtering system by selecting a filter offset from an analysis of recovered video data in a common color plane with the samples to be filtered.

[0017] Figure 1 A simplified block diagram of a video encoding system 100 according to embodiments of the present disclosure is shown. System 100 can include a plurality of terminals 110-120 interconnected via a network 130. Certain terminals can encode video data for transmission to another terminal via network 130. Other terminals can receive other terminals' encoded video data from network 130, decode the encoded video data, and generally consume the video data recovered therefrom by displaying the decoded video.

[0018] The video encoding system 100 can be used in a variety of applications. In a first application, a pair of terminals 110, 120 can support real-time bidirectional exchange of encoded video to establish a video conferencing session between them. In another application, terminal 110 can encode pre-produced video (e.g., television or film programs) and store the encoded video for delivery to a client 120 for downloading, or frequently to multiple clients 120 for downloading. Thus, the video being encoded can be real-time or pre-produced, and it can be distributed in a one-to-one or one-to-many distribution model. For the purposes of this discussion, unless otherwise specified, the type of video and the video distribution scheme are irrelevant.

[0019] exist Figure 1 In this design, terminals 110-120 are shown as smartphones, but the principles of this disclosure are not limited thereto. Embodiments of this disclosure can be applied to set-top boxes, televisions, computers (both desktop and laptop computers), tablet computers, computer servers, media players, and / or dedicated video conferencing and entertainment devices, etc.

[0020] Network 130 refers to any number of networks that transmit encoded video data between terminals 110-120, including, for example, wired communication networks and / or wireless communication networks. Communication network 130 may exchange data in circuit-switched and / or packet-switched channels. Representative networks include telecommunications networks, local area networks (LANs), wide area networks (WANs), and / or the Internet. For the purposes of this discussion, unless otherwise specified, the architecture and topology of network 130 are irrelevant to the operation of this disclosure.

[0021] Figure 2 A simplified block diagram of the encoding system 200 according to an embodiment of this disclosure is shown. System 200 encodes input frames of a video sequence using compression techniques that reduce the bit rate of the frames. The system may include a segmentation unit 210 and one or more encoding units 220-240. Segmentation unit 210 may first deconstruct the content of the input frame based on its components in a color space, such as by deconstructing these components into luminance (often simply referred to as "luma") and chrominance components (typically there are two chrominance components, denoted as Cr and Cb). The segmentation unit may output the component data to its corresponding color encoder 220-240. Figure 2 In the example, luminance color data is output to luminance encoder 220, Cr color data is output to Cr encoder 230, and Cb color data is output to Cb encoder 240. Although Figure 2 The application of the Y / Cb / Cr color space is shown, but the principles of this disclosure are not limited thereto; in addition to those described below, the principles of this disclosure can also be applied to other color spaces such as RGB, XYZ, etc.

[0022] Segmentation unit 210 can also parse the data of each color component into a spatial array called a "pixel block". Many encoding protocols employ various types of segmentation schemes, which may be recursive; segmentation unit 210 can work in conjunction with such schemes. Therefore, color component data can be segmented according to a quadtree segmentation scheme, which can produce encoding units of different sizes that will be processed by encoders 220-240. Alternatively, color component data can be segmented into macroblocks and further segmented into blocks for encoding by encoders 220-240. Often, pixel blocks within a color plane frame may have different block sizes within the frame. Furthermore, pixel blocks generated for one encoder (i.e., luma encoder 220) may have different sizes than pixel blocks generated for other encoders (Cr encoder 230 and / or Cb encoder 240). Typically, the size and arrangement of pixel blocks within a color plane are selected based on content analysis of that plane.

[0023] Encoders 220-240 can perform encoding operations on their corresponding color plane data to reduce their bandwidth. Typically, encoders 220-240 utilize temporal and / or spatial redundancy within their input data. For example, encoders 220-240 can perform motion-compensated predictive coding, where input pixel blocks are encoded according to any of a variety of predictive coding modes, such as:

[0024] • Intra-frame coding, where the input pixel block is differentially encoded relative to previously encoded / decoded data of a common frame;

[0025] • Single-predictive inter-frame coding, where the input pixel block is differentially encoded relative to the data of a previously encoded / decoded frame; and

[0026] • Multi-hypothesis motion-compensated predictive coding, in which input pixel blocks are predictively encoded using decoded data from two or more sources via temporal or spatial prediction.

[0027] Predictive coding patterns can be used in conjunction with other coding techniques such as transform skip coding, RRU coding, prediction source scaling, palette coding, etc.

[0028] Figure 2Exemplary functional units of a pixel block encoder applicable to a luminance encoder 220, a Cr encoder 230, and a Cb encoder 240 are shown. The pixel block encoder may include a pixel block encoder 250, a pixel block decoder 260, a loop filter 270, a reference image cache 280, and a predictor 290. The pixel block encoder 250 encodes an input pixel block with reference to a predicted pixel block supplied by the predictor 290 and outputs encoded pixel block data obtained therefrom. The pixel block decoder 260 reverses the encoding operation applied by the pixel block encoder 250 to obtain decoded pixel block data therefrom. The loop filter 270 applies a selected filtering operation to the decoded pixel block data, which can be reconstructed into a recovered frame and stored in the reference image cache 280. The predictor 290 supplies predicted data as prediction data to the pixel block encoder 250.

[0029] The pixel block encoder 250 may include a subtractor 252, a transform unit 254, a quantizer 256, and an entropy encoder 258. The pixel block encoder 250 may accept pixel blocks of input data at the subtractor 252. The subtractor 252 may receive predicted pixel blocks from the predictor 290 and thereby generate a pixel residual array representing the difference between the input pixel blocks and the predicted pixel blocks. The transform unit 254 may apply a transform to the sample data output from the subtractor 252 to convert the data from the pixel domain to the transform coefficient domain. The quantizer 256 may perform quantization on the transform coefficients output by the transform unit 254. The quantizer 256 may be a uniform quantizer or a non-uniform quantizer. The entropy encoder 258 may reduce the output bandwidth of the coefficient quantizer by encoding the output, for example, using variable-length codewords or using a context-adaptive binary arithmetic encoder.

[0030] Transform unit 254 can operate in various transform modes. For example, transform unit 254 can apply Discrete Cosine Transform (DCT), Discrete Sine Transform (DST), Walsh-Hadamard Transform, Haar Transform, Daubechies Wavelet Transform, etc. In one aspect, a controller (not shown) can select the encoding mode M to be applied by transform unit 254, configure transform unit 254 accordingly, and explicitly or implicitly signal the encoding mode M in the encoded video data.

[0031] The quantizer 256 can operate according to the quantization parameters QP supplied by the controller 270 (not shown). In one aspect, the quantization parameters QP can be applied as multi-valued quantization parameters to the transform coefficients, which can be varied, for example, at different coefficient positions within a pixel block in the transform domain. Therefore, the quantization parameters QP can be provided as an array of quantization parameters.

[0032] As its name suggests, the entropy encoder 258 performs entropy encoding on the data output from the quantizer 256. For example, the entropy encoder 258 can perform run-length encoding, Huffman encoding, Golomb encoding, context-adaptive binary arithmetic encoding, and so on.

[0033] The pixel block decoder 260 can reverse the encoding operation of the pixel block encoder 250. For example, the pixel block decoder 260 may include an inverse quantizer 262, an inverse transform unit 264, and an adder 266. The pixel block decoder 260 can obtain its input data from the output of the quantizer 256. Although permitted, the pixel block decoder 260 does not need to perform entropy decoding of the entropy-encoded data because entropy encoding is a lossless event. The inverse quantizer 262 can reverse the operation of the quantizer 256 of the pixel block encoder 250. The inverse quantizer 262 can perform uniform or non-uniform dequantization, as specified by the decoded signal QP. Similarly, the inverse transform unit 264 can reverse the operation of the transform unit 254. The inverse quantizer 262 and the inverse transform unit 264 can use the same quantization parameters QP and transform mode M as their corresponding components in the pixel block encoder 250. Quantization operations typically truncate data in various aspects, and therefore, the data recovered by the inverse quantizer 262 may have encoding errors when compared with the data presented to the quantizer 256 in the pixel block encoder 250.

[0034] Adder 266 reverses the operation performed by subtractor 252. This adder can receive the same predicted pixel blocks from predictor 290 used by subtractor 252 in generating the residual signal. Adder 266 can add the predicted pixel blocks to the reconstructed residual value output by inverse transform unit 264 and can output the reconstructed pixel block data.

[0035] As described, loop filter 270 can perform various filtering operations 272-276 on the recovered pixel block data. This loop filter may have a multi-feature sample offset (“MFSO”) filter 274, as discussed below. In one embodiment, MFSO filter 274 may be part of a multi-filter filtering system 270, which may include other filters 272, 276. Such other filters may include, for example, a deblocking filter, a sample adaptive offset (“SAO”) filter, a constrained orientation enhancement filter (“CDEF”), an adaptive loop filter (“ALF”), a cross-component adaptive loop filter (“CCALF”), and / or a loop recovery (“LR”) filter.

[0036] The MFSO filter 274 proposed herein can work in conjunction with other filtering units within the loop filter 270. For example, the MFSO filter 274 can accept input data from the deblocking filter and output filtered data to the CDEF. Alternatively, the MFSO filter 274 can accept input data from the CDEF and output filtered data to the LR filter. In another embodiment, the MFSO can be placed parallel to the CDEF; in this application, the input to the MFSO can be a reconstructed sample prior to the CDEF, and the output of the MFSO can be applied to the reconstructed sample obtained from the CDEF. In yet another embodiment, the MFSO filter 274 can accept input data from the deblocking filter and output filtered data to the ALF.

[0037] As discussed, the reference image cache 280 can store filtered frame data for use in subsequent predictions of other pixel blocks. Different types of prediction data are available to the predictor 290 for different prediction modes. For example, for an input pixel block, intra-frame prediction obtains a prediction reference from the decoded data of the same frame, where the input pixel block is located. Therefore, the reference image cache 280 can store the decoded pixel block data for each frame during encoding. For the same input pixel block, inter-frame prediction can employ prediction references from previously encoded and decoded frames, which are designated as reference frames. Therefore, the reference image cache 280 can store these decoded reference frames.

[0038] As discussed, predictor 290 can feed prediction blocks to pixel block encoder 250 for use in generating residuals. Predictor 290 may include an inter-frame predictor, an intra-frame predictor, and a mode decision unit (not shown). The inter-frame predictor may receive pixel block data representing new pixel blocks to be encoded, and may search for reference frame data from reference image cache 280 for use in encoding input pixel blocks, against pixel block data from reference frames. The inter-frame predictor may select prediction reference data that provides the closest match to the input pixel block being encoded. The inter-frame predictor may generate prediction reference metadata, such as prediction block size and motion vectors, to identify which portions(s) of which reference frames are selected as prediction sources for input pixel blocks.

[0039] The intra predictor supports intra (I) mode coding. It searches through pixel block data from the same frame as the pixel block being encoded, providing the closest match to the input pixel block. The intra predictor also generates a prediction mode indicator to identify which portion of the frame is selected as the prediction source for the input pixel block.

[0040] The mode decision unit (MDU) selects a hypothetical final coding mode from the outputs of the inter-frame predictor and the intra-frame predictor. The MDU outputs prediction data and coding parameters (e.g., selection of a reference frame, motion vectors, etc.) for the selected prediction mode. Typically, as described above, given a target bit rate, the MDU will select the mode that achieves the lowest distortion when decoding the video. Exceptions may occur when the coding mode is selected to satisfy other strategies followed by the coding system 200, such as satisfying specific channel behavior or supporting random access or data refresh strategies.

[0041] As discussed herein, embodiments of this disclosure propose an MFSO filtering system to improve the quality of input reconstructed samples. MFSO uses multiple features detected from within the image content to derive a classification of the input samples. In one embodiment, the data input to the MFSO is a reconstructed sample in a color component, and the output offset of the MFSO is applied to the same color component. For example, the input to the MFSO in luma encoder 220 is a reconstructed sample in the luma component, and the output offset of the MFSO is applied to the luma component. In another example, the input to the MFSO in Cr encoder 230 is a reconstructed sample in the Cr component, and the output offset of the MFSO is applied to the Cr component. In yet another example, the input to the MFSO in Cb encoder 240 is a reconstructed sample in the Cb component, and the output offset of the MFSO is applied to the Cb component.

[0042] In another embodiment, the data input to the MFSO of one color component may include reconstructed samples from another color component, and the output offset of the MFSO is applied to any other color component. For example, the input to the MFSO of a Cr encoder 230 or a Cb encoder may include reconstructed samples from the luminance component, and the output offset of the MFSO is applied to the Cb / Cr component.

[0043] Figure 3 This is a block diagram of a decoding system 300 according to an embodiment of the present disclosure. The decoding system 300 can decode data that has been encoded by an encoder (e.g., Figure 2 The decoding system 300 decodes frames of a video sequence encoded by the encoder shown. The decoding system 300 may include one or more encoding units 310-330, which are reversible from frames encoded by the encoder shown. Figure 2 The encoding operations performed by encoding units 220-240. Therefore, continue. Figure 2 For example, the decoding system 300 may have a luminance decoder 310, a chrominance decoder 320, and a chrominance decoder 330. The decoding system 300 may also have a reconstruction 340 that generates a restored frame based on the color component data output by decoders 310-330. Figure 2 Similarly, although Figure 3The decoding system 300 illustrates the application of the Y / Cb / Cr color space, but the principles of this disclosure can also be applied to other color spaces such as RGB, XYZ, etc.

[0044] Figure 3 An exemplary functional unit of a pixel block decoder that can be applied in a luminance decoder, a Cr decoder, and a Cb decoder 310-340 is shown. The decoder may be a pixel block decoder 350, a loop filter 360, a reference image cache 370, and a predictor 380 that operate under the control of a controller (not shown).

[0045] Predictor 380 can receive prediction metadata identifying the prediction mode and prediction reference of the encoded pixel block, and can output prediction data from the reference image cache 370 to pixel block decoder 350. Pixel block decoder 350 can generate reconstructed pixel blocks from the encoded pixel block data and the prediction data supplied by predictor 380. Loop filter 360 can filter the reconstructed pixel block data output from decoder 350. For a frame designated as a reference frame, the output of the loop filter can also be stored in reference image cache 370.

[0046] The pixel block decoder 350 may include an entropy decoder 352, an inverse quantizer 354, an inverse transform unit 356, and an adder 358. The entropy decoder 352 can perform entropy decoding to reverse the process performed by the entropy encoder 258. Figure 2 The operation of quantizer 256 in invertible pixel block encoder 250 ( ). Figure 2 Similarly, the inverse transform unit 326 can reverse the operation of the inverse transform unit 254. Figure 2 They can use the quantization parameter QP and transform mode M provided in the encoded video data stream. Since quantization can truncate data, the pixel block recovered by the inverse quantizer 324 is likely to have encoding errors compared to the input pixel block presented to the encoder 250. Figure 2 ).

[0047] Adder 358 can invert the operation performed by subtractor 252. Figure 2 The adder can receive predicted pixel blocks from predictor 380, as determined by a prediction reference in the encoded video data stream. Adder 358 can add the predicted pixel blocks to the reconstructed residual values ​​output by inverse transform unit 356, and can output reconstructed pixel block data.

[0048] As described, the loop filter 360 can perform various filtering operations 362-366 on the recovered pixel block data, and... Figure 2The loop filter 270 operates synchronously. This loop filter may include an MFSO filter 364, as discussed below. In one embodiment, the MFSO filter 364 may be part of a multi-filter system 360, which may include other filters 362, 366. Such other filters may include, for example, deblocking filters, SAO filters, CDEF, ALF, CCALF, and / or LR filters.

[0049] The MFSO 364 proposed herein can work in conjunction with other filtering units within the loop filter 360. For example, the MFSO 364 can accept input data from the deblocking filter and output filtered data to the CDEF. Alternatively, the MFSO 364 can accept input data from the CDEF and output filtered data to the LR filter. In another embodiment, the MFSO can be placed parallel to the CDEF; in this application, the input to the MFSO can be a reconstructed sample prior to the CDEF, and the output of the MFSO can be applied to the reconstructed sample obtained from the CDEF. In yet another embodiment, the MFSO 364 can accept input data from the deblocking filter and output filtered data to the ALF.

[0050] Reference image cache 370 can store filtered frame data for use in subsequent predictions of other pixel blocks. Reference image cache 370 can also store decoded frames (during encoding) for use in intra-frame prediction. Reference image cache 370 can also store decoded reference frames.

[0051] As discussed, predictor 380 can feed prediction blocks to pixel block decoder 350. Predictor 380 can retrieve prediction data from reference picture cache 370, as determined by prediction reference indicators supplied in the encoded video data stream.

[0052] Figure 4 This is a block diagram of the MFSO 400 according to an embodiment of this disclosure. The MFSO 400 can be applied to encoders and decoders, as described above. Figure 2 and Figure 3As shown. The MFSO 400 may include a feature detector 410, an index calculator 420, an offset calculator 430, and a filter 440. The MFSO 400 can receive a set of reconstructed samples and generate corrected samples from them. The feature detector 410 can detect predetermined features represented from the input reconstructed samples and output the identifiers of the detected features to the offset calculator 430. The index calculator 420 can generate offset indices d0 and d1 from selected input samples, which are input to the offset calculator 430. The offset calculator 430 can generate offsets from its input data, which can be output to the filter 440. The filter 440 can filter the reconstructed samples using the offsets supplied by the offset calculator.

[0053] In one implementation, the MFSO 400 can be used for the input-to-loop filter 270 ( Figure 2 Each reconstructed sample r i ( Figure 5 ) Select filter 440 settings individually. MFSO 400 can be based on other reconstructed samples present in the HxW spatial array 500 with respect to the reconstructed sample r. i The analysis is used to select filter settings. In many implementations, array 500 may contain samples r present therein. i The array 500 may contain reconstructed samples from both the same color plane and other color planes. In other embodiments discussed below, the array 500 may contain reconstructed samples from both the same color plane and other color planes.

[0054] As discussed, feature detector 410 can identify the presence and / or type of predetermined content features represented in the reconstructed samples. In one aspect, feature detector 410 can analyze array 500 of reconstructed samples to identify indicators of orientation in the image content. For example, feature detector 410 can perform edge detection to estimate the presence and orientation of edge content in sample array 500. Alternatively, feature detector 410 can apply texture classification to the reconstructed samples in array 500, estimate the variance between reconstructed samples in array 500, or estimate the differences in values ​​in reconstructed samples in array 500. When such analysis indicates that array 500 contains identifiable orientation in the image content, feature detector 410 can generate feature IDs representing such orientation.

[0055] In another embodiment, the feature detector 410 can reconstruct the sample r based on the sample intensity. i ( Figure 5 The system classifies samples within a predetermined range R, where the sample values ​​are represented numerically. The range R can be divided into N intensity bands, each representing a portion of the total range R. The feature detector 410 generates a feature ID that identifies the reconstructed sample r. iThe belt to which it belongs.

[0056] Intensity bands can be defined in several ways. As an example, the range R of sample values ​​can be divided into N uniformly sized bands that collectively cover the entire range R of sample values. The value N can be predetermined within the system. Alternatively, N can be dynamically defined during system operation and signaled between the encoder and decoder at predetermined intervals (e.g., in the APS, in the slice header, in the tile header, in the picture parameter set, in the sequence parameter set, in the video parameter set, or when N changes).

[0057] As another example, the range R of sample values ​​can be divided into N bands of non-uniform size, which collectively cover the entire range R of sample values. In this example, the number and size of the bands can be predetermined within the system. Alternatively, the number and size of the bands can be dynamically defined during system operation and signaled between the encoder and decoder at predetermined intervals (e.g., in the APS, in the slice header, in the tile header, in the picture parameter set, in the sequence parameter set, in the video parameter set, or when they change). For example, the frame header may include a flag (mfso_enable) that, in one state (e.g., true), indicates the use of a set of uniformly sized sample intensity bands, and in another state (e.g., false), indicates the use of a set of non-uniformly sized sample intensity bands.

[0058] In another embodiment, the range R of sample values ​​can be divided into N segments from the minimum intensity value to the maximum intensity value, wherein each group of M adjacent segments is grouped together to form a band of MFSO 400. In this embodiment, N and M can be positive integers, where N ≥ M.

[0059] In another implementation, reconstruct sample r i The classification can be done by exporting the index band_idx, as shown below:

[0060] band_idx=r i >>(bitDepth-maxBandLog2)

[0061] Where bitDepth corresponds to the bit depth of the reconstructed sample in the applicable color plane, and maxBandLog2 is log2 of the maximum allowed number of bands.

[0062] In one implementation, the sample r is reconstructed. i The information can be computed at the pixel level. For example, for each reconstructed sample r i The intensity value can be used to check which band the current sample belongs to.

[0063] In another implementation, the sample r is reconstructed. i The information can be computed at the block level. For example, reconstructing sample r i The average intensity value of the pixel block to which it belongs can be used to reconstruct the sample r i This is assigned to the sample intensity band. This block can be a superblock (SB), coding tree unit (CTU), coding block, segmentation unit, transform unit, prediction unit, filter unit, etc.

[0064] In one implementation, the sample r is reconstructed. i Information can be obtained from the reconstructed sample r i The value is calculated to represent the sample content within a single color plane. In another implementation, the sample r is reconstructed. i The information can be calculated not only from its own value, but also from its relationship with the reconstructed sample r. i The values ​​of the reconstructed samples of the other relevant color components are used for calculation. Typically, due to the chromaticity format used by the system (e.g., 4:4:4 vs. 4:2:0, etc.), perfect registration may not exist between all luminance samples and all Cb and Cr chromaticity samples. In such cases, it may be useful to reduce the size of the reconstructed luminance samples to match the reconstructed Cb and Cr chromaticity samples. Alternatively, it may be useful to expand the size of the reconstructed Cb and Cr chromaticity samples to match the reconstructed luminance samples.

[0065] In one implementation, the reconstructed sample r is obtained before applying other loop filters. i It can be used to compute information. Alternatively, it may be used to obtain reconstructed samples r after other loop filters. i Used for calculating information.

[0066] As yet another example, the MFSO 400 can employ both uniformly sized and non-uniformly sized sample intensity bands during operation. Encoder ( Figure 2 It can signal the use of a certain type of sample intensity band (e.g., whether to use a uniform-sized band or a non-uniform-sized band) in channel data, such as in APS, in slice headers, in tile headers, in image parameter sets, in sequence parameter sets, and in video parameter sets.

[0067] In another embodiment, the feature detector 410 can be based on the reconstructed sample ri ( Figure 5 The feature detector 410 classifies the sample based on the encoding parameters selected from the pixel blocks to which the sample belongs. For example, the feature detector 410 may reconstruct the sample r based on the encoding pattern of the pixel blocks (e.g., the encoding parameters of the pixel blocks). iThe feature ID can be selected based on whether it belongs to a pixel block encoded via intra-frame prediction, inter-frame prediction mode, etc. In another example, the feature detector 410 may select the feature ID based on the transform process and / or coefficient encoding selected for the pixel block to which the sample belongs (such as transform size and type, or coded block flag (CBF)). For example, the feature ID may be derived from the CBF flag state, regardless of whether it is zero. In another example, the feature detector 410 may select the feature ID based on the size of the pixel block of the reconstructed sample, the segmentation type of the pixel block of the reconstructed sample, the quantization parameters (QP) of the pixel block of the reconstructed sample, and / or the motion information (motion vector, reference frame, motion model parameters, etc.) of the pixel block of the reconstructed sample.

[0068] In another example, the feature detector 410 may select the feature ID based on parameters (such as ALF block classification results, CDEF information, etc.) selected by other loop or out-of-loop filtering processes applied to the reconstructed sample.

[0069] In one implementation, the features upon which the feature detector 410 generates its feature ID can vary for different reconstructed samples. For example, the features can vary on a per-pixel block basis, a per-slice basis, or a per-frame basis. The encoder can signal the feature detector 410 to select features being used in the High-Level Syntax (HLS) structure, such as APS, slice header, tile header, frame header, PPS, SPS, VPS, etc.

[0070] As discussed, the index calculator 420 can generate indices d0, d1 from the offset calculator 430. In one embodiment, the index calculator 420 can generate indices d0, d1 from the reconstructed sample r. i In the context of adjacent reconstructed samples of the same color plane, the reconstructed sample r i Analysis to generate reconstructed samples r i The index.

[0071] Figure 6 The diagram illustrates one such implementation, in which the sample r is reconstructed. i Sample 610 is shown together with adjacent samples 615-690. The index calculator 420 can operate according to multiple 3-tap filters, where the filter inputs (referred to as p0 and p1 respectively) are selected according to different filter directions. In one aspect, six filter combinations can be used, as described in Table 1 below:

[0072]

[0073] Table 1

[0074] System designers are expected to be able to customize the number of different directions and their inputs to suit their respective application needs.

[0075] On one hand, the encoder can choose the direction applied during encoding. The direction can be changed at predetermined levels of the encoding hierarchy (such as at the Cb / Cr color component level). The encoder can signal its chosen direction in the encoded bitstream using appropriate flags. For example, the variable `filter_sup` can be interchanged, indicating the filter selected for each corresponding color component. Figure 6 As shown in the configuration, the filter_sup syntax element can use 3 bits to signal notifications.

[0076] For each filter direction, the MFSO 400 can calculate a pair of Δ values ​​m0 and m1, denoted as m j =rc i -p j Where j = 0, 1. Afterwards, the index calculator 420 can generate quantized values ​​d0, d1 based on the Δ values ​​m0, m1, as shown below:

[0077] di = -1 if m < -thr;

[0078] di = 0, if -thr <= m <= thr; and

[0079] di = 1 if m > thr.

[0080] Here, thr represents the quantization step size, which can be a predetermined value set by the encoder. For example, thr can take values ​​of 8, 16, 32, or 64. Furthermore, the thr value can be dynamically set during operation and can be signaled from the encoder to the decoder in the encoded bitstream.

[0081] In one implementation, the offset calculator 430 may be implemented as a multidimensional lookup table (LUT), which is indexed by a feature ID provided by the feature detector 410 and an index output by the index calculator 420. Prior to runtime operation of the MFSO 400, the LUT may be pre-populated with offset values ​​suitable for the samples being processed. During runtime operation, the MFSO 400 may read the offset values ​​from the LUT and supply them to the filter 440.

[0082] The LUT may have sub-tables corresponding to different feature IDs generated by the feature detector 410. In one embodiment, the feature detector 410 may classify input samples based on sample intensity band information and edge information. In this respect, the feature ID may have a first component (i) representing the band index of the sample and a second component (j) representing the edge index of the sample. These (i,j) pairs may correspond to the associated offset values ​​s used by the filter 440. ijFor example, when there are N bands and N LUTs, each band can have associated LUTs with entries from different groups. Exemplary values ​​for N can be 8, 16, and 32.

[0083] In one implementation, LUTs can be dynamically derived. For example, these LUTs can be signaled at the sequence level, frame level, tile level, CTU / SB level, or pixel block level of the coding hierarchy.

[0084] In another embodiment, the offset calculator 430 may have N LUTs in the MFSO 400, each LUT being associated with a corresponding sample intensity band. Each LUT may have M entries, each storing an offset value. In this embodiment, the encoder may signal the M*N offset values ​​(e.g., as part of the APS, slice header, tile header, frame header, PPS, SPS, VPS, etc.) that are signaled in the HLS.

[0085] In another embodiment, the offset calculator 430 can form a parametric model of the offset defined by parameters. For example, samples from the luminance and chrominance components of the MFSO 400 can be used to derive a linear relationship s = A*y + B*c, where A and B are the coefficients to be derived, y refers to the luminance sample value, c refers to the Cb or Cr sample value in the evaluation, and s is the output offset value used in the filtering process of the MFSO 400. During operation, the encoder can estimate the values ​​of A and B that minimize distortion during the application of the MFSO 400, and these values ​​can be signaled to the decoder. Alternatively, the values ​​of A and B can be derived from the samples being processed, r i The reconstructed sample is implicitly derived in the neighborhood, which reduces signaling overhead within the system.

[0086] Another example of using a parametric model is to employ a non-linear relationship s = f0(y) across all three color planes. i )+f1(cb i )+f2(cr i The reconstructed samples, where f0, f1, and f2 are functions that map input values ​​to output values, y i This refers to the brightness sample value, cb i / cr i Here, represents the Cb / Cr sample value, and s is the output offset value used during the filtering process of MFSO 400. During operation, the encoder can estimate the functions f0, f1, and f2 that minimize distortion during the application of MFSO 400 from a set of candidate functions F. The encoder can indicate its selection of functions f0, f1, and f2 in the channel signaling to the decoder. Alternatively, the functions f0, f1, and f2 can be implicitly derived from the neighborhood of the reconstructed sample with respect to the sample being processed, which reduces signaling overhead within the system.

[0087] When the parameter models are dynamically derived, they can be signaled at the sequence level, frame level, tile level, CTU / SB level, or pixel block level of the coding hierarchy.

[0088] In one implementation, when offset values ​​in the LUT or parametric model are dynamically formed during runtime operation, the encoder does not need to signal the entire LUT or parametric model. In some implementations, the encoder signals some offset values ​​of the LUT, and the decoder derives the remaining offset values ​​from the signaled offset values, or it may be sufficient if the remaining offset values ​​are fixed. For example, consider a system employing a nine-entry lookup table corresponding to a given feature ID; the encoder might signal a subgroup of offset values ​​s0, s1, s2, s3, and s4 for selected combinations, and the decoder could form the complete table by inverting the offset values ​​to the following values:

[0089]

[0090] As another example, the encoder can signal subgroups s0, s1, s2, s3, and s4 of offset values ​​for selected combinations, and the decoder can form a complete table by inverting the offset values ​​to the following values:

[0091]

[0092] It is anticipated that during implementation, system designers will be able to customize the derived values ​​to suit their various application requirements.

[0093] In another implementation, a single LUT can be formed by combining the feature ID output by the feature detector and the indices d0 and d1 output by the index calculator 420. For example, in an implementation where the feature ID is generated as a single-bit binary value, the LUT takes the following form:

[0094]

[0095]

[0096] During implementation, system designers are expected to be able to customize the number and offset values ​​of feature IDs to suit their individual application needs.

[0097] In another implementation, for the MFSO 400, a filter scaling factor x is used. This scaling refers to scaling the offset value generated by the MFSO400 by a factor of x. The value of x can be signaled at the sequence level, frame level, tile level, CTU / SB level, or coded block level. In this case, the offset value derived by the offset calculator 430 can be scaled using the x factor received via the channel.

[0098] In one implementation, the feature ID may represent a sample intensity band, and the offset calculator 430 may have a LUT corresponding to each available band, wherein each LUT stores a value s associated with its corresponding band i and entry j (entry j corresponds to the corresponding combination of d0 and d1). ij In this implementation, the input sample can be classified using information, with the output being an index denoted as i, and it can also be classified using edge information, with the output being an edge index denoted as j. Each (i,j) pair has an associated offset value sij used in the filtering process of MFSO 400.

[0099] In another implementation, the current color representation (e.g., matrix coefficients that can be associated with the video) can be used to adjust the offset values ​​of the MFSO 400 based on the values ​​of luminance and / or Cb and Cr. For example, certain relationships and constraints between the Cb and Cr components can be derived based on the color representation. Such constraints can be taken into account to adjust the basic offset values ​​stored in the LUT according to the signal values, thereby avoiding the use of certain offsets in certain areas.

[0100] Filter 440 can apply offset filtering to the reconstructed samples using offset values ​​obtained from offset calculator 430. Filter 440 can generate filtered reconstructed samples that represent the output of MFSO 400. MFSO 400 can have a predetermined number F of taps.

[0101] In one implementation, the MFSO 400 may have multiple taps F that can be signaled by an encoder in the channel. Similarly, the MFSO 400 may have multiple candidate filter shapes that can be selected based on signaling provided in the channel. The filter shapes can be selected and signaled at the sequence level, frame level, tile level, CTU / SB level, or coded block level. Alternatively, the number of taps and / or the filter shape may be selected based on the feature ID output by the feature detector 410.

[0102] In one implementation, filter 440 may apply a filtering direction based on the current luminance and chrominance relationship. This relationship includes, but is not limited to, the chrominance subsampling format and the position of the chrominance sample associated with the luminance sample.

[0103] In another embodiment, filter 440 may apply F filter taps based on the current luminance and chrominance relationship. This relationship includes, but is not limited to, the chrominance subsampling format and the position of the chrominance sample associated with the luminance sample.

[0104] In one implementation, the selection of the number of taps, filter shape, and / or offset values ​​of the MFSO 400 can be entropy-encoded using Universal Variable Length Code (“UVLC”). Alternatively, one or more of these values ​​can be signaled using fixed-length code.

[0105] During the runtime operation of the encoder and decoder, the MFSO can operate in a synchronized state. Although the operating settings of the MFSO 400 can change dynamically during operation, the operating settings present at the MFSO 400 when encoding a given pixel block should also be present at the MFSO 400 when decoding the same pixel block. In one implementation, the encoder and decoder may exchange signaling appropriately to synchronize the state of their MFSOs.

[0106] In one implementation, the number of bands for each color component can be signaled. For example, the encoder can provide a value max_band_log2, which represents log2 of the maximum allowed number of bands for each color component. It may be convenient to use 2 bits to signal max_band_log2, which would identify the allowed number of bands as one of 1, 2, 4, and 8.

[0107] In another implementation, the selection of the filter to be used for each color component can be signaled. (See above regarding...) Figure 6 The MFSO 400, as discussed, supports several different filters. The encoder can interchange the variable `filter_sup`, which indicates the selected filter for each corresponding color component. It may be convenient to use a 3-bit signal to notify `filter_sup`.

[0108] In another implementation, an identifier for the sample intensity threshold can be signaled. For example, the encoder can supply a thr_idx value, which represents the index of the threshold for each color component. In one application, it might be convenient to use 2 bits to signal thr_idx, which identifies the sample intensity threshold of 8, 16, 32, or 64.

[0109] In another implementation, the filter offset value can be signaled. In one application, it may be convenient to use 3 bits to signal the filter offset value, which represents the selection of a predetermined offset value from the group {-10,-7,-3,0,1,3,7}.

[0110] In one implementation, a flag can be provided to signal when MFSO is enabled or disabled. For example, it might be convenient to provide a 1-bit mfso_enable signal for each color component, indicating whether MFSO is enabled for that color component. On the other hand, it might be convenient to provide a 1-bit mfso_blk_ctr signal for each 128x128 superblock, indicating whether MFSO is enabled for the superblock.

[0111] In one implementation, the offset values ​​generated by the offset calculator 430 can be formed by the encoder through a training operation that derives the offset values ​​from the training sequence based on an estimate of the value that minimizes distortion when applying MFSO 400. The derived offset values ​​can be transmitted to the decoder using various techniques. Figure 1 For example, the derived MFSO value can be explicitly transmitted at the sequence level, frame level, or tile level in the communication hierarchy. In one embodiment, the encoder can transmit a single set of signaling information per sequence, per frame, or per tile, with the Y / Cb / Cr components sharing the signaling information.

[0112] In one implementation, training derives a linear relationship s = A*y + B*c, where A and B are the derived coefficients, y is the luminance sample value, c is the Cb or Cr sample value, and s is the output offset value used in the MFSO 400 filtering process. The coefficient values ​​are signaled from the encoder to the decoder, which can use these coefficient values ​​to derive its MFSO 400 offset values.

[0113] In another implementation, samples from all three color components of the MFSO 400 can be used with a non-linear relationship s = f0(y) + f1(cb) + f2(cr), where f0 / f1 / f2 are derived functions mapping input values ​​to output values, y refers to the luminance sample value, cb / cr refers to the Cb / Cr sample values, and s is the output offset value used in the filtering process of the MFSO 400. Function identifiers can be signaled from the encoder to the decoder, which can use these function identifiers to derive its MFSO 400 offset values.

[0114] In another implementation, the current color representation (e.g., matrix coefficients that can be associated with the video) can be used to adjust the offset values ​​of the MFSO 400 based on the values ​​of y and / or Cb and Cr. For example, certain relationships and constraints between the Cb and Cr components are derived based on the color representation. Such constraints can be taken into account to adjust the offset values ​​of the MFSO 400 according to the signal values, thereby avoiding the use of certain offsets in certain areas.

[0115] In one implementation, when training a LUT for the MFSO 400 at the encoder, the initial block-level on / off states of the MFSO 400 can be carried over from the states of other loop filters in the current frame or previous encoded frames to achieve faster encoder convergence. For example, the states of the SAO filter, ALF, CCALF, LR filter, or CDEF can determine the state of the MFSO 400 during training.

[0116] In one implementation, the encoder can signal the number (L) of active LUTs in the MFSO 400. In one example, L is a fixed positive integer value. In another example, L can vary during operation, and changes in L can be signaled at the sequence level, frame level, tile level, CTU / SB level, or code block level.

[0117] In one implementation, the MFSO 400 may have L LUTs, each LUT associated with a sample intensity band of the MFSO 400. Each LUT may have M entries, each of which represents an offset value. In this implementation, there will be M*L offset values ​​that can be signaled in the HLS (APS, slice or tile header, frame header, PPS, SPS, VPS). For a LUT, LUT entries may have the same offset value for multiple sample intensity bands in the sample intensity band, in which case the LUT may have fewer than M entries. As discussed, the LUT can be one or more parametric models defined by parameters.

[0118] In another implementation, when deriving entries for the MFSO LUT given an input sample, the following equation can be used: m = rl - ((a*p0 + b*p1) >> k), where k is a positive integer. On one hand, the values ​​of a, b, and k can be signaled in the HLS (APS, slice or tile header, frame header, PPS, SPS, VPS). Alternatively, these values ​​can be predefined between the encoder or decoder.

[0119] In another implementation, multiple sets of MFSO information can be signaled at the first level of the protocol hierarchy (e.g., sequence level). At lower levels of the protocol hierarchy (e.g., frame level, slice level, or pixel block level), the encoder can signal the index of the set of MFSO information to be used.

[0120] In another implementation, when the filter shape of the MFSO 400 is entropy-encoded (e.g., when signaling using UVLC), signaling for other information of the MFSO 400 can be adjusted based on the filter shape. In one example, a UVLC code of 0 for the filter shape might mean that the MFSO 400 is not in use (e.g., off); in this case, no further signaling for other information of the MFSO 400 is required.

[0121] In another implementation, the MFSO LUT can be signaled once per group (N frames or N blocks). In the first frame (or block) of the group, the LUT can be signaled. For the remaining frames or blocks of the group, if the encoder changes the MFSO LUT, the encoder can signal the changed LUT data, for example, by completely replacing the LUT or by signaling a change to a previously used LUT.

[0122] In another implementation, the block-level state of the MFSO 400 (e.g., on or off) may be carried over from the block-level states of other loop filters 272, 276 (e.g., SAO filter, ALF, CCALF, LR filter, or CDEF) in the loop filter system 270.

[0123] In another implementation, the on / off state of MFSO 400 can be derived from other coding information (such as transform type, prediction mode, number of coefficients, etc.) of the block and / or its neighboring blocks. In this way, the signaling overhead of the MFSO process can be reduced.

[0124] In another embodiment, the encoder can signal the array of MFSO offset values, and for each combination, the encoder can signal the index of the offset value s, which indicates the position of the offset value s in the MFSO array. Such offset values ​​and / or indices can be signaled at the sequence level, frame level, tile level, or block level. In another embodiment, for each combination, the offset value s is signaled at the sequence level, frame level, tile level, or block level.

[0125] This paper proposes that techniques utilizing multiple features during input sample classification / grouping are also applicable to other loop filtering methods. In one implementation, multi-feature techniques can be used in the constrained orientation enhancement filter (CDEF) edge orientation search process. Typically, the CDEF orientation search is performed on the reconstructed pixels immediately after the deblocking filter. Since the decoder can use these pixels, orientation signaling is not required. The search is performed on 8x8 blocks, and for each block, the orientation that best matches the pattern in the block is determined by minimizing the sum of squared differences (SSD) between the quantized block and the nearest orientation block. The identified orientation is then used to select the filter shape and filter coefficients. In this application, feature IDs generated by feature detector 420 can also be used to select the filter shape and filter coefficients for the CDEF filter. Using such techniques, CDEF can extend a set of candidate orientation blocks from eight to a larger number, such as 16, 32, or 64 candidate blocks, which combine orientation and feature IDs.

[0126] The CDEF works by identifying the orientation of each block, then performing adaptive filtering along the identified orientation, and a smaller degree of filtering along the orientation rotated 45 degrees from the identified orientation. The CDEF orientation search is typically performed on the reconstructed pixels immediately after the deblocking filter is applied, on 8x8 blocks, and finds the orientation that best matches the pattern in the block by minimizing the sum of squared differences (SSD) between the quantized block and the nearest orientation block. Figure 7 An exemplary set of eight candidate orientation blocks is shown. In one implementation, a multi-feature approach can be used to select the filter shape and filter coefficients of the CDEF filter. This can be based on edge detection. Sample strength analysis and / or encoding / filtering parameters The detected features are used to select the filter shape and filter coefficients. In this way, CDEF can use the multi-feature analysis described in this paper to select from its candidate modes, either alone or in combination with the conventional SSD technique for CDEF filters.

[0127] CDEF uses a non-linear low-pass filter designed to remove coded artifacts without blurring sharp edges. This is achieved by selecting the filter tap position based on the identified direction, and also by preventing excessive blurring when applying the filter across edges. The latter is implemented using a non-linear low-pass filter that does not emphasize pixels that differ too much from the pixel being filtered. CDEF defines major and minor taps. The major tap follows the direction d and such as... Figure 8 The weights are shown in the example. For the main tap, the weights alternate every other intensity, so the weights for intensities 1, 3, 5, etc., are different from the weights for intensities 2, 4, 6, etc. The secondary taps form a cross shape, with their direction at a 45-degree angle to direction d, and their weights are as follows. Figure 9 As shown in the example.

[0128] In another implementation, multi-feature techniques can be used in the ALF block classification process. The standard ALF process classifies blocks based on their orientation D and activity. The quantization values ​​are used to classify the input blocks. On one hand, The multi-feature detection analysis described in [the document] can be used with D and [other methods] to identify the class of the current block. They can be used together or in combination. For example, sample strength analysis can provide an estimate of the range of sample strength, denoted as P. The classification index C can be derived from D, Export P. Afterwards, ALF processing can be applied using the categorical index.

[0129] The foregoing discussion has described the operation of various aspects of this disclosure within the context of video encoders and decoders. These components are often provided as electronic devices. Video decoders and / or controllers can be embedded in integrated circuits, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and / or digital signal processors (DSPs). Alternatively, they can be embedded in computer programs that execute in camera devices, personal computers, laptops, tablets, smartphones, or computer servers. Such computer programs are typically stored in physical storage media such as electronic, magnetic, and / or optical-based storage devices, where they are read by a processor and executed. Decoders are often packaged in consumer electronic devices, such as smartphones, tablets, gaming systems, DVD players, portable media players, etc.; and they can also be packaged in consumer software applications, such as video games, media players, media editors, etc. Furthermore, these components can, of course, be provided as hybrid systems that distribute functionality as needed across dedicated hardware components and programmed general-purpose processors.

[0130] Video encoders and decoders can exchange video over a channel in various ways. They can communicate with each other via communications and / or computer networks, such as... Figure 1 As shown. In other applications, the video encoder can output video data to a storage device, such as an electrical, magnetic, and / or optical storage medium, which can then be provided to the decoder at a later time. In such applications, the decoder can retrieve the encoded video data from the storage device and decode it.

[0131] This document specifically illustrates and / or describes several embodiments of the invention. However, it should be understood that modifications and variations of the invention are covered by the foregoing teachings and are within the scope of the appended claims without departing from the spirit and intended scope of the invention.

Claims

1. A filtering system, comprising: A feature detector having inputs of samples reconstructed from coded video data representing color components of a source video, and an output of data identifying features recognized from the data. An index calculator, having input for the reconstructed sample and an output including an offset index, An offset calculator, having input to feature identifier data from the feature detector and an output for filter offset, the output of the offset calculator being partially based on the offset index from the index calculator, and A filter having an input for the filter offset from the offset calculator and an input for the reconstructed sample, and an output for the filtered sample.

2. The filtering system of claim 1, wherein the feature identification data from the feature detector represents the classification of the reconstructed sample into one of a plurality of sample intensity bands.

3. The filtering system according to claim 2, wherein the sample intensity band is defined by signaling, and the signaling is provided by the video encoder that generates the encoded video data.

4. The filtering system of claim 1, wherein the feature identification data from the feature detector represents the classification of a reconstructed sample block into one of a plurality of sample intensity bands.

5. The filtering system of claim 1, wherein the classification of the reconstructed samples is derived from the intensity values ​​of co-samples, which are reconstructed from coded video data representing another color component of the source video.

6. The filtering system of claim 1, wherein the feature identification data from the feature detector represents the directional classification of the reconstructed sample.

7. The filtering system of claim 1, wherein the feature identification data from the feature detector represents the texture classification of the reconstructed sample.

8. The filtering system according to claim 1, wherein the feature identification data is derived from the prediction mode of the coded video data block, and the reconstructed sample is reconstructed from the coded video data block.

9. The filtering system according to claim 1, wherein the feature identification data is derived from the encoding parameters of the encoded video data block, and the reconstructed sample is reconstructed from the encoded video data block.

10. The filtering system according to claim 1, wherein The reconstructed samples are received from the output of the second filter of the video coding system, and The feature identification data is derived from the filtering parameters of the second filter.

11. The filtering system of claim 1, wherein the offset calculator is an N-way lookup table having a path corresponding to each of a plurality of candidate feature identifiers.

12. The filtering system of claim 11, wherein at least one entry of the lookup table is provided by the video encoder that generates the encoded video data.

13. The filtering system of claim 1, wherein the offset calculator is a computer that calculates the filter offset according to a parameter model, and the parameters of the parameter model are provided by a video encoder that generates the encoded video data.

14. A method comprising: Predetermined features of the input samples are detected from the input samples and from the output identifiers of the detected features. The input samples are reconstructed from coded video data representing the color components of the source video. The filter offset is estimated based on the predetermined features detected from the input samples and the output identifier. At least an offset index is generated based on the input sample, and The input samples reconstructed from the coded video data are filtered based on the estimated offset and the offset index applied to the color component.

15. The method of claim 14, wherein the feature is detected from the intensity of the input sample.

16. The method of claim 14, wherein the feature is detected in the classification from the reconstructed sample to one of a plurality of sample intensity bands.

17. The method of claim 14, wherein the feature is detected from the classification of a sample intensity band among a plurality of sample intensity bands from a reconstructed sample block.

18. The method of claim 14, wherein the feature is detected from the intensity values ​​of co-samples, the co-samples being reconstructed from coded video data representing another color component of the source video.

19. The method of claim 14, wherein the feature is detected from the directional classification of the reconstructed sample.

20. The method of claim 14, wherein the feature is detected from the texture classification of the reconstructed sample.

21. The method of claim 14, wherein the feature is detected from the prediction pattern of the coded video data block, and the reconstructed sample is reconstructed from the coded video data block.

22. The method of claim 14, wherein the feature is detected from the encoding parameters of the encoded video data block, and the reconstructed sample is reconstructed from the encoded video data block.

Images