Neural network video coding in-loop filtering in the transform domain

Abstract

A method for coding video data comprises the steps of: acquiring input data—input data including one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data—; converting the input data from an input domain to a transform domain to generate converted video data; applying a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and converting the filtered video data from the transform domain to an input domain.

Description

Technology Field

[0001] This application claims priority to U.S. Patent Application No. 18 / 987,925 filed December 19, 2024 and U.S. Provisional Patent Application No. 63 / 621,516 filed January 16, 2024, the entire contents of each of which are incorporated by reference. U.S. Patent Application No. 18 / 987,925 filed December 19, 2024 claims the benefit of U.S. Provisional Patent Application No. 63 / 621,516 filed January 16, 2024.

[0002] Technology field

[0003] The present disclosure relates to video encoding and video decoding. Background Technology

[0004] Digital video capabilities can be integrated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptops or desktop computers, tablet computers, e-book readers, digital cameras, digital recording devices, digital media players, video gaming devices, video game consoles, cellular or satellite radio phones, so-called "smartphones," video teleconferencing devices, video streaming devices, etc. Digital video devices implement video coding techniques such as those described in standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4, Part 10, Advanced Video Coding (AVC), and High Efficiency Video Coding (HEVC), and extensions of such standards. By implementing such video coding techniques, video devices can transmit, receive, encode, decode, and / or store digital video information more efficiently.

[0005] Video coding techniques include spatial (intra-image) prediction and / or temporal (inter-image) prediction to reduce or eliminate redundancy inherent to video sequences. For block-based video coding, a video slice (e.g., a video image, or a part of a video image) may be partitioned into video blocks, which may also be referred to as coding tree units (CTUs), coding units (CUs), and / or coding nodes. Video blocks in an intra-coded (I) slice of an image are encoded using spatial prediction for reference samples in neighboring blocks of the same image. Video blocks in an inter-coded (P or B) slice of an image may use spatial prediction for reference samples in neighboring blocks of the same image, or temporal prediction for reference samples in different reference images. Images may be referred to as frames, and reference images may be referred to as reference frames.

[0006] Generally, the present disclosure describes techniques for neural network-based in-loop filtering (NN-ILF) in video coding. As described herein, the techniques of the present disclosure can improve coding performance under complexity and memory requirement constraints. In modern convolutional neural network (CNN) in-loop filters, filtering is often performed in the YUV domain. This can result in a non-optimal design for certain dimensions and with respect to capturing signal correlations. The techniques of the present disclosure can mitigate the effects of non-optimality by introducing a transformation process to the input signals. Although the techniques described in this document relate to CNN-assisted loop filtering, they are applicable to any CNN-based video coding tool consuming input data having specific statistical properties. The techniques can be used in the context of advanced video codecs, such as extensions of Versatile Video Coding (VVC) or next-generation video coding standards, and any other video codecs.

[0007] In one example, the present disclosure describes a method for coding video data, the method comprising: acquiring input data—input data comprises one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data—; converting the input data from an input domain to a transform domain to generate converted video data; applying a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and converting the filtered video data from the transform domain to an input domain.

[0008] In another example, the present disclosure describes a device for coding video data, wherein the device comprises one or more memories for storing video data; and one or more processors implemented as circuits, wherein the one or more processors acquire input data—the input data comprises one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data—; convert the input data from an input domain to a transform domain to generate converted video data; apply a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and convert the filtered video data from the transform domain to an input domain.

[0009] In another example, the present disclosure describes one or more non-transient computer-readable storage media in which instructions are stored, the instructions, when executed by one or more processors, cause one or more processors to acquire input data—input data comprises one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data—; convert the input data from an input domain to a transform domain to generate converted video data; apply a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and convert the filtered video data from the transform domain to an input domain.

[0010] Details of one or more examples are described in the attached drawings and the description below. Other features, purposes, and advantages will be apparent from the description, drawings, and claims. Brief explanation of the drawing

[0011] FIG. 1 is a block diagram illustrating an exemplary video encoding and decoding system capable of performing the techniques of the present disclosure. FIGS. 2a and 2b are conceptual diagrams illustrating an exemplary quadtree binary tree (QTBT) structure and a corresponding coding tree unit (CTU). FIG. 3 is a block diagram illustrating an exemplary video encoder capable of performing the techniques of the present disclosure. FIG. 4 is a block diagram illustrating an exemplary video decoder capable of performing the techniques of the present disclosure. FIG. 5 is a flowchart illustrating an exemplary method for encoding a current block according to the techniques of the present disclosure. FIG. 6 is a flowchart illustrating an exemplary method for decoding a current block of video data according to the techniques of the present disclosure. Figure 7 is a conceptual diagram illustrating an example of hierarchical prediction structures having the same GOP size as 16. Figure 8 is a conceptual diagram illustrating a CNN (convolutional neural network)-based filter having four layers. Figure 9 is a conceptual diagram illustrating a CNN-based filter with padded input samples and supplementary data. Figure 10 is a conceptual diagram illustrating exemplary human visual and display capabilities. Figure 11 is a conceptual diagram illustrating an exemplary color gamut. Figure 12 is a conceptual diagram illustrating a CNN architecture. Figure 13 is a conceptual diagram illustrating a spatial attention layer of an attention residual block. Figure 14 is a conceptual diagram illustrating an exemplary CNN architecture. Figure 15 is a conceptual diagram illustrating an exemplary CNN architecture that includes filter blocks that do not contain bypass branches around convolution and activation layers. Figure 16 is a conceptual diagram illustrating an exemplary CNN architecture. Figure 17 is a conceptual diagram illustrating an exemplary multiscale feature extraction backbone network using 2-component convolution. FIG. 18 is a conceptual diagram illustrating an exemplary unified filter having a joint model (joint luminance and chroma). FIG. 19 is a conceptual diagram illustrating an exemplary unified filter having separate luminance / chroma models (lumas). FIG. 20 is a conceptual diagram illustrating an exemplary unified filter having separate luminance / chroma models (chroma). Figure 21 is a conceptual diagram illustrating a unified filter using luminance / chroma splitting. Figure 22 is a conceptual diagram illustrating an exemplary architecture for filtering in a transformation domain for low complexity filters. FIG. 23 is a flowchart illustrating an exemplary operation of a video coder according to one or more techniques of the present disclosure. Specific details for implementing the invention

[0012] Neural network (NN)-based intra-loop filtering (ILF) is a process in which a video encoder or video decoder uses a neural network to apply filters to input data, such as predicted video data, reconstructed video data, or other auxiliary video data, to generate filtered video data. The application of NN-based ILF can have several advantages over conventional intra-loop filtering processes, such as matrix-based adaptive loop filters (ALF), sample-adaptive offset (SAO) filtering, and deblocking filters. For example, an artificial neural network based on NN-based ILF filtering can be trained to filter reconstructed video data to generate more realistic video data and remove more artifacts than conventional filters.

[0013] However, there are several problems with NN-based ILF. For example, video data is typically generated and consumed in the RGB (red-green-blue) domain. That is, the colors of pixels are represented using red, green, and blue samples. However, video encoding and video decoding typically occur in the Y'CbCr domain. In this Y'CbCr domain, the color of a pixel is represented using a luminance value (Y') and two chroma values ​​(Cb, Cr). Therefore, to prepare video data for encoding, a video encoder converts video data in the RGB domain into video data in the Y'CbCr domain. Conversely, to prepare video data for consumption after decoding the encoded video data, a video decoder converts the decoded video data from the Y'CbCr domain into the RGB domain. In the Y'CbCr domain, the resolution of the Y' component may differ from the resolutions of the Cb and Cr components. For example, there may be four Y' samples for every Cb sample and every Cr sample. In other words, the Cb and Cr color components have half the spatial resolution of the Y' color component. As a result of differences in spatial resolution and other factors, the application of conventional in-loop filters, such as conventional NN-based in-loop filters, to video data in the Y'CbCr domain can lead to substandard performance and visible artifacts, particularly in high dynamic range or wide color gamut video signals.

[0014] The techniques of the present disclosure can solve these problems. According to one example of the present disclosure, a video coder (e.g., a video encoder or a video decoder) may acquire input data (e.g., generate, acquire, retrieve). The input data may include one or more of reconstructed video data or supplementary data (e.g., predicted video data, quantization parameter data, boundary intensity data, or prediction mode data). The prediction mode data may represent a prediction model of a block (e.g., intra-mode, unidirectional inter-prediction, bidirectional inter-prediction, etc.). The present disclosure uses the abbreviation IPB (Intra, Inter Prediction (uni / bi-prediction)) to represent a prediction mode. The video coder may convert the input data from an input domain to a transformation domain to generate converted video data. Subsequently, the video coder may apply an NN-based ILF to the converted video data to generate filtered video data. Next, the video coder can convert the filtered video data from the transform domain to the input domain. Converting the reconstructed video data from the input domain to the transform domain before applying the NN-based ILF can increase the performance of the video encoder or video data and avoid the introduction of visible artifacts.

[0015] FIG. 1 is a block diagram illustrating an exemplary video encoding and decoding system (100) capable of performing the techniques of the present disclosure. The techniques of the present disclosure generally relate to coding (encoding and / or decoding) video data. Generally, video data includes any data for processing video. Accordingly, video data may include raw, unencoded video, encoded video, decoded (e.g., reconstructed) video, and video metadata, such as signaling data.

[0016] As illustrated in FIG. 1, the system (100) includes a source device (102) that provides encoded video data to be decoded and displayed by a destination device (116) in this example. In particular, the source device (102) provides video data to the destination device (116) via a computer-readable medium (110). The source device (102) and the destination device (116) may include any of a wide range of devices, including desktop computers, notebook (i.e., laptop) computers, mobile devices, tablet computers, set-top boxes, telephone handsets, such as smartphones, televisions, cameras, display devices, digital media players, video gaming consoles, video streaming devices, broadcast receiver devices, etc. In some cases, the source device (102) and the destination device (116) may be equipped for wireless communication and thus may be referred to as wireless communication devices.

[0017] In the example of FIG. 1, the source device (102) includes a video source (104), memory (106), a video encoder (200), and an output interface (108). The destination device (116) includes an input interface (122), a video decoder (300), memory (120), and a display device (118). According to the present disclosure, the video encoder (200) of the source device (102) and the video decoder (300) of the destination device (116) may be configured to apply techniques for neural network-based in-loop filtering. Thus, the source device (102) represents an example of a video encoding device, while the destination device (116) represents an example of a video decoding device. In other examples, the source device and the destination device may include other components or arrangements. For example, the source device (102) may receive video data from an external video source, such as an external camera. Likewise, the destination device (116) may interface with an external display device rather than including an integrated display device.

[0018] The system (100) as illustrated in FIG. 1 is merely one example. In general, any digital video encoding and / or decoding device may perform techniques for neural network-based in-loop filtering. The source device (102) and the destination device (116) are merely examples of such coding devices in which the source device (102) generates coded video data for transmission to the destination device (116). The present disclosure refers to a "coding" device as a device that performs the coding (encoding and / or decoding) of data. Accordingly, the video encoder (200) and the video decoder (300) represent examples of coding devices, specifically a video encoder and a video decoder, respectively. In some examples, the source device (102) and the destination device (116) may operate in a substantially symmetric manner such that the source device (102) and the destination device (116) each include video encoding and decoding components. Accordingly, the system (100) can support unidirectional or bidirectional video transmission between a source device (102) and a destination device (116) for, for example, video streaming, video playback, video broadcasting, or video telephony.

[0019] Generally, a video source (104) represents a source of video data (i.e., raw, unencoded video data) and provides a sequential series of images (also referred to as “frames”) of video data to a video encoder (200) that encodes data for the images. The video source (104) of the source device (102) may include a video capture device such as a video camera, a video archive containing previously captured raw video, and / or a video feed interface for receiving video from a video content provider. As an additional alternative, the video source (104) may generate computer graphics-based data as source video, or as a combination of live video, archived video, and computer-generated video. In each case, the video encoder (200) encodes the captured, pre-captured, or computer-generated video data. The video encoder (200) may rearrange the images from the received order (sometimes referred to as “display order”) into a coding order for coding. A video encoder (200) can generate a bitstream containing encoded video data. Subsequently, the source device (102) can output the encoded video data onto a computer-readable medium (110) via an output interface (108) for reception and / or retrieval, for example, by an input interface (122) of a destination device (116).

[0020] The memory (106) of the source device (102) and the memory (120) of the destination device (116) represent general-purpose memories. In some examples, the memories (106, 120) may store raw video data, such as raw video from a video source (104) and raw decoded video data from a video decoder (300). Additionally or alternatively, the memories (106, 120) may store software instructions executable by, for example, the video encoder (200) and the video decoder (300), respectively. Although the memory (106) and the memory (120) are depicted separately from the video encoder (200) and the video decoder (300) in this example, it should be understood that the video encoder (200) and the video decoder (300) may also include internal memories for functionally similar or equivalent purposes. Furthermore, the memories (106, 120) may store encoded video data, for example, output from a video encoder (200) and input to a video decoder (300). In some examples, portions of the memories (106, 120) may be allocated as one or more video buffers for storing, for example, raw, decoded, and / or encoded video data.

[0021] The computer-readable medium (110) may represent any type of medium or device capable of transmitting encoded video data from a source device (102) to a destination device (116). In one example, the computer-readable medium (110) represents a communication medium that enables the source device (102) to transmit encoded video data directly to the destination device (116) in real time, for example, through a radio frequency network or a computer-based network. According to a communication standard such as a wireless communication protocol, an output interface (108) may modulate a transmission signal containing the encoded video data, and an input interface (122) may demodulate the received transmission signal. The communication medium may include any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network, such as the Internet. The communication medium may include routers, switches, base stations, or any other equipment that may be useful for facilitating communication from a source device (102) to a destination device (116).

[0022] In some examples, the source device (102) may output encoded data from the output interface (108) to the storage device (112). Similarly, the destination device (116) may access the encoded data from the storage device (112) through the input interface (122). The storage device (112) may include any of the various distributed or locally accessed data storage media, such as a hard drive, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile or non-volatile memory, or any other suitable digital storage media for storing encoded video data.

[0023] In some examples, the source device (102) may output the encoded video data to a file server (114) or other intermediate storage device capable of storing the encoded video data generated by the source device (102). The destination device (116) may access the stored video data from the file server (114) via streaming or download.

[0024] The file server (114) may be any type of server device capable of storing encoded video data and transmitting the encoded video data to a destination device (116). The file server (114) may represent a web server (e.g., for a website), a server configured to provide file transfer protocol services (such as FTP (File Transfer Protocol) or FLUTE (File Delivery over Unidirectional Transport) protocol), a CDN (content delivery network) device, an HTTP (hypertext transfer protocol) server, a MBMS (Multimedia Broadcast Multicast Service) or eMBMS (Enhanced MBMS) server, and / or a NAS (network attached storage) device. The file server (114) may additionally or alternatively implement one or more HTTP streaming protocols such as DASH (Dynamic Adaptive Streaming over HTTP), HLS (HTTP Live Streaming), RTSP (Real Time Streaming Protocol), HTTP dynamic streaming, etc.

[0025] The destination device (116) can access encoded video data from the file server (114) via any standard data connection including an internet connection. This may include a wireless channel (e.g., Wi-Fi connection), a wired connection (e.g., a digital subscriber line (DSL), a cable modem, etc.), or a combination of both, suitable for accessing encoded video data stored on the file server (114). The input interface (122) may be configured to operate according to any one or more of the various protocols discussed above, or other such protocols for retrieving media data, to retrieve or receive media data from the file server (114).

[0026] The output interface (108) and input interface (122) may represent wireless transmitters / receivers, modems, wired networking components (e.g., Ethernet cards), wireless communication components operating according to any of the various IEEE 802.11 standards, or other physical components. In examples where the output interface (108) and input interface (122) include wireless components, the output interface (108) and input interface (122) may be configured to transmit data, such as encoded video data, according to cellular communication standards such as 4G, 4G-LTE (Long-Term Evolution), LTE Advanced, 5G, etc. In some examples where the output interface (108) includes a wireless transmitter, the output interface (108) and the input interface (122) may be configured to transmit data, such as encoded video data, according to other wireless standards such as IEEE 802.11, IEEE 802.15 (e.g., ZigBee™), Bluetooth™ standards, etc. In some examples, the source device (102) and / or the destination device (116) may include individual system-on-a-chip (SoC) devices. For example, the source device (102) may include an SoC device for performing functions attributed to the video encoder (200) and / or the output interface (108), and the destination device (116) may include an SoC device for performing functions attributed to the video decoder (300) and / or the input interface (122).

[0027] The techniques of the present disclosure may be applied to video coding that supports any of various multimedia applications, such as over-the-air television broadcasts, cable television transmissions, satellite television transmissions, internet streaming video transmissions, e.g., DASH (dynamic adaptive streaming over HTTP), digital video encoded on a data storage medium, decoding of digital video stored on a data storage medium, or other applications.

[0028] The input interface (122) of the destination device (116) receives an encoded video bitstream from a computer-readable medium (110) (e.g., a communication medium, a storage device (112), a file server (114), etc.). The encoded video bitstream may include signaling information defined by a video encoder (200), which is also used by a video decoder (300), such as syntax elements having values ​​describing the processing and / or characteristics of video blocks or other coded units (e.g., slices, images, groups of images, sequences, etc.). A display device (118) displays the decoded images of the decoded video data to a user. The display device (118) may represent any of the various display devices, such as a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or other types of display devices.

[0029] Although not illustrated in FIG. 1, in some examples, the video encoder (200) and the video decoder (300) may each be integrated with an audio encoder and / or an audio decoder and may include suitable MUX-DEMUX units or other hardware and / or software to handle multiplexed streams containing both audio and video in a common data stream. Where applicable, the MUX-DEMUX units may follow the ITU H.223 multiplexer protocol or other protocols, such as UDP (user datagram protocol).

[0030] Each of the video encoder (200) and video decoder (300) may be implemented with any of the various suitable encoder and / or decoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When the techniques are partially implemented in software, the device may store instructions for the software on a suitable non-transient computer-readable medium and execute instructions in hardware using one or more processors to perform the techniques of the present disclosure. Each of the video encoder (200) and video decoder (300) may be included in one or more encoders or decoders, any one of which may be integrated as part of a combined encoder / decoder (CODE) in individual devices. A device including a video encoder (200) and / or a video decoder (300) may include an integrated circuit, a microprocessor, and / or a wireless communication device, such as a cellular phone.

[0031] The video encoder (200) and video decoder (300) may operate according to a video coding standard such as ITU-T H.265, also referred to as HEVC (High Efficiency Video Coding), or extensions thereof, such as multi-view and / or scalable video coding extensions. Alternatively, the video encoder (200) and video decoder (300) may operate according to other proprietary or industry standards, such as ITU-T H.266, also referred to as VVC (Versatile Video Coding). A draft of the VVC standard is "Versatile Video Coding (Draft 10)" by Bross et al., Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 18 th Meeting: by teleconference, 22 June - 1 July 2020, described in JVET-S2001-vA (hereinafter, "VVC Draft 10"). However, the techniques of the present disclosure are not limited to any specific coding standard.

[0032] Generally, the video encoder (200) and video decoder (300) can perform block-based coding of images. The term “block” generally refers to a structure containing data to be processed (e.g., to be encoded, to be decoded, or otherwise used in the encoding and / or decoding process). For example, a block may contain a two-dimensional matrix of samples of luminance and / or chrominance data. Generally, the video encoder (200) and video decoder (300) can code video data expressed in a YUV (e.g., Y, Cb, Cr) format. That is, rather than coding RGB (red, green, blue) data for samples of an image, the video encoder (200) and video decoder (300) can code luminance and chrominance components, wherein the chrominance components may include both red hue and blue hue chrominance components. In some examples, the video encoder (200) converts the received RGB-formatted data into a YUV representation before encoding, and the video decoder (300) converts the YUV representation into an RGB format. Alternatively, pre-processing and post-processing units (not shown) may perform these conversions.

[0033] The present disclosure may refer to the coding of images (e.g., encoding and decoding) to include a process of encoding or decoding data of images in general. Similarly, the present disclosure may refer to the coding of blocks of images, e.g., prediction and / or residual coding, to include a process of encoding or decoding data for blocks. An encoded video bitstream generally includes a series of values ​​for syntax elements representing partitioning and coding decisions (e.g., coding modes) of images into blocks. Accordingly, references to coding an image or block should generally be understood as coding values ​​for syntax elements forming the image or block.

[0034] HEVC defines various blocks including coding units (CUs), prediction units (PUs), and transform units (TUs). According to HEVC, a video coder (such as a video encoder (200)) partitions coding tree units (CTUs) into CUs according to a quadtree structure. That is, the video coder partitions the CTUs and CUs into four identical non-overlapping squares, and each node of the quadtree has either zero or four child nodes. Nodes without child nodes may be referred to as "leaf nodes," and the CUs of such leaf nodes may contain one or more PUs and / or one or more TUs. The video coder may further partition the PUs and TUs. For example, in HEVC, a residual quadtree (RQT) represents the partitioning of TUs. In HEVC, PUs represent inter-predicted data, while TUs represent residual data. Intra-predicted CUs include intra-predicted information such as intra-mode indications.

[0035] As another example, the video encoder (200) and video decoder (300) may be configured to operate according to VVC. According to VVC, the video encoder (e.g., video encoder (200)) partitions the image into multiple coding tree units (CTUs). The video encoder (200) may partition the CTUs according to a tree structure, such as a quadtree-binary tree (QTBT) structure or a Multi-Type Tree (MTT) structure. The QTBT structure eliminates the concepts of multiple partition types, such as the separation between CUs, PUs, and TUs in HEVC. The QTBT structure includes two levels: a first level partitioned according to quadtree partitioning, and a second level partitioned according to binary tree partitioning. The root node of the QTBT structure corresponds to a CTU. The leaf nodes of the binary trees correspond to coding units (CUs).

[0036] In an MTT partitioning structure, blocks can be partitioned using QT (quadtree) partitions, BT (binary tree) partitions, and one or more types of TT (triple tree) (also called TT (ternary tree)) partitions. A triple or ternary tree partition is a partition in which a block is divided into three sub-blocks. In some examples, a triple or ternary tree partition divides a block into three sub-blocks without dividing the original block through the center. The partitioning types in MTT (e.g., QT, BT, and TT) can be symmetric or asymmetric.

[0037] In some examples, the video encoder (200) and the video decoder (300) may use a single QTBT or MTT structure to represent each of the luminance and chrominance components, whereas in other examples, the video encoder (200) and the video decoder (300) may use two or more QTBT or MTT structures, such as one QTBT / MTT structure for the luminance component and another QTBT / MTT structure for both of the chrominance components (or two QTBT / MTT structures for each chrominance component).

[0038] The video encoder (200) and video decoder (300) may be configured to use quadtree partitioning, QTBT partitioning, MTT partitioning, or other partitioning structures per HEVC. For the purposes of explanation, the description of the techniques of the present disclosure is presented with respect to QTBT partitioning. However, it should be understood that the techniques of the present disclosure may also be applied to video coders configured to use quadtree partitioning or other types of partitioning.

[0039] In some examples, the CTU includes a coding tree block (CTB) of luminance samples, two corresponding CTBs of chroma samples of an image having three sample arrays, or a CTB of samples of an image coded using a monochrome image or three distinct color planes, and syntax structures used to code the samples. The CTB may be an NxN block of samples for some values ​​of N such that the partitioning of components into CTBs is partitioned. A component may be an array constituting an image in a 4:2:0, 4:2:2, or 4:4:4 color format, or a single sample from one of three arrays (luma and two chroma), or an array constituting an image in a monochrome format, or a single sample from an array. In some examples, the coding block is an MxN block of samples for some values ​​of M and N such that the partitioning of the CTB into coding blocks is partitioned.

[0040] Blocks (e.g., CTUs or CUs) can be grouped in various ways within an image. For example, a brick may refer to a rectangular area of ​​rows of CTUs within a specific tile in the image. A tile may be a rectangular area of ​​CTUs within a specific tile row and a specific tile column in the image. A tile column refers to a rectangular area of ​​CTUs having a width specified by syntax elements (e.g., in an image parameter set) and a height equal to the height of the image. A tile row refers to a rectangular area of ​​CTUs having a width equal to the width of the image and a height specified by syntax elements (e.g., in an image parameter set).

[0041] In some examples, a tile may be partitioned into multiple bricks, each of which may contain one or more CTU rows within the tile. A tile that is not partitioned into multiple bricks may also be referred to as a brick. However, a brick, which is a true subset of a tile, may not be referred to as a tile.

[0042] Bricks in an image can also be arranged into slices. A slice may be an integer number of bricks in an image that can be exclusively contained in a single network abstraction layer (NAL) unit. In some examples, a slice includes only a number of complete tiles or a consecutive sequence of complete bricks of a single tile.

[0043] The present disclosure may use "NxN" and "N by N," e.g., 16x16 samples or 16 by 16 samples, interchangeably to refer to the sample dimensions of a block (such as a CU or other video block) in terms of vertical and horizontal dimensions. Generally, a 16x16 CU will have 16 samples in the vertical direction (y = 16) and 16 samples in the horizontal direction (x = 16). Similarly, an NxN CU generally has N samples in the vertical direction and N samples in the horizontal direction, where N represents a non-negative integer value. Samples within a CU may be arranged in rows and columns. Furthermore, CUs do not necessarily have to have the same number of samples in the horizontal direction as in the vertical direction. For example, CUs may contain NxM samples, where M is not necessarily equal to N.

[0044] A video encoder (200) encodes video data for CUs and other information expressing prediction and / or residual information. The prediction information indicates how the CU will be predicted to form a prediction block for the CU. The residual information generally expresses the sample-by-sample differences between the samples of the CU before encoding and the prediction block.

[0045] To predict the CU, the video encoder (200) can generally form a prediction block for the CU through inter-prediction or intra-prediction. Inter-prediction generally refers to predicting the CU from data of a previously coded image, whereas intra-prediction generally refers to predicting the CU from data of the same image that was previously coded. To perform inter-prediction, the video encoder (200) can generate a prediction block using one or more motion vectors. The video encoder (200) can generally perform motion search to identify a reference block that closely matches the CU, for example, in terms of the differences between the CU and the reference block. The video encoder (200) can calculate a difference metric using SAD (sum of absolute difference), SSD (sum of squared differences), MAD (mean absolute difference), MSD (mean squared differences), or other such difference calculations to determine whether the reference block closely matches the current CU. In some examples, the video encoder (200) can predict the current CU using unidirectional prediction or bidirectional prediction.

[0046] Motion-compensated or inter-image prediction takes advantage of the redundancy existing between (and therefore "inter") images in a video sequence. In block-based motion compensation used in all modern video codecs, prediction is derived from one or more previously decoded images, i.e., reference image(s). Corresponding regions for generating inter prediction are indicated by motion information containing motion vectors and reference image indices.

[0047] Some examples of VVC also provide an affine motion compensation mode that can be considered as an inter-prediction mode. In an affine motion compensation mode, the video encoder (200) can determine two or more motion vectors representing non-translational motions such as zoom in or out, rotation, perspective motion, or other irregular motion types.

[0048] To perform intra-prediction, the video encoder (200) may select an intra-prediction mode to generate prediction blocks. Some examples of VVC provide 67 intra-prediction modes, including planar mode and DC mode, as well as various directional modes. Generally, the video encoder (200) selects an intra-prediction mode that describes neighbor samples for the current block (e.g., a block of CUs) to predict samples of the current block from it. Such samples may generally be located above, above and to the left of, or to the left of the current block in the same image as the current block, assuming that the video encoder (200) codes the CTUs and CUs in raster scan order (from left to right, from top to bottom).

[0049] Intra-image prediction utilizes spatial redundancy (hence "intra") present within an image by deriving predictions for a block from spatially neighboring samples (i.e., reference samples) that are already encoded—and subsequently decoded. Directional angle prediction, DC prediction, and planar or planar prediction are used in the most recent video codecs, including AVC, HEVC, and VVC.

[0050] The video encoder (200) encodes data representing the prediction mode for the current block. For example, in the case of inter-prediction modes, the video encoder (200) can encode motion information for the corresponding mode as well as data representing which of the various available inter-prediction modes is used. In the case of unidirectional or bidirectional inter-prediction, for example, the video encoder (200) can encode motion vectors using AMVP (advanced motion vector prediction) or a merge mode. The video encoder (200) can use similar modes to encode motion vectors for an affine motion compensation mode.

[0051] Following a prediction, such as an intra-prediction or inter-prediction of a block, the video encoder (200) may calculate residual data for the block. Residual data, such as a residual block, represents the sample-by-sample differences between the block formed using the corresponding prediction mode and the prediction block for the block. The video encoder (200) may apply one or more transformations to the residual block to generate transformed data in a transformation domain instead of a sample domain. For example, the video encoder (200) may apply a discrete cosine transform (DCT), an integer transform, a wavelet transform, or a conceptually similar transform to the residual video data. Additionally, the video encoder (200) may apply a secondary transform following the first transform, such as a mode-dependent non-separable secondary transform (MDNSST), a signal-dependent transform, or a Karhunen-Loeve transform (KLT). The video encoder (200) generates transformation coefficients following the application of one or more transformations.

[0052] Hybrid video coding standards apply block transforms to prediction residuals (regardless of whether they originate from inter- or intra-image prediction). Early standards, including H.261, H.262, and H.263, applied the discrete cosine transform (DCT) to the residual data. In HEVC and VVC, transform kernels other than or in addition to the DCT may be applied to account for different statistics in specific video signals.

[0053] As mentioned above, following any transformations to generate transformation coefficients, the video encoder (200) may perform quantization of the transformation coefficients. Quantization generally refers to a process in which the transformation coefficients are quantized to reduce the amount of data used to represent the transformation coefficients as much as possible, thereby providing additional compression. By performing the quantization process, the video encoder (200) may reduce the bit depth associated with some or all of the transformation coefficients. For example, during quantization, the video encoder (200) n -bit value m - You can round down by bit value, and here n silver m It is larger than. In some examples, to perform quantization, the video encoder (200) may perform a bitwise right-shift of the value to be quantized.

[0054] Quantization aims to reduce the precision of an input value or a set of input values ​​to decrease the amount of data required to represent the values. In hybrid video coding, quantization is typically applied to individual transformed residual samples, i.e., transform coefficients, resulting in integer coefficient levels. In recent video coding standards, the step size is derived from the so-called quantization parameter (QP), which controls fidelity and bit rate. A larger step size lowers the bit rate but also degrades quality, resulting in video images exhibiting, for example, blocking artifacts and blurred details.

[0055] Following quantization, the video encoder (200) may scan the transform coefficients to generate a one-dimensional vector from a two-dimensional matrix containing the quantized transform coefficients. The scan may be designed to place higher energy (and therefore lower frequency) transform coefficients at the front of the vector and lower energy (and therefore higher frequency) transform coefficients at the rear of the vector. In some examples, the video encoder (200) may generate a serialized vector using a predefined scan order for scanning the quantized transform coefficients, and then entropy-encode the quantized transform coefficients of the vector. In other examples, the video encoder (200) may perform an adaptive scan.

[0056] After scanning quantized transform coefficients to form a one-dimensional vector, the video encoder (200) can entropy-encode the one-dimensional vector according to, for example, context-adaptive binary arithmetic coding (CABAC). CABAC is used in recent video codecs, such as AVC, HEVC, and VVC, due to its high efficiency. The video encoder (200) can also entropy-encode values ​​for syntax elements describing metadata associated with the encoded video data for use by the video decoder (300) when decoding the video data. As part of performing CABAC, the video encoder (200) can assign a context within a context model to the symbol to be transmitted. The context may relate, for example, whether the neighbor values ​​of the symbol are zero values. Probability determination may be based on the context assigned to the symbol.

[0057] The video encoder (200) may additionally generate syntax data for the video decoder (300), such as block-based syntax data, image-based syntax data, and sequence-based syntax data, such as image headers, block headers, slice headers, or other syntax data, such as SPS (sequence parameter set), PPS (picture parameter set), or VPS (video parameter set). The video decoder (300) may likewise decode such syntax data to determine how to decode the corresponding video data.

[0058] In this way, the video encoder (200) can generate a bitstream containing encoded video data, such as syntax elements describing the partitioning of the image into blocks (e.g., CUs) and prediction and / or residual information for the blocks. Ultimately, the video decoder (300) can receive the bitstream and decode the encoded video data.

[0059] Generally, the video decoder (300) performs a reciprocal process to decode the encoded video data of the bitstream, which is performed by the video encoder (200). For example, the video decoder (300) can decode values ​​for the syntax elements of the bitstream using CABAC in a manner substantially similar but opposite to the CABAC encoding process of the video encoder (200). The syntax elements can define the CUs of the CTU by defining partitioning information for partitioning the image into CTUs and partitioning of each CTU according to a corresponding partition structure, such as a QTBT structure. The syntax elements can further define prediction and residual information for blocks of video data (e.g., CUs).

[0060] Residual information can be represented, for example, by quantized transform coefficients. The video decoder (300) can inversely quantize and inversely transform the quantized transform coefficients of the block to regenerate a residual block for the block. The video decoder (300) forms a prediction block for the block using a signaled prediction mode (intra- or inter-prediction) and associated prediction information (e.g., motion information for inter-prediction). Subsequently, the video decoder (300) can regenerate the original block by combining the prediction block and the residual block (on a sample-by-sample basis). The video decoder (300) can perform additional processing, such as performing a deblocking process, to reduce visual artifacts along the boundaries of the block.

[0061] The video encoder (200) and the video decoder (300) may apply an in-loop filter to input data such as predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, IPB data, or other types of video data. According to the technique of the present disclosure, the video encoder (200) may convert the input data from an input domain to a transform domain to generate converted video data. Subsequently, the video encoder (200) may apply an NN-based ILF to the converted video data to generate filtered video data. Subsequently, the video encoder (200) may convert the filtered video data from the transform domain to an input domain. The video decoder (300) may perform the same process on the reconstructed video data. The video encoder (200) and the video decoder (300) may use the filtered video data in the input domain for the prediction of subsequently encoded blocks of the video data. In examples where the conversion domain is the RGB domain and the input data contains reconstructed video data, the video decoder (300) can output video data filtered in the conversion domain.

[0062] The present disclosure may generally refer to "signaling" specific information, such as syntax elements. The term "signaling" may generally refer to the communication of values ​​for syntax elements and / or other data used to decode encoded video data. That is, the video encoder (200) may signal values ​​for syntax elements in a bitstream. Generally, signaling refers to generating values ​​in a bitstream. As mentioned above, the source device (102) may transmit the bitstream to the destination device (116) substantially in real time or non-real time, such as when storing syntax elements in the storage device (112) for subsequent retrieval by the destination device (116).

[0063] FIGS. 2a and 2b are conceptual diagrams illustrating an exemplary quadtree binary tree (QTBT) structure (130) and a corresponding coding tree unit (CTU) (132). Solid lines represent quadtree splits, and dotted lines represent binary tree splits. At each split (i.e., non-leaf) node of the binary tree, a flag is signaled to indicate which split type (i.e., horizontal or vertical) is used, where in this example 0 indicates a horizontal split and 1 indicates a vertical split. For quadtree splits, it is not necessary to indicate the split type, as quadtree nodes split blocks horizontally and vertically into four sub-blocks of the same size. Accordingly, the video encoder (200) can encode the syntax elements (e.g., partition information) for the region tree levels (i.e., solid lines) of the QTBT structure (130) and the syntax elements (e.g., partition information) for the prediction tree levels (i.e., dotted lines) of the QTBT structure (130), and the video decoder (300) can decode them. The video encoder (200) can encode the video data for the CUs represented by the end leaf nodes of the QTBT structure (130), such as prediction and transformation data, and the video decoder (300) can decode them.

[0064] Generally, the CTU (132) of FIG. 2b may be associated with parameters that define the sizes of blocks corresponding to the nodes of the QTBT structure (130) at the first and second levels. These parameters may include CTU size (representing the size of the CTU (132) in the samples), minimum quadtree size (MinQTSize representing the minimum allowed quadtree leaf node size), maximum binary tree size (MaxBTSize representing the maximum allowed binary tree root node size), maximum binary tree depth (MaxBTDepth representing the maximum allowed binary tree depth), and minimum binary tree size (MinBTSize representing the minimum allowed binary tree leaf node size).

[0065] The root node of the QTBT structure corresponding to the CTU may have four child nodes at the first level of the QTBT structure, each of which may be partitioned according to quadtree partitioning. That is, the nodes at the first level may be leaf nodes (having no child nodes) or have four child nodes. An example of the QTBT structure (130) represents such nodes as including parent nodes and child nodes with solid lines for branches. If the nodes at the first level are not larger than the maximum allowed binary tree root node size (MaxBTSize), the nodes may be further partitioned by their respective binary trees. The binary tree splitting of a node may be repeated until the nodes resulting from the split reach the minimum allowed binary tree leaf node size (MinBTSize) or the maximum allowed binary tree depth (MaxBTDepth). An example of the QTBT structure (130) represents such nodes as having dotted lines for branches. Binary tree leaf nodes are referred to as coding units (CUs) used for prediction (e.g., intra-image or inter-image prediction) and transformation without any additional partitioning. As discussed above, CUs may also be referred to as "video blocks" or "blocks".

[0066] In one example of a QTBT partitioning structure, the CTU size is set to 128x128 (luminance samples and two corresponding 64x64 chroma samples), MinQTSize is set to 16x16, MaxBTSize is set to 64x64, MinBTSize (for both width and height) is set to 4, and MaxBTDepth is set to 4. Quadtree partitioning is first applied to the CTU to generate quadtree leaf nodes. Quadtree leaf nodes can have sizes ranging from 16×16 (i.e., MinQTSize) to 128×128 (i.e., CTU size). If a quadtree leaf node is 128x128, the leaf quadtree node will not be further partitioned by the binary tree because its size exceeds MaxBTSize (i.e., 64x64 in this example). Otherwise, the quadtree node will be further partitioned by the binary tree. Thus, the quadtree leaf node is also the root node of the binary tree and has a binary tree depth of 0. When the binary tree depth reaches MaxBTDepth (4 in this example), no further partitioning is allowed. A binary tree node with a width equal to MinBTSize (4 in this example) implies that no further vertical partitioning (i.e., partitioning of width) is allowed for that binary tree node. Similarly, a binary tree node with a height equal to MinBTSize implies that no further horizontal partitioning (i.e., partitioning of height) is allowed for that binary tree node. As mentioned above, the leaf nodes of the binary tree are referred to as CUs and are further processed according to prediction and transformation without additional partitioning.

[0067] FIG. 3 is a block diagram illustrating an exemplary video encoder (200) capable of performing the techniques of the present disclosure. FIG. 3 is provided for illustrative purposes and should not be considered a limitation to the techniques as extensively illustrated and described in the present disclosure. For illustrative purposes, the present disclosure describes a video encoder (200) according to the techniques of VVC (ITU-T H.266, under development) and HEVC (ITU-T H.265). However, the techniques of the present disclosure may be performed by video encoding devices comprising other video coding standards.

[0068] In the example of FIG. 3, the video encoder (200) includes a video data memory (230), a mode selection unit (202), a residual generation unit (204), a conversion processing unit (206), a quantization unit (208), an inverse quantization unit (210), an inverse conversion processing unit (212), a reconstruction unit (214), a filter unit (216), a DPB (decoded picture buffer) (218), and an entropy encoding unit (220). Any or all of the video data memory (230), the mode selection unit (202), the residual generation unit (204), the conversion processing unit (206), the quantization unit (208), the inverse quantization unit (210), the inverse conversion processing unit (212), the reconstruction unit (214), the filter unit (216), the DPB (218), and the entropy encoding unit (220) may be implemented in one or more processors or in a processing circuit. For example, the units of the video encoder (200) may be implemented as one or more circuits or logic elements as part of a hardware circuit or as part of a processor, ASIC, or FPGA. In addition, the video encoder (200) may include additional or alternative processors or processing circuits to perform these and other functions.

[0069] The video data memory (230) can store video data to be encoded by the components of the video encoder (200). The video encoder (200) can receive video data stored in the video data memory (230) from, for example, a video source (104) (Fig. 1). The DPB (218) can serve as a reference image memory that stores reference video data for use in predicting subsequent video data by the video encoder (200). The video data memory (230) and the DPB (218) can be formed by any of the various memory devices, such as DRAM including SDRAM (synchronous DRAM), MRAM (magnetoresistive RAM), RRAM (resistive RAM), or other types of memory devices. The video data memory (230) and the DPB (218) can be provided by the same memory device or by separate memory devices. In various examples, the video data memory (230) may be on-chip with other components of the video encoder (200) or off-chip with respect to such components, as illustrated.

[0070] In the present disclosure, reference to the video data memory (230) should not be interpreted as being limited to memory inside the video encoder (200) or memory outside the video encoder (200) unless specifically described as such. Rather, reference to the video data memory (230) should be understood as a reference memory that stores video data received by the video encoder (200) for encoding (e.g., video data for the current block to be encoded). The memory (106) of FIG. 1 may also provide temporary storage of outputs from various units of the video encoder (200).

[0071] Various units of FIG. 3 are illustrated to aid in understanding the operations performed by the video encoder (200). The units may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Fixed-function circuits refer to circuits that provide specific functions and are pre-configured for the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks and provide flexible functions in the operations that can be performed. For example, programmable circuits may execute software or firmware that causes the programmable circuits to operate in a manner defined by instructions of the software or firmware. Fixed-function circuits may execute software instructions (e.g., to receive parameters or output parameters), but the types of operations performed by the fixed-function circuits are generally invariant. In some examples, one or more of the units may be separate circuit blocks (fixed-function or programmable), and in some examples, one or more of the units may be integrated circuits.

[0072] The video encoder (200) may include arithmetic logic units (ALUs), elementary function units (EFUs), digital circuits, analog circuits, and / or programmable cores formed from programmable circuits. In examples where the operations of the video encoder (200) are performed using software executed by the programmable circuits, memory (106) (FI. 1) may store instructions (e.g., object code) of the software that the video encoder (200) receives and executes, or another memory (not shown) within the video encoder (200) may store such instructions.

[0073] The video data memory (230) is configured to store received video data. The video encoder (200) can retrieve images of video data from the video data memory (230) and provide the video data to the residual generation unit (204) and the mode selection unit (202). The video data in the video data memory (230) may be raw video data to be encoded.

[0074] The mode selection unit (202) includes a motion estimation unit (222), a motion compensation unit (224), and an intra-prediction unit (226). The mode selection unit (202) may include additional function units to perform video prediction according to different prediction modes. As examples, the mode selection unit (202) may include a palette unit, an intra-block copy unit (which may be part of the motion estimation unit (222) and / or the motion compensation unit (224)), an affine unit, a linear model (LM) unit, etc.

[0075] The mode selection unit (202) generally adjusts a number of encoding passes to test combinations of encoding parameters and the resulting rate-distortion values ​​for such combinations. The encoding parameters may include partitioning of CTUs into CUs, prediction modes for CUs, transformation types for residual data of CUs, quantization parameters for residual data of CUs, etc. The mode selection unit (202) can ultimately select a combination of encoding parameters that has better rate-distortion values ​​than other tested combinations.

[0076] The video encoder (200) partitions the image retrieved from the video data memory (230) into a series of CTUs and can encapsulate one or more CTUs within a slice. The mode selection unit (202) can partition the CTUs of the image according to a tree structure, such as the quad-tree structure of HEVC or the QTBT structure described above. As described above, the video encoder (200) can form one or more CUs by partitioning the CTUs according to the tree structure. Such CUs may also generally be referred to as "video blocks" or "blocks".

[0077] Generally, the mode selection unit (202) also controls its components (e.g., motion estimation unit (222), motion compensation unit (224), and intra-prediction unit (226)) to generate a prediction block for the current block (e.g., the current CU, or, in HEVC, the overlapping portion of PU and TU). For inter-prediction of the current block, the motion estimation unit (222) can perform motion search to identify one or more closely matched reference blocks in one or more reference images (e.g., one or more previously coded images stored in DPB (218)). In particular, the motion estimation unit (222) can calculate a value expressing how similar a potential reference block is to the current block according to, for example, SAD (sum of absolute difference), SSD (sum of squared differences), MAD (mean absolute difference), MSD (mean squared difference), etc. The motion estimation unit (222) can generally perform these calculations using sample-by-sample differences between the reference block being considered and the current block. The motion estimation unit (222) can identify the reference block having the lowest value resulting from these calculations, which indicates the reference block that matches most closely with the current block.

[0078] The motion estimation unit (222) may form one or more motion vectors (MVs) that define the positions of reference blocks in reference images for the position of the current block in the current image. Subsequently, the motion estimation unit (222) may provide the motion vectors to the motion compensation unit (224). For example, for unidirectional inter-prediction, the motion estimation unit (222) may provide a single motion vector, whereas for bidirectional inter-prediction, the motion estimation unit (222) may provide two motion vectors. Subsequently, the motion compensation unit (224) may generate a prediction block using the motion vectors. For example, the motion compensation unit (224) may retrieve data of the reference block using the motion vectors. As another example, if the motion vector has fractional sample precision, the motion compensation unit (224) may interpolate values ​​for the prediction block according to one or more interpolation filters. In addition, for bidirectional inter-prediction, the motion compensation unit (224) retrieves data for two reference blocks identified by individual motion vectors and can combine the retrieved data, for example, through a sample-by-sample average or a weighted average.

[0079] As another example, for intra-prediction or intra-prediction coding, the intra-prediction unit (226) may generate prediction blocks from samples adjacent to the current block. For example, for directional modes, the intra-prediction unit (226) may generally generate prediction blocks by mathematically combining the values ​​of neighboring samples and populating these calculated values ​​across the current block in a defined direction. As another example, for DC mode, the intra-prediction unit (226) may calculate the average of neighboring samples for the current block and generate prediction blocks, including this resulting average for each sample of the prediction block.

[0080] The mode selection unit (202) provides the prediction block to the residual generation unit (204). The residual generation unit (204) receives the raw, unencoded version of the current block from the video data memory (230) and the prediction block from the mode selection unit (202). The residual generation unit (204) calculates the sample-by-sample differences between the current block and the prediction block. The resulting sample-by-sample differences define the residual block for the current block. In some examples, the residual generation unit (204) may also determine the differences between sample values ​​within the residual block to generate the residual block using residual differential pulse code modulation (RDPCM). In some examples, the residual generation unit (204) may be formed using one or more subtractor circuits that perform binary subtraction.

[0081] In examples where the mode selection unit (202) partitions the CUs into PUs, each PU may be associated with a luminance prediction unit and a corresponding chroma prediction unit. The video encoder (200) and the video decoder (300) may support PUs of various sizes. As indicated above, the size of the CU may refer to the size of the luminance coding block of the CU, and the size of the PU may refer to the size of the luminance prediction unit of the PU. Assuming that the size of a specific CU is 2Nx2N, the video encoder (200) may support PU sizes of 2Nx2N or NxN for intra prediction, and symmetric PU sizes such as 2Nx2N, 2NxN, Nx2N, NxN for inter prediction. The video encoder (200) and video decoder (300) can also support asymmetric partitioning for PU sizes of 2NxnU, 2NxnD, nLx2N, and nRx2N for inter-prediction.

[0082] In examples where the mode selection unit (202) does not further partition the CU into PUs, each CU may be associated with a luminance coding block and a corresponding chroma coding block. As above, the size of the CU may refer to the size of the luminance coding block of the CU. The video encoder (200) and the video decoder (300) may support CU sizes of 2N×2N, 2N×N, or N×2N.

[0083] For some examples, for other video coding techniques such as intra-block copy mode coding, affine mode coding, and LM (linear model) mode coding, the mode selection unit (202) generates a prediction block for the current block being encoded through individual units associated with the coding techniques. In some examples, such as palette mode coding, the mode selection unit (202) may not generate a prediction block and instead may generate syntax elements indicating a method of reconstructing the block based on a selected palette. In such modes, the mode selection unit (202) may provide these syntax elements to be encoded to the entropy encoding unit (220).

[0084] As described above, the residual generation unit (204) receives video data for the current block and the corresponding prediction block. Subsequently, the residual generation unit (204) generates a residual block for the current block. To generate the residual block, the residual generation unit (204) calculates the sample-by-sample differences between the current block and the prediction block.

[0085] The transformation processing unit (206) applies one or more transformations to the residual block to generate a block of transformation coefficients (referred to herein as a “transformation coefficient block”). The transformation processing unit (206) may form the transformation coefficient block by applying various transformations to the residual block. For example, the transformation processing unit (206) may apply a discrete cosine transform (DCT), a directional transformation, a Karhunen-Loeve transform (KLT), or a conceptually similar transformation to the residual block. In some examples, the transformation processing unit (206) may perform multiple transformations on the residual block, such as a first transformation and a second transformation, such as a rotation transformation. In some examples, the transformation processing unit (206) does not apply transformations to the residual block.

[0086] The quantization unit (208) can quantize the transformation coefficients within the transformation coefficient block to create a quantized transformation coefficient block. The quantization unit (208) can quantize the transformation coefficients of the transformation coefficient block according to the quantization parameter (QP) value associated with the current block. The video encoder (200) can adjust the degree of quantization applied to the transformation coefficient blocks associated with the current block by adjusting the QP value associated with the CU (e.g., via the mode selection unit (202)). Quantization can introduce a loss of information, and thus, the quantized transformation coefficients may have lower precision than the original transformation coefficients generated by the transformation processing unit (206).

[0087] The inverse quantization unit (210) and the inverse transform processing unit (212) can each apply inverse quantization and inverse transforms to the quantized transform factor block to reconstruct a residual block from the transform factor block. The reconstruction unit (214) can generate a reconstructed block corresponding to the current block (potentially having some degree of distortion) based on the prediction block generated by the mode selection unit (202) and the reconstructed residual block. For example, the reconstruction unit (214) can generate a reconstructed block by adding samples of the reconstructed residual block to corresponding samples from the prediction block generated by the mode selection unit (202).

[0088] The filter unit (216) may perform one or more filter operations on the reconstructed block. For example, the filter unit (216) may perform deblocking operations to reduce blockiness artifacts along the edges of the CU. According to the techniques of the present disclosure, the filter unit (216) may convert the reconstructed video data from an input domain to a transform domain to generate converted video data. The filter unit (216) may apply an NN-based ILF to the converted video data to generate filtered video data. Subsequently, the filter unit (216) may convert the filtered video data from the transform domain to an input domain.

[0089] The video encoder (200) stores the reconstructed blocks in the DPB (218). For example, in examples where the operations of the filter unit (216) are not performed, the reconstruction unit (214) may store the reconstructed blocks in the DPB (218). In examples where the operations of the filter unit (216) are performed, the filter unit (216) may store the filtered reconstructed blocks in the DPB (218). The motion estimation unit (222) and the motion compensation unit (224) may retrieve a reference image from the DPB (218), formed from the reconstructed (and potentially filtered) blocks, to inter-predict blocks of subsequently encoded images. Additionally, the intra-prediction unit (226) may use the reconstructed blocks in the DPB (218) of the current image to intra-predict other blocks within the current image.

[0090] Generally, the entropy encoding unit (220) can entropy encode syntax elements received from other functional components of the video encoder (200). For example, the entropy encoding unit (220) can entropy encode quantized transform factor blocks from the quantization unit (208). As another example, the entropy encoding unit (220) can entropy encode prediction syntax elements (e.g., intra-mode information for intra-prediction or motion information for inter-prediction) from the mode selection unit (202). The entropy encoding unit (220) can perform one or more entropy encoding operations on syntax elements, which are other examples of video data, to generate entropy-encoded data. For example, the entropy encoding unit (220) may perform a context-adaptive variable length coding (CAVLC) operation, a CABAC operation, a variable-to-variable length coding (V2V) operation, a syntax-based context-adaptive binary arithmetic coding (SBAC) operation, a probability interval partitioning entropy (PIPE) coding operation, an exponential-Golomb encoding operation, or other types of entropy encoding operations on the data. In some examples, the entropy encoding unit (220) may operate in a bypass mode where syntax elements are not entropy encoded.

[0091] The video encoder (200) can output a bitstream containing entropy-encoded syntax elements necessary to reconstruct blocks of an image or slice. In particular, the entropy encoding unit (220) can output the bitstream.

[0092] The actions described above are described with respect to blocks. Such descriptions should be understood as actions for Luma Coding Blocks and / or Chroma Coding Blocks. As described above, in some examples, Luma Coding Blocks and Chroma Coding Blocks are Luma and Chroma components of CU. In some examples, Luma Coding Blocks and Chroma Coding Blocks are Luma and Chroma components of PU.

[0093] In some examples, operations performed on a luminance coding block do not need to be repeated for a chroma coding block. As an example, operations to identify the motion vector (MV) and reference image for a luminance coding block do not need to be repeated to identify the MV and reference image for chroma blocks. Rather, the MV for the luminance coding block can be scaled to determine the MV for the chroma blocks, and the reference image can be the same. As another example, the intra-prediction process can be the same for the luminance coding block and the chroma coding block.

[0094] A video encoder (200) represents an example of a device configured to encode video data, the device comprising one or more memories configured to store video data and one or more processors implemented in circuitry, wherein the one or more processors are configured to convert video input data (e.g., reconstructed video data) from an input representation (i.e., input domain) to a conversion domain to generate converted video data; apply a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and convert the filtered video data to an input representation.

[0095] FIG. 4 is a block diagram illustrating an exemplary video decoder (300) capable of performing the techniques of the present disclosure. FIG. 4 is provided for illustrative purposes and is not a limitation to the techniques as extensively illustrated and described in the present disclosure. For illustrative purposes, the present disclosure describes a video decoder (300) according to the techniques of VVC (ITU-T H.266) and HEVC (ITU-T H.265). However, the techniques of the present disclosure may be performed by video coding devices comprising other video coding standards.

[0096] In the example of FIG. 4, the video decoder (300) includes a CPB (coded picture buffer) memory (320), an entropy decoding unit (302), a prediction processing unit (304), an inverse quantization unit (306), an inverse conversion processing unit (308), a reconstruction unit (310), a filter unit (312), and a DPB (decoded picture buffer) (314). Any or all of the CPB memory (320), the entropy decoding unit (302), the prediction processing unit (304), the inverse quantization unit (306), the inverse conversion processing unit (308), the reconstruction unit (310), the filter unit (312), and the DPB (314) may be implemented in one or more processors or in a processing circuit. For example, the units of the video decoder (300) may be implemented as one or more circuits or logic elements as part of a hardware circuit or as part of a processor, an ASIC, or an FPGA. In addition, the video decoder (300) may include additional or alternative processors or processing circuits to perform these and other functions.

[0097] The prediction processing unit (304) includes a motion compensation unit (316) and an intra-prediction unit (318). The prediction processing unit (304) may include additional units to perform predictions according to different prediction modes. As examples, the prediction processing unit (304) may include a palette unit, an intra-block copy unit (which may form part of the motion compensation unit (316)), an affine unit, a linear model (LM) unit, etc. In other examples, the video decoder (300) may include more, fewer, or different functional components.

[0098] The CPB memory (320) can store video data, such as an encoded video bitstream to be decoded by components of the video decoder (300). The video data stored in the CPB memory (320) can be obtained, for example, from a computer-readable medium (110) (Fig. 1). The CPB memory (320) may include a CPB that stores encoded video data (e.g., syntax elements) from the encoded video bitstream. Additionally, the CPB memory (320) can store video data other than the syntax elements of the encoded image, such as temporary data representing outputs from various units of the video decoder (300). The DPB (314) generally stores decoded images that the video decoder (300) can output and / or use as reference video data when decoding subsequent data or images of the encoded video bitstream. The CPB memory (320) and DPB (314) may be formed by any of the various memory devices, such as DRAM, MRAM, RRAM, or other types of memory devices including SDRAM. The CPB memory (320) and DPB (314) may be provided by the same memory device or by separate memory devices. In various examples, the CPB memory (320) may be on-chip with respect to other components of the video decoder (300) or off-chip with respect to such components.

[0099] Additionally or alternatively, in some examples, the video decoder (300) can retrieve coded video data from memory (120) (Fig. 1). That is, the memory (120) can store data as discussed above using CPB memory (320). Likewise, the memory (120) can store commands to be executed by the video decoder (300) when some or all of the functions of the video decoder (300) are implemented in software so that they are executed by the processing circuit of the video decoder (300).

[0100] The various units illustrated in FIG. 4 are exemplified to aid in understanding the operations performed by the video decoder (300). The units may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Similar to FIG. 3, fixed-function circuits refer to circuits that provide specific functions and are pre-configured for the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks and provide flexible functions in the operations that can be performed. For example, programmable circuits may execute software or firmware that causes the programmable circuits to operate in a manner defined by instructions of the software or firmware. Fixed-function circuits may execute software instructions (e.g., to receive parameters or output parameters), but the types of operations performed by the fixed-function circuits are generally invariant. In some examples, one or more of the units may be separate circuit blocks (fixed-function or programmable), and in some examples, one or more of the units may be integrated circuits.

[0101] The video decoder (300) may include ALUs, EFUs, digital circuits, analog circuits, and / or programmable cores formed from programmable circuits. In examples where the operations of the video decoder (300) are performed by software running on the programmable circuits, on-chip or off-chip memory may store instructions (e.g., object code) of the software that the video decoder (300) receives and executes.

[0102] The entropy decoding unit (302) receives encoded video data from the CPB and can regenerate syntax elements by entropy decoding the video data. The prediction processing unit (304), the inverse quantization unit (306), the inverse transform processing unit (308), the reconstruction unit (310), and the filter unit (312) can generate decoded video data based on the syntax elements extracted from the bitstream.

[0103] Generally, the video decoder (300) reconstructs the image on a block-by-block basis. The video decoder (300) can perform a reconstruction operation for each block individually (wherein the block currently being reconstructed, i.e., being decoded, may be referred to as the “current block”).

[0104] The entropy decoding unit (302) can entropy decode not only conversion information such as QP (quantization parameter) and / or conversion mode indication(s), but also syntax elements defining the quantized conversion coefficients of the quantized conversion coefficient block. The inverse quantization unit (306) can determine the degree of quantization and, similarly, the degree of inverse quantization for the inverse quantization unit (306) to be applied using the QP associated with the quantized conversion coefficient block. The inverse quantization unit (306) can perform a bit-by-bit left-shift operation to inversely quantize the quantized conversion coefficients, for example. By doing so, the inverse quantization unit (306) can form a conversion coefficient block containing the conversion coefficients.

[0105] After the inverse quantization unit (306) forms a transform factor block, the inverse transform processing unit (308) may apply one or more inverse transforms to the transform factor block to generate a residual block associated with the current block. For example, the inverse transform processing unit (308) may apply an inverse DCT, an inverse integer transform, an inverse KLT (Karhunen-Loeve transform), an inverse rotation transform, an inverse directional transform, or other inverse transforms to the transform factor block.

[0106] Furthermore, the prediction processing unit (304) generates a prediction block according to the prediction information syntax elements that were entropy-decoded by the entropy decoding unit (302). For example, if the prediction information syntax elements indicate that the current block is inter-predicted, the motion compensation unit (316) can generate a prediction block. In this case, the prediction information syntax elements may indicate a motion vector identifying the position of the reference block in the reference image as well as the position of the current block in the current image, as well as the reference image in the DPB (314) to retrieve the reference block. The motion compensation unit (316) can generally perform the inter-prediction process in a manner substantially similar to that described for the motion compensation unit (224) (Fig. 3).

[0107] As another example, if the prediction information syntax elements indicate that the current block is intra-predicted, the intra-predict unit (318) can generate a prediction block according to the intra-predict mode indicated by the prediction information syntax elements. Again, the intra-predict unit (318) can generally perform the intra-predict process in a manner substantially similar to that described for the intra-predict unit (226) (Fig. 3). The intra-predict unit (318) can retrieve data of neighbor samples for the current block from the DPB (314).

[0108] The reconstruction unit (310) can reconstruct the current block using the prediction block and the residual block. For example, the reconstruction unit (310) can reconstruct the current block by adding samples of the residual block to the corresponding samples of the prediction block.

[0109] The filter unit (312) may perform one or more filter operations on the reconstructed blocks. For example, the filter unit (312) may perform deblocking operations to reduce blockiness artifacts along the edges of the reconstructed blocks. According to the techniques of the present disclosure, the filter unit (312) may convert input data, such as predicted video data, reconstructed video data, or other types of video data from an input domain to a transformation domain to generate converted video data. Additionally, the filter unit (312) may apply an NN-based ILF to the converted video data to generate filtered video data. The filter unit (312) may convert the filtered video data from the transformation domain to an input domain.

[0110] The video decoder (300) can store filtered reconstructed blocks in the DPB (314). For example, in examples where the operations of the filter unit (312) are not performed, the reconstruction unit (310) can store the reconstructed blocks in the DPB (314). In examples where the operations of the filter unit (312) are performed, the filter unit (312) can store the filtered reconstructed blocks in the DPB (314). As discussed above, the DPB (314) can provide reference information, such as samples of the current image for intra-prediction and previously decoded images for subsequent motion compensation, to the prediction processing unit (304). Furthermore, the video decoder (300) can output decoded images (e.g., decoded video) from the DPB (314) for subsequent presentation on a display device such as the display device (118) of FIG. 1.

[0111] In this way, the video decoder (300) represents an example of a video decoding device, the video decoding device comprising one or more memories configured to store video data and one or more processors implemented in circuitry, and the one or more processors are configured to convert video input data (e.g., reconstructed video data, predicted video data, QP data, BS data, IPB data, etc.) from an input representation (i.e., input domain) to a conversion domain to generate converted video data; apply a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and convert the filtered video data to an input representation.

[0112] FIG. 5 is a flowchart illustrating an exemplary method for encoding a current block according to the techniques of the present disclosure. The current block may include a current CU. Although a video encoder (200) (Fig. 1 and Fig. 3) has been described, it should be understood that other devices may be configured to perform a method similar to that of FIG. 5.

[0113] In this example, the video encoder (200) initially predicts the current block (350). For instance, the video encoder (200) can form a predicted block for the current block. Subsequently, the video encoder (200) can calculate a residual block for the current block (352). To calculate the residual block, the video encoder (200) can calculate the difference between the original uncoded block and the predicted block for the current block. Subsequently, the video encoder (200) can transform the residual block and quantize the transformation coefficients of the residual block (354). Next, the video encoder (200) can scan the quantized transformation coefficients of the residual block (356). During or following the scan, the video encoder (200) can entropy-encode the transformation coefficients (358). For example, the video encoder (200) can encode the transformation coefficients using CAVLC or CABAC. Then, the video encoder (200) can output the entropy-encoded data of the block (360).

[0114] Additionally, the video encoder (200) can reconstruct the video data (362). In one example, the video encoder (200) can obtain residual data by applying inverse quantization to the quantized transform coefficients and applying inverse transformation to the inverse quantized transform coefficients. The video encoder (200) can add samples of prediction blocks to the corresponding samples of residual data to reconstruct the video data.

[0115] The video encoder (200) may apply an in-loop filter to input data, such as reconstructed video data (364). According to the technique of the present disclosure, the video encoder (200) may convert the input data from an input domain to a transform domain to generate converted video data. Subsequently, the video encoder (200) may apply an NN-based ILF to the converted video data to generate filtered video data. Subsequently, the video encoder (200) may convert the filtered video data from the transform domain to an input domain. The video encoder (200) may use the filtered video data to predict subsequent encoded blocks of the video data.

[0116] FIG. 6 is a flowchart illustrating an exemplary method for decoding a current block of video data according to the techniques of the present disclosure. The current block may include a current CU. Although a video decoder (300) (Fig. 1 and FIG. 4) has been described, it should be understood that other devices may be configured to perform a method similar to that of FIG. 6.

[0117] The video decoder (300) can receive entropy-encoded data for the current block, such as entropy-encoded prediction information and entropy-encoded data for the transformation coefficients of the residual block corresponding to the current block (370). The video decoder (300) can entropy-decode the entropy-encoded data to determine the prediction information for the current block and regenerate the transformation coefficients of the residual block (372). The video decoder (300) can predict the current block using an intra- or inter-prediction mode, such as indicated by the prediction information for the current block, to calculate the prediction block for the current block (374). Subsequently, the video decoder (300) can back-scan the regenerated transformation coefficients to generate a block of quantized transformation coefficients (376). Next, the video decoder (300) can inversely quantize the transform coefficients and apply the inverse transform to the transform coefficients to generate a residual block (378). The video decoder (300) can decode the current block by combining the prediction block and the residual block (380). In other words, the video decoder (300) can generate reconstructed video data based on the prediction block and the residual block. For example, the video decoder (300) can add samples from the prediction block to the corresponding samples of the residual block to generate samples of the reconstructed video data.

[0118] Additionally, the video decoder (300) may apply an in-loop filter to input data such as reconstructed video data (382). According to the technique of the present disclosure, the video decoder (300) may convert the input data from an input domain to a transform domain to generate converted video data. Subsequently, the video decoder (300) may apply an NN-based ILF to the converted video data to generate filtered video data. Subsequently, the video decoder (300) may convert the filtered video data from the transform domain to an input domain. The video decoder (300) may use the filtered video data to predict subsequent encoded blocks of the video data.

[0119] All video coding standards since H.261 have been based on the so-called hybrid video coding principles exemplified in Fig. 3. The term "hybrid" refers to the combination of two means to reduce redundancy in a video signal: predictive and transform coding and the quantization of predictive residuals. While predictive and transform coding reduce redundancy in the video signal through decorrelation, quantization reduces the data in the transform coefficient representation by reducing their precision, ideally by removing only irrelevant details. These hybrid video coding design principles are also used in the two most recent standards, HEVC and VVC. Block partitioning is used to divide the image into smaller blocks for the operation of the predictive and transform processes. Early video coding standards used a fixed block size, typically 16×16 samples. Recent standards, such as HEVC and VVC, utilize tree-based partitioning structures to provide flexible partitioning.

[0120] In recent video codecs, hierarchical prediction structures within a group of pictures (GOP) are applied to improve coding efficiency. FIG. 7 is a conceptual diagram illustrating an example of a hierarchical prediction structure (700) having the same GOP size as 16. In the example of FIG. 7, each of the quadrilateral shapes corresponds to a separate image. Arrows pointing from the first image to the second image indicate that the decoding of the second image depends on the decoding of the first image. For example, to decode image B1, it may be necessary to decode images I0 and B2.

[0121] Post-loop filtering and in-loop filtering are filtering processes (or combinations of such processes) applied to reconstructed images or other video data to reduce coding artifacts. The input to the filtering process is typically a reconstructed image, which is a combination of the reconstructed residual signal (including quantization error) and the prediction. As illustrated in FIG. 3, the reconstructed images after in-loop filtering are stored and used as a reference for inter-image prediction of subsequent images. Coding artifacts are mostly determined by QPs. Therefore, QP information is generally used in the design of the filtering process. In HEVC, in-loop filters include deblocking filtering and SAO (sample adaptive offset) filtering. In the VVC standard, an ALF (adaptive loop filter) was introduced as a third filter. The filtering process of the ALF is represented by Equation (1) below:

[0122]

[0123] In mathematical formula (1), is the position before the filtering process is applied ( i , j It is a sample from ), and is the position after the filtering process ( i , jIt is a sample value from ), and represents the filter coefficients, is a clipping function, and represents the clipping parameter. The variables k and l are class It changes in between, and here L represents the filter length. The filter length is the number of values ​​that can be used to determine the output value. Clipping function is, and this is a function It corresponds to. The clipping operation introduces a nonlinearity that makes ALF more efficient by reducing the influence of neighboring sample values ​​that are too different from the current sample value. In other words, the output value generated by the clipping function has discontinuous and non-differentiable corners at the upper and lower boundaries of the clipping function. In VVC, filtering parameters can be signaled in the bitstream, or filtering parameters can be selected from a plurality of predefined filter sets. The ALF filtering process can also be summarized as follows.

[0124]

[0125] Many studies demonstrate that embedding neural networks into hybrid video coding frameworks can improve compression efficiency. Neural networks have been used for intra-prediction and inter-prediction to improve prediction efficiency. Neural network (NN)-based in-loop filtering has also been a prominent research topic recently. In some studies, the filtering process is applied as a post-filter. In these cases, the filtering process is applied only to the output image, and the unfiltered images are used as reference images.

[0126] In some examples, a video coder (e.g., a video encoder or a video decoder) may apply NN-based filters in addition to existing filters such as deblocking filters, SAO, and ALF. In some examples, the video coder may apply NN-based filters exclusively, where the NN-based filters are designed to replace all existing filters.

[0127] An example of a NN-based filter is illustrated in FIG. 8. FIG. 8 is a conceptual diagram illustrating a CNN-based filter (800) having four layers (802A, 802B, 802C, and 802D). The present disclosure collectively refers to the layers (802A, 802B, 802C, and 802D) as "layers (802)". Each of the layers (802A, 802B, and 802C) includes a convolutional layer and a PreLU activation function layer. Each of the convolutional layers applies a convolution function. The hidden layers may include layers that perform convolutions, pooling layers, fully connected layers, normalization layers, and layers of other types. Layer (802D) has a convolutional layer and does not have an activation function layer. The present disclosure relates to convolutional layers. a x b x c x d Notation is used. In this notation, a and b represents the dimensions of the kernel (i.e., a 2D array of features), and c represents the number of input channels per feature of the feature map, and drepresents the number of output channels. Thus, in FIG. 8, the notation 3x3x6x8 in the convolutional layer of layer (802A) has a 3x3 kernel (i.e., the convolutional neural network is applied to a 3x3 grid of features), and each feature has 6 input channels (e.g., 4 Y' samples, 1 Cb sample, and 1 Cr sample) and 8 output channels. Thus, the convolutional layer of layer (802A) outputs 8 values.

[0128] In one example of FIG. 8, there is a 4:1 relationship between the luminance samples and the Cb or Cr chroma samples. Therefore, in the example of FIG. 8, the NN-based filtering process takes reconstructed luminance and chroma samples (804) packed into a 3D volume having six planes (i.e., four planes of luminance samples, a plane of Cb samples, and a plane of Cr samples). Layers (802) output intermediate samples. Intermediate samples are residual values ​​that are added back to the input reconstructed luminance and chroma samples (804) to generate refined input samples (806). The NN-based filter can use all color components as inputs to utilize cross-component correlations. Different components may share the same filters (including network structures and model parameters), or each component may have its own specific filters.

[0129] The NN-based filtering process can also be generalized as shown in the following mathematical equation (3):

[0130]

[0131] The model structures and model parameters of the NN-based filters can be predefined and stored in the video encoder (200) and video decoder (300). The model structures and / or model parameters of the NN-based filters can also be signaled in the bitstream.

[0132] When NN-based filtering is applied in video coding, the video coder can divide the entire video signal (pixel data) into one or more processing units (e.g., 2D blocks). The video coder can process each processing unit individually or in combination with other information associated with these blocks of pixels. Possible choices for the processing units may include frames, slices / tiles, CTUs, or any predefined or signaled shapes and sizes.

[0133] To further improve the performance of NN-based filtering, input data of different types may be jointly processed to generate a filtered output. The input data may include (but is not limited to) reconstructed, predicted pixels, pixels after loop filter(s), partitioning structure information, deblocking parameters (BS), QP values, slice or image type or filter applicability, or coding mode maps. The input data may be provided at different granularities. Luma reconstruction and prediction samples may be provided at the original resolution, while chroma samples may be provided at a lower resolution, for example, for 4:2:0 representation, or upsampled to the luminance resolution to achieve per-pixel representation. Similarly, QP, BS, partitioning, or coding mode information may be provided at a lower resolution, including cases where there is a single value per frame / slice or processing block (e.g., QP), or these values ​​may be expanded (duplicated) to achieve per-pixel representation.

[0134] FIG. 9 is a conceptual diagram illustrating a CNN-based filter (900) having padded input samples and supplementary data. An example of an architecture utilizing supplementary data is illustrated in FIG. 9. Pixels of a processing block (902) (four sub-blocks of interlaced luminance sample planes and associated Cb and Cr planes) are combined with supplementary information such as QP stages and BS. The area of ​​the processing pixels (i.e., the block of pixels being processed) can be extended by four padded pixels from each side. The total size of the processing volume is (4+64+4) x (4+64+4) x (4 Y+2UV+1 QP + 3 BS), i.e., 72x72x10. In other words, the input to the CNN-based filter (900) is a 64x64 block of pixels padded by four pixels on the top and bottom, left and right (i.e., 4+64+4). Each pixel is associated with 10 channels, namely 4 Y samples and 2 UV samples per pixel, plus 1 QP, plus 3 boundary intensity values. A first convolutional layer (904) is applied to a 3x3 array of pixels in the input, resulting in K values ​​for each of the 3x3 arrays. A final convolutional layer (906) outputs residual video data that is added to the original video data to obtain filtered video data (910).

[0135] To further improve the performance of NN-based filtering, multi-mode solutions may be designed. For example, for each processing unit, the video encoder (200) may select from a set of modes based on rate-distortion optimization, and the selection may be signaled in the bitstream. The set of modes may include different NN models, different values ​​used as input information for the NN models, etc. The video decoder (300) may use the selected mode for NN-based filtering. As an example, an NN-based filtering solution was previously proposed that generated multiple modes based on a single NN model by using different QP values ​​as inputs to the NN models for different modes.

[0136] Next-generation video applications are expected to represent captured landscapes with HDR (high dynamic range) and WCG (wide color gamut) expressions and operate with video data sourced from dedicated content creation software, such as CGI (computer-generated imagery) or camera capture content.

[0137] Dynamic range is typically defined as the ratio between the minimum and maximum brightness of a video signal. It is also measured in terms of 'f-stops,' where one f-stop corresponds to a doubling of the signal's dynamic range. In the MPEG definition, high dynamic range content is content characterized by brightness fluctuations exceeding 16 f-stops. In some terms, levels between 10 and 16 f-stops are considered intermediate dynamic range, but in other definitions, they may be considered HDR. At the same time, the human visual system can perceive a much larger dynamic range, but it includes adaptation mechanisms to narrow the so-called dynamic range.

[0138] Current video applications and services are defined by Rec.709 and typically support SDR, a brightness (or luminance) range of approximately 0.1 to 100 cd (candelas) per m2 (often referred to as "nits"), providing SDR that results in fewer than 10 f-stops. Next-generation video services are expected to provide dynamic ranges of up to 16 f-stops, and while detailed specifications are currently under development, some initial parameters were specified in SMPTE-2084 and Rec.2020.

[0139] A visualization of the dynamic range provided by the SDR (1000) of HDTV, the expected HDR (1002) of UHDTV (ultrahigh definition television), and the dynamic range of the human visual system (1004) is illustrated in FIG. 10. FIG. 10 is a conceptual diagram illustrating exemplary human visual and display capabilities.

[0140] Another aspect for a more realistic video experience beyond HDR is the color dimension, which is traditionally defined by the color gamut. Fig. 11 is a conceptual diagram illustrating an exemplary color gamut. Fig. 11 visualizes the SDR color gamut (1100) (a triangle based on the BT.709 color red, green, and blue primary colors), and a wider color gamut for UHDTV (a triangle based on the BT.2020 color red, green, and blue primary colors). The figure also depicts so-called spectral locus (demarcated by tongue-shaped areas) representing the limits of natural colors. As illustrated by Fig. 11, the transition from the BT.709 color primarys to the BT.2020 color primarys aims to provide over 70% of colors to UHDTV services. Point D65 specifies the white color for a given standard.

[0141] Some examples of color gamut standards are shown in Table 1 below.

[0142] [Table 1]

[0143]

[0144] RGB data is used as input because it is typically generated by image capturing sensors. However, this color space has high redundancy among its components and is not optimal for compact representation. To achieve a more compact and robust representation, RGB components are typically converted to a less correlated color space, such as YCbCr, which is more suitable for compression. This color space separates brightness in the form of luminance and color information from different uncorrelated components.

[0145] For modern video coding systems, the commonly used color space is ITU-R BT.709 or YCbCr as specified in ITU-R BT.709. The YCbCr color space in the BT.709 standard specifies the following conversion process from R'G'B' to Y'CbCr (non-constant luminance representation):

[0146]

[0147] The above mathematical expressions can also be implemented using the following approximate conversion that avoids partitioning for the Cb and Cr components:

[0148]

[0149] The ITU-R BT.2020 standard specifies the following conversion process from R'G'B' to Y'CbCr (non-constant luminance representation):

[0150]

[0151] The above mathematical formulas (5) can also be implemented using the following approximate conversion that avoids splitting for the Cb and Cr components:

[0152]

[0153] It should be noted that both color spaces remain in a normalized state. Therefore, for input values ​​normalized in the range 0...1, the resulting values ​​will be mapped to the range 0..1. In general, color transformations implemented with floating-point accuracy provide perfect reconstruction, and thus this process is lossless.

[0154] The following section presents examples of CNN In-Loop Filtering (ILF) architectures being actively developed at JVET.

[0155] FIG. 12 is a conceptual diagram illustrating a CNN architecture (1200). In "EE1-1.7: Combined Test of EE1-1.6 and EE1-1.3" by Y. Li et al., JVET-Z0113, April 2022 (hereinafter JVET-Z0113), a NN-based filtering solution having multiple modes was proposed. The architecture (1200) of the network is illustrated in FIG. 12. In the first part (Fig. 12), different input data types (i.e., reconstructed video data (rec), predicted video data (pred), boundary intensity values ​​(BS), partitioning data (part), and quantization parameter (QP) data) are convolved with a kernel size of 3x3 (represented in Fig. 12 as rectangles labeled conv3x3) to generate feature maps and undergo activation (represented in Fig. 12 as rectangles labeled PReLU, which represents a parameterized linear unit activation function). Partitioning data indicates how blocks are partitioned. The label Conv 3x3,2↓ indicates down-sampling of 2 by using a stride of 2. The results (1202) for each data type are concatenated, fused, and subsampled once to generate the output y. The number of feature maps used in JVET-Z0113 is 96. Subsequently, these outputs are supplied through N=8 attention residual blocks (1204) (AttRes blocks). The structure of an exemplary attention residual block (1206) is further illustrated in FIG. 12. As illustrated, the attention residual block (1206) includes a first convolution layer, an activation layer, a second convolution layer, and a spatial attention layer.

[0156] The output from the last attention residual block z is fed to the last part of the network, which includes a first set of convolutional layers, an activation layer, additional convolutional layers, and a pixel shuffle layer. The pixel shuffle layer rearranges elements within a tensor to perform upsampling, for example, to increase spatial resolution. In the context of architecture (1200) and other architectures described in this disclosure, the pixel shuffle layer performs upsampling by converting data from the channel domain to the spatial domain. The output of the pixel shuffle layer is added to the reconstructed video data to generate the output of the CNN architecture (1200).

[0157] FIG. 13 is a conceptual diagram illustrating a spatial attention layer (1300) of attention residual blocks. FIG. 13 illustrates that attention can be performed using element-wise multiplication from input features to extracted features of each backbone block.

[0158] In S. Eadie, M. Coban, M. Karczewicz, EE1-1.9: Reduced complexity CNN-based in-loop filtering, JVET-AC0155, January 2023 (hereinafter, "JVET-AC0155"), an alternative design of a NN architecture was proposed. It was proposed to use a larger number of low-complexity residual blocks in the backbone of the JVET-Z0113 CNN filter, along with a reduced number of channels (feature maps) and the removal of attention modules. The proposed CNN filtering structure (for luminance filtering) is illustrated in FIG. 14. FIG. 14 is a conceptual diagram illustrating an exemplary CNN architecture (1400).

[0159] In the CNN architecture (1400), the number of residual blocks used is M=24. The number of feature maps (convolutions) is reduced to 64. The CNN architecture (1400) includes residual blocks (ResBlocks) (1402). In the ResBlocks (1402), the number of channels first goes up to 160 before the activation layer and then goes down to 64 after the activation layer. Residual block (1404) is an example of residual blocks (1402). The number of residual blocks and channels can be configured differently for different performance-complexity trade-offs (M is set to a different value, and the number of channels in the residual blocks can be set to a number different from 160). Chroma filtering follows the concept in JVET-Z0113, reflecting the above modifications to its backbone for processing chroma channels.

[0160] In further modifications, bypass branches around the convolution and activation layers within the residual block of the previous solution are removed. FIG. 15 is a conceptual diagram illustrating an exemplary CNN architecture (1500) that includes filter blocks (1502) that do not contain bypass branches around the convolution and activation layers. Thus, in the example of FIG. 15, the filter block (1504) may have the same layers as the residual block (1404) but does not contain bypass branches. The number of channels and the number of filter blocks may be configurable, for example, 64 channels, 24 filter blocks, and 160 channels before and after activation, which results in a network complexity of 605.93 kMAC and a number of parameters of 1.5M for the intraluminal model.

[0161] Further reduction in complexity of the CCN ILF architecture is achieved by using separable convolutions instead of 2D convolutions (3x3), as described in U.S. Provisional Patent Application No. 63 / 485,862, filed on February 17, 2023, converted to U.S. Patent Application No. 18 / 442,955, and published in U.S. Patent Publication No. 2024 / 0283925. In Seregin et al.'s "EE2: Summary report of exploration experiment on enhanced compression beyond VVC capability" JVET-AD0023 (hereinafter "JVET-AD0023"), EE1 test 1.3.5, a low-rank convolution approximation that decomposes a 3x3xMxN convolution into a pixel-wise convolution (1x1xMxR), two separable convolutions (3x1xRxR, 1x3xRxR), and another pixel-wise convolution (1x1xRxN) was applied to the residual block of the architecture described in JVET-AC0155. Here, R is the rank of the approximation, which can ablate the performance / complexity of the approximation.

[0162] In one example, the CNN architecture (1500) of FIG. 15 using the decomposition illustrated in FIG. 16 is implemented with parameters K=64, M=160 and R=51, and a total of 24 residual blocks result in a network complexity of 356.43 kMAC and a number of parameters of 1.07 M for an intraluminal model. K and M are channels (input or output). R is the rank of the decomposition. FIG. 16 is a conceptual diagram illustrating an exemplary CNN architecture (1600). In the example of FIG. 16, the last convolutional layer (1602) of the filter block (1504) includes a first convolutional layer (1604) and a second convolutional layer (1606).

[0163] In Y. Li, S. Eadie, D. Rusanovskyy, M. Karczewicz, EE1-Related: Combination test of EE1-1.3.5 and multi-scale component of EE1-1.6, JVET-AD0211, April 2023 (hereinafter, "JVET-AD0211"), multi-scale feature extraction using a 2-component convolution network is proposed, which is exemplified in FIG. 17, wherein 3x3 convolutions are decomposed into 3x1xC1xR convolutions followed by 1x3xRxC2 convolutions, where C1 and C2 are the number of input and output channels, respectively, and R is the rank of approximation. FIG. 17 is a block diagram illustrating an exemplary multi-scale feature extraction backbone network (1700) using 2-component convolutions. The parameter R can be created proportionally to R=C1xC2 / (C1+C2) and controls the complexity of the approximation.

[0164] As an example, the architecture illustrated in Fig. 17 can be implemented with parameters R1 = 8, R2 = 44, M1 = 160 and M2 = 16, and a total of 24 residual blocks, and for the intraluminal model, the complexity of the network will be 358.43 kMAC and the number of parameters is 1.07 M. M1 and M2 are input channels, and R is the rank of decomposition.

[0165] A multiscale feature extraction backbone using 2-component decomposition was integrated into a unified model in EE. Additionally, the specification from EE includes two versions of the model, which are 1) a unified model for combined luminance and chroma (see FIG. 18), and 2) separate models for luminance and chroma (see FIG. 19 and FIG. 20, respectively). FIG. 18 is a conceptual diagram illustrating an exemplary unified filter having a joint model (1800) (joint luminance and chroma). In the example of FIG. 18, the inputs to the joint model (1800) are reconstructed Y samples (RecEXT Y), reconstructed UV samples (Rec EXT It includes UV), prediction modes (IPB) indicating the prediction mode of each block (e.g., intra prediction, inter single-prediction, or double-prediction), slice QP (QPSLICE), base QP (QBPBASE), boundary strength (BS), and predicted samples (pred). Rec EXT is the reconstructed UV data. 3x3 signifies a 3x3 convolutional kernel. d1, d2, ..., d5 are the output channels. In the example of Fig. 18, it is assumed that a 4:2:0 format is used. Therefore, the reconstructed UV samples are upsampled by a factor of 2 (i.e., 2↑) to form the reconstructed samples (rec). Furthermore, in the example of Fig. 18, the parameters d1= 192, d2= 32, d3= 16, d4= 16, d5= 16, C = 64, C1= 160, C 21 = 32, C 22 = 32, C 31 = 64, N = 24, and d6 = 48. FIG. 19 is a conceptual diagram illustrating an exemplary unified filter having distinct luminance / chroma models (1900) (luma). FIG. 20 is a conceptual diagram illustrating an exemplary unified filter having distinct luminance / chroma models (2000) (chroma). In the example of FIG. 19, the parameters d1 = 192, d2 = 32, d3 = 16, d4 = 16, d5 = 16, C = 64, C1 = 160, C 21 = 32, C 22 = 32, C 31 = 64, N = 20, and d6 = 48. In the example of Fig. 20, the parameters d1 = 192, d2 = 32, d3 = 16, d4 = 16, d5 = 16, C = 64, C1 = 160, C 21 = 160, C 22 = 32, C 31 = 64, N = 20, and d6 = 48.

[0166] A CCN ILF filter architecture utilizing luminance / chroma decomposition was proposed by Rusanovskyy et al. in "Unified LOP filter design, training procedure and filter usage", JVET-AE0281 (hereinafter, "JVET-AE0281"). Separate processing branches for luminance and chroma allow for independent training of NN weights for target components and optimization of a certain degree of complexity-performance trade-off. In the filter architecture illustrated in Fig. 21, the chroma branch has a smaller number of BBs, e.g., N c < N y or a reduced number of channels, e.g., C uv < Cy or C uv21 < C y21 It may be used. FIG. 21 is a block diagram illustrating a unified filter (2100) using luminance / chroma splitting. As illustrated in FIG. 21, luminance samples are processed in a first path (2102), and chroma samples are processed in a second path (2104). The backbone blocks of both the first path (2102) and the second path (2104) may have the same structure (2106). In the example of FIG. 21, the parameters may be defined as shown in the following tables.

[0167] Head block parameters

[0168]

[0169] Backbone parameters

[0170]

[0171] The production of video content by CGI or camera sensors, as well as the consumption of video content (through displays), is typically performed in the RGB domain, and imagery quality is controlled for each color component. In contrast, video compression is typically performed in the Y'CbCr domain with a 4:2:0 chroma representation. In such a format, the luminance is represented at full resolution, while the two distinct color components (Cb and Cr) are represented at half spatial resolution.

[0172] It is known that processing performed independently on the luminance and chroma components, as well as color space conversion (from RGB to Y'CbCr and vice versa) and chroma down-sampling, can result in suboptimal performance or quality degradation in the RGB domain. In particular, due to the non-linear characteristics of the Y'CbCr representation (electrooptical transfer function (EOTF)) and its effects on quantization, it has been observed that special care must be taken when selecting filter coefficients for such resampling filters to mitigate chroma "leakage." Conventional filters, such as the linear filters commonly used for the down-conversion of SDR chroma signals, can potentially cause visual artifacts when applied to HDR / WCG signals.

[0173] In the application of enhanced filtering such as NN-based ILF, filtering the Y and UV channels together using a non-optimal RGB-Y'CbCr conversion may be a suboptimal approach, partly because the Y and UV data represent different distributions and the filters may not be suitable for generalizing to both distributions.

[0174] To solve the problem described above, input YUV video frames can be converted, for example, to a non-YUV color space, such as RGB, or to a transformation domain, so that the distribution of signals in said domain can be beneficial for filtering. Subsequently, the filtering process is applied in the transformation domain. At the end of the filtering process, the transformed signals are inversely converted back to the input representation, such as the YUV domain.

[0175] In one example, cross-component color space conversion can be used as the conversion. For instance, YUV inputs are converted to the RGB domain using methods defined in the BT.709 system, and the conversion from RGB to YUV and from YUV to RGB are performed, respectively, using the following matrix multiplications:

[0176]

[0177]

[0178] An example of a filtering process using conversion without input down-sampling for a low-complexity filter is illustrated in FIG. 22. FIG. 22 is a conceptual diagram illustrating an exemplary architecture (2200) for filtering in the transform domain for a low-complexity filter. When converting from the RGB domain to the YUV420 domain, mean pooling can be performed on the UV channels of the YUV444 domain to generate the required sub-sampling. In the YUV420 domain, U and V samples are downsampled by half in both horizontal and vertical directions. In the YUV444 domain, U and V samples are not downsampled for the Y samples.

[0179] In the example of FIG. 22, the inputs to the architecture (2200) are reconstructed Y samples (Rec EXT Y), reconstructed UV samples (Rec EXTIncludes UV), IPB data, slice QP (QPSlice), base QP (QPBase), and boundary intensity (BS) values. Rec EXT UV is expanded / padding reconstructed UV data. Rec EXT Y is the expanded / padding reconstructed Y data. Rec EXT UV is upsampled so that Y and UV samples have the same spatial resolution (2↑). Rec EXT Y and upsampled Rec EXT UVs are merged to form reconstructed video data (rec). Subsequently, a transformation (transform) is applied to the reconstructed video data to generate transformation-domain reconstructed video data. The transformation converts the reconstructed video data from a first domain to a second domain. For example, the transformation can convert the reconstructed video data from the Y'CbCr domain to the RGB domain. The transformation is also applied to the predicted video data (pred) to generate transformation-domain predicted video data. A video coder (e.g., a video encoder (200) or a video decoder (300)) may use intra-prediction, inter-prediction, or other forms of prediction to generate the predicted video data. Individual convolutional layers (2202) are applied to IPB, QPSlice, QPBase, BS, the transformation-domain reconstructed video data, and the transformation-domain predicted video data. In the example of Fig. 22, the parameters are the following values: d1= 12, d2= 8, d3= 4, d4= 2, d5= 2, C = 24, C1= 72, C 21 = 24, N = 11, and d6 = 24 can be used.

[0180] Furthermore, as illustrated in FIG. 22, the outputs of convolutional layers (2202) are concatenated, a convolutional layer (2204) is applied, followed by a PReLU activation layer (2206), a down-sampling convolutional layer (2208), another PReLU activation layer (2210), and a set of N backbone blocks (2212). Each backbone block (2212) has a structure (2214) as additionally illustrated in FIG. 22. That is, the input to an individual backbone block (i.e., a 3D matrix [C,h,w], where C represents the number of channels, h represents the height of the matrix, and w represents the width of the matrix) passes through a series of convolutional layers, activation function layers, sepConv layers, and a final convolutional layer. sepConv is intended to separate, for example, a 3x3 convolution into 3x1 and 1x3 convolutions. The output of the final convolutional layer is added to the initial input of the backbone block to form the output matrix.

[0181] A convolutional layer (2216) is applied to the output of the final backbone block. The convolutional layer (2216) includes two sepConv layers and is followed by a convolutional layer. An activation layer (2218) is applied to the output of the convolutional layer (2216) and is followed by another convolutional layer (2220). A pixel shuffle (2222) rearranges the Y data of the pixels from the channel domain to the spatial domain. An inverse transformation (2226) converts the Y data back to the state before the Y data was transformed. A pixel shuffle (2224) rearranges the UV data of the pixels from the channel domain to the spatial domain. An inverse transformation (2228) converts the UV data back to the state before the UV data was transformed. The output of the inverse transform (2226) (e.g., luminance samples in an initial domain, e.g., a Y'CbCr domain) is added to the reconstructed Y samples (2230) and cropped (2234) thereby producing filtered reconstructed Y samples (2238). The output of the inverse transform (2228) (e.g., chroma samples in an initial domain, e.g., a Y'CbCr domain) is added to the reconstructed UV samples (2232) and cropped (2236) thereby producing filtered reconstructed Y samples (2240).

[0182] In some examples, the video coder (e.g., video encoder (200) or video decoder (300)) applies a transformation across the inputs, for example, in the form of a color space conversion, or the transformation may be applied in a spatial domain, where each component is transformed independently. In some examples, the video coder applies a transformation across different inputs. In some examples, independently applied transformations may be combined.

[0183] In one example, the video coder applies a wavelet transform to the signal in the spatial YUV domain (e.g., reconstructed video data) for each component to decompose the signal from the YUV inputs into different frequency bands, and the video coder performs filtering in the decomposed signal domain. In other words, the video coder performs filtering on the signal in a domain where the reconstructed video data is decomposed into values ​​corresponding to different frequency bands. At the end of the process, an inverse wavelet transform converts the signal back to the YUV domain. In another example, the wavelet transform may be a Haar wavelet.

[0184] In some examples, the transform kernel size can be 2x2 to KxK, where K can be divided into both the height H and the width W of the filtering block. The transform kernel is an operator that applies a transform to the input data. The size of the transform kernel is the size of the input data to which the transform is applied. In other examples, four frequency bands from wavelet decomposition can be arranged into four channels, where each frequency band is a block with half the resolution of the original block. This transform is essentially a process of downsampling the original block in the spatial domain by a factor of 2 in each dimension and increasing the number of channels by a factor of 4. In other examples, the same transform can be applied to other input signals, such as boundary intensity (BS) and IPB, and input signals with constant values ​​can be directly downsampled, for example, by using pixel unshuffle or reshape operators.

[0185] In another example, the video coder may apply the Discrete Cosine Transform (DCT) or its integer approximation to the input signals. The kernel size may be 2x2 to KxK, where K can be divided into W and H. In another example, coefficients from different frequency bands after the DCT transformation may be arranged into different channels, where coefficients within the same frequency band are arranged into blocks of resolution (W / / K, H / / K). This transformation essentially downsamples the original blocks in the spatial domain by K in each dimension and expands the number of channels by a factor of KxK. In another example, the same transformation may be applied to other input signals, such as BS and IPB, and input signals with constant values ​​may be directly downsampled.

[0186] In another example, a transformation kernel can be trained and applied to input signals. The kernel size can be 1x1 to KxK, where K can be divided into both W and H. The trainable transformation kernel can be implemented as convolutional neural network layers having a kernel of KxK and a stride of K_s, where K_s can be divided into W and H. In another example, different frequency bands from the trained transformation, i.e., the outputs from each kernel, can be arranged in the channel domain, where each frequency band is a block of (W / / K_s, H / / K_s) in resolution. The convolutional layers essentially downsample the original block in the spatial domain by K_s in each dimension and expand the number of channels by a factor of K_s x K_s or by a number from 1 to N, where N is constrained by the model complexity. In another example, the same convolutional layers may be applied to different input signals, such as BS and IPB, and input signals with constant values ​​may be directly down-sampled. In another example, the channel extension factor may be different for each input signal.

[0187] In another example, the methods mentioned for filtering in the transformation domain can also be applied to separate the luminance and chroma branches of NN models using luminance and chroma splitting.

[0188] In another example, the number of output channels prior to pixel shuffling can be adjusted, and the pixel shuffling operation can be turned on or off so that a desired spatial resolution can be obtained for filtering. That is, if the spatial size of the output after the inverse transform can be matched with the spatial size of the input, pixel shuffling is not necessary.

[0189] In another example, a transformation or trainable transformation may be applied in a downsampled domain, for example, after pixel unshuffling, where pixels in the spatial domain are arranged into the channel domain. In other words, video filtering may apply a transformation while the data is in a downsampled form and then subsequently upsample the data, for example, using pixel shuffling. Thus, a video coder may downsample and / or rearrange the reconstructed video data so that the input data (e.g., reconstructed video data, predicted video data, etc.) is in the downsampled or rearranged domain. Video filtering may apply a transformation to the input data in the downsampled or rearranged domain so that the input data is in the transformation domain for filtering. Correspondingly, at the end of filtering, pixel shuffling may be used to rearrange pixels from the channel domain back into the spatial domain.

[0190] In another example, to obtain the same spatial resolution after applying the transformation to the luminance and chroma components, the transformation kernel size may differ for luminance and chroma. In another example, the downsampling process may be omitted for the chroma components. In another example, direct downsampling may be applied to BS and IPB data to which the transformation has not been applied.

[0191] In another example, an input signal in the Y'CbCr domain can first be converted to linear YCbCr by applying an inverse nonlinearity (EOTF) specified by the individual color space (ITU-R BT.2100 or BT.2020), followed by applying a YCbCr-RGB color conversion in the linear domain, and then applying a nonlinearity opto-electric transfer function (OETF) to the RGB data. Thus, the input domain is the Y'CbCr domain, and the transformation domain is the RGB domain. An NN ILF filter can be applied to the resulting representation, followed by inverse operations, to bring the data back to the Y'CbCr domain.

[0192] The proposed techniques can be applied to all NN models of different functions and different types of architectures and modules, and are evaluated to use linear or non-linear functions for YUV inputs.

[0193] Adopting the techniques of the present disclosure for NNVC architectures can reduce computational complexity and memory bandwidth requirements and provide better performance. Although the examples described in this document relate to NN-assisted loop filtering, they are applicable to any NN-based video coding tool that consumes input data having certain statistical properties, such as static content or sparse representation.

[0194] FIG. 23 is a flowchart illustrating an exemplary operation of a video coder according to one or more techniques of the present disclosure. The operation of FIG. 23 may be performed by a video encoder (200) or a video decoder (300). Accordingly, the term “coding” relating to the operation of FIG. 23 may be applied to encoding or decoding.

[0195] In the example of FIG. 23, the video coder may acquire input data (2300). The input data includes one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or IPB data. For example, in cases where the video coder is a video encoder (200), the reconstruction unit (214) may generate reconstructed video data based on the predicted video data and the reconstructed video data. In this example, the predicted video data may be generated by a motion compensation unit (224), an intra-prediction unit (226), or predicted in another way. In this example, the reconstructed video data may be generated by an inverse transformation processing unit (212). In one example where the video coder is a video decoder (300), the reconstruction unit (310) may generate reconstructed video data based on the predicted video data and the reconstructed video data. In this example, the predicted video data may be generated by a prediction processing unit (304). In this example, the reconstructed video data can be generated by the inverse conversion processing unit (308).

[0196] Furthermore, the video coder may convert input data from an input domain to a transform domain to generate converted video data (2302). In some examples, the filter unit (216) of the video encoder (200) converts the input data. In other examples, the filter unit (312) of the video decoder (300) converts the input data. The input domain and the transform domain may correspond to different ways of representing the input data. As an example of converting reconstructed video data from an input domain to a transform domain, the video coder may convert predicted video data and / or reconstructed video data from the YUV domain to a non-YUV color space, such as the frequency domain. In other words, the input domain may be the YUV domain, and the transform domain may be the non-YUV domain. In some examples, the input domain is the Y'CbCr domain, and the transform domain is the linear YCbCr domain.

[0197] In some examples, the video coder converts predicted video data and / or reconstructed video data in the form of color space conversion. In other words, the video coder can change the color space of the predicted video data and / or reconstructed video data from one color space to another. In some examples, the video coder converts the predicted video data and / or reconstructed video data in the spatial domain, where each component is converted separately. In other words, the data in the input domain and the transformation domain still correspond to locations within the space. In some examples, the video coder converts the video input data across multiple temporal entities of the video input data.

[0198] In some examples, the input domain is the YUV domain, and the video coder applies a wavelet transform to the YUV domain for each component to decompose the video input data into multiple frequency bands. In these examples, the transform domain is the decomposed signal domain. In some examples, the video coder applies a discrete cosine transform to the video input data.

[0199] A video coder may apply NN-based ILF to converted video data to generate filtered video data (2304). In some examples, a filter unit (216) of a video encoder (200) applies NN-based ILF. In other examples, a filter unit (312) of a video decoder (300) applies NN-based ILF. In some examples, the transform kernel size of the NN-based ILF ranges from 2x2 to KxK, where K can be divided into both the height H and the width W of the filtering block. In some examples, the video coder applies different transform kernel sizes for luminance and chroma.

[0200] A video coder can convert filtered video data from a transform domain to an input domain (2306). In some examples, a filter unit (216) of a video encoder (200) converts the filtered video data. In other examples, a filter unit (312) of a video decoder (300) converts the filtered video data. In some examples, the video coder applies an NN-based ILF to separate the luminance and chroma branches of NN models using an architecture similar to, for example, the unified filter (2100) of FIG. 21 but including transforms and inverse transforms. In other examples, the video coder can apply the NN-based ILF to the shared luminance and chroma branches of NN models.

[0201] The following is a non-limiting list of provisions according to one or more techniques of the present disclosure.

[0202] Clause 1A. A method for coding video data comprises: generating reconstructed video data based on predicted video data and residual data; converting the reconstructed video data from an input domain to a transformation domain to generate converted video data; applying a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and converting the filtered video data from the transformation domain to an input domain.

[0203] Clause 2A. In the method of Clause 1A, the input representation is in the YUV domain.

[0204] Clause 3A. In the method of Clause 1A or Clause 2A, the transformation domain is a non-YUV color space.

[0205] Clause 4A. In the method of any one of provisions 1A through 3A, the step of converting video input data includes one of the steps of converting video input data into a color space conversion form, converting video input data in a spatial domain where each component is converted separately, or converting video input data across multiple temporal entities of video input data.

[0206] Clause 5A. In the method of any one of clauses 1A through 4A, the input representation is in the YUV domain, the method further comprises the step of applying a wavelet transform to the YUV domain for each component to decompose video input data into multiple frequency bands, and the transform domain is the decomposed signal domain.

[0207] Clause 6A. In the method of any one of provisions 1A through 5A, the transform kernel size of the neural network-based in-loop filter ranges from 2x2 to KxK, where K can be divided into both the height H and the width W of the filtering block.

[0208] Clause 7A. In the method of any one of provisions 1A through 6A, the method further comprises the step of applying a discrete cosine transform to video input data.

[0209] Clause 8A. In the method of any one of provisions 1A through 7A, the step of applying the NN-based ILF includes the step of applying the NN-based ILF to separate luminance and chroma branches of the NN models.

[0210] Clause 9A. The method of any one of clauses 1A through 8A further includes the step of adjusting the number of output channels before pixel shuffling.

[0211] Clause 10A. In the method of any one of provisions 1A through 9A, the transformation is applied in the down-sampled domain.

[0212] Clause 11A. In the method of any one of provisions 1A through 10A, the step of applying NN-based ILF includes the step of applying different transformation kernel sizes to luminance and chroma.

[0213] Clause 12A. In the method of any one of Clause 1A, Clause 3A, Clause 4A, and Clauses 6A through 11A, the input domain is a Y'CbCr domain and the transformation domain is a linear YCbCr domain.

[0214] Clause 13A. In the method of any one of Clauses 1A through 12A, coding includes decoding.

[0215] Clause 14A. In the method of any one of Clauses 1A through 13A, coding includes encoding.

[0216] Clause 15A. As a device for coding video data, the device comprises one or more means for performing the method of any one of provisions 1A through 14A.

[0217] Clause 16A. In the device of Clause 15A, one or more means include one or more processors implemented as circuits.

[0218] Clause 17A. The device of Clause 15A or Clause 16A further includes memory for storing video data.

[0219] Clause 18A. A device of any one of provisions 15A through 17A further comprises a display configured to display decoded video data.

[0220] Clause 19A. In any one of Clauses 15A through 18A, the device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

[0221] Clause 20A. In any one of provisions 15A through 19A, the device comprises a video decoder.

[0222] Clause 21A. In any one of Clauses 15A through 20A, the device comprises a video encoder.

[0223] Clause 22A. A computer-readable storage medium in which instructions are stored, wherein the instructions, when executed, cause one or more processors to perform the method of any one of provisions 1A through 14A.

[0224] Clause 1B. A method for coding video data comprises the steps of: acquiring input data—input data including one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data—; converting the input data from an input domain to a transform domain to generate converted video data; applying a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and converting the filtered video data from the transform domain to an input domain.

[0225] Clause 2B. In the method of Clause 1B, the input domain is the YUV domain.

[0226] Clause 3B. In the method of Clause 1B or Clause 2B, the transformation domain is a non-YUV domain.

[0227] Clause 4B. In the method of any one of provisions 1B to 3B, the step of converting input data includes one of the steps of converting the reconstructed video into a color space conversion form, converting the reconstructed video data in a spatial domain where each component is converted separately, or converting the reconstructed video data across multiple temporal entities of the reconstructed video data.

[0228] Clause 5B. In the method of any one of provisions 1B to 4B, the input domain is the YUV domain, the method further comprises the step of applying a wavelet transform to the YUV domain for each component to decompose the reconstructed video data into a plurality of frequency bands, and the transform domain is the decomposed signal domain.

[0229] Clause 6B. In the method of any one of provisions 1B to 5B, the transform kernel size of the neural network-based in-loop filter ranges from 2x2 to KxK, where K can be divided into both the height H and the width W of the filtering block.

[0230] Clause 7B. In the method of any one of provisions 1B through 6B, the method further comprises the step of applying a discrete cosine transform to the reconstructed video data.

[0231] Clause 8B. In the method of any one of provisions 1B through 7B, the step of applying the NN-based ILF includes the step of applying the NN-based ILF to separate luminance and chroma branches of the NN models.

[0232] Clause 9B. The method of any one of clauses 1B through 8B further includes the step of adjusting the number of output channels before pixel shuffling.

[0233] Clause 10B. In the method of any one of provisions 1B through 9B, the step of converting input data comprises: a step of downsampling or rearranging the reconstructed video data so that the reconstructed video data is in a downsampled or rearranged domain; and a step of applying a transformation to the reconstructed video data in the downsampled or rearranged domain so that the reconstructed video data is in a transformation domain for filtering.

[0234] Clause 11B. In the method of any one of provisions 1B through 10B, the step of applying NN-based ILF includes the step of applying different transformation kernel sizes to the luminance and chroma.

[0235] Clause 12B. In the method of any one of provisions 1B through 11B, the input domain is the Y'CbCr domain and the transformation domain is the RGB domain.

[0236] Clause 13B. In the method of any one of provisions 1B through 12B, coding includes decoding.

[0237] Clause 14B. In the method of any one of provisions 1B through 12B, coding includes encoding.

[0238] Clause 15B. A device for coding video data comprises: one or more memories for storing video data; and one or more processors implemented as circuits, wherein the one or more processors acquire input data—the input data includes one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data—; convert the input data from an input domain to a transform domain to generate converted video data; apply a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and convert the filtered video data from the transform domain to an input domain.

[0239] Clause 16B. For the device of Clause 15B, the input domain is the YUV domain.

[0240] Clause 17B. In the device of Clause 15B or Clause 16B, the conversion domain is a non-YUV domain.

[0241] Clause 18B. In a device of any one of provisions 15B through 17B, one or more processors are configured to convert the reconstructed video data into a color space conversion form as part of converting the input data, convert the reconstructed video data in a spatial domain where each component is converted separately, or convert the reconstructed video data across multiple temporal entities of the reconstructed video data.

[0242] Clause 19B. In a device of any one of provisions 15B through 18B, the input domain is a YUV domain, one or more processors are further configured to apply a wavelet transform to the YUV domain for each component to decompose the reconstructed video data into multiple frequency bands, and the transform domain is a decomposed signal domain.

[0243] Clause 20B. One or more non-transient computer-readable storage media in which instructions are stored, wherein the instructions, when executed by one or more processors, cause one or more processors to acquire input data—input data includes one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data—; cause the input data to be converted from an input domain to a transform domain to generate converted video data; cause a neural network (NN)-based in-loop filter (ILF) to be applied to the converted video data to generate filtered video data; and cause the filtered video data to be converted from the transform domain to an input domain.

[0244] It should be recognized that, depending on the example, specific actions or events of any of the techniques described herein may be performed in different sequences, added, merged, or completely omitted (e.g., not all described actions or events are necessary for the implementation of the techniques). Furthermore, in certain examples, actions or events may be performed simultaneously rather than sequentially, for example, through multi-threaded processing, interrupt processing, or multiple processors.

[0245] In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored as one or more instructions or code on a computer-readable medium or transmitted therethrough, and may be executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol, for example. In this way, computer-readable media may generally correspond to (1) computer-readable storage media of a non-transient type or (2) communication media such as a signal or carrier wave. Data storage media may be available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for the implementation of the techniques described in the present invention. A computer program product may include a computer-readable medium.

[0246] As an example, not a limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be accessed by a computer and used to store desired program code in the form of instructions or data structures. Additionally, any connection is appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL (digital subscriber line), or wireless technologies (such as infrared, radio, and microwave), then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies (such as infrared, radio, and microwave) are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other transient media, but instead refer to non-transient types of storage media. As used herein, disks and discs include CDs (compact discs), laser discs, optical discs, DVDs (digital versatile discs), floppy disks, and Blu-ray discs, wherein disks generally reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0247] Instructions may be executed by one or more processors, such as one or more DSPs, general-purpose microprocessors, ASICs, FPGAs, or other equivalent integrated or discrete logic circuits. Accordingly, as used herein, the terms “processor” and “processing circuit” may refer to any of the aforementioned structures or any other structures suitable for implementing the techniques described herein. Additionally, in some aspects, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or integrated into a combined codec. Furthermore, the techniques may be fully implemented by one or more circuits or logic elements.

[0248] The techniques of the present disclosure may be implemented in a wide variety of devices or apparatus, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chipsets). Various components, modules, or units are described in the present disclosure to highlight functional aspects of devices configured to perform the disclosed techniques, but are not required to be realized by different hardware units. Rather, as described above, various units may be combined into a codec hardware unit or provided by a set of interacting hardware units including one or more processors as described above, together with suitable software and / or firmware.

[0249] Various examples have been described. These and other examples exist within the scope of the following claims.

Claims

Claim 1 A method for coding video data comprising: acquiring input data, wherein the input data comprises one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data; converting the input data from an input domain to a transform domain to generate converted video data; applying a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and converting the filtered video data from the transform domain to the input domain. Claim 2 A method for coding video data according to claim 1, wherein the input domain is a YUV domain. Claim 3 A method for coding video data according to claim 1, wherein the transformation domain is a non-YUV domain. Claim 4 A method for coding video data according to claim 1, wherein the step of converting the input data comprises one of the steps of converting the reconstructed video data into a color space conversion form, converting the reconstructed video data in a spatial domain where each component is converted separately, or converting the reconstructed video data across a plurality of temporal entities of the reconstructed video data. Claim 5 A method for coding video data according to claim 1, wherein the input domain is a YUV domain, the method further comprises the step of applying a wavelet transform to the YUV domain for each component to decompose the reconstructed video data into a plurality of frequency bands, and the transform domain is a decomposed signal domain. Claim 6 A method for coding video data according to claim 1, wherein the transform kernel size of the neural network-based in-loop filter is in the range of 2x2 to KxK, and K can be divided into both the height H and the width W of the filtering block. Claim 7 A method for coding video data according to claim 1, wherein the method further comprises the step of applying a discrete cosine transform to the reconstructed video data. Claim 8 A method for coding video data according to claim 1, wherein the step of applying the NN-based ILF includes the step of applying the NN-based ILF to separate luminance and chroma branches of NN models. Claim 9 A method for coding video data according to claim 1, further comprising the step of adjusting the number of output channels before pixel shuffle. Claim 10 A method for coding video data according to claim 1, wherein the step of converting the input data comprises: a step of performing at least one of downsampling or rearranging the reconstructed video data such that the reconstructed video data is in a downsampled or rearranged domain; and a step of applying a transformation to the reconstructed video data in the downsampled or rearranged domain such that the reconstructed video data is in the transformation domain for filtering. Claim 11 A method for coding video data according to claim 1, wherein the step of applying the NN-based ILF includes the step of applying different transformation kernel sizes for luminance and chroma. Claim 12 A method for coding video data according to claim 1, wherein the input domain is a Y'CbCr domain and the transformation domain is an RGB domain. Claim 13 A method for coding video data according to claim 1, wherein the coding includes decoding. Claim 14 A method for coding video data according to claim 1, wherein the coding includes encoding. Claim 15 A device for coding video data, comprising: one or more memories for storing said video data; and one or more processors implemented as circuit parts, wherein said one or more processors, Acquire input data - said input data includes one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data -; To generate converted video data, the above input data is converted from an input domain to a conversion domain; To generate filtered video data, a neural network (NN)-based in-loop filter (ILF) is applied to the converted video data; and A device for coding video data configured to convert the filtered video data from the conversion domain to the input domain. Claim 16 In paragraph 15, a device for coding video data, wherein the input domain is a YUV domain. Claim 17 In paragraph 15, a device for coding video data, wherein the conversion domain is a non-YUV domain. Claim 18 A device for coding video data, wherein, in part of converting the input data, the one or more processors are configured to convert the reconstructed video data into a color space conversion form, convert the reconstructed video data in a spatial domain where each component is converted separately, or convert the reconstructed video data over a plurality of temporal entities of the reconstructed video data. Claim 19 A device for coding video data, wherein, in paragraph 15, the input domain is a YUV domain, and the one or more processors are further configured to apply a wavelet transform to the YUV domain for each component to decompose the reconstructed video data into a plurality of frequency bands, and the transform domain is a decomposed signal domain. Claim 20 One or more non-transient computer-readable storage media in which instructions are stored, wherein the instructions, when executed by one or more processors, cause the one or more processors to acquire input data—the input data comprising one or more of predicted video data, reconstructed video data, quantization parameter data, boundary intensity data, or prediction mode data—; convert the input data from an input domain to a transform domain to generate converted video data; apply a neural network (NN)-based in-loop filter (ILF) to the converted video data to generate filtered video data; and convert the filtered video data from the transform domain to the input domain.

Images