Encoding device, decoding device, encoding method, decoding method, computer program

Abstract

The present invention provides a method, apparatus, and system for encoding and decoding tensors from a convolutional neural network using video compression technology. [Solution] The method comprises: generation means for generating a frame on which a plurality of feature maps obtained based on at least neural network processing of an input image are arranged; and encoding means for encoding the frame on which the plurality of feature maps are arranged into a bitstream, using a first part of a plurality of tools and without using a second part of the plurality of tools which includes at least a deblocking filter (DBF).

Description

[Technical Field]

[0001] References to related applications This application claims the benefits under 35 U.S. SC § 119 as of the filing date of Australian Patent Application No. 2021202142, filed on 7 April 2021, and is incorporated herein by reference as if it were fully described herein.

[0002] The present invention generally relates to digital video signal processing, and more particularly to methods, apparatus, and systems for encoding and decoding tensors from convolutional neural networks. The present invention also relates to a computer program product including a computer-readable medium containing a computer program for encoding and decoding tensors from convolutional neural networks using video compression techniques. [Background technology]

[0003] Video compression is a ubiquitous technology used to support many applications, including applications for transmitting and storing video data. Many video coding standards have been developed, and others are currently under development. Recent developments in video coding standardization have led to the formation of a group called the "Joint Video Experts Team" (JVET). The Joint Video Experts Team (JVET) includes members of two Standards Setting Organisations (SSOs): Study Group 16, Question 6 (SG16 / Q6) of the Telecommunication Standardisation Sector (ITU-T) of the International Telecommunication Union (ITU), also known as the "Video Coding Experts Group" (VCEG), and Working Group 11 (ISO / IEC JTC1 / SC29 / WG11) of the International Organization for Standardization / International Electrotechnical Commission Joint Technical Committee 1 / Subcommittee 29.

[0004] The Joint Video Experts Team (JVET) developed a video compression standard called "versatile video coding" (VVC).

[0005] Convolutional neural networks (CNNs) are an emerging technology that addresses use cases involving machine vision, particularly object recognition, object tracking, human pose estimation, and behavior recognition. A CNN typically contains many layers, such as convolutional and fully connected layers, with data passed from one layer to the next in the form of "tensors." The weights of each layer are determined in the training stage, where a very large amount of training data passes through the CNN, and the determined results are compared to ground truth associated with the training data. Processes for updating network weights, such as stochastic gradient descent, are applied to iteratively refine the network weights until the network performs at the desired level of accuracy. If a convolutional stage has a "stride" greater than 1, the output tensor from the convolution has lower spatial resolution than the corresponding input tensor. Behaviors like "maximum pooling" also reduce the spatial size of the output tensor compared to the input tensor. Maximum pooling divides the input tensor into groups of data samples (for example, 2x2 groups of data samples) and generates an output tensor by selecting the maximum value from each group as the output for the corresponding value in the output tensor. The process of running a CNN with the input and progressively transforming the input into an output is generally called "inference".

[0006] Generally, a tensor has four dimensions: batch, channel, height, and width. The first dimension, "batch," with a size of "1" when inferring video data, indicates that one frame passes through the CNN at a time. When training a network, the batch dimension can be increased according to a given "batch size" so that multiple frames pass through the network before the network weights are updated. A multi-frame video can be processed as a single tensor with a batch dimension whose size is increased according to the number of frames in a given video. However, due to practical considerations regarding memory consumption and access, inference on video data is typically performed frame by frame. The "channel" dimension indicates the number of concurrent "feature maps" for a given tensor, while the height and width dimensions indicate the size of the feature maps at a particular stage of the CNN. The channel count changes throughout the CNN according to the network architecture. The feature map size also changes depending on the subsampling that occurs in a particular network layer.

[0007] The input to the first layer of a CNN is typically an image or video frame, resized for compatibility with the dimensions of the tensor input to the first layer. The dimensions of the tensor depend on the CNN architecture and generally have several dimensions related to the input width and height, plus an additional "channel" dimension.

[0008] Slicing a tensor based on its channels results in a set of so-called "feature maps," where each slice of the tensor has some relationship to the corresponding input image, capturing some characteristic such as edges. Further layers away from the network's input, these relationships can be more abstract. A CNN's "task performance" is measured by comparing the CNN's results when performing a task with a particular input to the provided ground truth (i.e., "training data"), which is generally human-prepared and intended to show "correct" results.

[0009] Once the network topology is determined, the network weights can be updated over time as more training data becomes available. It is also possible to retrain a portion of the CNN while leaving the weights of other parts of the network unchanged. The overall complexity of CNNs tends to be very high, with numerous multiply-accumulate operations being performed and many intermediate tensors being written to and read from memory. In some applications, CNNs are implemented entirely in the "cloud," requiring high and expensive processing power. In other applications, CNNs are implemented on edge devices such as cameras or mobile phones, offering less flexibility but more distributed processing load.

[0010] VVC is expected to address the ongoing demand for increasingly higher compression performance, particularly as video formats increase their capabilities (e.g., with higher resolution and higher frame rates), and the growing market demand for service delivery over WANs where bandwidth costs are relatively high. VVC is feasible in modern silicon processes and offers an acceptable trade-off between the performance achieved and the cost of implementation. Implementation costs can be considered, for example, in terms of one or more of the following: silicon area, CPU processor load, memory utilization, and bandwidth. Part of the versatility of the VVC standard lies in the wide selection of tools available for compressing video data, as well as the wide range of applications for which VVC is suitable.

[0011] Video data consists of a sequence of frames of image data, each frame containing one or more color channels. Generally, one primary color channel and two secondary color channels are required. The primary color channel is commonly called the "luma" channel, and the secondary color channels are commonly called the "chroma" channels. Video data is typically displayed in the RGB (red-green-blue) color space, which has a high degree of correlation between each of its three components. Video data representations seen by encoders or decoders often use color spaces such as YCbCr. YCbCr concentrates luminance, mapped to "luma" according to a transfer function, in the Y (primary) channel and saturation in the Cb and Cr (secondary) channels. Due to the use of uncorrelated YCbCr signals, the statistics of the luma channel differ significantly from those of the chroma channel. The main difference is that, after quantization, the chroma channel contains a relatively small number of significance coefficients for a given block compared to the coefficients of the corresponding luma channel block. Furthermore, the Cb and Cr channels may be spatially sampled (subsampled) at a lower rate compared to the Luma channels, for example, half horizontally and half vertically, in what is known as the "4:2:0 chroma format." The 4:2:0 chroma format is used in internet video streaming, broadcast television, and Blu-ray. TM It is commonly used in "consumer" applications, such as saving to disk. When only chroma samples are present, the resulting monochrome frame is said to use the "4:0:0 chroma format".

[0012] The VVC standard specifies a “block-based” architecture, where a frame is first divided into a square array of areas known as “coding tree units” (CTUs). Generally, CTUs occupy a relatively large area, such as 128 × 128 lumens. However, the CTUs at the right and bottom edges of each frame may be smaller in area. Associated with each CTU is a “coding tree” (a “shared tree”) for both the lumens and chroma channels, or separate trees for each of the lumens and chroma channels, respectively. The coding tree defines the decomposition of the area of ​​the CTU into a set of blocks, also called “coding blocks” (CBs). When a shared tree is in use, a single coding tree designates blocks for both the lumens and chroma channels, in which case the collated collection of coding blocks is called a “coding unit” (CU) (i.e., each CU has a coding block for each color channel). CBs are processed to encode or decode in a specific order. As a result of using the 4:2:0 chroma format, a CTU with a luma coding tree for a 128×128 luma sample area has a corresponding chroma coding tree for a 64×64 chroma sample area juxtaposed with the 128×128 luma sample area. When a single coding tree is used for luma and chroma channels, the collection of collated blocks for a given area is generally called a “unit,” e.g., the CU above, as well as a “prediction unit” (PU) and a “conversion unit” (TU). A single tree with CUs spanning the color channels of 4:2:0 chroma format video data will make the chroma blocks half the width and height of the corresponding luma blocks. When separate coding trees are used for a given area, the CBs above, as well as a “prediction block” (PB) and a “conversion block” (TB) are used.

[0013] Despite the above distinction between "units" and "blocks," the term "block" can be used as a general term for an area or region of a frame to which behavior applies to all color channels.

[0014] For each CU, a prediction unit (PU) is generated for the content (sample values) of the corresponding region of the frame data ("prediction unit"). Furthermore, a representation of the difference (or "spatial region" residual) between the prediction and the content of the region seen in the input to the encoder is formed. The difference in each color channel can be transformed and coded as a sequence of residual coefficients to form one or more TUs for a given CU. The transformation applied may be a discrete cosine transform (DCT) or other transformation applied to each block of residual values. The transformation is applied separably (i.e., a two-dimensional transformation is performed in two passes). The block is first transformed by applying a one-dimensional transformation to each row of samples within the block. The partial result is then transformed by applying a one-dimensional transformation to each column of the partial result to produce a final block of transformation coefficients that substantially decorrelates the residual samples. Transformations of various sizes are supported by the VVC standard, including the transformation of rectangular-shaped blocks, where each side dimension is a power of 2. The transformation coefficients are quantized for entropy coding to the bitstream.

[0015] VVC features intra-frame prediction and inter-frame prediction. Intra-frame prediction involves the use of previously processed samples within a frame, which are used to generate a prediction for the current block of data samples within the frame. Inter-frame prediction involves generating a prediction for the current block of samples within a frame, using a block of samples obtained from a previously decoded frame. The block of samples obtained from a previously decoded frame is often offset from the spatial position of the current block according to a filtered motion vector. The intra-frame predicted block can be (i) a uniform sample value ("DC intra-prediction"), (ii) a plane with offsets and horizontal and vertical slopes ("plane intra-prediction"), (iii) a population of blocks with adjacent samples applied in a particular direction ("angle intra-prediction"), or (iv) the result of matrix multiplication using adjacent samples and selected matrix coefficients. Further discrepancies between the predicted block and the corresponding input sample can be corrected to some extent by encoding the "residuals" into a bitstream. Residuals are generally converted from the spatial domain to the frequency domain to form residual coefficients in the "first-order conversion domain," which can be further converted by the application of a "second-order conversion" to generate residual coefficients in the "second-order conversion domain." The residual coefficients are quantized according to the quantization parameters, resulting in a loss of accuracy in the reconstruction of the samples generated by the decoder, but with the consequence of a reduction in the bitrate in the bitstream. [Overview of the Initiative]

[0016] The object of the present invention is to substantially overcome, or at least improve upon, one or more drawbacks of existing configurations.

[0017] According to one aspect of this disclosure, an apparatus for generating first encoded data and second encoded data, A determination means for determining whether the device generates encoded data including encoded data of feature maps based on a neural network, The provided device includes, when the device generates the first encoded data in the form of encoded video data that does not include encoded data of the feature map, encoding means for generating the first encoded data using a plurality of functions for encoding video data, wherein when the device generates the second encoded data that includes encoded data of the feature map, the encoding means uses the first part of the plurality of functions but does not use the second part of the plurality of functions to generate the encoded data of the feature map.

[0018] According to another aspect of this disclosure, a device for decoding first encoded data and second encoded data, The device includes a determination means for determining whether or not to decode encoded data, including encoded data of a feature map, based on a neural network. The provided device includes, when the device decodes the first encoded data in the form of encoded video data that does not include encoded data of the feature map, a decoding means that decodes the first encoded data using a plurality of functions for decoding video data, wherein when the device decodes the second encoded data that includes encoded data of the feature map, the decoding means uses the first part of the plurality of functions but does not use the second part of the plurality of functions to decode the encoded data of the feature map.

[0019] According to another aspect of this disclosure, a method for generating first encoded data and second encoded data, The device determines whether it generates encoded data, including encoded data of feature maps, based on a neural network. When the device generates the first encoded data in the form of encoded video data that does not include the encoded data of the feature map, the device generates the first encoded data using a plurality of functions for encoding video data, A method is provided for generating the second encoded data, which includes encoded data of the feature map, by using the first part of the plurality of functions but without using the second part of the plurality of functions.

[0020] According to another aspect of the present disclosure, a method for decoding first encoded data and second encoded data, comprising: determining whether the device decodes the encoded data including the encoded data of the feature map based on a neural network; when the device decodes the first encoded data in the form of encoded video data not including the encoded data of the feature map, decoding the first encoded data using a plurality of functions for decoding video data; when the device decodes the second encoded data including the encoded data of the feature map, a method is provided that decodes the encoded data of the feature map using a first part of the plurality of functions but not using a second part of the plurality of functions.

[0021] According to another aspect of the present disclosure, a non - transient computer - readable storage medium storing a program for executing a method for generating first encoded data and second encoded data, the method comprising: determining whether the device generates encoded data including the encoded data of the feature map based on a neural network; when the device generates the first encoded data in the form of encoded video data not including the encoded data of the feature map, generating the first encoded data using a plurality of functions for encoding video data; when the device generates the second encoded data including the encoded data of the feature map, generating the encoded data of the feature map using a first part of the plurality of functions but not using a second part of the plurality of functions. A non - transient computer - readable storage medium is provided.

[0022] According to another aspect of the present disclosure, a non - transient computer - readable storage medium storing a program for executing a method for decoding first encoded data and second encoded data, the method comprising: The device determines whether or not to decode the encoded data, which includes the encoded data of the feature map, based on a neural network. When the device decodes the first encoded data in the form of encoded video data that does not include the encoded data of the feature map, the device decodes the first encoded data using a plurality of functions for decoding video data, A non-temporary computer-readable storage medium is provided, which includes the device decoding the second encoded data, which includes the encoded data of the feature map, by using the first part of the plurality of functions but not by using the second part of the plurality of functions.

[0023] Other aspects will also be disclosed. [Brief explanation of the drawing]

[0024] Next, at least one embodiment of the present invention will be described with reference to the following drawings and appendices. [Figure 1] Figure 1 is a schematic block diagram illustrating a distributed machine task system. [Figure 2A] Figure 2A forms a schematic block diagram of a general-purpose computer system in which the distributed machine task system of Figure 1 can be implemented. [Figure 2B] Figure 2B forms a schematic block diagram of a general-purpose computer system in which the distributed machine task system of Figure 1 can be implemented. [Figure 3A] Figure 3A is a schematic block diagram showing the functional modules of the CNN backbone. [Figure 3B] Figure 3B is a schematic block diagram showing the residual block in Figure 3A. [Figure 3C] Figure 3C is a schematic block diagram showing the residual unit in Figure 3A. [Figure 3D] Figure 3D is a schematic block diagram showing the CBL module in Figure 3A. [Figure 4] Figure 4 is a schematic block diagram showing the functional modules of the alternative backbone portion of the CNN. [Figure 5] Figure 5 is a schematic block diagram showing a feature map quantizer and packer as part of a distributed machine task system. [Figure 6] Figure 6 is a schematic block diagram showing the functional module of the video encoder. [Figure 7] Figure 7 is a schematic block diagram showing the functional module of the video decoder. [Figure 8] Figure 8 is a schematic block diagram showing a feature-map inverse quantizer and umpacker as part of a distributed machine task system. [Figure 9A] Figure 9A is a schematic block diagram showing the head of the CNN. [Figure 9B] Figure 9B is a schematic block diagram showing the upscaler module of Figure 9A. [Figure 9C] Figure 9C is a schematic block diagram showing the detection module in Figure 9A. [Figure 10] Figure 10 is a schematic block diagram showing the alternative head portion of the CNN. [Figure 11] Figure 11 is a schematic block diagram showing the feature map packing arrangement in a monochrome frame. [Figure 12] Figure 12 is a schematic block diagram showing an alternative feature map packing arrangement in a monochrome frame. [Figure 13] Figure 13 is a schematic block diagram showing the feature map packing arrangement in a 4:2:0 chroma subsampling color frame. [Figure 14] Figure 14 is a schematic block diagram showing the bitstream that holds the encoded packed feature map and associated metadata. [Figure 15] Figure 15 shows how to run the first part of the CNN and encode the resulting feature map. [Figure 16] Figure 16 shows how to decode the feature map and run the second part of the CNN. [Figure 17] Figure 17 shows how to determine the grouping of feature maps. [Figure 18] Figure 18 shows how to select a set of coding tools or features from the video standard. Appendix A is a syntax table showing the Supplemental Enhancement Information (SEI) message format for representing metadata related to feature mapping packing and quantization in a bitstream. [Modes for carrying out the invention]

[0025] Where any step and / or feature having the same reference numeral is referenced in any of the attached drawings, those steps and / or features have the same function or operation for the purposes of this description, unless otherwise intended.

[0026] A distributed machine task system may include edge devices such as network cameras or smartphones that generate intermediate compressed data. The distributed machine task system may also include end devices such as server farm-based ("cloud") applications that manipulate the intermediate compressed data to produce some task result. In addition, edge device functionality may be embodied in the cloud, and the intermediate compressed data may potentially be stored for subsequent processing for multiple different tasks as needed.

[0027] A convenient form of intermediate compressed data is the compressed video bitstream, due to the availability of high-performance compression standards and their implementations. Video compression standards typically manipulate integer samples of a given bit depth, such as 10 bits, arranged in a planar array. Color video has three planar arrays corresponding to color components, for example, Y, Cb, Cr, or R, G, B, depending on the application. Convolutional Neural Networks (CNNs) typically manipulate floating-point data in the form of tensors, which generally have a much smaller spatial dimension compared to the incoming video data, but have more channels than the typical three channels of color video data on which the CNN operates.

[0028] A tensor typically has the following dimensions: frames, channels, height, and width. For example, a tensor with dimensions [1, 256, 76, 136] is said to contain 256 feature maps, each with a size of 136 × 76. For video data, inference is typically performed on one frame at a time, rather than using a tensor containing multiple frames.

[0029] VVC encoders and decoders include a capability signaling mechanism known as "constraints." Early in a bitstream, there is a set of constraints indicating which capabilities of the VVC standard will not be used in the bitstream. Constraints signal along with the bitstream's "profile" and "level." A profile broadly indicates the set of tools that must be available to decode the bitstream. Constraints also provide finer granularity of control over which tools are further constrained in a given profile. Further constraints on tools are similar to "subprofiling," but subprofiles are defined outside the VVC standard, while general constraint flag semantics are defined within the VVC standard. Depending on the type of data being encoded by the video encoder, by defining a subset of tools (equivalent to defining a subprofile, for example), the decoder can know, before beginning bitstream decoding, that a subset of coding tools for the indicated profile of the bitstream should be used.

[0030] Figure 1 is a schematic block diagram showing the functional modules of the distributed machine task system 100. System 100 can be used to implement a method for efficiently packing and quantizing feature maps into planar frames for encoding and decoding feature maps from encoded data, so that the associated overhead data is not excessively burdensome and the task performance of the decoded feature maps is resilient to changes in the bit rate of the bitstream.

[0031] System 100 includes a source device 110 for generating encoded data in the form of encoded video information. System 100 also includes a destination device 140. A communication channel 130 is used to communicate the encoded video information from the source device 110 to the destination device 130. In some configurations, one or both of the source device 110 and the destination device 140 may have their respective mobile phone handsets (e.g., "smartphones") or network cameras and cloud applications. The communication channel 130 may be a wired connection such as Ethernet®, or a wireless connection such as WiFi or 5G. Furthermore, the source device 110 and the destination device 140 may have applications in which the encoded video data is captured on some computer-readable storage medium, such as a hard disk drive in a file server.

[0032] As shown in Figure 1, the source device 110 includes a video source 112, a CNN backbone 114, a feature map quantizer and packer 116, a multiplexer 118, a video encoder 120, and a transmitter 122. The video source 112 typically comprises a source of captured video frame data (shown as 113), such as an image capture sensor, a previously captured video sequence stored on a non-temporary recording medium, or a video feed from a remote image capture sensor. The video source 112 may also be the output of a computer graphics card, for example, displaying the video output of various applications and operating systems running on a computing device (e.g., a tablet computer). Examples of source devices 110 that may include an image capture sensor as the video source 112 include smartphones, video camcorders, professional video cameras, and network video cameras.

[0033] The CNN backbone 114 receives video frame data 113 and executes specific layers of the overall CNN, such as the layer corresponding to the CNN's "backbone." The CNN's backbone layer can, for example, produce multiple tensors as output, corresponding to different spatial scales of the input image represented by the video frame data 113. The "feature pyramid network" (FPN) architecture can yield three tensors corresponding to the three layers output from the backbone 114, with varying spatial resolutions and channel counts. The feature map quantizer and packer 116 receives tensor 115 output from the CNN backbone 114. The feature map quantizer and packer 116 acts to interface the inner layers of the overall CNN, which are the output of the CNN backbone 114, to the video encoder 120 by quantizing the floating-point values ​​in tensor 115 into data samples that are packed into frame 119. The resolution of frame 119 is obtained based on the total area of ​​the feature map to be coded and the target aspect ratio. If excess unused space occurs within frame 119 during packing, the frame size may be increased (for example, the height may be increased), so that all feature maps can be placed within frame 119. For example, the resolution of frame 119 may be 2056 × 1224, and the bit depth of frame 119 may be 10 bits. Determining the placement of feature maps within frame 119 needs to be done only when the dimensions of tensor 115 are established. Slicing tensor 115 along the channel dimensions results in extracting one feature map per channel, and the feature maps of a given tensor have a specific size determined by the additional dimensions of the tensor. When FPN is used, multiple tensors are generated for each incoming frame, containing multiple sets of feature maps, each set of feature maps having a different spatial resolution. Feature maps of all layers are packed into a planar video frame, such as the packed feature map frame 117.The multiplexer 118 selects a packed feature map frame 117 if the source device 110 is configured to encode video data, or if the source device 110 is configured to encode feature maps or frame data 113, and outputs frame 119 to the encoding unit in the form of a video encoder 120. The selection between feature maps and regular video data is encoded in the bitstream using the "frame_type" syntax element in the metadata SEI message. The metadata SEI message is described with reference to Appendix A. Frame 119 is input to the video encoder 120, where lossy compression is applied to frame 119 to produce bitstream 121. Bitstream 121 is supplied to the transmitter 122 for transmission over the communication channel 130, or bitstream 121 is written to the storage device 132 for later use.

[0034] After conversion to tensors by the CNN backbone 114, the content of the resulting feature map can no longer identify individuals that are clearly identifiable in the video data 113. Storing the feature map (e.g., in a compressed form) using the storage device 132 may be more secure from a user privacy standpoint, particularly in relation to the European General Data Protection Regulation (GDPR) requirements for pseudonymization or anonymization.

[0035] Source device 110 supports a specific network for the CNN backbone 114. However, destination device 140 may use one of several networks for the head CNN 150. In this way, partially processed data in the form of packed feature maps can be stored for later use when performing various tasks without having to run the CNN backbone 114 again. Video encoder 120 uses a specific set of VVC coding tools (or "profiles") to encode frame data 119.

[0036] The bitstream 121 is transmitted by the transmitter 122 over the communication channel 130 as encoded video data (or "encoded video information"). In some implementations, the bitstream 121 can be stored in a storage device 132, which is a non-temporary storage device such as "flash" memory or a hard disk drive until it is later transmitted over the communication channel 130 (or instead of being transmitted over the communication channel 130). For example, the encoded video data may be provided to customers on demand over a wide area network (WAN) for video streaming applications.

[0037] The destination device 140 includes a receiver 142, a video decoder 144, a demultiplexer 146, a feature map umpacker and inverse quantizer 148, a CNN head 150, a CNN task 152, and a display device 160. The receiver 142 receives encoded video data from the communication channel 130 and passes the received video data as a bitstream to the video decoder 144 (indicated by arrow 143). The video decoder 144 then outputs the decoded frame data to the demultiplexer 146 (indicated by arrow 145). The decoded metadata 155 is also extracted from the bitstream 143 by the video decoder 144 and passed to the feature map umpacker and inverse quantizer 148. The decoded metadata 155 is typically obtained from a "Supplementary Enhancement Information" (SEI) message 1413 (see Figure 14) present in the bitstream 143. Appendix A shows the exemplary syntax of decoded metadata 155, along with the semantics of each exemplary syntax element. Decoded metadata 155 can be decoded from and exist from the bitstream of any frame. Decoded metadata 155 can exist and be decoded less frequently than all frames. For example, decoded metadata 155 can exist and be decoded only for intrapictures in bitstream 143. When decoded metadata 155 does not exist for a given frame, the most recent available metadata is used. If the destination device 140 is configured to perform a CNN task, as indicated by the "frame_type" syntax element in the SEI message 1413 of bitstream 143, the frame data 145 is output as feature map frame data 147 to the feature map unpacker and inverse quantizer 148. Otherwise, if the destination device 140 is configured to perform video data decoding, the frame data 145 is output as frame data 159 and fed to the display device 160 for display as video. The feature-map umpacker and inverse quantizer output a tensor 147 that is fed to the CNN head 150.The CNN head 150 executes subsequent layers of the task initiated by the CNN backbone 114 to produce task results 151 stored in the task result buffer 152. Examples of display devices 160 include liquid crystal displays such as cathode ray tubes, smartphones, tablet computers, computer monitors, or standalone television sets. The functionality of each of the source device 110 and destination device 140 can also be embodied in a single device, such as a mobile phone handset, tablet computer, and cloud application.

[0038] Despite the exemplary devices described above, each of the source device 110 and destination device 140 can generally be configured within a general-purpose computing system through a combination of hardware and software components. Figure 2A shows such a computer system 200, which includes a computer module 201 and input devices such as a keyboard 202, a mouse pointer device 203, a scanner 226, a camera 227 which may be configured as a video source 112, and a microphone 280, and output devices including a printer 215, a display device 214 which may be configured as a display device 160, and a loudspeaker 217. An external modulator-demodulator (Modem) transceiver device 216 may be used by the computer module 201 to communicate with a communication network 220 via a connection 221. The communication network 220, which may represent a communication channel 130, could be the Internet, a cellular telecommunications network, or a private WAN (WAN). If the connection 221 is a telephone line, the modem 216 may be a conventional "dial-up" modem. Alternatively, if connection 221 is a high-capacity (e.g., cable or fiber optic) connection, modem 216 may be a broadband modem. A wireless modem may also be used for wireless connectivity to communication network 220. Transceiver device 216 can provide the functions of transmitter 116 and receiver 142, and communication channel 130 may be embodied in connection 221.

[0039] The computer module 201 typically includes at least one processor unit 205 and a memory unit 206. For example, the memory unit 206 may have semiconductor RAM (random access memory) and semiconductor ROM (read-only memory). The computer module 201 also includes several input / output (I / O) interfaces, including an audio-video interface 207, a loudspeaker 217, and a microphone 280 coupled to a video display 214, an I / O interface 213 coupled to a keyboard 202, a mouse 203, a scanner 226, a camera 227, and optionally a joystick or other human interface device (not shown), and an interface 208 for an external modem 216 and a printer 215. The signal from the audio-video interface 207 to the computer monitor 214 is generally the output of a computer graphics card. In some implementations, the modem 216 may be integrated into the computer module 201, for example, within interface 208. The computer module 201 also has a local network interface 211 that allows the computer system 200 to be connected via a connection 223 to a local area communication network 222 known as a local area network (LAN). As shown in Figure 2A, the local communication network 222 can also be connected to a wide network 220 via a connection 224, which typically includes a so-called "firewall" device or a device with similar functionality. The local network interface 211 is Ethernet TM Circuit card, Bluetooth TMIt may have a wireless configuration or an IEEE 802.11 wireless configuration, but many other types of interfaces can be implemented for interface 211. The local network interface 211 can also provide the functions of a transmitter 122 and a receiver 142, and the communication channel 130 can also be implemented in a local communication network 222.

[0040] I / O interfaces 208 and 213 can provide either or both serial and parallel connectivity, the former typically implemented according to the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). A storage device 209 is provided, typically including a hard disk drive (HDD) 210. Other storage devices such as floppy disk drives or magnetic tape drives (not shown) may also be used. An optical disk drive 212 is typically provided to function as a non-volatile source of data. For example, an optical disk (e.g., CD-ROM, DVD, Blu-ray Disc) TM Portable memory devices such as USB-RAM, portable external hard disks, and floppy disks can be used as suitable data sources to the computer system 200. Typically, the HDD 210, optical drive 212, and networks 220 and 222 may be configured to act as a video source 112 or as a destination for decoded video data stored for playback via the display 214. The source device 110 and destination device 140 of system 100 can be embodied in the computer system 200.

[0041] Components 205–213 of computer module 201 typically communicate via an interconnected bus 204 to bring about a conventional operating mode of computer system 200 known to those skilled in the art. For example, processor 205 is coupled to system bus 204 using connection 218. Similarly, memory 206 and optical disc drive 212 are coupled to system bus 204 by connection 219. Examples of computers capable of implementing the described configuration include IBM-PC and compatibles, SunSPARCstation, and AppleMac. TM , or similar computer systems.

[0042] Where appropriate or desirable, the video encoder 120 and video decoder 144, and the method described below, may be implemented using a computer system 200. In particular, the video encoder 120, video decoder 144, and the method described may be implemented as one or more software application programs 233 executable within the computer system 200. Specifically, the steps of the video encoder 120, video decoder 144, and the method described are performed by instructions 231 (see Figure 2B) in the software 233 executed within the computer system 200. The software instructions 231 may be formed as one or more code modules, each for performing one or more specific tasks. The software may also be divided into two distinct parts, the first part and its corresponding code modules for performing the method described, and the second part and its corresponding code modules for managing the user interface between the first part and the user.

[0043] The software may be stored, for example, on a computer-readable medium including a storage device as described below. The software is loaded from the computer-readable medium into the computer system 200 and then executed by the computer system 200. Such software or a computer-readable medium having a computer program recorded on it is a computer program product. The use of the computer program product in the computer system 200 preferably results in an advantageous apparatus for implementing the source device 110 and the destination device 140, and the method described.

[0044] The software 233 is typically stored on the HDD 210 or in memory 206. The software is loaded from a computer-readable medium into the computer system 200 and executed by the computer system 200. For example, the software 233 may be stored on an optically readable disk storage medium (e.g., a CD-ROM) 225 that is read by an optical disk drive 212.

[0045] In some examples, the application program 233 may be supplied to the user encoded on one or more CD-ROMs 225 and read via the corresponding drive 212, or read by the user from a network 220 or 222. Furthermore, the software may also be loaded into the computer system 200 from other computer-readable media. Computer-readable storage media refers to any non-temporary tangible storage medium that provides recorded instructions and / or data to the computer system 200 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tapes, CD-ROMs, DVDs, and Blu-ray Discs. TMThis includes hard disk drives, ROMs or integrated circuits, USB memory sticks, magneto-optical disks, or computer-readable cards such as PCMCIA cards, and these devices are internal or external to the computer module 201. Examples of temporary or intangible computer-readable transmission media that may also participate in providing software, application programs, instructions, and / or video data or encoded video data to the computer module 201 include wireless or infrared transmission channels, as well as network connections to other computers or networked devices, and the internet or intranets, including information recorded on websites and the like, including email transmissions.

[0046] The second part of the application program 233 and the corresponding code modules described above may be implemented to implement one or more graphical user interfaces (GUIs) that are rendered or represented on the display 214. Typically, through the operation of the keyboard 202 and mouse 203, a user of the computer system 200 and the application can operate the interface in a functionally adaptable manner to provide control commands and / or inputs to the GUI-related application. Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface that utilizes speech prompts output via the loudspeaker 217 and user voice commands input via the microphone 280.

[0047] Figure 2B is a detailed schematic block diagram of the processor 205 and “memory” 234. Memory 234 represents the logical set of all memory modules (including storage devices 209 and semiconductor memory 206) accessible by the computer module 201 in Figure 2A.

[0048] When the computer module 201 is first powered on, a power-on self-test (POST) program 250 is executed. The POST program 250 is typically stored in the ROM 249 of the semiconductor memory 206, as shown in Figure 2A. Hardware devices such as the ROM 249 that store software are sometimes called firmware. The POST program 250 checks the hardware within the computer module 201 to ensure proper functioning, and typically checks the processor 205, memory 234 (209, 206), and the Basic Input / Output System Software (BIOS) module 251, also typically stored in the ROM 249, for correct operation. If the POST program 250 executes successfully, the BIOS 251 boots the hard disk drive 210, as shown in Figure 2A. The booting of the hard disk drive 210 causes the bootstrap loader program 252, which resides on the hard disk drive 210, to be executed via the processor 205. This loads the operating system 253 into the RAM memory 206, and the operating system 253 begins to operate. Operating System 253 is a system-level application runnable by Processor 205, performing various high-level functions including processor management, memory management, device management, storage management, software application interface, and general-purpose user interface.

[0049] The operating system 253 manages memory 234 (209, 206) to ensure that each process or application running on the computer module 201 has enough memory to run without conflicting with memory allocated to other processes. Furthermore, the different types of memory available in the computer system 200 in Figure 2A must be used appropriately so that each process can run effectively. Therefore, aggregated memory 234 is not intended to show how specific segments of memory are allocated (unless otherwise specified), but rather to provide a general view of the memory accessible by the computer system 200 and how such memory is used.

[0050] As shown in Figure 2B, the processor 205 includes several functional modules, including a control unit 239, an arithmetic logic unit (ALU) 240, and local or internal memory 248, sometimes called cache memory. The cache memory 248 typically contains several storage registers 244-246 within a register section. One or more internal buses 241 functionally interconnect these functional modules. The processor 205 also typically has one or more interfaces 242 for communicating with external devices via the system bus 204, using connection 218. Memory 234 is coupled to bus 204 using connection 219.

[0051] The application program 233 includes a set of instructions 231 that may include conditional branch and loop instructions. The program 233 may also include data 232 used for the execution of the program 233. The instructions 231 and data 232 are stored in memory locations 228, 229, 230, and 235, 236, and 237, respectively. Depending on the relative size of the instructions 231 and memory locations 228-230, a particular instruction may be stored in a single memory location, as indicated by the instruction shown in memory location 230. Alternatively, the instruction may be segmented into several parts, each stored in a separate memory location, as indicated by the instruction segments shown in memory locations 228 and 229.

[0052] Generally, the processor 205 is given a set of instructions to be executed within it. The processor 205 awaits subsequent inputs to which it responds by executing another set of instructions. Each input may come from one or more sources, all of which are shown in Figure 2A, including data generated by one or more of the input devices 202, 203, data received from an external source across one of the networks 220, 202, data retrieved from one of the storage devices 206, 209, or data retrieved from a storage medium 225 inserted into the corresponding reader 212. Execution of a set of instructions may, in some cases, result in the output of data. Execution may also involve storing data or variables in memory 234.

[0053] The video encoder 120, video decoder 144, and the method described may use input variables 254, which are stored in corresponding memory locations 255, 256, and 257 in memory 234. The video encoder 120, video decoder 144, and the method described may generate output variables 261, which are stored in corresponding memory locations 262, 263, and 264 in memory 234. Intermediate variables 258 may be stored in memory locations 259, 260, 266, and 267.

[0054] Referring to processor 205 in Figure 2B, registers 244, 245, 246, arithmetic logic unit (ALU) 240, and control unit 239 cooperate to execute the sequence of microoperations necessary to perform a “fetch, decode, and execute” cycle for each instruction in the instruction set that makes up program 233. Each fetch, decode, and execute cycle is: A fetch operation that fetches or reads instruction 231 from memory locations 228, 229, and 230; The control unit 239 performs a decoding operation to determine which instruction has been fetched, This includes the execution operation in which the control unit 239 and / or ALU 240 execute instructions.

[0055] Subsequently, further fetch, decode, and execute cycles may be performed for the next instruction. Similarly, a storage cycle may be performed by the control unit 239 storing or writing values ​​to memory location 232.

[0056] Each step or subprocess in the methods described in Figures 15, 16, 17, and 18 is associated with one or more segments of program 233 and is typically executed by register sections 244, 245, 247, ALU 240, and control unit 239 in processor 205, which cooperate to perform a fetch, decode, and execute cycle for all instructions in the instruction set for the mentioned segments of program 233.

[0057] Figure 3A is a schematic block diagram showing a functional module of the CNN backbone portion 310 that can function as CNN backbone 114. Backbone portion 114 is sometimes referred to as "DarkNet-53," but different backbones are possible, resulting in a different number and dimensions of layers in tensor 115 from frame to frame. The "backbone_id" syntax element in SEI message 1413, as explained with reference to Figure 14 and Appendix A, indicates the type of backbone. If the type of backbone is unknown, the tensor dimensions are specified using the feature map count ("fm_cnt") for each layer and the feature map dimensions ("fm_width" and "fm_height") for each layer.

[0058] As shown in Figure 3A, the video data 113 is passed to a resizer module 304 that resizes the frames to a resolution suitable for processing by the CNN backbone 310, generating resized frame data 312. If the resolution of the frame data 113 is already suitable for the CNN backbone 310, the operation of the resizer module 304 is unnecessary. The resized frame data 312 is passed to a convolutional batch normalization leaky rectified linear (CBL) module 314, generating a tensor 316. The CBL 314 includes modules such as the CBL module 360 ​​described with reference, as shown in Figure 3D.

[0059] The CBL module 360 ​​receives tensor 361 as input, which is passed to the convolutional layer 362 to generate tensor 363. When the convolutional layer 362 has a stride of 1, tensor 363 has the same spatial dimensions as tensor 361. When the convolutional layer 362 has a larger stride, such as 2, tensor 363 has smaller spatial dimensions compared to tensor 361, for example, half the size of a stride of 2. Regardless of the stride, the size of the channel dimensions of tensor 363 can vary compared to the channel dimensions of tensor 361 for a given CBL block. Tensor 363 is passed to the batch normalization module 364, which outputs tensor 365. The batch normalization module 364 normalizes the input tensor 363 and applies scaling factors and offset values ​​to generate output tensor 365. The scaling factors and offset values ​​are derived from the training process. Tensor 365 is passed to the LeakyReLU (Leaky Correction Linear Activation) module 366, which generates tensor 367. Module 366 provides an "activation function" through which positive values ​​in the tensor are passed and the magnitude of negative values ​​is reduced significantly, for example, to 0.1x their previous values.

[0060] The tensor 316 is passed from the CBL block 314 to the residual block 11 module 320, which contains a chain of 11 residual units internally.

[0061] The residual block is described with reference to ResBlock340 shown in Figure 3B. ResBlock340 receives tensor 341, which has been zero-padded by zero-padding module 342 to generate tensor 343. Tensor 343 is passed to CBL module 344 to generate tensor 345. Tensor 345 is passed to residual unit 346, and residual block 340 contains a series of concatenated residual units. The last residual unit of residual unit 346 outputs tensor 347. The residual unit is described with reference to ResUnit350, as seen in Figure 3C. ResUnit350 takes tensor 351 as input and passes it to CBL module 352 to generate tensor 353. Tensor 353 is passed to second CBL unit 354 to generate tensor 355. Addition module 356 sums tensor 355 with tensor 351 to generate tensor 357. The summing module 356 is sometimes called a "shortcut" because the input tensor 351 effectively influences the output tensor 357. For an untrained network, ResUnit 350 acts on the passthrough tensor. Once training is performed, the CBL modules 352 and 354 work to separate tensor 357 from tensor 351 according to the training data and ground truth data.

[0062] The Res11 module 320 outputs tensor 322, which is output from the backbone module 310 as one of the layers and also provided to the Res8 module 324. The Res8 module 324 is a residual block (i.e., 340) containing eight residual units (i.e., 350). The Res8 module 324 generates tensor 326, which is passed to the Res4 module 328 and is also output from the backbone module 310 as one of the layers. The Res4 module is a residual block (i.e., 340) containing four residual units (i.e., 350). The Res4 module 324 generates tensor 329, which is output from the backbone module 310 as one of the layers. Together, the layer tensors 322, 326, and 329 are output as tensor 115. The backbone CNN310 can take a video frame with a resolution of 1088×608 as input and generate three tensors corresponding to three layers, with dimensions of [1, 256, 76, 136], [1, 512, 38, 68], and [1, 1024, 19, 34]. The overall CNN shown in Figures 3 and 9 may be partitioned as shown, but other partitions of the overall CNN are also possible. The tensors output from the first convolutions in CBL blocks 912, 926, and 940 (i.e., tensor 363 in each respective CBL module) may be tapped as outputs from the backbone, in which case the first convolutions of upscaler modules 922 and 936 as well as CBL modules 912, 926, and 940 are included in the backbone CNN310. The resulting tensor dimensions are [1, 512, 34, 19], [1, 256, 68, 38], and [1, 128, 136, 76]. When all layers and operations of the YOLOv3 network are enumerated, the tapping tensor 363 in CBL modules 912, 926, and 940 corresponds to the tapping tensor in module 75, module 90, and module 105 of the YOLOv3 network, respectively.The resulting tensor has half the number of feature maps at each resolution compared to the "Darknet-53" output (i.e., 322, 326, and 329).

[0063] Figure 4 is a schematic block diagram showing the functional modules of an alternative backbone portion 400 of a CNN that can function as the CNN backbone 114. The backbone portion 400 implements a residual network with a feature pyramid network ("ResNet FPN") and is an alternative to the CNN backbone 114. Frame data 113 is input and passes through tensors 409, 413, 417, 425 to the stem network 408, res2 module 412, res3 module 416, res4 module 420, res5 module 424, and max pool module 428, the max pool module 428 producing tensor 429 as output. The stem network 408 includes a 7x7 convolution with a stride of 2 and a max pooling operation. The res2 module 412, res3 module 416, res4 module 420, and res5 module 424 perform convolution operations and LeakyReLU activation. Each module 421, 416, 420, and 424 also performs one half of the resolution of the processed tensor via a stride setting of 2. Tensors 409, 413, 417, and 425 are passed to 1x1 transverse convolution modules 440, 442, 444, and 446 to produce tensors 441, 443, 445, and 447. Tensor 441 is passed to 3x3 output convolution module 470 to produce output tensor P5 471. Tensor 441 is also passed to upsampler module 450 to produce upsampled tensor 451. Summarizing module 460 sums tensors 443 and 451 to produce tensor 461, which is passed to upsampler module 452 and 3x3 transverse convolution module 472. Module 472 outputs P4 tensor 473. The upsampler module 452 generates the upsampled tensor 453. The summation module 462 sums tensors 445 and 453 to generate tensor 463, which is then passed to the 3x3 transverse convolution module 474 and the upsampler module 454. Module 474 outputs the P3 tensor 475.The upsampler module 454 outputs the upsampled tensor 455. The summation module 464 sums tensors 447 and 455 to produce tensor 465, which is passed to the 3x3 horizontal convolution module 476. Module 476 outputs the P2 tensor 477. The upsampler modules 450, 452, and 454 use nearest-neighbor interpolation for lower computational cost. Tensors 429, 471, 473, 475, and 477 form the output tensor 115 of the CNN backbone 400.

[0064] Figure 5 is a schematic block diagram showing the feature map quantizer and packer 116 as part of a distributed machine task system 100. Tensor 115 from the CNN backbone 114 is input to a group decision module 510, a range decision module 514, and a quantizer module 518. In other words, the quantizer module 518 performs a mapping function or transfer function from floating-point values ​​to integer values. The group decision module 510 assigns the feature maps (channels) of the input tensor 115 to feature map groups 512 based on a predetermined criterion or some measure of the data present in the tensor 115. The feature map groups 512 may span tensors of different layers or may be limited to individual layers. The feature map groups 512 are passed to the range decision module 514 and output as part of metadata 125. For each group, the range decision module 514 determines a quantization range that represents the maximum amplitude value present in the feature maps belonging to each group, and generates a quantization range 516. The range determination module 514 can determine a new quantization range for every frame, or it can determine a new quantization range at a lower frequency, for example, only on intrapictures.

[0065] Bitstream 121 includes a "qr_update" flag in its metadata (see Appendix A) indicating whether the quantization range has been updated. A single quantization range can be used to represent the maximum magnitude of any pre-quantized value in the feature map of the group to which the quantization range belongs. In another arrangement, separate quantization ranges are used for the maximum positive value and the maximum negative value in the feature map within the feature map group, resulting in an asymmetric quantization range with two values ​​per group.

[0066] Tensor-115 generally has 32-bit floating-point precision values, and therefore each quantization range is also a floating-point value. Other floating-point precisions such as 16-bit and 8-bit are possible, and various bit assignments for the exponent and fractional parts of floating-point values ​​are also possible.

[0067] The quantization range 516 is passed to the quantizer module 518 and output as part of the metadata 125. The quantizer module 518 quantizes each feature map to sample values ​​in two steps. First, the feature map value is normalized using the quantization range of the feature map group to which the feature map belongs, obtaining a value in the range from [-1, 1]. Second, the normalized feature map value is scaled to a sample range corresponding to the bit depth of the video encoder 120. For 10-bit operations, the normalized feature map is multiplied by the feature map group 512, then the offset of the feature map group 512 is added, the sum is converted to integer precision, and output as an integerized feature map 520. The multiplication and addition operations result in the use of at least one value of the minimum or maximum allowable sample value (i.e., 0 or 1023 for 10-bit video) among the feature maps of a given feature map group. To provide some resilience against overshoot that may occur in the output of the video decoder 144, the multiplication coefficient applied to the normalized feature map may be reduced compared to the largest possible multiplication coefficient that can be used without introducing clipping. For regular video represented in the YCbCr color space, a "video range" of 16-235 or 8-bit video data and a "video range" of 64-940 for 10-bit video data are defined. Therefore, the multiplication coefficient can be reduced to 7 / 8 of the total value, resulting in a similar sample range as seen in the video range of YCbCr video data. The resulting multiplication coefficient is 7 / 8 × (1 << (bit_depth-1)). The offset coefficient used to shift negative tensor values ​​to the positive range is left at the midpoint, i.e., 1 << (bit_depth-1), corresponding to the default predictor for the unavailable reference sample for intra prediction, as explained with reference to Figures 6 and 7. If the integer value generated from quantization exceeds the range allowed by the bit depth of the samples in the frame, clipping is applied to ensure that the integer value remains within the bit depth of the samples in the frame.The integerized feature map 520 is passed to the packer module 522, which generates a packed feature map frame 117 containing each feature map of the integerized feature map 520 arranged according to a packing format. The packing format is further described with reference to Figures 11-13. The resulting packed feature map frame 117 is passed to the video encoder 120 via the multiplexer 118.

[0068] Figure 6 is a schematic block diagram showing the functional modules of the video encoder 120. Figure 7 is a schematic block diagram showing the functional modules of the video decoder 144. Generally, data passes between the functional modules in the video encoder 120 and the functional modules in the video decoder 144 in groups of samples or coefficients, or as arrays, such as by dividing blocks into fixed-size subblocks. The video encoder 120 and video decoder 144 may be implemented using a general-purpose computer system 200, as shown in Figures 2A and 2B, and various functional modules may be implemented by dedicated hardware within the computer system 200, or by software executable within the computer system 200, such as one or more software code modules of a software application program 233 residing on a hard disk drive 205 and controlled in its execution by a processor 205. Alternatively, the video encoder 120 and video decoder 144 may be implemented by a combination of dedicated hardware and software executable within the computer system 200. The video encoder 120, the video decoder 144, and the described method may be implemented in dedicated hardware, such as one or more integrated circuits that perform the functions or subfunctions of the described method. Such dedicated hardware may include a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific standard product (ASSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or one or more microprocessors and associated memory. In particular, the video encoder 120 comprises modules 610-690, and the video decoder 144 comprises modules 720-796, each of which may be implemented as one or more software code modules of the software application program 233.

[0069] The video encoder 120 in Figure 6 is an example of a General-Purpose Video Coding (VVC) video encoding pipeline, but other video codecs may also be used to perform the processing stages described herein. The video encoder 120 receives frame data 119, such as a series of frames, each frame containing one or more color channels. The frame data 119 can be any chroma format and bit depth supported by the profile in use, for example, 4:0:0, 4:2:0 for the "Main 10" profile of the VVC standard, with a sample precision of 8 to 10 bits. The block partitioner 610 first divides the frame data 119 into CTUs, which are roughly square in shape and configured so that a specific size is used for the CTU. The maximum effective size of a CTU can be 32×32, 64×64, or 128×128 luma samples, for example, as defined by the "sps_log2_ctu_size_minus5" syntax element present in the "sequence parameter set". The CTU size also provides the maximum CU size, as a CTU without further division contains one CU. The block partitioner 610 further divides each CTU into one or more CBs according to the luma coding tree and chroma coding tree. Luma channels are sometimes called primary color channels. Each chroma channel may also be called a secondary color channel. CBs can be of various sizes and can include both square and non-square aspect ratios. However, in the VVC standard, CBs, CUs, PUs, and TUs always have side lengths that are powers of 2. Thus, the current CB, represented as 612, is output from the block partitioner 610, proceeding according to the luma coding tree and chroma coding tree of the CTU, following iterations across one or more blocks of the CTU.CU or CB is generated by recursively partitioning the CTU using quadtree partitioning (dividing the parent region into four subregions arranged as a 2x2 partition), binary partitioning (dividing the parent region horizontally or vertically into two equally sized subregions), and ternary partitioning (dividing the parent region horizontally or vertically into three subregions with an area ratio of 1:2:1).

[0070] While operation is generally described per CTU, the video encoder 120 and video decoder 144 may operate in smaller regions to reduce memory consumption. For example, each CTU may be divided into smaller regions known as "Virtual Pipelined Data Units" (VPDUs) of size 64x64. VPDUs form a data granularity more suitable for pipeline processing in the hardware architecture, and the reduction in memory footprint reduces silicon area and therefore cost compared to operating for a full CTU. If the CTU size is 128x128, restrictions are placed on the permitted coding tree to ensure that processing of one VPDU is fully completed before proceeding to the next VPDU. For example, at the root node of a coding tree for a 128x128 CTU, ternary partitioning is prohibited because the resulting CUs (32x128 / 128x32, etc., or further decomposition thereof) cannot be processed in the necessary progression from one 64x64 region to subsequent 64x64 regions. If the CTU size is 64x64, regardless of the coding tree selected by the encoder, processing will always complete one 64x64 region before moving on to the next 64x64 region (i.e., from one CTU to the next).

[0071] The CTUs obtained from the first split of frame data 119 may be scanned in raster scan order and grouped into one or more “slice.” A slice may be an “intra” (or “I”) slice. An intra slice (I slice) indicates that all CUs in the slice are intra-predicted. Generally, the first picture in a coded layer video sequence (CLVS) contains only I slices and is called an “intra picture.” A CLVS may contain periodic intra pictures that form “random access points” (i.e., intermediate frames in the video sequence from which decoding may begin). Alternatively, a slice may be a single-predict or a bi-predict (a “P” or “B” slice, respectively), indicating the additional availability of single and bi-predictions within the slice.

[0072] When a chroma format other than 4:0:0 is used, in an I-slice, the coding tree of each CTU may diverge below the 64x64 level into two separate coding trees, one for luma and the other for chroma. The use of separate trees allows for different block structures to exist between luma and chroma within the 64x64 luma area of ​​the CTU. For example, a large chroma CB may colcate with many smaller luma CBs, and vice versa. In a P or B-slice, a single coding tree of a CTU defines a block structure common to luma and chroma. The blocks resulting from a single tree can be intra-predicted or inter-predicted.

[0073] For each CTU, the video encoder 120 operates in two stages. In the first stage (called the “search” stage), the block partitioner 610 tests various potential configurations of the coding tree. Each potential configuration of the coding tree has an associated “candidate” CB. The first stage involves testing various candidate CBs to select a CB that provides relatively high compression efficiency with relatively low distortion. The tests generally involve Lagrangian optimization, thereby evaluating candidate CBs based on a weighted combination of rate (i.e., coding cost) and distortion (i.e., error relative to the input frame data 119). The “best” candidate CB (i.e., the CB with the lowest evaluated rate / distortion) is selected for subsequent encoding to the bitstream 121. The evaluation of candidate CBs includes the option of using the CB for a given area, or further dividing the area according to various partitioning options and coding each of the smaller resulting areas with further CBs, or further dividing the area. As a result, both the coding tree and the CBs themselves are selected in the search stage.

[0074] The video encoder 120 generates a prediction block (PB) indicated by arrow 620 for each CB, for example, CB612. PB620 is the prediction of the content of the associated CB612. The subtractor module 622 generates a difference (or "residual," referring to the difference in the spatial domain) between PB620 and CB612, indicated as 624. Difference 624 is the block size difference between the corresponding samples in PB620 and CB612. Difference 624 is transformed, quantized, and represented as a transformed block (TB) indicated by arrow 636. PB620 and the associated TB636 are typically selected from one of many possible candidate CBs, for example, based on an evaluated cost or distortion.

[0075] The candidate coding block (CB) is a CB that arises from one of the prediction modes available to the video encoder 120 due to the associated PB and the resulting residual. When combined with the predicted PB in the video encoder 120, TB636 reduces the difference between the decoded CB and the original CB612 at the expense of additional signals in the bitstream.

[0076] Therefore, each candidate coding block (CB), i.e., a prediction block (PB) combined with a transformation block (TB), has an associated coding cost (or "rate") and an associated difference (or "distortion"). The distortion of a CB is estimated as a difference in sample values, typically such as the sum of absolute differences (SAD), the sum of squared differences (SSD), or the Hadamard transform applied to the difference. The resulting estimate from each candidate PB may be determined by the mode selector 686 using the difference 624 to determine the prediction mode 687. The prediction mode 687 indicates a decision to use a specific prediction mode for the current CB, e.g., intra-frame prediction or inter-frame prediction. Estimating the coding cost associated with each candidate prediction mode and its corresponding residual coding can be performed at a significantly lower cost than the entropy coding of the residuals. Therefore, several candidate modes may be evaluated to determine the optimal mode in rate distortion detection, even in real-time video encoders.

[0077] Determining the optimal mode with respect to rate distortion is typically achieved using variations of Lagrangian optimization.

[0078] Lagrangian or similar optimization processes can be used for both selecting the optimal partitioning of the CTU to the CB (by the block partitioner 610) and selecting the best prediction mode from multiple possibilities. Through the application of the Lagrangian optimization process of the candidate modes in the mode selection module 686, the intra-prediction mode with the lowest cost measurement is selected as the "best" mode. The lowest cost mode includes the selected quadratic transformation index 688, which is also encoded in the bitstream 121 by the entropy encoder 638.

[0079] In the second stage of operation of the video encoder 120 (called the "coding" stage), the video encoder 120 performs iterations against the determined coding tree for each CTU. For CTUs using separate trees, for each 64x64 luma region of the CTU, the luma coding tree is encoded first, followed by the chroma coding tree. Within the luma coding tree, only luma CBs are encoded, and within the chroma coding tree, only chroma CBs are encoded. For CTUs using a shared tree, a single tree describes the CUs (i.e., luma CBs and chroma CBs) according to the common block structure of the shared tree.

[0080] The entropy encoder 638 supports bitwise coding of syntax elements using variable-length and fixed-length codewords, as well as an arithmetic coding mode for syntax elements. Parts of a bitstream, such as "parameter sets," e.g., sequence parameter sets (SPS) and picture parameter sets (PPS), use a combination of fixed-length and variable-length codewords. A slice, also called a continuum, has a slice header using variable-length coding, followed by slice data using arithmetic coding. The slice header defines parameters specific to the current slice, such as the slice-level quantization parameter offset. The slice data contains the syntax elements for each CTU in the slice. The use of variable-length and arithmetic coding requires sequential parsing within each part of the bitstream. Parts may be delimited by start codes to form "network abstraction layer units" or "NAL units." Arithmetic coding is supported using a context-adaptive binary arithmetic coding process.

[0081] Arithmetically coded syntax elements consist of a sequence of one or more "bins." A bin, like a bit, has a value of either "0" or "1." However, bins are not encoded as discrete bits within bitstream 121. A bin has an associated predicted (or "most likely" or "highest probability") value and an associated probability known as the "context." When the actual bin to be coded matches the predicted value, the "Most Probable Symbol" (MPS) is coded. Coding the most likely symbol is relatively inexpensive in terms of bits consumed within bitstream 121, costing less than one discrete bit. If the actual bin to be coded does not match any of the possible values, the "Least Probable Symbol" (LPS) is coded. Coding the least likely symbol is relatively expensive in terms of bits consumed. The bin coding technique allows for efficient coding of bins where the "0" vs. "1" probabilities are skewed. For syntax elements with two possible values ​​(i.e., "flags"), a single bin is appropriate. For syntax elements with many possible values, a sequence of bins is required.

[0082] The existence of a later bin in a sequence may be determined based on the value of the previous bin in the sequence. Furthermore, each bin may be associated with two or more contexts. The selection of a particular context may depend on previous bins in the syntax element, the bin values ​​of adjacent syntax elements (i.e., those from adjacent blocks), and so on. Each time a context-coded bin is encoded, the context selected for that bin (if any) is updated in a way that reflects the new bin value. Thus, binary arithmetic coding is said to be adaptive.

[0083] Furthermore, the entropy encoder 638 supports bins without context, called "bypass bins." Bypass bins are coded assuming an equal probability distribution between "0" and "1." Thus, each bin has a coding cost of 1 bit in bitstream 121. The absence of context saves memory and reduces complexity, and therefore bypass bins are used when the distribution of values ​​in a particular bin is not skewed. An example of an entropy coder that uses context and adaptation is known in the art as CABAC (Context Adaptive Binary Arithmetic Coder), and many variations of this coder are used in video coding.

[0084] The entropy encoder 638 encodes the quantization parameter 692, and when used for the current CB, encodes the LFNST index 388 using a combination of context-coded and bypass-coded bins. The quantization parameter 692 is encoded using "delta QP". Delta QP is signaled at most once in each area known as a "quantization group". The quantization parameter 692 is applied to the residual coefficients of the luma CB. The adjusted quantization parameter is applied to the residual coefficients of the collated chroma CB. The adjusted quantization parameter may include mapping from the luma quantization parameter 692 according to a CU level offset selected from a list of offsets and a mapping table. The quadratic transformation index 688 is signaled when it contains significant residual coefficients only at coefficient positions where the residuals associated with the transformation block are transformed into linear coefficients by the application of the quadratic transformation.

[0085] The multiplexer module 684 outputs the PB620 from the intra-frame prediction module 664 according to the determined best intra-prediction mode selected from the tested prediction modes of each candidate CB. The candidate prediction modes do not need to include all possible prediction modes supported by the video encoder 120. Intra-predictions are divided into three types: firstly, “DC intra-prediction” involves populating the PB with a single value representing the mean of nearby reconstructed samples; secondly, “planar intra-prediction” involves populating the PB with samples according to a plane, where the DC offset and vertical and horizontal slopes are derived from nearby reconstructed adjacent samples; thirdly, “angle intra-prediction” involves populating the PB with reconstructed neighbor samples filtered and propagated across the PB in a particular direction (or “angle”), typically consisting of a row of reconstructed samples above the current PB extending to the right of the PB to some extent, a column of reconstructed samples to the left of the current PB extending downward beyond the PB to some extent, and a third “angle intra-prediction”. VVC supports 65 angles, and rectangular blocks can utilize additional angles that are not available to square blocks, resulting in a total of 87 angles.

[0086] A fourth type of intra-prediction is available for ChromaPB, where the PB is generated from luma-reconstructed samples collated according to a "cross-component linear model" (CCLM) mode. Three different CCLM modes are available, each using a different model derived from adjacent luma and chroma samples. The derived models are used to generate blocks of samples for ChromaPB from the collated luma samples. Luma blocks can be intra-predicted using matrix multiplication of a reference sample with a matrix selected from a predefined set of matrices. This matrix intra-prediction (MIP) achieves gain by using a matrix trained on a large set of video data, where the matrix represents a relationship between the reference sample and the predicted block that is not readily captured in angular, plane, or DC intra-prediction modes.

[0087] Module 664 may also generate prediction units by copying blocks from near the current frame using the “intra-block copy” (IBC) method. The location of the reference block is constrained to a region corresponding to one CTU divided into 64x64 areas known as VPDUs, which cover the VPDUs of previous CTUs and the processed VPDUs of the current CTU up to the region limit of one CTU. This region is known as the “IBC virtual buffer” and limits the IBC reference region, and therefore limits the memory required. The IBC buffer is populated in the reconstructed sample 654 (i.e., before loop filtering), and therefore a separate buffer to the frame buffer 672 is required.

[0088] The residuals of predicted blocks when encoding feature-map data differ from those seen for natural video. Such natural video is typically captured by image sensors or screen content, as commonly found in operating system user interfaces, etc. Feature-map residuals tend to contain a lot of detail, which is suitable for transforms that skip more coding than the predominantly low-frequency coefficients of various transforms. Experiments show that feature-map residuals have enough local similarity to benefit from transform coding. However, the distribution of feature-map residual coefficients does not cluster toward the DC (top-left) coefficient of the transform blocks. In other words, there is enough correlation that the transforms show gain when encoding feature-map data, and this is also true when intra-block copies are used to generate predicted blocks of feature-map data. Therefore, Hadamard cost estimation can be used when encoding feature-map data to evaluate the residuals arising from candidate block vectors of intra-block copies, rather than relying solely on SAD or SSD cost estimation. SAD or SSD cost estimation tends to select block vectors with residuals that are better suited to transforming skip coding, potentially missing block vectors with residuals that can be compactly encoded using the transform. The VVC standard's Multiple Transform Selection (MTS) tool can be used when encoding feature map data, as combinations of DST-7 and DCT-8 transforms, in addition to the DCT-2 transform, are available horizontally and vertically for residual coding.

[0089] The intra-predicted lumacoding block can be divided vertically or horizontally into sets of prediction blocks of equal size, each block having a minimum area of ​​16 luma samples. This intra-subpartition (ISP) approach improves compression efficiency by allowing separate transformation blocks to contribute to the generation of prediction blocks from one subpartition to the next within the lumacoding block.

[0090] If previously reconstructed adjacent samples are unavailable, for example at the edge of a frame, a default halftone value of half the sample range is used. For example, in 10-bit video, a value of 512 is used. Since no previous samples are available for the CB located at the top-left position of the frame, the angle and plane intra-prediction modes produce the same output as the DC prediction mode (i.e., the plane of the sample with halftone values ​​as magnitude).

[0091] In interframe prediction, the prediction block 682 is generated by the motion compensation module 680 using samples from one or two frames preceding the current frame in the coding order frames within the bitstream, and output as PB620 by the multiplexer module 684. Furthermore, in interframe prediction, a single coding tree is typically used for both the lumens and chroma channels. The order in which frames are coded in the bitstream may differ from the order in which frames are captured or displayed. When one frame is used for prediction, the block is said to be a "single prediction" and has one associated motion vector. When two frames are used for prediction, the block is said to be a "double prediction" and has two associated motion vectors. In the case of a P slice, each CU can be intra-predicted or single-predicted. In the case of a B slice, each CU can be intra-predicted, single-predicted, or double-predicted.

[0092] Frames are typically coded using a “group of pictures” structure, allowing for a temporal hierarchy of frames. Frames can be divided into multiple slices, each of which encodes a portion of the frame. The temporal hierarchy of frames allows frames to reference preceding and succeeding pictures in the order in which they are displayed. Images are coded in the order necessary to ensure that dependencies for decoding each frame are satisfied. Instead of using one or two motion vectors to select and filter reference sample blocks for the prediction unit, an affine interprediction mode is available where the prediction unit is divided into multiple smaller blocks, generating a motion field, and thus each smaller block has a distinct motion vector. The motion field uses the motion vectors of points near the prediction unit as “control points”. Affine prediction allows for coding motion to different transformations with less need for deeply divided coding trees. The biprediction mode available for VVC performs a geometric blend of two reference blocks along a selected axis, with angles and offsets from the center of the signaled block. This geometric division mode ("GPM") allows the use of larger coding units along the boundary between two objects, with the geometry of the boundary coded for the coding unit being used as an angle and center offset. Instead of using Cartesian (x,y) offsets, the motion vector difference can be coded as direction (up / down / left / right) and distance using a supported set of powers of two distances. The motion vector predictor is taken from the adjacent block ("merge mode") as if no offset were applied. The current block shares the same motion vector as the selected adjacent block.

[0093] Samples are selected according to motion vector 678 and reference picture index. Motion vector 678 and reference picture index are applied to all color channels, and therefore interpretation is primarily described in terms of operation in PU rather than PB. The decomposition of each CTU into one or more interpretation blocks is described using a single coding tree. The interpretation method can vary in the number of motion parameters and their precision. Motion parameters typically consist of a reference frame index indicating which reference frame from a list of reference frames should be used, and a spatial transformation for each of the reference frames, but may include more frames, dedicated frames, or complex affine parameters such as scaling and rotation. In addition, predetermined motion refinement processes may be applied to generate dense motion estimates based on the referenced sample blocks.

[0094] By determining and selecting PB620 and subtracting PB620 from the original sample block with subtractor 622, a residual with the lowest coding cost, represented as 624, is obtained and undergoes lossy compression. The lossy compression process includes the steps of transformation, quantization, and entropy coding. The forward linear transformation module 626 applies a forward transformation to the difference 624, transforming the difference 624 from the spatial domain to the frequency domain and generating linear transformation coefficients represented by arrows 628. The maximum linear transformation size in one dimension is either a 32-point DCT-2 or 64-point DCT-2 transformation, defined by "sps_max_luma_transform_size_64_flag" in the sequence parameter set. If the CB being encoded is larger than the maximum supported linear transformation size represented as a block size (e.g., 64×64 or 32×32), the linear transformation 626 is applied in a tiling manner to transform all samples of the difference 624. When non-square CBs are used, tiling is also performed using the largest available transformation size at each dimension of the CB. For example, when a maximum transformation size of 32 is used, a 64×16 CB will use two 32×16 linear transformations arranged in a tiled manner. When a CB is larger than the maximum supported transformation size, the CB is filled with TBs in a tiled manner. For example, a 128×128 CB with a maximum transformation size of 64-pt will be filled with four 64×64 TBs in a 2×2 arrangement. A 64×128 CB with a maximum transformation size of 32-pt will be filled with eight 32×32 TBs in a 2×4 arrangement.

[0095] The application of transformation 626 results in multiple TBs for the CB. If each application of the transformation operates on a difference 624 larger than 32×32, for example, a 64×64 TB, all resulting linear transformation coefficients 628 outside the upper left 32×32 area of ​​the TB are set to zero (i.e., discarded). The remaining linear transformation coefficients 628 are passed to the quantizer module 634. The linear transformation coefficients 628 are quantized according to the quantization parameter 692 associated with the CB to produce linear transformation coefficients 632. In addition to the quantization parameter 692, the quantizer module 634 may also apply a “scaling list” to enable heterogeneous quantization within the TB by further scaling the residual coefficients according to their spatial position within the TB. The quantization parameter 692 may differ for luma CBs versus each chroma CB. The linear transformation coefficients 632 are passed to the forward quadratic transformation module 630, which performs an inseparable quadratic transformation (NSST) operation or bypasses the quadratic transformation to produce transformation coefficients represented by arrow 636. The forward linear transformation is typically separable, transforming a set of rows, and then a set of columns for each TB. The forward linear transformation module 626 uses either the Type II Discrete Cosine Transform (DCT-2) horizontally and vertically, or a bypass of the transformation horizontally and vertically, or a combination of the Type VII Discrete Sine Transform (DST-7) and Type VIII Discrete Cosine Transform (DCT-8) horizontally or vertically for Luma TBs whose width and height do not exceed 16 samples. The use of the combination of DST-7 and DCT-8 is referred to as a “Multiple Transform Selection Set” (MTS) in the VVC standard.

[0096] The forward quadratic transform of module 630 is generally an inseparable transform, which is applied only to the residuals of the intra-predicted CU, and can nevertheless be bypassed. The forward quadratic transform operates on either 16 samples (configured as a 4x4 subblock in the upper left of the linear transform coefficients 628) or 48 samples (configured as three 4x4 subblocks in the 8x8 coefficients in the upper left of the linear transform coefficients 628) to generate a set of quadratic transform coefficients. The set of quadratic transform coefficients may be fewer in number than the set of linear transform coefficients from which they are derived. By applying the quadratic transform only to sets of coefficients that are adjacent to each other and contain DC coefficients, the quadratic transform is called a "low-frequency inseparable quadratic transform" (LFNST). Furthermore, when the LFNST is applied, all remaining coefficients in the TB are zero in both the linear and quadratic transform regions.

[0097] The quantization parameter 692 is constant for a given TB and therefore results in uniform scaling for generating residual coefficients in the linear transformation domain for TB. The quantization parameter 692 can vary periodically along with the signaled "delta quantization parameter". The delta quantization parameter (delta QP) is signaled once for each CU contained within a given area, called a "quantization group". If the CU is larger than the quantization group size, the delta QP is signaled once using one of the TBs of the CU. That is, the delta QP is signaled once by the entropy encoder 638 for the first quantization group of the CU and not for any subsequent quantization groups of the CU. Non-uniform scaling is also possible by applying a "quantization matrix", thereby deriving the scaling coefficient applied to each residual coefficient from a combination of the quantization parameter 692 and the corresponding entry in the scaling matrix. The scaling matrix can be smaller in size than the size of the bitstream (TB), and when applied to the TB, a nearest-neighbor approach is used to provide the scaling value for each residual coefficient from a scaling matrix smaller in size than the TB. The residual coefficients 636 are fed to the entropy encoder 638 for encoding in the bitstream 121. Typically, the residual coefficients of each TB having at least one significant residual coefficient of the TU are scanned according to a scanning pattern to generate an ordered list of values. The scanning pattern generally scans the TB as a sequence of 4x4 "subblocks," providing regular scanning behavior with a granularity of 4x4 sets of residual coefficients, and the arrangement of the subblocks depends on the size of the TB. Scanning within each subblock and progressing from one subblock to the next typically follows a backward oblique scanning pattern. In addition, the quantization parameter 692 is encoded in the bitstream 121 using delta QP syntax elements, and the quadratic transformation index 688 is encoded in the bitstream 121.

[0098] As described above, the video encoder 120 needs to access the frame representation corresponding to the decoded frame representation seen in the video decoder 144. Therefore, the residual coefficient 636 passes through the inverse quadratic transform module 644 and operates according to the quadratic transform index 688 to produce the intermediate inverse transform coefficient represented by arrow 642. The intermediate inverse transform coefficient 642 is inversely quantized by the inverse quantizer module 640 according to the quantization parameter 692 to produce the inverse transform coefficient represented by arrow 646. The inverse quantizer module 640 may also perform inverse heterogeneous scaling of the residual coefficient using a scaling list, corresponding to the forward scaling performed in the quantizer module 634. The inverse transform coefficient 646 is passed to the inverse linear transform module 648 to produce the residual sample of TU, ​​represented by arrow 650. The inverse linear transform module 648 applies the DCT-2 transform horizontally and vertically, constrained by the maximum available transform size, as described with reference to the forward linear transform module 626. The type of inverse transformation performed by the inverse quadratic transformation module 644 corresponds to the type of forward transformation performed by the forward quadratic transformation module 630. The type of inverse transformation performed by the inverse linear transformation module 648 corresponds to the type of linear transformation performed by the linear transformation module 626. The adder module 652 adds the residual samples 650 and PU 620 to produce a reconstructed sample of CU (indicated by arrow 654).

[0099] The reconstructed sample 654 is passed to the reference sample cache 656 and the in-loop filter module 668. Typically implemented using static RAM on the ASIC to avoid costly off-chip memory access, the reference sample cache 656 provides the minimum sample storage required to satisfy the dependency for generating an intra-frame PB for subsequent CUs in the frame. The minimum dependency typically includes a "line buffer" of samples along the bottom of the row of CTUs for use by the next row of CTUs, and column buffering whose range is set by the height of the CTUs. The reference sample cache 656 feeds the reference sample (represented by arrow 658) to the reference sample filter 660. The sample filter 660 applies a smoothing operation to generate filtered reference samples (indicated by arrow 662). The filtered reference sample 662 is used by the intra-frame prediction module 664 to generate an intra-predicted block of samples, represented by arrow 666. For each candidate intra-prediction mode, the intra-frame prediction module 664 generates a block of samples, i.e., 666. The block of samples 666 is generated by module 664 using techniques such as DC, planar, or angular intra-prediction. The block of samples 666 can also be generated using a matrix multiplication approach with adjacent reference samples as input and a matrix selected by the video encoder 120 from a set of matrices, the selected matrix being signaled in the bitstream 120 using an index to identify which matrix from the set of matrices should be used by the video decoder 144.

[0100] The In-Loop Filter Module 668 applies several filtering stages to the reconstructed sample 654. These filtering stages include a “Deblocking Filter” (DBF) that applies aligned smoothing to the CU boundary to reduce artifacts caused by discontinuities. The Deblocking Filter smooths block edges where coding artifacts may be seen, arising from the transformation basis functions that cause misaligned boundaries along the block boundary, and such artifacts are more visible at higher values ​​of the quantization parameter 692. At lower values ​​of the quantization parameter 692, the filtering intensity of the Deblocking Filter is reduced. Another filtering stage present in the In-Loop Filter Module 668 is the “Adaptive Loop Filter” (ALF), which applies a Wiener-based adaptive filter to further reduce distortion. A further filtering stage available in the In-Loop Filter Module 668 is the “Sample Adaptive Offset” (SAO) filter. The SAO filter first categorizes the reconstructed sample into one or more categories and then applies an offset at the sample level according to the assigned category.

[0101] The filtered sample, represented by arrow 670, is output from the in-loop filter module 668. The filtered sample 670 is stored in the frame buffer 672. The frame buffer 672 typically has the capacity to store several (e.g., up to 16) pictures and is therefore stored in memory 206. The frame buffer 672 is typically not stored using on-chip memory due to the large memory consumption required. Therefore, access to the frame buffer 672 is costly in terms of memory bandwidth. The frame buffer 672 provides the reference frame (represented by arrow 674) to the motion estimation module 676 and the motion compensation module 680.

[0102] The motion estimation module 676 estimates several “motion vectors” (represented as 678), each being a Cartesian space offset from the current CB position and referencing a block in one of the reference frames in the frame buffer 672. A filtered block of reference samples (represented as 682) is generated for each motion vector. The filtered reference samples 682 form further candidate modes available for potential selection by the mode selector 686. Furthermore, for a given CU, the PU620 can be formed using one reference block ("single-predicted") or two reference blocks ("double-predicted"). For the selected motion vector, the motion compensation module 680 generates the PB620 according to a filtering process that supports sub-pixel precision in the motion vector. Thus, the motion estimation module 676 (which operates for many candidate motion vectors) can achieve reduced computational complexity by performing a simplified filtering process compared to that of the motion compensation module 680 (which operates only for selected candidates). When the video encoder 120 selects an interpretation for the CU, the motion vector 678 is encoded into the bitstream 121.

[0103] The video encoder 120 in Figure 6 is described with reference to General-Purpose Video Coding (VVC), but other video coding standards or implementations may also employ the processing stages of modules 610-690. The frame data 119 (and bitstream 121) is also stored in memory 206, hard disk drive 210, CD-ROM, and Blu-ray disc. TMor can be read from (or written to) other computer-readable storage media. Furthermore, the frame data 119 (and bitstream 121) can be received from (or transmitted to) an external source such as a communication network 220 or a server connected to a radio frequency receiver. The communication network 220 may provide limited bandwidth and requires the use of rate control in the video encoder 120 to avoid saturating the network when it is difficult to compress the frame data 119. Furthermore, the bitstream 121 can be constructed from one or more slices representing spatial sections (collections of CTUs) of the frame data 119, generated by one or more instances of the video encoder 120, which operate cooperatively under the control of the processor 205.

[0104] The video decoder 144 is shown in Figure 7. The video decoder 144 in Figure 7 is an example of a general-purpose video coding (VVC) video decoding pipeline, but other video codecs may also be used to perform the processing stages described herein. As shown in Figure 7, the bitstream 143 is input to the video decoder 144. The bitstream 143 is input to memory 206, hard disk drive 210, CD-ROM, Blu-ray disc. TM or it may be read from another non-temporary computer-readable storage medium. Alternatively, bitstream 143 may be received from an external source such as a server connected to a communication network 220 or a radio frequency receiver. Bitstream 143 includes encoded syntax elements representing captured frame data to be decoded.

[0105] Bitstream 143 is input to the entropy decoder module 720. The entropy decoder module 720 extracts syntax elements from bitstream 143 by decoding a sequence of “bins” and passes the values ​​of the syntax elements to other modules in the video decoder 144. The entropy decoder module 720 uses variable-length and fixed-length decoding to decode arithmetic decoding engines, SPS, PPS, or slice headers, decoding the syntax elements of the slice data as a sequence of one or more bins. Each bin can have one or more “contexts,” which describe the probability levels used to code the “1” and “0” values ​​of the bin. If multiple contexts are available for a given bin, a “context modeling” or “context selection” step is performed to select one of the available contexts for decoding the bin. The bin decoding process forms a sequential feedback loop, so that each slice can be decoded in its entirety by a given instance of the entropy decoder 720. A single (or a small number of) high-performance entropy decoder 720 instances can decode all slices of a frame from bitstream 143, while multiple low-performance entropy decoder 720 instances can decode slices of a frame from bitstream 143 simultaneously.

[0106] The entropy decoder module 720 decodes syntax elements from the bitstream 143 by applying an arithmetic coding algorithm, such as "Context-Adaptive Binary Arithmetic Coding" (CABAC). The decoded syntax elements are used to reconstruct parameters in the video decoder 144. The parameters include mode selection information such as residual coefficients (represented by arrow 724), quantization parameters 774, quadratic transformation index 770, and intra-prediction mode (represented by arrow 758). The mode selection information also includes information such as motion vectors and the division of each CTU into one or more CBs. The parameters are used to generate PBs, which are typically combined with sample data from previously decoded CBs.

[0107] The residual coefficients 724 are passed to the inverse quadratic transform module 736, where, according to the quadratic transform index, the quadratic transform is applied or the operation is not performed (bypassed). The inverse quadratic transform module 736 generates reconstructed transform coefficients 732, i.e., linear transform coefficients, from the quadratic transform region coefficients. The reconstructed transform coefficients 732 are input to the inverse quantizer module 728. The inverse quantizer module 728 performs inverse quantization (or "scaling") on the residual coefficients 732, i.e., the linear transform coefficient region, to create reconstructed intermediate transform coefficients, represented by the arrow 740, according to the quantization parameter 774. The inverse quantizer module 728 may also apply a scaling matrix to provide heterogeneous inverse quantization within the TB, corresponding to the operation of the inverse quantizer module 640. If the use of a heterogeneous inverse quantization matrix is ​​indicated in the bitstream 143, the video decoder 144 reads the quantization matrix from the bitstream 143 as a sequence of scaling factors and places the scaling factors into the matrix. Inverse scaling uses the quantization matrix in combination with the quantization parameters to create a reconstructed intermediate transformation coefficient of 740.

[0108] The reconstructed conversion coefficients 740 are passed to the inverse linear transformation module 744. Module 744 transforms the coefficients 740 back from the frequency domain to the spatial domain. The inverse linear transformation module 744 applies the inverse DCT-2 transformation horizontally and vertically, constrained by the maximum available transformation size, as described with reference to the forward linear transformation module 626. The result of the operation of module 744 is a block of residual samples represented by arrow 748. The size of the block of residual samples 748 is equal to the corresponding CB. The residual samples 748 are fed to the adder module 750.

[0109] In the addition module 750, the residual sample 748 is added to the decoded PB (represented as 752) to generate a reconstructed sample block, represented by the arrow 756. The reconstructed sample 756 is supplied to the reconstructed sample cache 760 and the in-loop filtering module 788. The in-loop filtering module 788 generates a reconstructed block of frame samples, represented as 792. The frame sample 792 is written to the frame buffer 796.

[0110] The reconfigured sample cache 760 operates similarly to the reconfigured sample cache 656 of the video encoder 120. The reconfigured sample cache 760 provides storage for the reconfigured samples necessary to intra-predict subsequent CBs without memory 206 (for example, by using data 232, which is typically on-chip memory, instead). The reference sample represented by arrow 764 is taken from the reconfigured sample cache 760 and fed to the reference sample filter 768 to produce the filtered reference sample indicated by arrow 772. The filtered reference sample 772 is fed to the intra-frame prediction module 776. Module 776 generates a block of intra-prediction samples represented by arrow 780 according to the intra-prediction mode parameter 758, which is signaled in the bitstream 143 and decoded by the entropy decoder 720. The intra-prediction module 776 supports the modes of module 664, including IBC and MIP. The block of samples 780 is generated using modes such as DC, planar, or angular intra-prediction.

[0111] When the prediction mode of the CB is indicated to use intra-prediction in bitstream 143, the intra-predicted sample 780 forms the decoded PB 752 via the multiplexer module 784. Intra-prediction generates a predicted block (PB) of samples, which is a block in one color component derived using “adjacent samples” in the same color component. Adjacent samples are samples adjacent to the current block and have already been reconstructed by preceding the block decoding order. When luma blocks and chroma blocks are collated, different intra-prediction modes may be used for the luma blocks and chroma blocks. However, two chroma CBs share the same intra-prediction mode.

[0112] When the prediction mode of the CB is indicated as inter-prediction in bitstream 143, the motion compensation module 734 generates a block of inter-prediction samples represented as 738. The block of inter-prediction samples 738 is generated using the motion vector decoded from bitstream 143 by the entropy decoder 720 and a reference frame index for selecting and filtering the block of samples 798 from the frame buffer 796. The block of samples 798 is obtained from previously decoded frames stored in the frame buffer 796. In the case of bi-prediction, two blocks of samples are generated and blended together to generate the samples for the decoded PB 752. The frame buffer 796 is populated with filtered block data 792 from the in-loop filtering module 788. Similar to the in-loop filtering module 668 of the video encoder 120, the in-loop filtering module 788 applies one of the DBF, ALF, and SAO filtering operations. Generally, motion vectors are applied to both lunar and chroma channels, but the filtering processes for subsample interpolation in lunar and chroma channels differ.

[0113] Although not shown in Figures 6 and 7, there is a module for pre-processing the video before encoding and post-processing the video after decoding to shift sample values ​​so that a more uniform use of the range of sample values ​​within each chroma channel is achieved. The multi-segment linear model is derived in the video encoder 120 and signaled in the bitstream for use by the video decoder 144 to undo the sample shift. This linear model chroma scaling (LMCS) tool offers compression advantages for certain color spaces and content with some degree of heterogeneity, particularly limited range utilization, in the use of sample space, which can result in higher quality loss from the application of quantization.

[0114] Figure 8 is a schematic block diagram showing the feature map inverse quantizer and unpacker 148 as part of the distributed machine task system 100. The decoded frame 147 is input to the unpacker module 810, where feature maps are extracted from each frame according to the packing format to produce an unpacked feature map 812. The unpacked feature map 812 contains the sample values ​​present in the decoded frame 147. The packing format is further described with reference to Figures 11-13. The set of feature maps in the unpacked feature map 812 is assigned to groups according to the feature map group 820 obtained from the decoded metadata 155, such that each feature map belongs to one group, and one or more groups are shown in the feature map group 820. The inverse quantizer 814 then performs scaling to convert the integer sample values ​​present in the unpacked feature map 812 into floating-point values ​​present in the tensor 149. The scaling uses a quantization range for the group of feature maps. The quantization range is obtained from the quantization range 822 extracted from the decoded metadata 155. The quantization range specifies the maximum magnitude of any floating-point value found in the feature maps belonging to the corresponding group. The inverse quantizer 814 normalizes the samples from the feature maps 812 of each group to a range centered on zero and reaching 1 or -1, depending on whether the sign of the detected maximum amplitude value is positive or negative. In the rare case where the maximum magnitude has equal positive and negative values, the range [-1, 1] is observed. The normalized samples of the feature map group are then multiplied (scaled) by the quantization range of the feature map group.

[0115] When all groups of the feature maps are scaled, the result is output as intermediate data in the form of Tensor 149. Tensor 149 may include a plurality of tensors each having a different spatial resolution, for example, when the CNN backbone 114 includes an FPN. In addition to using zero-centered linear symmetric quantization processing, other quantization processes are also possible. For example, an asymmetric approach can be used where positive and negative quantization ranges are signaled for each group of feature maps. The positive and negative quantization ranges map the range utilized by the floating-point values of the group of features to the full sample range given by the bit depth of the samples, which results in asymmetric quantization as the midpoint of the sample range which is no longer guaranteed to correspond to a zero floating-point value. The "quant_type" syntax element within the SEI message 1413 selects the quantization approach and is described by reference to Appendix A.

[0116] The quantization range for a given group of feature maps is derived from the values within the group of feature maps, but the quantization range needs to hold the same data type as the values within the group of feature maps. A coarser floating-point precision may be used and rounding is applied so that the range when represented in the original floating-point format (e.g., 32-bit IEEE754 format) is not reduced. For example, at step 1550, a coarser floating-point precision can be used by rounding up. Rounding up can be achieved by adding a constant value ε to the quantization range qr, resulting in an adjusted quantization range qr adjust to be generated, where ε = 2 floor(log2(qr)) / 2 fract_prec where frac_prec is the number of fractional bits to be preserved and the "floor" operator then rounds towards the next negative integer. Next, the leftmost bit of the fractional part of qr adjust is incorporated into and coded in the SEI message, and the remaining bits are truncated, resulting in qr adjustIt cannot be a value smaller than qr. The precision of the quantization range with respect to the bits allocated to the fractional part is selected using the “qr_fraction_precision” syntax element, which is described with reference to Appendix A. By setting qr_fraction_precision(fract_prec) to 5, the quantization range can be precisely set, with a worst-case increase of ~3% compared to the fractional precision of the original floating-point value, i.e., before reducing the fractional precision to 5 bits. A leading “1” is prepended to the fractional part to generate the mantissa of the quantization range (i.e., the quantization range does not have to be a “non-normal” value). Since the quantization range is always positive, it is not necessary to encode a sign bit for each quantization range. Since the quantization range can be greater than or less than 1, a sign bit is required for the quantization range exponent. In the arrangement of system 100, quantization ranges less than 1.0 are not allowed, and the quantization exponent sign bit may be omitted from SEI message 1413. If the quantization exponent code bit is not coded, the quantization range determination module 514 clips the quantization range less than 1.0 to the value 1.0.

[0117] Although the operation of the inverse quantizer module 814 and the quantizer module 518 is called "quantization," the operation of modules 518 and 814 differs from the quantization operation of the video encoder 120 and video decoder 144, which involve the use of quantization parameters. Furthermore, the operation of modules 518 and 814 can be considered a form of tone mapping operation, involving a conversion between the floating-point domain of the tensor and the sample domain of the frame. There is scaling (i.e., via the quantization range of each group of feature maps) for the purpose of utilizing a wide range of sample value spaces, but there are no quantization parameters applicable to modules 518 and 814 to further change the quantizer step size.

[0118] Figure 9A is a schematic block diagram showing the head portion 150 of a CNN for object detection. Depending on the task to be performed on the destination device 140, a different network can be used instead of the CNN head 150. The input tensor 149 is separated into tensors for each layer (i.e., tensors 910, 920, and 934). Tensor 910 is passed to the CBL module 912 to produce tensor 914, which is then passed to the detection module 916 and the upscaler module 922. The bounding box 918 in the form of the detection tensor is passed to the non-maximal suppression (NMS) module 948 to produce the detection result 151. Scaling by the original video width and height is performed before resizing the backbone portion of the network 114 to generate a bounding box that addresses coordinates in the original video data 113 (see "orig_source_width" and "orig_source_height", decoded from SEI message 1413 and described in Appendix A). The upscaler module 922 generates an upscaled tensor 924, which is passed to the CBL module 926, which generates tensor 928 as its output. Tensor 928 is passed to the detection module 930 and the upscaler module 936. The detection module 930 generates a detection tensor 932, which is fed to the NMS module 948. The upscaler module 936 is another instance of module 960 and outputs the upscaled tensor 938. The upscaled tensor 938 is passed to the CBL module 940, which outputs tensor 942 to the detection module 944. CBL modules 912, 926, and 940 each contain a concatenation of five CBL modules. The upscaler modules 922 and 936 are each instances of the upscaler module 960 as shown in Figure 9B.

[0119] The upscaler module 960 accepts tensor 962 as input and passes it to the CBL module 966 to generate tensor 968. Tensor 968 is passed to the upsampler 970 to generate the upsampled tensor 972. The concatenation module 974 generates tensor 976 by concatenating the upsampled tensor 972 with the input tensor 964. Detection modules 916, 930, and 944 are instances of the detection module 980 as shown in Figure 9C. Detection module 960 receives tensor 982 and passes it to the CBL module 984 to generate tensor 986. Tensor 986 is passed to the convolution module 988, which implements the detection kernel. The detection kernel 1x1 kernel is applied to generate the output of feature maps in three layers. The detection kernel is 1 × 1 × (B x (5 + C)), where B is the number of bounding boxes a particular cell can predict, typically 3, and C is the number of possible classes, which is 80, resulting in a kernel size of 255 detection attributes (i.e., tensor 990). The constant "5" represents four bounding box attributes (box center x, y and size scale x, y) and one object confidence level ("objectiness"). The result of the detection kernel has the same spatial dimensions as the input feature map, but the depth of the output corresponds to the detection attributes. The detection kernel is applied to each layer, typically three layers, resulting in a large number of candidate bounding boxes. A non-maximal suppression process is applied to the resulting bounding boxes by the NMS module 948, discarding redundant boxes such as duplicate predictions at similar scales, resulting in a final set of bounding boxes as the output for object detection.

[0120] Figure 10 is a schematic block diagram showing the alternative head portion 1000 of the CNN. The head portion 1000 forms part of the overall network known as “faster RCNN” and includes the feature network (i.e., the backbone portion 400), the region proposal network, and the detection network. The input to the head portion 1000 is tensor 149, which contains the P2-P6 layer tensors 1010, 1012, 1014, 1016, and 1018. The P2-P6 tensors 1010, 1012, 1014, 1016, and 1018 are input to the Region Proposal Network (RPN) head module 1020. The RPN head module 1020 performs convolution on the input tensors to produce intermediate tensors that feed into two subsequent sibling layers, one for classification and the other for bounding boxes, or “Regions of Interest” (ROIs), which are then regressed as classification and bounding boxes 1022. The classification and bounding boxes 1022 are passed to the NMS module 1024, which prunes redundant bounding boxes by removing duplicate boxes with lower scores, thereby generating pruned bounding boxes 1026. The bounding boxes 1026 are passed to the Region of Interest (ROI) puller 1028. The ROI puller 1028 uses a max pooling operation to generate a fixed-size feature map from various input-size maps, and subsampling takes the maximum value within each group of input values ​​to generate a single output value in the output tensor.

[0121] The inputs to the ROI pooler 1028 are the P2-P5 feature maps 1010, 1012, 1014, and 1016, as well as the region of interest proposal 1026. Each proposal (ROI) from 1026 is associated with a portion of the feature maps (1010-1016) to generate a fixed-size map. The fixed-size map is independent of the size of the underlying portion of the feature maps 1010-1016. One of the feature maps 1010-1016 is selected such that the resulting cropped map has sufficient detail according to the following rule, for example: floor(4+log2(sqrt(box_area) / 224), where 224 is the normal box size. Thus, the ROI puller 1028 crops the input feature map according to proposal 1026, which generates tensor 1030. Tensor 1030 is fed to a fully connected (FC) neural network head 1032. The FC head 1032 runs two fully connected layers to generate a class score and bounding box predictor delta tensor 1034. The class score is generally 80 The element tensor is an 80x4=320-element tensor containing the bounding boxes for the corresponding object categories. Final processing is performed by the output layer module 1036, which receives tensor 1034 and performs a filtering operation to produce the filtered tensor 1038. Low-scoring (low-classification) objects are excluded from further consideration. The non-maximal suppression module 1040 removes duplicate bounding boxes by removing duplicate boxes with lower classification scores, resulting in the inference output tensor 151.

[0122] Figure 11 is a schematic block diagram showing a feature map packing arrangement 1100 in a two-dimensional array in the form of a monochrome frame 1102. Three layers of feature maps, such as feature map 1110, feature map 1112, and feature map 1114, can be placed within frame 1102. In the example in Figure 11, frame 1102 contains regions corresponding to each feature map (e.g., feature map 1110). Feature maps 1110, 1112, and 1114 are placed in a raster scan arrangement that fills the monochrome frame 1102. The size of frame 1102 is first set according to the area of ​​all feature maps placed in frame 1102, and has an aspect ratio close to the aspect ratio of the target UHD frame, i.e., 3840 / 2160 = 1.78. The resolution can be increased, for example, by increasing the width and height to multiples of the minimum block size, such that the width and height are each multiples of 4. When arranging feature maps, due to the mismatch between feature map size and frame width, the final frame height may be increased to provide adequate space, allowing for some unused space resulting from the inability to pack feature maps together without unused space. The sample value in unused space within frame 1102, such as unused space 1104, is set to the midpoint tone point of the frame's bit depth, i.e., 512 for a 10-bit frame. The size of the feature map depends on the CNN backbone 114. For the "Darknet-53" backbone, the size is 136×76 for feature map 1110, with 256 instances; 68×38 for feature map 1112, with 512 instances; and 34×19 for feature map 1120, with 1024 instances. For clarity, Figure 12 shows frame 1202 with fewer feature maps than would be present in a typical application, but the three layers and relative resolutions are represented in Figure 12 as described below. Different CNNs and different partitions between the "backbone" and "head" sections of a CNN can result in different dimensions and numbers of feature maps for each layer, as well as different numbers of layers (i.e., more than three layers).

[0123] When arranging feature maps in a two-dimensional array in the form of a monochrome frame 1102, feature maps of the same group within a frame are placed adjacent to each other within frame 1102. For example, group 1106 contains feature map 1110, and groups 1108 and 1109 contain the remaining feature maps in the layer. Similarly, group 1114 contains feature map 1112, which has two additional groups for the layer. For brevity, grouping for the layer containing the smallest feature map (i.e., feature map 1120) is not shown, but the same group-by-group packing technique is used. Within each group, the feature maps exist in a determined order, and their arrangement within the monochrome frame 1102 reflects this order.

[0124] When placing feature maps in the monochrome frame 1202 of Figure 12, alignment with a specific boundary, such as a 4x4 grid boundary, can be maintained. If the feature map size is not a multiple of such alignment, unused sample space exists between adjacent feature maps. For example, a 34x19 feature map occupies a 36x20 sample area, with the unused space occupied by intermediate tone sample values. The presence of unused space between feature maps reduces the occurrence of coding artifacts within a single feature map caused by content in adjacent feature maps and improves the alignment of feature maps with respect to the underlying block structure of the video codec. For example, in the case of VVC, a minimum block size of 4x4 is typically used.

[0125] In addition to aligning feature maps to a specific alignment grid, minimum padding can also be implemented between feature maps, such as between two samples. Minimum padding helps prevent artifacts within a single feature map caused by content in adjacent feature maps when the feature map size is a multiple of the alignment grid. For example, a 136x76 feature map fits into a 4x4 alignment grid without any unused sample space inserted between itself and adjacent feature maps. The minimum padding area ensures some separation between adjacent feature maps, which can help reduce coding artifacts that cross from one feature map to an adjacent one.

[0126] Figure 12 is a schematic block diagram showing an alternative feature map packing arrangement 1200 in a monochrome frame 1202. Feature map packing arrangement 1200 is suitable for feature map groupings where multiple groupings of four feature maps exist. The groupings in Figure 12 can be based on spatial similarity between feature maps, resulting in groupings of similar feature maps. Spatial similarity can be measured using absolute difference sums, square difference sums, or some other similarity measure. The groupings are applied to feature maps within the same layer and do not span multiple layers. As seen in Figure 12, grouping 1210 contains four feature maps. The feature maps of grouping 1210 are arranged in the monochrome frame 1202 using sample-wise interleaving so that they occupy a 2x2 area of ​​constituent feature maps. Sample-wise interleaving results in higher structural detail of the four feature maps shared by the same coding tree structure, with the details between the four feature maps differing from sample to sample. Therefore, a common coding tree structure and shared residuals (excluding local differences necessary to code adjacent samples of different feature maps) are achieved, resulting in increased compression efficiency. Once all groups of size 4 are packed into a monochrome frame 1202 for a given layer, the remaining feature maps, such as feature map 1214, are packed adjacently based on their grouping, but not in an interleaved manner. The remaining feature maps can be assigned to groups of any size, regardless of the packing order, as their group configuration does not affect the packing process. In the next layer, four groups, such as group 1220, are packed using a sample-wise interleaved method, followed by feature maps belonging to groups of other sizes, such as feature map 1224. For the final layer, four groups, such as group 1230, are packed using a sample-wise interleaved method, followed by feature maps belonging to groups of other sizes, such as feature map 1234.

[0127] Figure 13 is a schematic block diagram showing a feature map packing arrangement 1300 in a 4:2:0 chroma subsampling color frame 1301. A group of feature maps containing two or three feature maps with a high degree of similarity and belonging to different layers is placed in different color channels within a collated region of the color frame 1301. Thus, the position of at least part of the first feature map in one layer corresponds relative to the position of at least part of the second feature map in another layer. In the case of two feature maps in adjacent layers, the larger feature map is placed in the chroma plane 1302, such as feature map 1304. The smaller of the two feature maps is placed in the chroma plane 1310, such as feature map 1314. If the group contains three feature maps, the third feature map is smaller in size than the feature map placed in the chroma plane 1310, and the third feature map is packed into the second chroma plane 1320 so that its size is doubled, resulting in a double-packed feature map 1324. Since two or three feature maps in a group are grouped based on spatial similarity, in the example of Figure 13, coding tools targeting interchannel correlation are available to improve compression efficiency when coding color frame 1301. For example, tools that attempt to predict chroma samples from luma based on a difference model, such as a linear model targeting cross-color component prediction, could be applied. In the case of an interslice where the shared coding tree designates luma coding blocks and chroma coding blocks, the block structure of two or three feature maps is coded using a single coding tree instead of requiring separate coding trees, as if the feature maps were located in different positions.

[0128] Figure 14 is a schematic block diagram showing bitstream 1400, which holds the encoded packed feature map and associated metadata. Bitstream 1400 corresponds to bitstream 121 generated by video encoder 120 or bitstream 143 decoded by video decoder 134. The bitstream contains a group of syntax preceded by a “Network Abstraction Layer” unit header. For example, NAL unit header 1408 precedes sequence parameter set (SPS) 1410. SPS 1410 may contain “Profile Level Tier” (PLT) units of syntax 1438, which may contain “General Constraint Information” (GCI) units of syntax (i.e., constraint flag 1440). Constraint flag 1440 is present in SPS 1410 if “gci_present_flag” is present in SPS 1410 and equal to 1; otherwise, constraint flag 1440 is not present in SPS 1410. When constraint flags are present in SPS1410, any one that is activated indicates that bitstream 1400 conforms to a restricted subset (which may correspond to subprofiles) of tools or functions indicated within the signaled profile of bitstream 1400. When constraint flags are not present in SPS1410, each constraint flag that would otherwise be signaled is inferred to have a value of zero, and the bitstream conforms to the signaled profile of bitstream 1400. Each flag in constraint flags 1440, when set, indicates the disabling of a particular tool within the VVC standard, along with the flag semantics defined in the VVC standard. A separate set of syntax elements (zero or more instances of the ptl_num_sub_profiles and general_sub_profile_idc syntax elements) identifies a particular subprofile that the bitstream conforms to, and the definition of a subprofile is defined outside the VVC standard. The GCI includes a set of flags, each constraining a particular coding tool that is not used in bitstream 1400.The PLT1438 can signal a specific set of tools, known as a “profile,” that can be used in bitstream 1400. An example of a profile is “Main10,” which provides 8- to 10-bit video with either 4:0:0 or 4:2:0 chroma format and targets a broad range of applications. The GCI may indicate further constraints on the set of tools in a profile, which may correspond to a subset of tools. Generally, when the video encoder 120 is encoding video samples (i.e., from video source 112 via multiplexer 118), all tools in a given profile can be used to efficiently encode frame data. When the video encoder 120 is encoding feature maps packed into frames (i.e., from module 116), some tools in the VVC standard no longer provide a compression advantage. Tools that do not provide a compression advantage to packed feature maps do not need to be tried by the video encoder 120 and can be signaled in the GCI as not being used in bitstream 1400. SPS1410 also indicates the resolution of the frame data, represented by the chroma format, bit depth, and bitstream 1400.

[0129] The Picture Parameter Set (PPS) 1412 contains syntax elements that control the lower-level behavior of the tool, including the control of the deblocking filter. PPS1412 includes pps_deblocking_filter_control_present_flag, which, when set, indicates that the deblocking filter setting is controlled in PPS1412. When pps_deblocking_filter_control_present_flag is set, pps_deblocking_filter_disabled_flag is present in PPS1412. When pps_deblocking_filter_disabled_flag is present in PPS1412 and set to 1, the deblocking filter is disabled for all pictures that reference PPS1412 unless further overrides of the deblocking control occur in the picture header or slice header 1418 of the picture. If pps_deblocking_filter_disabled_flag exists in PPS1412 and is set to 1, then pps_deblocking_filter_override_enabled_flag exists in PPS1412. When pps_deblocking_filter_override_enabled_flag exists and is set to 1 in PPS1412, each picture's slice header 1418 or picture header includes an additional flag that can override the enabling or disabling of the deblocking filter indicated by pps_deblocking_filter_disabled_flag.

[0130] SEI message 1413 encodes the feature map grouping 1430 as determined by the group determination module 510 and the quantization range 1432, as determined by the range determination module 514. Appendix A shows exemplary syntax and semantics of SEI message 1413. The packing format used by the packer module 522 may also be encoded in SEI message 1413 using an index for selecting one feature packing format from an enumeration of all available feature packing formats. The specific CNN backbone used to generate the feature map may also be indicated in SEI message 1413 using an index for selecting one CNN backbone from an enumeration of a given set of CNN backbones, some or all of which are available to the source device 110. From the CNN backbone type index, the number of layers and channels in each layer, as well as the resolution of each feature map in each layer, may be determined. For groupings where the feature maps in a given group are in the same layer, a separate group list of feature map indices is coded for each layer. For groupings where a given group of feature maps can span multiple layers, the feature map index and layer index pairs are coded as items within each group. For groupings where those feature maps are in adjacent layers and each layer has at most one feature map, the layer index is only required for the first feature map in the group. If a group contains feature maps from all layers, for example, in all three layers, the feature map index is implicitly applied to one feature map in each layer, so a group index is not required. If all feature maps from a given layer belong to a separate layer, one quantization range is coded for each layer.

[0131] Each frame is encoded within the bitstream 1400 as an “access unit,” such as access unit 1414, as seen in Figure 14. Each access unit contains one or more slices, such as slice 1416. For the first access unit of the bitstream, and generally for “random access point” access units, the intra-slice is used to avoid any predictive dependency on other access units in the bitstream 1400. Slice 1416 contains a slice header 1418 followed by slice data 1420. Slice data 1420 contains a sequence of CTUs that give a coded representation of the frame data. CTUs are square, typically 128x128 in size, which is not well-matched to typical feature map sizes. Placing feature maps in the smallest block size, such as a 4x4 grid, partially mitigates this misalignment.

[0132] Figure 15 shows Method 1500 for executing the first part of a CNN and encoding the resulting feature maps for frames of video data. Method 1500 can be implemented using a configured FPGA, ASIC, or ASSP or similar device. Alternatively, as described below, Method 1500 can be implemented by the source device 110 as one or more software code modules of an application program 233 under the execution of a processor 205. The software code modules of the application program 233 that implement Method 1500 can reside, for example, in a hard disk drive 210 and / or memory 206. Method 1500 is repeated for each frame of video data generated by the video source 112. Method 1500 can be stored in a computer-readable storage medium and / or memory 206.

[0133] Method 1500 begins with the execution of the CNN in first part step 1510. In step 1510, the CNN backbone 114, under the execution of processor 205, executes a subset of the layers of a particular CNN to convert the input frame 113 into an intermediate tensor 115. Using a prediction head or FPN, the tensor 115 may contain multiple tensors. Method 1500 operates to encode a tensor corresponding to one frame of video data from video source 112. Control in processor 205 then proceeds from step 1510 to the feature map similarity determination step 1520. The intermediate tensor 115 may be stored, for example, in memory 206 and / or on a hard disk drive 210.

[0134] In the feature map similarity determination step 1520, module 116 generates a similarity matrix containing a measure of similarity between each feature map and each feature map within each layer, under the execution of processor 205. The similarity matrix may be stored, for example, in memory 206 and / or hard disk drive 210. The similarity measure may be the mean squared difference (MSE) of two feature maps, the sum of absolute differences (SAD) of two feature maps, or some other measure of difference. If it is desired to measure the similarity of feature maps in different layers, feature maps with lower spatial resolution may be upscaled (for example, using nearest neighbor interpolation) to produce a resolution compatible with a higher spatial resolution for the purpose of difference measurement. To reduce computational overhead, step 1520 is performed rarely, for example, for each random access point in the CLVS, or only for the first picture of the CLVS. Next, control in processor 205 proceeds from step 1520 to the feature map grouping determination step 1530.

[0135] In the feature map group determination step 1530, the group determiner 510, under the control of the processor 205, determines the set of groups to which the feature maps will be assigned. The groups of feature maps may be stored, for example, in memory 206 and / or hard disk drive 210. The operation of the group determiner 510 is illustrated with reference to Figure 17. Step 1530 should be performed when the similarity matrix of step 1520 has been determined, for example, for the first picture in the CLVS or for all random access points in the CLVS. Control in the processor 205 proceeds from step 1530 to the feature map placement determination step 1540.

[0136] In the feature map placement determination step 1540, the packer module 522, under the execution of the processor 205, determines the position in which each feature map will be placed within the frame. When the frame is a monochrome frame, the feature maps are placed in the raster scan order that fills the frame area, and the frame area is initialized based on the total area of ​​all feature maps to be packed into the frame and the target aspect ratio. The packing arrangement is described with reference to Figures 11-13. The packing format in use is determined from the "packing_format" syntax element decoded from SEI message 1413, as described with reference to Appendix A. Feature maps belonging to a given group are packed sequentially, in the order in which the feature maps are listed within each group. As described with reference to Figure 13, groups of feature maps of size 2 or 3, each having a feature map belonging to a different layer, are packed together spatially but in different color channels. Since the number and size of feature maps do not change during the operation of the source device 110, the placement is determined once and can be saved for use with subsequent frames. The packed frames can be stored, for example, in memory 206 and / or hard disk drive 210. Next, control in processor 205 proceeds from step 1540 to group range determination step 1550.

[0137] In the group range determination step 1550, the range determiner 514, under the execution of the processor 205, determines the range of floating-point data in each group of feature maps determined in step 1530. The determined ranges may be stored, for example, in memory 206 and / or hard disk drive 210. In symmetric operation, the group range is the maximum magnitude (absolute) value of the value in the feature map belonging to the group. The range provides a value for normalizing the feature map data before quantization and conversion to integer sample values. In asymmetric operation, positive and negative ranges are determined for each group of feature maps, indicating the largest positive and largest negative values ​​encountered within the group of feature maps. The quantization range is determined for each group of feature maps in tensor 115. The quantization range may be determined for the tensor of all frames of video data, or a lower frequency update may be applied. To reduce signaling overhead, the quantization range may be determined only for intra-pictures or random-access pictures in the video bitstream. The range of the floating-point data tensor for subsequent frames whose quantization range has not been determined may exceed the previously determined quantization range. A safety margin may be introduced by increasing the size of the quantization range determined by some specified scaling factor. Multiplying the quantization range by a fixed coefficient, e.g., 8 / 7, compresses the sample range of the data used to a range that roughly corresponds to the video range used in YCbCr video data. Subsequent frames, for which the quantization range may not be determined, have some headroom to exceed this range up to the limit of the sample bit depth, e.g., [0..1023] for 10-bit video. Control in processor 205 then proceeds from step 1550 to feature map quantization step 1560.

[0138] In the feature map quantization step 1560, the quantizer module 518, under the execution of the processor 205, quantizes each feature map from floating-point values ​​to integer sample values ​​according to the quantization range of the group to which the feature map belongs. The determined integer sample values ​​can be stored, for example, in memory 206 and / or hard disk drive 210. Scaling to a normalized range with a maximum value of 1.0 is performed first, followed by multiplication to the sample range and addition of an offset, resulting in the use of a substantial portion of the sample size. For 10-bit video, a multiplication factor 512 is used, and an offset quant_offset 512 is also used. Smaller multiplication factors may be used to reduce nonlinear effects from overshoot that may be introduced by video encoders 120 and 144. If the quantization range has not yet been adjusted by a fixed factor such as 8 / 7 to align with the video range commonly used in YCbCr video data, a scaling factor scale_f of 7 / 8x512=448 may be used. For 8-bit video data, an offset of 128 and a scaling factor of 128 or 112 may be used for video range-aligned operation. If the quantization range is determined for a tensor from the previous frame and has not been updated for the current frame, it is possible for input floating-point values ​​to exceed the quantization range for the feature map group to which the feature map belongs. To prevent overflow when mapping floating-point values ​​to integer sample values, a clipping operation is applied. In one arrangement of quantizer module 518, clipping to the range indicated by the quantization range of the floating-point value is applied to prevent overflow. Clipping of the floating-point value to the quantization range ensures that all samples are within the range [quant_offset-scale_f, quant_offset+scale_f]. In another arrangement of quantizer module 518, clipping is applied after quant_offset and scale_f are applied, at which point the determined value can fall outside the range indicated by the bit depth, and is applied before conversion to integer sample values.Clipping is applied to ensure that the integer sample values are within the range indicated by the bit depth, i.e., [0..(1<<bit_depth)-1]. Clipping after scaling and before integer conversion, in combination with the scale_f value that utilizes a smaller range such as the video range, allows some headroom in subsequent frames to exceed the quantization range determined from the previous frame. There is also some tolerance for a certain amount of overshoot in the operation of the video encoder 120 and video decoder 144 before clipping introduces non-linear distortion into the conversion from the floating-point tensor to integer and back to the floating-point tensor. Next, the control in the processor 205 proceeds from step 1560 to the feature map pack step 1570.

[0139] In the feature map pack step 1570, the pack module 522 packs the integer feature map 520 under the execution of the processor 205 to generate the packed feature map frame 117. The quantized feature map 520 corresponding to the feature map from each layer of the tensor 115 can be stored, for example, in a memory buffer configured within the memory 206 that holds one frame of video data and / or the hard disk drive 210. Referring to FIGS. 11-13, the packing format of the feature map will be described. Next, the control in the processor 205 proceeds from step 1570 to the metadata encoding step 1580.

[0140] In metadata encoding step 1580, the entropy encoder 638, under the execution of processor 205, encodes the feature map grouping 512 and quantization range 516, i.e., metadata 125, into bitstream 121. Metadata 125 can be encoded as SEI message 1413. The format of SEI message 1413 is described with reference to Appendix A. Next, control in processor 205 proceeds from step 1580 to frame encoding step 1590. In the first picture (picture order count equal to 0), the "layers_update", "groups_update", and "qr_update" flags in SEI message 1413 are set, and the feature map layers and dimensions, feature map group definitions, and associated quantization ranges are encoded in bitstream 121. The "qr_update" flag in SEI message 1413 may be set periodically, and the quantization range information is updated accordingly. In a random access configuration, every random access point or intra-picture may contain an updated quantization range. In a low-latency configuration, periodic updates of the quantization range may occur for inter-pictures, for example, one picture approximately every second, corresponding to the intra-picture periodicity in a random access configuration. Updating the quantization range of several inter-pictures allows for continuous adaptation to data independent of the bitstream structure (i.e., intra / inter-slice selection), for example, when intra-pictures occur very rarely in the bitstream.

[0141] In the frame encoding step 1590, the video encoder 120 encodes frame 119 into a bitstream 121 under the execution of processor 205. When source device 110 is configured to encode feature maps, frame 119 is obtained from a packed feature map frame 117 via multiplexer 118. When source device 110 is configured to encode feature maps, the video encoder 120 may use a subset of coding tools available for profiling video coding standards. This subset of coding tools may be signaled using common constraint flags. For example, the "Main10" profile may be signaled in profile level tier syntax 1438 in bitstream 120, and general constraint flags 1440 may signal that the following tools: LFNST (via gci_no_lfnst_constraint_flag), MIP (via gci_no_mip_constraint_flag), LMCS (via gci_no_lmcs_constraint_flag), ISP (via gci_no_isp_constraint_flag), Affine (via gci_no_affine_motion_constraint_flag), GPM (via gci_no_gpm_constraint_flag), and MMVD (via gci_no_mmvd_constraint_flag) are not used in bitstream 120. In addition to, or instead of using, GCI flags, subprofiles can be defined outside the VVC standard for feature map coding and identified within the bitstream using specific values ​​of the general_sub_profile_idc syntax element, which may be included in SPS1410. Disabling deblocking filters improves compression efficiency when coding feature maps and enhances task performance.In the VVC coding standard, the deblocking filter is disabled for pictures that reference the picture parameter set in bitstream 121 with pps_deblocking_filter_disabled_flag set to "1", unless it is overridden at the slice or picture level by coding sh_deblocking_filter_disabled_flag to a value of "1" or by coding ph_deblocking_filter_disabled_flag to a value of "1". Deblocking is not explicitly disabled using constraint flags in VVC standard version 1, and therefore disabling the deblocking filter does not constitute part of a tool subset that may be equivalent to subprofiles for feature map coding, despite such disabling showing merit. Method 1500 is completed, and processing in processor 205 proceeds to the next frame.

[0142] Figure 16 shows Method 1600 for decoding feature maps from encoded data and executing the second part of a CNN. Method 1600 can be implemented by a device such as a configured FPGA, ASIC, or ASSP. Alternatively, as described below, Method 1600 can be implemented by a destination device 140 as one or more software code modules of an application program 233 under the execution of a processor 205. Method 1600 is repeated for each frame of video data encoded in a bitstream 143. The software code modules of the application program 233 that implement Method 1600 can be stored, for example, in a hard disk drive 210 and / or memory 206. Method 1600 begins with a feature map grouping decoding step 1610. Method 1600 is configured to determine one or more parameters related to quantization and perform inverse quantization on data samples decoded from the encoded data to derive feature maps according to one or more parameters. In one configuration, Method 1600 is configured to deinterleave feature maps corresponding to groups of feature maps after inverse quantization has been performed. As will be described in detail below, Method 1600 may be used to determine feature maps based on images of a first group of feature maps placed in a first frame (or two-dimensional array) and a second group of feature maps placed in a second frame (or two-dimensional array), where the first frame is different from the second frame.

[0143] In the feature map grouping decoding step 1610, the entropy decoder 720, under the execution of the processor 205, decodes from the SEI message 1413 a structure indicating the assignment of each feature map of each layer to one or more groups of feature maps (i.e., feature map groups 820). The decoded structure can be stored, for example, in memory 206 and / or hard disk drive 210. The syntax of feature map grouping in the SEI message 1413 is described with reference to Appendix A. Control in the processor 205 then proceeds from step 1610 to the quantization range decoding step 1620.

[0144] In the quantization range decoding step 1620, the entropy decoder 720, under the execution of the processor 205, decodes the parameters for each feature map group of 820 in the form of a quantization range 822, as determined from the SEI message 1413 in step 1610. The quantization range 822 is shared by each of the multiple feature maps within a feature map group. The quantization range 822 determined in step 1620 can be stored, for example, in memory 206 and / or hard disk drive 210. When symmetric quantization is used, in step 1620, a single value is decoded for each feature map group, representing the maximum size of the floating-point data in the feature maps belonging to each group. When asymmetric quantization is used in step 1620, a pair of values ​​representing the maximum and minimum values ​​of the floating-point data in the feature maps belonging to each group are decoded for each feature map group. The processor 205 may operate to perform step 1620 for all frames of the video data, or it may operate to perform step 1620 less frequently. Step 1620 may be performed on random access points or intrapictures in the bitstream 143. When step 1620 is not performed for all frames, the feature map grouping and quantization range data are carried over to subsequent frames for reuse until a new set of feature map grouping and / or quantization range data is decoded from the bitstream 143. Control in the processor 205 then proceeds from step 1620 to frame decoding step 1630.

[0145] In the frame decoding step 1630, the entropy decoder 114 operates under the execution of the processor 205 to generate a frame 145 by decoding a portion of the bitstream 143 corresponding to an access unit such as AU 1414. The frame 145 may contain a packed feature map or an image corresponding to a frame from, for example, a video source 112. If the frame 145 contains an image frame, i.e., does not contain a packed feature map, method 1600 ends, and decoding proceeds to the next frame. The frame 145 generated in step 1630 can be stored, for example, in memory 206 and / or hard disk drive 210. If the frame 145 contains a packed feature map, the processor 205 proceeds from step 1630 to the feature map placement determination step 1640.

[0146] In the feature map placement determination step 1640, the unpacker module 810, under the execution of the processor 205, determines the position of each feature map in each layer within frame 145. Using the spatial size of each feature map, the feature map grouping, and the number of feature maps in each layer, the placement information is determined according to the approach of step 1540, as described with reference to Figures 11-13. If the feature map size, quantity, and packing format do not change compared to the previous frame, the feature map placement data is retained from the previous frame. Control in the processor 205 then proceeds from step 1640 to the feature map unpacking step 1650.

[0147] In the feature map unpacking step 1650, the unpacker module 810, under the execution of the processor 205, extracts samples from the frame 147 and generates an integer feature map 812 according to the feature map arrangement determined from step 1640. The integer feature map 812 determined in step 1650 can be stored, for example, in memory 206 and / or hard disk drive 210. Next, control in the processor 205 proceeds from step 1650 to the feature map inverse quantization step 1660.

[0148] In the feature map inverse quantization step 1660, the inverse quantization module 814, under the execution of processor 205, converts the integer feature map 812 to a floating-point feature map and assembles it into tensor 149 as input to the CNN head 150. The floating-point feature map can be stored, for example, in memory 206 and / or hard disk drive 210. Integer samples are converted to floating-point precision, and the quant_offset and scale_f values ​​in step 1560 are used to shift the samples to a normalized range. For each feature map in the feature map group, the normalized range value is multiplied by the quantization range 822 of the feature map group 820 to create a floating-point feature map. The floating-point feature maps are assembled into tensor 119 as a multidimensional array, where the dimensions are generally (frames, channels, height, width). If an FPN is used, the assembly works to write the feature map from a set of tensors in 119 corresponding to the FPN layer into a single tensor. Control in processor 205 proceeds from step 1660 to step 1670, which is the execution step of the second part of the CNN.

[0149] In the second part execution step 1670 of the CNN, the CNN head 150 executes the remaining stages of the CNN (i.e., stages specific to the particular task) under the execution of the processor 205. The decoded, unpacked, and inversely quantized tensor 149 is input to the CNN head 150. Within the CNN head 150, a series of convolution, normalization, fully connected layer operations, and activation stages are performed to obtain the CNN result 151. The CNN result 151 is stored in a task result buffer 152 configured, for example, in memory 206. Step 1600 ends, and control in the processor 205 proceeds to the next frame.

[0150] In one arrangement of method 1600, steps 1610 and 1620 are performed when indicated by flags in SEI message 1413. Step 1610 is performed when indicated by the "groups_update" flag decoded from SEI message 1413, and step 1620 is performed when indicated by the "qr_update" flag similarly decoded from SEI message 1413.

[0151] Figure 17 shows a method for determining the grouping of feature maps. Method 1700 can be embodied by a configured device such as an FPGA, ASIC, or ASSP. Alternatively, as described above, Method 1700 can be implemented by the source device 110 as one or more software code modules of the application program 233 under the execution of the processor 205. The software code modules of the application program 233 that implement Method 1700 can be stored, for example, in the hard disk drive 210 and / or memory 206. Method 1700 begins in the list initialization step 1710.

[0152] In the list initialization step 1710, the group decisionator 510, under the execution of the processor 205, creates a set of groups such that each feature map in a given layer is assigned to a single group. The groups are represented as an ordered list of feature maps, each having adjacency relationships within a group to indicate the similarity of pairs of feature maps. The ordered list is initialized and can be stored in memory 206 and / or the hard disk drive 210. Control in the processor 205 then proceeds from step 1710 to step 1720, which finds the most similar pair of feature maps.

[0153] In step 1720, the group decisionator 510, under the execution of the processor 205, determines the pair of feature maps with the greatest similarity in the similarity matrix from step 1520. Since the similarity matrix is ​​a measure of the difference between feature maps, the pair with the greatest similarity is identified by the position in the matrix that has the minimum value. If the similarity matrix indicates that no further pairs of feature maps are similar (i.e., all entries are set to "not-a-number" (NaN)), this value is returned. Next, control in the processor 205 proceeds from step 1720 to the remaining map test step 1730.

[0154] In the remaining map test step 1730, the group decisionator 510, under the execution of the processor 205, determines whether all pairs of feature maps were identified in step 1720. If step 1720 returns NaN, then all groups of feature maps are considered for joining and it is not necessary to further join the groups together (i.e., two smaller groups form one larger group). If it is not necessary to further join the groups together, method 1700 terminates and a set of groups is obtained as a result. If not, and there are no pairs of feature maps with measured similarity (i.e., the result of the minimum operation is not NaN), then control in the processor proceeds from step 1730 to the group determination discovery step 1740.

[0155] In the group index determination step 1740, the group determinist 510, under the execution of the processor 205, determines which group each feature map belongs to and the index of each feature map within that group. Next, control in the processor 205 proceeds from step 1740 to the group test step 1750, which is connectable from step 1740.

[0156] In the connectable group test step 1750, the group decisionator 510, under the execution of the processor 205, determines whether a pair of feature maps can be connected to form one larger group. If either feature map is in the middle of its corresponding group, it is impossible to connect the feature maps to each other, as the nodes in the list may only have preceding and succeeding nodes. The entry in the similarity matrix corresponding to the pair of feature maps is set to NaN, preventing further consideration of this pair of feature maps. Similarly, if two feature maps belong to the same group, the entry in the similarity matrix corresponding to the pair of feature maps is then set to NaN, preventing further consideration of joining these two feature maps. If both feature maps are at the beginning or end of their respective groups, the feature maps can be connected to each other, making it possible to form one larger group from the two initial groups. In configurations where the group size is limited to a certain number of feature maps, for groups that can be joined, if the resulting group size exceeds the group size limit, the entry in the similarity matrix corresponding to the pair of feature maps is set to NaN, and the groups are not joined to each other. To reduce iterations in determining feature map groups, the group size is limited, and if, after joining, the resulting group is equal to the group size, the rows and columns in the similarity matrix corresponding to each endpoint of the newly formed group are set to NaN, preventing further consideration of these feature maps for joining to a larger group. If groups are joined, control in the processor 205 proceeds to the group joining step 1760.

[0157] In the group connection step 1760, the group determiner 510, under the execution of the processor 205, connects two groups containing the pairs of feature maps identified in step 1720. These groups are connected so that the pairs are adjacent in the newly formed larger group. The connected groups determined in step 1760 may be stored, for example, in memory 206 and / or hard disk drive 210. When a feature map is in a previous group of two or more feature maps and is connected to another group, the feature map now occupies some position in the center of the newly formed larger group. When a feature map becomes an intermediate node in a list or group, the rows and columns in the similarity matrix corresponding to that feature map are set to NaN, preventing further consideration of joining that feature map to other groups. The processor 205 then proceeds from step 1760 to step 1720 to determine the next pair of feature maps that should be considered for joining to a larger group.

[0158] In one arrangement, all feature maps within each layer are merged into a single group. When packed according to packing format 1100, the resulting feature map arrangement places similar feature maps relatively close together. The VVC's intrablock copy coding tool can then be used to predict a portion of one feature map from previous and adjacent feature maps, subject to some constraints on block selection arising from the IBC virtual buffer. Since the residuals of feature maps are continuous and tend to be coded more efficiently using various transformations, IBC search can use the Hadamard transformation as a cost estimate, in addition to, or instead of, the SAD cost estimate.

[0159] In another arrangement, the group size is limited to four. When the group size is limited to four, the "four-group" feature maps may be arranged using the sample-wise interleaving packing format 1200 to achieve compression efficiency from shared block structures and some shared predictive signals among the four feature maps. A similarity threshold may be applied in the execution of method 1700 so that only groups of four feature maps that are very similar are determined. Other, less similar feature maps may be assigned to one larger residual group that is packed in a raster scan format.

[0160] In yet another arrangement, groups may be determined across layers and their size may be limited to 3, which is particularly suitable for 3-layer FPNs. Interlayer grouping is packed in a collated manner using packing arrangement 1300, allowing the use of VVC cross-component prediction tools to improve compression efficiency. Combinatorial grouping is possible when interlayer grouping is used to collate feature maps across layers, while intralayer grouping places groups based on the layers occupying the luma channels of the frame.

[0161] In yet another arrangement, there is one group per layer, and all the feature maps of a layer reside within that group. Within the group, the ordering of feature maps is encoded, allowing similar feature maps within a layer to be placed close together so that tools such as IBC can predict one feature map from adjacent feature maps.

[0162] In yet another configuration, there is one group per layer, and within each group, the feature maps are arranged according to the channel indices of their tensors. In such a configuration, one quantization range is coded per layer, resulting in lower overhead for quantization range coding in SEI message 1413.

[0163] Because various grouping approaches are possible, the "grouping_type" syntax element is included in SEI message 1413 and is further explained in Appendix A.

[0164] Figure 18 illustrates a method for selecting a set of coding tools or functions for a video standard, depending on the type of frame data to be encoded. Method 1800 can be implemented by a configured device such as an FPGA, ASIC, or ASSP. Alternatively, as described below, Method 1800 can be implemented by a source device 110 as one or more software code modules of an application program 233 under the execution of a processor 205. The software code modules of the application program 233 that implement Method 1800 can be stored, for example, in a hard disk drive 210 and / or memory 206. A step in Method 1800 is configured to determine whether a source device 120 generates encoded video data containing encoded feature map data based on a convolutional neural network (CNN). A step in Method 1800 is also configured, if a source device 120 generates encoded video data containing encoded feature map data, to generate encoded video data using a set of coding tools or functions for encoding the video data. Furthermore, as described, the steps of method 1800 are configured to generate feature map encoding data using a first part of multiple coding tools or functions, but not using a second part of multiple coding tools or functions, when the source device 120 generates second encoding data containing feature map encoding data.

[0165] Method 1800 begins with the frame type configuration determination step 1810.

[0166] In the frame type configuration step 1810, the source device 110 is configured to operate on either video data or feature map data under the execution of the processor 205. The configuration may be the result of receiving commands via the network 200 or 222, or it may be by direct user control via a user interface (e.g., via keyboard 202, mouse 203). Next, control in the processor 205 proceeds from step 1810 to the frame-containing feature map data test step 1820.

[0167] In step 1820, the source device 110, under the execution of the processor 205, determines whether the source device 110 generates encoded regular video frame data or encoded feature map data based on a convolutional neural network (CNN). The encoded data conforms to a coding standard (e.g., the VVC standard). When the source device 110 is configured for video frame data, control in the processor 205 proceeds from step 1820 to the video data functions selection step 1830. When the source device 110 is configured for feature map transmission, control in the processor 205 proceeds from step 1820 to the feature map functions selection step 1840.

[0168] In the video data function selection step 1830, the multiplexer 118, under the execution of the processor 205, routes the frame data 113 directly to the video encoder 120. A set of functions or coding tools is selected to be used to encode the frame data 119. The set of functions corresponds to the functions available in the profile of the video coding standard used to encode the frame data 119. The set of functions corresponds to the first part of the multiple coding tools or functions described above. For example, in step 1830, a set of functions defined for the "Main10" profile of the VVC standard may be selected. Control in the processor 205 proceeds from step 1830 to the frame data encoding step 1850.

[0169] In the feature map function selection step 1840, the multiplexer 118 routes the packed feature map 117 as frame data 119 to the video encoder 120 under the execution of the processor 205. A set of features or coding tools, which is a subset of the coding tools of a standard profile, is selected for use when encoding the frame data 119. The subset of coding tools may be selected by activating a “constraint flag” to disable a specific coding tool or feature of the video coding standard used to encode the frame data 119. The disabled coding tool or feature represents the second part of the coding tools or features described above and may be at least one of Low Frequency Non-Separated Transform (LFNST), Matrix Intra Prediction (MIP), Linear Mode Chroma Scaling (LMCS), Afine Prediction Mode, Geometric Division Mode (GPM), ISP, or Deblocking Filter. In this example, prohibiting the use of the second part of the coding tool or feature may be indicated using a constraint flag. For video coding standards other than VVC, coding tools that provide similar functionality may be disabled in the same way. Control in processor 205 proceeds from step 1840 to frame data encoding step 1850.

[0170] In the frame data encoding step 1850, the video encoder 120 encodes the frame data 119 according to a set of functions or coding tools under the execution of the processor 205. Method 1800 ends and the source device 110 proceeds to the next frame. As a result of Method 1800, the bitstream 121 includes a clear indication (for example, in the form of a set of constraint flags appearing at the beginning of the bitstream) whether the data it contains is regular video data or packed feature map data. Furthermore, when the bitstream 121 encodes packed feature map data, an SEI message 1413 is present for at least one frame, allowing the destination device 140 to further process the data after decoding the bitstream (for example, processing the decoded frame data 145 using modules 148 and 150). If the destination device 140 is only intended to perform the task according to the CNN head 150, the destination device does not need to decode the bitstream 143 when it is indicated that it contains regular video data beyond the initial profile and constraint flag syntax. A destination device that outputs only task result 151 to task result buffer 152 and does not output the decoded video (for example, to display device 160) does not need to implement a coding tool or function that is indicated to be disabled via a constraint flag.

[0171] In the arrangement of Method 1800, instead of indicating which tools are disabled for feature map coding by setting constraint flags, tools are indicated, for example, by disabling an enable flag in a sequence parameter set or equivalent syntax structure.

[0172] In the arrangements of methods 1500 and 1600, steps 1580 and 1610 encode and decode the feature map group size as a log2 value (i.e., the feature map group size must be a power of 2), and an offset of 1 is applied so that a coded value of zero corresponds to a feature map group size of 1. The syntax element 'log2_group_size_minus1' is used to encode the feature map group size.

[0173] In alternative arrangements of methods 1500, 1600, and 1700, feature map groups are constrained to contain feature maps indexed in a monotonically increasing order within a given layer. When feature maps exist by index in a monotonically increasing order within each group, the group configuration can be encoded using a bitmap indicating the presence or absence of a given feature map within a group. For subsequent groups, the encoded bitmap may be reduced in length to omit feature map indices already assigned to previous groups.

[0174] In the CNN backbone 310 arrangement, the tensor dimensions, and therefore the size of the resulting feature maps, are chosen to align with the block size of the VVC standard. Generally, for rectangular video and the default CTU size of 128x128, the width and height of the feature maps can be powers of 2; for example, the sizes of three layers could be 128x64, 64x32, and 32x16. Feature map sizes being powers of 2 results in greater alignment of features packed within the block sizes available in the VVC standard, resulting from quad-tree, binary, or ternary partitioning, and reduces the likelihood of coding artifacts within a single feature map caused by the contents of adjacent feature maps.

[0175] In the bitstream 1400 arrangement, as additional syntax present when the SPS extension is active via a flag, with "sps_extension_flag" equal to 1, SPS1410 includes sps_deblocking_filter_enabled_flag for controlling the deblocking filter. When sps_deblocking_filter_enabled_flag is equal to zero, pps_deblocking_filter_control_present_flag in PPS1412 must be set to 1, thus explicitly coding the deblocking filter control; pps_deblocking_filter_override_enabled_flag in PPS1412 must be set to zero, thus disabling slice header or picture header overrides of the deblocking control set in PPS1412; and pps_deblocking_filter_disabled_flag in PPS1412 must be set to zero, disabling in-loop filtering. When sps_deblocking_filter_enabled_flag is equal to 1, these constraints on the pps_deblocking_filter_control_present_flag, pps_deblocking_filter_override_enabled_flag, and pps_deblocking_filter_disabled_flag flags do not apply. If gci_no_deblocking_filter_flag is present in constraint flag 1440 and is set to 1, sps_deblocking_filter_enabled_flag in SPS1410 must be set to zero. When gci_no_deblocking_filter_flag is set to zero, no constraints apply to sps_deblocking_filter_enabled_flag in SPS1410.If sps_deblocking_filter_enabled_flag does not exist in SPS1410, the constraints applicable to the pps_deblocking_filter_control_present_flag, pps_deblocking_filter_override_enabled_flag, and pps_deblocking_filter_disabled_flag flags are applied when gci_no_deblocking_filter_flag is set to 1. By explicitly prohibiting the application of the deblocking filter via the constraint flags, it becomes possible to define subprofiles for feature map coding that exclude the application of the deblocking filter. gci_no_deblocking_filter_flag may exist in the area of ​​constraint flags 1440, which includes gci_reserved_zero_bits in version 1 of the VVC standard. When the application of system 100 requires high quality, i.e., high bitrate, achieved using a low value of quantization parameter 692, deblocking may not be necessary, and the constraint flags may be used, for example, for feature map coding, allowing deblocking to be completely omitted. Industrial applicability

[0176] The described configuration is applicable to the computer and data processing industries, and in particular to digital signal processing for encoding and decoding signals such as video and image signals, achieving high compression efficiency. By providing one or more of the constraint flags mentioned above, it becomes possible to select a subset of tools for a given profile (equivalent to "subprofiling"). Selecting a subset of tools offers several advantages, such as implementation advantages for VVC vendors, as it allows vendors to specify a subset of profiles that exclude unnecessary or other problematic coding tools, for example, from a complexity standpoint.

[0177] Configurations for quantizing floating-point tensor data within a group of channels or feature maps and packing the resulting integer values ​​into a planar frame are also disclosed. Grouping methods and trade-offs are disclosed for very coarse grouping, having low overhead for quantization range data and very fine grouping, having high overhead for quantization range data, while intermediate grouping granularity provides advantages in task performance.

[0178] The above describes only some embodiments of the present invention, and modifications and / or changes can be made without departing from the scope and spirit of the invention. The embodiments are illustrative and not limiting.

[0179] Appendix A: The SEI message format and associated semantics for representing metadata related to feature map packing and quantization in bitstreams are as follows:

[0180] [Table 1]

[0181] Features, Map, Packing Information, Semantics The syntax structure specifies the information needed to unpack the feature map plane frame and convert it into a tensor for performing the inference task.

[0182] A syntax element with descriptor u(n) indicates that the syntax element is coded using n bits and interpreted as an unsigned integer value. A syntax element with descriptor ue(v) indicates that the syntax element is coded as an exponential Golomb value and interpreted as an unsigned integer value.

[0183] The persistence of a Feature Map Information SEI message lasts from the associated AU until the next Feature Map Information SEI message is generated or the CLVS terminates.

[0184] A frame_type equal to 0 indicates that the AU does not contain packed feature map data, while a frame_type equal to 1 indicates that the AU contains packed feature map data.

[0185] A value of 1 for layers_update indicates that this instance of the Feature Map Packing Information SEI message defines the number of feature map layers, the number of dimensions, and the quantity of feature maps in each layer.

[0186] A values ​​of 1 for groups_update indicate that this instance of the Feature Map Packing Information SEI message defines the number and composition of feature map groups.

[0187] A qr_update value equal to 1 indicates that this instance of the Feature Map Packing Information SEI message signals an update to the quantization range of the feature map group.

[0188] The `backbone_id` indicates the type of network backbone and extraction point, implicitly signaling the tensor's layer count and dimensions, and therefore the feature map's dimensions. The table below shows some predefined network backbones, their associated layer counts, feature map counts, and dimensions.

[0189] [Table 2]

[0190] `layer_cnt` specifies the number of layers present in the frame.

[0191] fm_cnt[layer_idx] specifies the number of feature maps present in layer_idx.

[0192] fm_width[layer_idx] specifies the width of the feature map of layer_idx.

[0193] fm_height[layer_idx] specifies the height of the feature map of layer_idx.

[0194] orig_source_width specifies the width of frame 112 in the Luma sample before it is resized for backbone operation, i.e., before resizing module 304.

[0195] orig_source_height specifies the height of frame 112 in the luma sample before it is resized for backbone operation, i.e., before resizing module 304.

[0196] The `packing_format` parameter specifies the format of the packed feature map data within the frame. The formats are listed in the following table.

[0197] [Table 3]

[0198] The `grouping_type` parameter specifies the scope of the feature map group by setting the `ExplicitGrouping`, `ExplicitGroupSize`, and `ExplicitLayerId` flags.

[0199] An ExplicitGrouping flag equal to 1 indicates that feature map grouping is explicitly signaled in the bitstream, while an ExplicitGrouping flag equal to 0 indicates that feature map grouping is implicitly determined based on grouping_type.

[0200] An ExplicitGroupSize flag equal to 1 indicates that the size of each feature map group is explicitly signaled in the bitstream, while an ExplicitGroupSize flag equal to 0 indicates that the size of each feature map group is implicitly determined based on the grouping_type.

[0201] An ExplicitLayerId flag equal to 1 indicates that the group may contain feature maps in different layers, while an ExplicitLayerId flag equal to zero indicates that the group is implicitly limited to a single layer.

[0202] The following table shows the values ​​assigned to the ExplicitGrouping flag, ExplicitGroupSize flag, and ExplicitLayerId flag according to the grouping_type. Where implicit signals are used, their implicit behavior is described.

[0203] [Table 4]

[0204] `group_cnt` exists when the `ExplicitGrouping` flag is equal to 1 and signals the number of feature map groups. When `ExplicitGroupingFlag` is equal to zero, `group_cnt` is inferred based on `grouping_type` according to the table above.

[0205] `quant_type` indicates the type of quantization operation according to the table below.

[0206] [Table 5]

[0207] qr_fraction_precision specifies the precision in which the fractional part of the floating-point quantization range is coded bit by bit.

[0208] The `group_size` parameter exists when the `ExplicitGrouping` flag is set to 1 and the `ExplicitGroupSize` flag is set to 1. `group_size` specifies the size of the group `grp_idx`. If `group_size` does not exist, it is inferred according to the 'Implicit Rules' described in the 'grouping_type' table.

[0209] fm_idx[grp_idx][fm_idx] specifies the feature map index or channel index of fm_idx at the position within the group grp_idx.

[0210] `layer_id[grp_idx][fm_idx]` specifies the layer index for the corresponding feature map identified by `fm_idx[grp_idx][fm_idx]`, if it exists. If `layer_idx` does not exist, it is inferred. For `group_type` equal to 1, 2, or 3, the feature maps of Layer 0 are initially assigned to one or more groups, and once all feature maps of Layer 0 are assigned to groups, the feature maps of Layer 1 are assigned to one or more groups, and so on. For `group_type` equal to 4, one group contains all feature maps of all layers.

[0211] qr_exp[grp_idx] specifies the exponent part of the quantization range of group grp_idx.

[0212] qr_exp_sign[grp_idx] specifies the sign of the exponent part of the quantization range of group grp_idx.

[0213] qr_fraction[grp_idx] specifies the fractional part of the quantization range of group grp_idx, with the bit width specified by qr_precision.

[0214] If second_qr_exp[grp_idx] exists, it specifies the exponential part of the second quantization range of group grp_idx.

[0215] second_qr_exp_sign[grp_idx] specifies the sign of the exponent part of the quantization range of group grp_idx.

[0216] second_qr_fraction[grp_idx], if present, specifies the fractional part of the second quantization range of group grp_idx with the bit width specified by qr_precision.

[0217] When quant_type is equal to zero, the quantization range indicates the maximum magnitude of values ​​encountered within the feature map in the group to which the quantization range applies.

[0218] When quant_type is equal to 1, the quantization range indicates the largest positive value encountered within the feature map in the group to which the quantization range is applied, and the second quantization range indicates the largest negative value encountered within the feature map in the group to which the second quantization range is applied.

[0219] The quantization range and the second quantization range (if any) may be adjusted to allow for a certain headroom, such as by multiplying them by a value slightly greater than 1.0. Such headroom allows the quantization range to be reused for subsequent frames in the frame associated with the feature map packing information SEI message, reducing the likelihood that tensor values ​​need to be clipped in the quantization module 518.

Claims

1. A generation means for generating a frame in which multiple feature maps obtained at least based on neural network processing of an input image are arranged, When generating a frame in which multiple feature maps are arranged, encoding means for encoding the frame in which the multiple feature maps are arranged into a bitstream using a first part of multiple tools and without using a second part of the multiple tools which includes at least a deblocking filter (DBF), An encoding device characterized by having the following features.

2. The encoding apparatus according to claim 1, wherein the second part of the plurality of tools further comprises at least one of LFNST, LMCS, and ISP.

3. The encoding apparatus according to claim 1, characterized in that the second part of the plurality of tools includes at least one of Afine, GPM, and MMVD.

4. The encoding apparatus according to claim 1, characterized in that the second part of the plurality of tools is constrained not to be used in the generation of the frame on which the plurality of feature maps are arranged.

5. The encoding device according to claim 1, characterized in that the encoding means encodes information indicating that the second portion of the plurality of tools is constrained not to be used for decoding the frame in which the plurality of feature maps are arranged.

6. The encoding device according to claim 1, characterized in that the encoding process for frames in which no feature maps are placed conforms to a first encoding standard, and the encoding process for frames in which a plurality of feature maps are placed conforms to a second encoding standard.

7. The encoding apparatus according to claim 1, characterized in that each of the plurality of feature maps is arranged in the frame according to the raster scan arrangement.

8. A feature map having a first width and a first height among the plurality of feature maps is placed in the first area of ​​the frame. The encoding device according to claim 1, characterized in that a feature map among the plurality of feature maps having a second width smaller than the first width and a second height smaller than the first height is arranged in a second area different from the first area of ​​the frame.

9. The encoding device according to claim 1, characterized in that the plurality of feature maps are a plurality of feature maps obtained by performing quantization on each of a plurality of feature maps that constitute a tensor obtained at least based on processing of the input image by a neural network.

10. The encoding device according to claim 1, characterized in that the encoding means encodes a constraint flag for prohibiting the use of the second portion of the plurality of tools.

11. The encoding device according to claim 1, further comprising means for generating a frame without feature maps, rather than a frame with multiple feature maps, using the multiple tools permitted to use DBF to generate the frame without feature maps.

12. A decoding means for decoding a frame in which multiple feature maps obtained at least based on neural network processing of an input image are arranged, When decoding a frame in which multiple feature maps are arranged, a decoding means decodes the frame in which the multiple feature maps are arranged from a bitstream using a first part of multiple tools and without using a second part of the multiple tools which includes at least a deblocking filter (DBF). A decoding device characterized by having the following features.

13. The decoding device according to claim 12, wherein the second part of the plurality of tools further comprises at least one of LFNST, LMCS, and ISP.

14. The decoding device according to claim 12, characterized in that the second part of the plurality of tools includes at least one of Afine, GPM, and MMVD.

15. The decoding apparatus according to claim 12, characterized in that the second part of the plurality of tools is constrained not to be used for decoding the frame on which the plurality of feature maps are arranged.

16. The decoding apparatus according to claim 12, characterized in that the decoding means decodes information indicating that the second portion of the plurality of tools is constrained not to be used for decoding the frame in which the plurality of feature maps are arranged.

17. The decoding device according to claim 12, characterized in that the decoding process for frames in which no feature maps are placed conforms to a first encoding standard, and the decoding process for frames in which the plurality of feature maps are placed conforms to a second encoding standard.

18. The decoding device according to claim 12, characterized in that each of the plurality of feature maps is arranged in the frame according to the raster scan arrangement.

19. A feature map having a first width and a first height among the plurality of feature maps is placed in the first area of ​​the frame. The decoding device according to claim 12, characterized in that a feature map among the plurality of feature maps having a second width smaller than the first width and a second height smaller than the first height is arranged in a second area different from the first area of ​​the frame.

20. The decoding apparatus according to claim 12, characterized in that the plurality of feature maps are a plurality of feature maps obtained by performing quantization on each of a plurality of feature maps that constitute a tensor obtained at least based on processing of the input image by a neural network.

21. The decoding device according to claim 12, characterized in that the decoding means decodes a constraint flag for prohibiting the use of the second portion of the plurality of tools.

22. The decoding device according to claim 12, further comprising means for decoding a frame in which no feature maps are placed, rather than a frame in which multiple feature maps are placed, using the multiple tools permitted to use DBF to decode the frame in which no feature maps are placed.

23. A frame is generated in which multiple feature maps, obtained at least based on neural network processing of the input image, are arranged. When generating a frame containing multiple feature maps, the first part of the multiple tools is used, and the second part of the multiple tools, which includes at least a deblocking filter (DBF), is not used, to encode the frame containing the multiple feature maps into a bitstream. An encoding method characterized by the following.

24. Decode a frame containing multiple feature maps obtained at least based on neural network processing of the input image, When decoding a frame containing multiple feature maps, the first part of the multiple tools is used, and the second part of the multiple tools, which includes at least a deblocking filter (DBF), is not used to decode the frame containing the multiple feature maps from the bitstream. A decoding method characterized by the following:

25. A computer program for causing a computer to function as each of the means of the encoding apparatus described in claim 1.

26. A computer program for causing a computer to function as each of the means of the decoding device described in claim 12.

Images