Method, apparatus and system for encoding and decoding tensors

Abstract

A system and method of decoding a bitstream to produce tensors for use by a network portion. The method comprises decoding a plurality of pictures from the bitstream, wherein each picture contains a feature map for the network portion and the decoding may or may not conform to behaviour of a particular implementation of neural network operations, with associated output from the decoder indicating the conformance status of the decoder output.

Description

METHOD, APPARATUS AND SYSTEM FOR ENCODING AND DECODING TENSORS REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims the benefit under 35 U. S. C. §119 of the filing date of Australian Patent Application No. 2025200211, filed 10 January 2025, hereby incorporated by reference in its entirety as if fully set forth herein.TECHNICAL FIELD

[0002] The present invention relates generally to digital video signal processing and, in particular, to a method, apparatus and system for encoding and decoding tensors for a convolutional neural network. The present invention also relates to a computer program product including a computer readable medium having recorded thereon a computer program for encoding and decoding tensors for a convolutional neural network using video compression technology.BACKGROUND

[0003] Convolutional neural networks (CNNs) are an emerging technology addressing, among other things, use cases involving machine vision such as object detection, instance segmentation, object tracking, human pose estimation, and action recognition. Applications for CNNs can involve use of ‘edge devices’, with sensors and some processing capability, coupled to application servers (the ‘cloud’) via a wide-area network (WAN). CNNs can require relatively high computational complexity, more than can typically be afforded either in computing capacity or power consumption by an edge device. Executing a CNN in a distributed manner has emerged as one solution to running leading-edge networks using with the computational workload apportioned to both an edge device of limited capability and cloud servers. Execution in a distributed manner (or ‘split inferencing’) avoids requiring all computational complexity to be incurred within cloud servers and avoids leaving computational resources of edge devices unused. In other words, distributed processing allows legacy edge devices to still provide the capability of leading-edge CNNs by distributing processing between the edge device and other processing means, such as cloud servers. Such a distributed network46839667_2architecture may be referred to as ‘collaborative intelligence’ (CI) and offers benefits such as re-using a partial result from a first portion of the network with several different second portions, perhaps with each portion being optimised for a different task. CI architectures introduce a need for efficient compression of tensor data, for transmission over a network such as a WAN.

[0004] CNNs typically include many layers, such as convolution layers and fully connected layers, with data passing from one layer to the next in the form of intermediate multidimensional tensors. Splitting a CNN across different devices introduces a need to compress the tensors that pass from one layer to the next within the CNN in order to facilitate transmission of the tensors between portions of the CNN over a network having bandwidth limitations or other associated costs. Compression of such tensors may be referred to as ‘feature compression’ and the intermediate tensor data is often referred to as ‘features’ or ‘feature maps’. Features or feature maps are generally a collection of two-dimensional (2D) arrays of values which, when combined into a 3D (or 4D) data structure form a tensor, with each feature map corresponding to one ‘channel’ of the tensor. Intermediate tensor data represents a partially processed form of input, such as an image frame or video frame, encountered within a neural network. Although a unit of data to be processed in a neural network is typically a tensor, operations performed may be described in relation to a feature map, in which case it is understood that the operation is to be performed to each feature map in the tensor. International Organisation for Standardisation / International Electrotechnical Commission Joint Technical Committee 1 / Subcommittee 29 / Working Groups 4 (ISO / IEC JTC 1 / SC 29 / WG 4), also known as the “Moving Picture Experts Group” (MPEG) Video coding are tasked with developing a standard for feature compression, known as the ‘feature coding for machines’ (FCM) standard. Previously WG 2 ‘MPEG Technical Requirements’ had completed a ‘Call for Proposals’ which received responses that demonstrated significant outperformance over feature compression results achieved using state-of-the-art standardised video compression technology directly applied to the tensors.

[0005] CNNs typically operate using weights for each of the layers in the network that have been predetermined in a training stage. During training a substantial amount of training data is passed through the CNN with results determined by the network undergoing training being compared to ground truth associated with the training data. Ground truth can include bounding boxes, tracking IDs, and instance segmentation maps or masks. Discrepancy between the obtained and desired result is expressed as a Toss’ and measured with a Toss function’. When46839667_2training data includes ground truth, typically the loss function used is the ‘task loss’, that is, the difference between the network output and the provided ground truth. An example training dataset is the ‘Openimages’ collection of images with bounding boxes and segmentation masks. Using the determined loss, a process for updating network weights, such as stochastic gradient descent (SGD), is performed. Network weight update typically involves a process of back-propagation of ‘gradients’ that begins at the output layer of the network and proceeds backward to terminate when the input layer to the network is updated, propagating through intermediate, or ‘hidden’, layers of the network. Gradients are indicative of deltas to be applied to network weights and are themselves updated as part of the back propagation process. The rate of weight update is set by a ‘learning rate’ hyperparameter, typically set to facilitate the training process in finding a global minima in terms of loss (i.e., highest possible task performance for the network architecture and training data) while avoiding the training process becoming ‘stuck’ in a local minima. Becoming stuck in a local minima corresponds to obtaining sub-optimal task performance for the network architecture and being incapable of finding new weight values that could lead to higher task performance. Network weights are repeatedly updated by supplying input data and ground truth data organised into ‘batches’ to iteratively refine the network performance until further improvement in accuracy is no longer achievable. The learning rate may be altered during the course of training using. For example, the “adaptive moment estimation” (“Adam”) optimizer” adapts the learning rate over time based on the moving average of the magnitudes of recent gradients, enabling a fine tuning of the weights later in the training process where a smaller learning rate is applied. The Adam optimizer also uses a moving average of the gradient for parameter update, further assisting updating parameters with amounts appropriate for the overall progress in network training. An iteration through the entire training dataset forms one ‘epoch’ of training and training typically requires multiple epochs to achieve a high level of performance for the task. Weights for a trained network are then available for deployment, and the network operates in a mode where weights are fixed and gradients for weight update are omitted. The process of executing a pretrained CNN with an input and progressively transforming the input into an output according to a topology of the CNN is commonly referred to as ‘inferencing’.

[0006] Generally, a tensor is an array of elements having four dimensions, namely: batch, channels, height and width. The first dimension, ‘batch’, is typically of size one when inferencing, when processing video data each batch corresponds to one successive frame to be passed through a CNN. When training a network, the value of the batch dimension may be increased so that multiple frames are passed through the network in a single batch from which46839667_2the network weights are updated, according to a predetermined ‘batch size’. A multi -frame video may be passed through as a single tensor with the batch dimension increased in size according to the number of frames of a given video. However, for practical considerations relating to memory consumption and access, inferencing on video data is typically performed on a frame-wise basis. The ‘channels’ dimension indicates the number of concurrent ‘feature maps’ included in a given tensor and the height and width dimensions indicate the size of the feature maps in the given tensor. Channel count varies through the layers of a CNN according to the network architecture. Feature map size also varies, depending on subsampling or upsampling occurring in specific network layers, such as resulting from convolutions with stride set to values other than one, such as two or one half.

[0007] The overall complexity of the CNN tends to be relatively high, with relatively large numbers of multiply-accumulate (MAC) operations being performed and numerous intermediate tensors being written to and read from memory, along with reading weights for performance of each layer of the CNN. As such, dividing a neural network into portions allows implementation of more complex networks even in systems containing less capable edge devices, without requiring cloud servers to bear the full burden of performing the network.

[0008] Feature compression may benefit from existing video compression standards, such as ISO / IEC 23090-2 “Versatile Video Coding” (VVC) / H.266, developed by the Joint Video Experts Team (JVET), a joint activity by ISO / IEC and ITU-T. VVC is anticipated to address ongoing demand for ever-higher compression performance, especially as video formats increase in capability (for example, with higher resolution and higher frame rate) and to address increasing market demand for service delivery over WANs, where bandwidth costs are relatively high. VVC is implementable in contemporary silicon processes and offers an acceptable trade-off between achieved performance versus implementation cost. The implementation cost may be considered for example, in terms of one or more of silicon area, CPU processor load, memory utilisation and bandwidth. Other video compression standards, such as ISO / IEC 23008-2 “High Efficiency Video Coding” (HEVC) / H.265 or ISO / IEC 14496-15, “Advanced Video Coding” (AVC) may also be used for feature compression applications. Other standards such as AV-1, developed by the Alliance for Open Media (AOMedia) may also be used.

[0009] Video data includes a sequence of frames of image data, each frame including one or more colour channels. Where feature map data is to be represented in a packed frame,46839667_2generally a monochrome frame having luminance only and no chroma channels is adequate. When only luma samples are present, the resulting monochrome frames are said to use a “4:0:0 chroma format”. When chroma samples are present, such that the sampling frequency in chroma is half that of luma in both horizontal and vertical directions, the frame is said to use a “4:2:0” chroma format. When chroma samples are present, such that the sampling frequency in chroma is half that of luma horizontally and the same frequency in the vertical direction, the frame is said to use a “4:2:2” chroma format. When chroma samples are present and sampled at the same frequency as luma samples the frame is said to use a “4:4:4” chroma format.

[0010] The VVC standard specifies a ‘block based’ architecture, in which frames are firstly divided into an array of square regions known as ‘coding tree units’ (CTUs). In VVC, CTUs generally occupy 128×128 luma samples. Other possible CTU sizes when using the VVC standard are 32×32 and 64×64. However, CTUs at the right and bottom edge of each frame may be smaller in area, with implicit splitting occurring to ensure coding blocks remain in the frame. Associated with each CTU is a ‘coding tree’ defining a decomposition of the area of the CTU into a set of blocks, also referred to as ‘coding units’ (CUs). Blocks applicable to only the luma channel or only the chroma channels are referred to as ‘coding blocks’ (CBs). A prediction of the contents of a coding block is held in a ‘prediction block’ (PB) or ‘prediction unit’ (PU) and a residual block defining an array of sample values to be additively combined with the PB or PU is referred to as a ‘transform block’ (TB) or ‘transform unit’ (TU), owing to the typical use of a transformation process in the generation of the TB or TU. In the case of HEVC, the CTU size may be 64×64, 32×32, or 16×16 luma samples. In the case of advanced video coding (AVC), a “Macroblock” is the analogue of a CTU and has a size of 16×16 luma samples.

[0011] Notwithstanding the above distinction between ‘units’ and ‘blocks’, the term ‘block’ may be used as a general term to refer to areas or regions of a frame for which operations are applied to all colour channels.

[0012] For each CU, a prediction unit (PU) of the contents (sample values) of the corresponding area of frame data is generated (a ‘prediction unit’). Further, a representation of the difference (or ‘spatial domain’ residual) between the prediction and the contents of the area as seen at input to the encoder is formed. The difference in each colour channel may be transformed and coded as a sequence of residual coefficients, forming one or more TUs for a given CU. The applied transform may be a Discrete Cosine Transform (DCT) or other46839667_2transform, applied to each block of residual values. The transform is applied separably, (i.e., the two-dimensional transform is performed in two passes, one horizontally and one vertically). The block is firstly transformed by applying a one-dimensional transform to each row of samples in the block. Then, the partial result is transformed by applying a one-dimensional transform to each column of the partial result to produce a final block of transform coefficients that substantially decorrelates the residual samples. Transforms of various sizes are supported by the VVC standard, including transforms of rectangular-shaped blocks, with each side dimension being a power of two. Transform coefficients are quantised for entropy encoding into a bitstream.

[0013] PBs or PUs in VVC may be generated using either an intra-frame prediction or an inter-frame prediction process. Intra-frame prediction involves the use of previously processed samples in a frame being used to generate a prediction of a current block of data samples in the frame. Inter-frame prediction involves generating a prediction of a current block of samples in a frame using a block of samples obtained from one or two previously decoded frames. The block of samples obtained from a previously decoded frame is offset from the spatial location of the current block according to a motion vector, which often has filtering applied. Intra-frame prediction blocks can be (i) a uniform sample value (“DC intra prediction”), (ii) a plane having an offset and horizontal and vertical gradient (“planar intra prediction”), (iii) a population of the block with neighbouring samples applied in a particular direction (“angular intra prediction”) or (iv) the result of a matrix multiplication using neighbouring samples and selected matrix coefficients.

[0014] Encoders and decoders conforming to different video encoding standards may be used to compress intermediate feature maps from a first portion (a ‘backbone’) of a neural network separated into two portions. In compression, the feature maps from the backbone are arranged into a frame and quantised from a floating-point domain to a sample domain suitable for compression as video data. Neural network layers, such as convolutions, batch normalisations, and activation functions, may be applied to reduce the dimensionality of the tensors prior to compression using a video compression standard such as VVC. Dimensionality reduction of tensors reduces the volume of data to be compressed, improving compression efficiency and reducing the runtime of the VVC encoding and decoding stages. Dimensionality reduction introduces complexity offsetting the reduction in runtime seen in the VVC encoding.Moreover, the exact implementations of operations such as convolutions varies from platform to platform due to low-level implementation details such as GPU architecture, CPU instruction46839667_2set extensions in use and software library version differences and the like. A need exists to support the use of encoders and decoders implemented on differing platforms whilst ensuring conformance of decoded tensors provided to the latter processing stage(s) when performing split inferencing.SUMMARY

[0015] It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

[0016] One aspect of the present disclosure provides a method of determining accuracy of producing one or more tensors from a bitstream, the method comprising: decoding platform information from the bitstream, wherein the platform information indicates a device used for encoding the one or more tensors; producing the one or more tensors from the bitstream, using a predetermined device; determining accuracy of the produced one or more tensors, based on the platform information and the predetermined device; and outputting information of the result of the determination.

[0017] Another aspect of the present disclosure provides a non-transitory computer-readable storage medium which stores a program for executing a method of determining accuracy of producing one or more tensors from a bitstream, the method comprising: decoding platform information from the bitstream, wherein the platform information indicates a device used for encoding the one or more tensors; producing the one or more tensors from the bitstream, using a predetermined device; determining accuracy of the produced one or more tensors, based on the platform information and the predetermined device; and outputting information of the result of the determination.

[0018] Another aspect of the present disclosure provides a system comprising: a memory; and a processor, wherein the processor is configured to execute code stored on the memory for implementing a method of determining accuracy of producing one or more tensors from a bitstream, the method comprising: decoding platform information from the bitstream, wherein the platform information indicates a device used for encoding the one or more tensors; producing the one or more tensors from the bitstream, using a predetermined device; determining accuracy of the produced one or more tensors, based on the platform information and the predetermined device; and outputting information of the result of the determination.46839667_2

[0019] Other aspects are also disclosed.BRIEF DESCRIPTION OF THE DRAWINGS

[0020] At least one embodiment of the present invention will now be described with reference to the following drawings and an appendix, in which:

[0021] Fig. 1 is a schematic block diagram showing a distributed machine task system;

[0022] Figs. 2A and 2B form a schematic block diagram of a general-purpose computer system upon which the distributed machine task system of Fig. 1 may be practiced;

[0023] Fig. 3 A is a schematic block diagram showing functional modules of a backbone portion of a CNN;

[0024] Fig. 3B is a schematic block diagram showing a residual block of Fig. 3 A;

[0025] Fig. 3C is a schematic block diagram showing a residual unit of Fig. 3A;

[0026] Fig. 3D is a schematic block diagram showing a CBL module of Fig. 3 A;

[0027] Fig. 4 is a schematic block diagram showing functional modules of an alternative backbone portion of a CNN;

[0028] Fig. 5 is a schematic block diagram of a tensor encoder;

[0029] Fig. 6 is a schematic block diagram showing a multi-scale feature fusion stage for a tensor compressor;

[0030] Fig. 7 shows a tensor compressor operable on one of several possible platforms providing low-level tensor functions;

[0031] Fig. 8 is a schematic block diagram showing functional modules of a video encoder;

[0032] Figs. 9A & 9B are schematic block diagrams showing an arrangement of regions or subpictures for holding compressed feature map data from compressed tensor data;

[0033] Fig. 10 is a schematic block diagram showing a bitstream structure with a container for coded feature frame data;46839667_2

[0034] Fig. 11 is a schematic block diagram showing a coded non-feature frame data;

[0035] Fig. 12 is a schematic block diagram showing a tensor decoder;

[0036] Fig. 13 is a schematic block diagram showing functional modules of a video decoder;

[0037] Fig. 14 is a schematic block diagram showing an implementation of a tensor decoder configurable to utilise provided low-level tensor functions according to a decoder platform;

[0038] Fig. 15 is a schematic block diagram showing an embodiment of a multi-scale feature reconstruction stage;

[0039] Fig. 16A is a schematic block diagrams showing a head portion of a CNN;

[0040] Fig. 16B is a schematic block diagram showing an upscaler module of Fig. 16A;

[0041] Fig. 16C is a schematic block diagram showing a detection module of Fig. 16A;

[0042] Fig. 17 is a schematic block diagram showing an alternative head portion of a CNN;

[0043] Fig. 18 shows a method for performing a first portion of a CNN and compressing the resulting intermediate tensors, with signalling included indicative of a conformance point for the compressed tensors;

[0044] Fig. 19 shows a method for decoding a bitstream using an available platform and determining whether the decoded tensors correspond to a conformance point, and performing a second portion of the CNN; and

[0045] Appendix A shows syntax structures for signalling a feature coding for machines conformance parameter set (FCM CPS) and a feature coding for a machine vision model parameter set (FCM VMPS).DETAILED DESCRIPTION INCLUDING BEST MODE

[0046] Where reference is made in any one or more of the accompanying drawings to steps and / or features, which have the same reference numerals, those steps and / or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.46839667_2

[0047] A distributed machine task system may include an edge device, such as a network camera or smartphone producing intermediate compressed data. The distributed machine task system may also include a final device, such as a server farm based (‘cloud’) application, operating on the intermediate compressed data to produce a task result. Additionally, the edge device functionality may be embodied in the cloud and the intermediate compressed data may be stored for later processing, potentially for multiple different tasks depending on need.

[0048] A convenient form of intermediate compressed data is a compressed video bitstream, owing to the availability of high-performing compression standards and implementations thereof. Video compression standards typically operate on integer samples of some given bit depth, such as 10 bits, arranged in planar arrays. Colour video has three planar arrays, corresponding, for example, to colour components Y, Cb, Cr, or R, G, B, depending on application. CNNs typically operate on floating point data in the form of tensors but may also operate on integer data, also forming tensors. Tensors generally have a relatively smaller spatial dimensionality compared to incoming video data upon which the CNN operates while having more channels than the three channels typical of colour video data, for example 128, 256, or 512 channels.

[0049] Tensors typically have the following dimensions: frames, channels, height, and width. For example, a tensor of dimensions [1, 256, 76, 136] would be said to contain floating-point or integer values for one frame comprising an array of two-hundred and fifty-six (256) feature maps (channels), each of size 136x76. For video data, inferencing is typically performed one frame at a time (frame or 'batch’ value of 1), rather than using tensors containing multiple frames. VVC, HEVC, and AVC support a division of a picture into ’slices’, or contiguous sequences of coded CTUs or Macroblocks in the case of AVC. A feature codec may include stages to reduce the dimensionality of intermediate tensors encountered at a given ‘split point’ between two network portions. The reduced-dimensionality tensors (said to be in a ‘reduced domain’, or ‘fused domain’) are then packed into frames and coded with a conventional video codec, or ‘inner codec’. Several different compression standards may be used for the ‘inner codec’, reflecting availability in deployments, various complexity / performance trade-offs, or other criteria. The stages used to reduce and restore the dimensionality of tensors encountered at a split point typically involve elements or functions such as convolutions, batch normalisations, activation functions, and the like. Dimensionality reduction and restoration of intermediate tensors may be termed ‘feature reduction’ and ‘feature restoration’, taking place in the encoder and decoder, respectively.46839667_2

[0050] The functions used for feature reduction and feature restoration are typically provided by the platform on which the encoder and decoder execute, which may be various GPUs or CPUs having various instruction set architecture (ISA) extensions used to accelerate performance. One example is a convolution, which when operative on floating-point tensor data, may have output dependent on implementation details like the particulars of the floatingpoint units implemented in the GPU or CPU and on the order of result accumulation. The result of an accumulation operation, performed within a convolution, is dependent on increases of the floating-point exponent to accommodate the magnitude of encountered values in the accumulation, resulting in least-significant bits (LSBs) of subsequent values to be discarded. When a convolution is parallelised for accelerated operation, the division of the workload into parallel segments thus introduces variation in the ordering or values processed in the convolution and thus in the final result. Parallel segments may be implemented in different threads, introducing a timing-dependent element to the result of the accumulation. Division of the MAC workload from sequential to some degree of parallelism may also include use of a binary tree to perform accumulation. Division of the MAC operations into one or more binary trees also affects the final result. Rounding operations may also introduce platform-dependent discrepancy into the results. Some platforms provide a ‘fused multiply accumulate’ (FMA) operation, which reduces the number of rounding operations in each MAC step from two to one operations. The IEEE 754 standard defines four rounding modes:rn - round to nearest values, ties (mid-point values) round to even values.rz - round to zero.ru - round to positive infinity.rd - round to negative infinity.

[0051] Exact rounding mode may depend on the platform, such as GPU vendor and model, CPU vendor and model, CPU Instruction Set Architecture (CPU ISA) in use. CPU ISAs include ‘multimedia extensions’ (MMX), ‘single instruction multiple data’ (SIMD), ‘streaming SIMD extensions’ (SSE) of various versions such as the original SSE, SSE2, SSE3, SSE4, SSE4.1, SSE4.2. More recent ISAs include the ‘advanced vector instructions’ (AVX), such as AVX, AVX2, and AVX512. Example of CPU vendors include Intel™, AMD™, ARM™. Examples of GPU vendors include Nvidia™, AMD™, Intel™. Mobile system-on-chip (SoC) vendors may also have their own architectures and thus can be identified as GPU or CPU vendors, 46839667_2companies such as Qualcomm™, MediaTek™, Apple™, Samsung™ produce mobile SoCs with their own (or derivative versions of) internal components such as CPU and GPU.

[0052] On CPU platforms when ‘x87’instructions are available, an 80-bit floating-point format is available in the register set, which may be used when intermediate results are kept in registers but discarded with conversion to 32-bit or 64-bit floating-point values when writing and reading to memory.

[0053] As the encoder and decoder can be expected to run on different devices, which may be implemented on different platforms which differ in the details of low-level operations, bit-accurate decoding of tensors for the remainder of the neural network is not always feasible. Herein, Tow-level operation’ is defined as any and all operations below the level of the network topology. The network topology defines the interconnection between elements (low level operations) such as convolutions, normalisation functions, activation functions. Other examples of low-level operations include transpose convolution, pooling layers such as max pooling or average pooling, pixel shuffle, padding, interpolation operations, sinc function. Activation functions include parameterised leaky rectified linear units (PReLU), hyperbolic tangent, sigmoid, threshold, sigmoid linear unit (SiLU), and layer normalisation. Where trigonometric functions are used, such as in the sinc function, various approximations, such as those categorised as Chebyshev approximations, may be used. Exact operation of such functions is dependent on low-level implementation details of the platform on which they are performed. One example is a sigmoid activation function which involves division and exponential computation. Floating-point precision and exponential function (exponent e to the power of n) implementation affect the result of sigmoid. The task network, split into two portions, and additional added layers for ‘feature reduction’ and ‘feature restoration’ each have corresponding network topologies. The low-level operations themselves may be implemented using CPU instructions and GPU primitives in combination with software optimisations.Typically, when bit-accurate operation is ensured, such as in a custom ‘Application-Specific Integrated Circuit’ (ASIC) implementation, a conformance point is said to exist and a conforming decoder is one that produces the bit-accurate result.

[0054] A conformance point is defined as two interface points at which data is transformed in a specific manner from one form to another. In the context of FCM, a bitstream at the input to an FCM decoder is transformed into tensors for provision to a second network portion.Although the transformation is specified in a bit accurate manner, implementations typically46839667_2use functions provided by widely available platforms that may not correspond exactly to the operation as specified in the FCM standard. Although the issue of non-conformant implementations is addressable in ASIC implementations by virtue of complete control down to the gate level in the design phase, ASIC implementation is not always feasible due to the high non-recurring expense (NRE) involved in design, generally requiring deployment of a custom chip to address a substantial market.

[0055] When ASIC implementation is not feasible, reuse of existing platforms such as CPU or GPU is an alternative. When reusing existing platforms for FCM implementations, the implementation may not conform with the original standard as specified but may be said to conform to another conformance point that is a hybrid of the FCM standard in combination with utilised low-level functions provided by the platform on which the FCM encoder or decoder are implemented. Due to low-level differences in the provided accelerated functions on CPU and GPU, it may be necessary to allow for operation on platforms that are not strictly conforming, i.e., not achieving bit-accurate result, yet produce an acceptable or usable result. Bit accurate results could be obtained by confining operation to avoid accelerated features such as GPU, various CPU ISA extensions, and parallelism techniques, at the expense of performance (likely losing the ability to operate in real time, for example). One example of vendor discrepancy in implementation is in relation to the RSQRT (reciprocal square root) and RCP (reciprocal) instructions, where differences in implementations between Intel and AMD CPUs result in numerically differing results. Although small differences are tolerable in many applications, any deviations from an anticipated bit accurate result affects the conformance of an implementation to a standard, having implications for interoperability among devices. A need exists for functionality to identify operation and assess whether conformant or not.Further, functionality to provide some fallback mechanism(s) to assess the degree of nonconformity when not conformant would also be useful. Implementations may still use the results produced by non-conforming decoder structures, provided the deviation of decoded tensors does not exceed a threshold of acceptance deemed suitable by the implementer.

[0056] Fig. 1 is a schematic block diagram showing functional modules of a distributed machine task system 100, capable of performing a machine task network in a distributed manner. The division of a particular neural network into two portions requires selecting a ‘split point’ in the network. Layers in the network from the input layer up to the split point form a first portion and are performed in a first device and the resulting intermediate tensor(s) are compressed. Layers from the split point up to the last layer in the network form a second46839667_2portion and are performed using decompressed tensor(s) from the first device as input to the layer(s) immediately following the split point. At the selected split point there may be one or more tensors that need to be compressed for conveyance over a communication channel with limited bandwidth compared to the bandwidth requirement for transmission of uncompressed tensors. Where a ‘feature pyramid network’ (FPN) is in use, it is common for layers in the FPN to be related in width and height such that a given layer is half the width and half the height of an adjacent layer among the layers. FPN architectures may also involve the width and height halving alternatively from one layer to the next layer. In some architectures, multiple tensors of the same width and height are produced within the FPN. An FPN may occur relatively early in the neural network topology, resulting in a necessity for a split point to occur within the FPN in order for a useful division of the network workload across the edge device and the cloud to be achieved. When a split occurs within the FPN of the machine task network, performance of a variety of machine task networks where layers up to the split point are common among the machine task networks (‘shared backbone’ architecture) may be achieved. Where a split point occurs within the FPN, tensor compression methods may exploit redundancies across the FPN layers to improve compression performance. Compression methods applicable to the various network topologies used in contemporary CNNs are therefore beneficial for application in a wide range of scenarios.

[0057] The system 100 may be used for implementing methods for decorrelating, packing and quantising feature maps into planar frames for encoding and decoding feature maps from encoded data for various neural networks. Various neural networks may be split at different points and may result in intermediate tensors of various number and dimensionality. A feature compression scheme capable of adapting to different types of intermediate data and capable of providing different quality reconstruction results in advantageous flexibility. Moreover, the system 100 provides flexibility to interface neural networks of various architectures and platforms and for various applications subjected to splitting into portions (e.g., for distributed execution), providing a means to determine whether the decoder and encoder are operating on compatible platforms, hence providing conformance to some conformance point.

[0058] The system 100 includes a source device 110 for generating frame data 115, typically in RGB 444 format. The frame data 115 is passed to a CNN backbone 116 to produce tensors 117. The tensors 117 are passed to a tensor encoder 118, which produces an encoded bitstream 121. The system 100 also includes a destination device 140 for decoding tensor data in the form of a received bitstream 143. The destination device 140 may be used for decoding46839667_2the tensor data (or tensors) for content (e.g., of audio data, video data, image data, and textual data) of the bitstream 143.

[0059] A communication channel 130 is used to communicate the encoded bitstream 121 from the source device 110 to the destination device 140. In some arrangements, the source device 110 and destination device 140 may either or both comprise respective mobile telephone 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, including connections across a Wide Area Network (WAN). The communication channel 130 may also be implemented across ad-hoc connections. Moreover, the source device 110 and the destination device 140 may comprise applications where encoded video data is captured on some computer-readable storage medium, such as a hard disk drive in a file server or memory. Although the system 100 is described as including a video source 112, which would provide the frame data 115 for a neural network targeting a computer vision application, other types of source data, such as audio or text, may be input to a suitable neural network implemented in the CNN backbone 116 and a CNN head 150. The CNN backbone 116 may also be referred to as a neural network first portion or NN part 1. The CNN head 150 may also be referred to as a neural network second portion or NN part 2.

[0060] As shown in Fig. 1, the source device 110 includes the video source 112, the CNN backbone 116, the tensor encoder 118, and a transmitter 122. The video source 112 typically comprises a source of captured video frame data (shown as 115), such as an image capture sensor, a previously captured video sequence stored on a non-transitory recording medium, or a video feed from a remote image capture sensor. The video source 112 may also be an output of a computer graphics card, for example, displaying the video output of an operating system and various applications executing upon 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 smart-phones, video camcorders, professional video cameras, and network video cameras. The video source 112 may produce independent images or may produce temporally sequential images, i.e., a video.

[0061] The neural network implemented in the CNN backbone 116 and the CNN head 150 may depend on the application. For example, a ‘YOLOv3’ network may be used as one part of an object tracking system and a ‘FasterRCNN’ network may be used as an object detection46839667_2system. The number and dimensionality of tensors 117 depends on a particular network performed in the system 100 and the split point of the particular network.

[0062] The CNN backbone 116 receives the video frame data 115 and performs specific layers of an overall CNN, such as layers corresponding to the first portion, which may be the ‘backbone’ 116 of the CNN, outputting tensors 117. The backbone layers 116 of the CNN may produce multiple tensors as output, for example, corresponding to different spatial scales of an input image represented by the video frame data 115 when splitting the network within the FPN. An FPN may result in three tensors, corresponding to three layers, output from the backbone 116 as the tensors 117 (e.g., if a ‘ YOLOv3’ network is performed by the system 100), with varying spatial resolution and channel count. When the system 100 is performing networks such as ‘Faster RCNN X101-FPN’ or ’Mask RCNN X101-FPN’ the tensors 117 may include tensors for four layers (P2-P5). Use of a FPN results in a plurality of tensors forming a hierarchical representation for a single frame to be encoded to (and decoded from) the bitstream when the split point of the network occurs within the FPN, as described hereafter. The tensor encoder 118 produces the encoded bitstream 121 from the tensors 117.

[0063] The bitstream 121 is supplied to the transmitter 122 for transmission over the communications channel 130 or the bitstream 121 is written to storage 132 for later use.

[0064] The source device 110 supports a particular network for the CNN backbone 116.However, the destination device 140 may use one of several networks for the head CNN 150. In using one of several networks for the head CNN 150, partially processed data in the form of packed feature maps may be stored for later use in performing various tasks without needing to again perform the operation of the CNN backbone 116.

[0065] The bitstream 121 is transmitted by the transmitter 122 over the communication channel 130 as encoded data. The bitstream 121 can in some implementations be stored in a storage memory 132, where the storage 132 is a non-transitory storage device such as a “Flash” memory or a hard disk drive, until later being transmitted over the communication channel 130 (or in-lieu of transmission over the communication channel 130). For example, encoded video data may be served upon demand to customers over a wide area network (WAN) for a video analytics application.

[0066] The destination device 140 includes a receiver 142, a tensor decoder 146, the CNN head 150, and a CNN task result buffer 152. The receiver 142 receives encoded video data 46839667_2from the communication channel 130 and passes the bitstream 143 to the tensor decoder 146. The tensor decoder 146 outputs decoded tensors 149, which are supplied to the CNN head 150. The CNN head 150 receives the tensors 149 and performs the second portion or later layers of the neural network that began with the CNN backbone 116 to produce a task result 151. The task result 151 is stored in the task result buffer 152. Example task results include mean object tracking accuracy (MOTA) metric or mean average precision (mAP). During training, the mAP determination typically involves comparison of the intersection divided by the union (IoU) of a predicted bounding box against a ground-truth bounding box, with a threshold applied such as 0.5. A mAP value for a video may be produced by taking the mean of the average thresholded IoUs in each supported object category.

[0067] The tensor decoder 146 also outputs a conformance information 159 to the task result buffer 152. The conformance information 159 is TRUE and indicates whether the tensors 149 are ‘conforming’, i.e., that the tensors 149 are bit-accurate (match tensors 592 described with reference to Fig. 5). When the tensors 149 are deemed conforming, operation of the tensor decoder 146 is said to correspond to a “conformance point” resulting from operation of the various layers in the tensor decoder 146 corresponding to operation of the tensor encoder 118. Typically, for the tensors 149 to be deemed as conforming, the platform on which the tensor decoder 146 operates needs to be substantially identical to the platform on which the tensor encoder 118 operates, thus ensuring that there are no noticeable discrepancies introduced into the tensors 149 attributable to platform differences. Notwithstanding platform alignment between the source device 110 and the destination device 140, differences are seen in the tensors 117 and the tensors 149 due to lossy compression performed in the tensor encoder 118. The contents of the task result buffer 152 may be presented to the user (e.g., via a graphical user interface), or provided to an analytics application where some action is decided based on the task result, which may include summary level presentation of aggregated task results to a user.

[0068] When the tensors 149 are not deemed to be conforming (i.e. the conformance information 159 is FALSE, indicates that the tensors 149 are not conforming), the task result 151 may be used with lower reliance than a task result 151 resulting from tensors which are determined to be conforming. In deployments of the FCM standard, it can be expected that heterogenous platforms will be used for instances of the source device 110 and instances of the destination device 140. In some FCM deployments, bitstreams could be allocated such that bitstreams encoded on a specific platform are allocated to decoders having the same platform (and hence producing conforming task results. Allocation of decoders having the same platform46839667_2can be performed when feasible, based on resource availability of compatible platforms for performance of the destination device 140.

[0069] Specific instances of the source device 110 could be deemed as being of high importance in some implementations. In surveillance networks for example, specific instances of the source device 110 could be deemed to be of high importance due to their physical placement resulting in capturing scenes of generally higher interest for video analysis.Allocation of limited processing resources among instances of the destination devices to achieve the most reliable task results could be based on achieving conforming decoder operation for such cases. It is also possible for the functionality of each of the source device 110 and the destination device 140 to be embodied in a single device (in which case conformance is ensured as the same platform is used for the tensor encoder 118 and the tensor decoder 146), examples of which include mobile telephone handsets and tablet computers and cloud applications.

[0070] As seen in Fig. 1, the system 100 also comprises a tensor codec repository 180. The codec repository 180 may include network topologies covering a variety of neural networks and associated split points, and reconstruction fidelity levels. The network topologies may be stored in in the tensor codec repository 180 for future reference (or use). The tensor codec repository 180 may be accessed ‘out of band’ or separately stored in each of the source device 110 and the destination device 140. In other words, the tensor codec repository 180 may be accessed over a network by the source device 110 and the destination device 140 rather than via the bitstream 143. A network topology identifier 174 and 176 may be sent by the tensor encoder 118 and the tensor decoder 146, respectively, to the tensor codec repository 180. The network topology identifiers 174 and 176 may be used for determining a given network topology from the bitstream 143.

[0071] As a result of a request for a given network topology, a network topology 172 and 178 may be returned by the tensor codec repository 180 to the tensor encoder 118 and the tensor decoder 146, respectively. As described in detail below, the information including the network topology identifier 178 may be decoded and used by the tensor decoder 146 for producing decoded tensors using the determined network topology. The tensor codec repository 180 may be accessible via public file repository or within a private network accessible to the source device 110 and the destination device 140. A given network topology defines the composition and interconnection of a set of machine-learning primitive operations including convolutions,46839667_2batch normalisations, activation functions, and concatenations. The data type provided from the CNN backbone 116 and supplied to the CNN head 150 may differ from that used internally by the network topology. For example, integer inferencing is commonly used due to its reduced complexity compared to floating-point inferencing. Where floating-point values are produced by the CNN backbone 116, precision such as 16-, 32-, and 64-bit are possible.Although the IEEE-754 standard specifies bit allocations between exponent and fraction for floating-point formats, such as “binaryl6”, “binary32”, different formats are possible. For 16-bit floating-point values, the “bfloatl6” format may be used, with 8-bit exponent and 7 -bit fraction. Where a network topology is available but configured to use floating-point inferencing, an adaptation between integer and floating-point domains is needed to couple the network topology implemented in the tensor encoder 118 and the tensor decoder 146 with the CNN backbone 116 and the CNN head 150.

[0072] The video source 112 can provide vision model parameters 113 to the tensor encoder 118, as described hereafter. The vision model parameters 113 include the spatial resolution of the frame data 115, used for bounding boxes (an example of the task result 151) to be scaled to correspond to the resolution of the frame data 115.

[0073] Notwithstanding the example devices mentioned above, each of the source device 110 and destination device 140 may be configured within a general -purpose computing system, typically through a combination of hardware and software components. Fig. 2A illustrates such a computer system 200, which includes: a computer module 201; input devices such as a keyboard 202, a mouse pointer device 203, a scanner 226, a camera 227, which may be configured as the video source 112, and a microphone 280; and output devices including a printer 215, a display device 214 and loudspeakers 217. An external Modulator-Demodulator (Modem) transceiver device 216 may be used by the computer module 201 for communicating to and from a communications network 220 via a connection 221. The communications network 220, which may represent the communication channel 130, may be a (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 221 is a telephone line, the modem 216 may be a traditional “dial-up” modem. Alternatively, where the connection 221 is a high capacity (e.g., cable or optical) connection, the modem 216 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 220. The transceiver device 216 may provide the functionality of the transmitter 122 and the receiver 142 and the communication channel 130 may be embodied in the connection 221.46839667_2

[0074] 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 random access memory (RAM) and semiconductor read only memory (ROM). The computer module 201 also includes a number of input / output (I / O) interfaces including: an audio-video interface 207 that couples to the video display 214, loudspeakers 217 and microphone 280; an I / O interface 213 that couples to the keyboard 202, mouse 203, scanner 226, camera 227 and optionally a joystick or other human interface device (not illustrated); and an interface 208 for the external modem 216 and 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 incorporated within the computer module 201, for example within the interface 208. The computer module 201 also has a local network interface 211, which permits coupling of the computer system 200 via a connection 223 to a local-area communications network 222, known as a Local Area Network (LAN). As illustrated in Fig. 2A, the local communications network 222 may also couple to the wide network 220 via a connection 224, which would typically include a so-called “firewall” device or device of similar functionality. The local network interface 211 may comprise an Ethernet™ circuit card, a Bluetooth™ wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 211. The local network interface 211 may also provide the functionality of the transmitter 122 and the receiver 142 and communication channel 130 may also be embodied in the local communications network 222.

[0075] The I / O interfaces 208 and 213 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 209 are provided and typically include a hard disk drive (HDD) 210. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 212 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g. CD-ROM, DVD, Blu ray Disc™), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the computer system 200. Typically, any of the HDD 210, optical drive 212, networks 220 and 222 may also be configured to operate as the video source 112, or as a destination for decoded video data to be stored for reproduction via the display 214. The source device 110 and the destination device 140 of the system 100 may be embodied in the computer system 200.46839667_2

[0076] The components 205 to 213 of the computer module 201 typically communicate via an interconnected bus 204 and in a manner that results in a conventional mode of operation of the computer system 200 known to those in the relevant art. For example, the processor 205 is coupled to the system bus 204 using a connection 218. Likewise, the memory 206 and optical disk drive 212 are coupled to the system bus 204 by connections 219. Examples of computers on which the described arrangements can be practised include IBM-PC’s and compatibles, Sun SPARCstations, Apple Mac™ or alike computer systems.

[0077] The tensor encoder 118, the tensor decoder 146 and methods to be described, may be implemented as one or more software application programs 233 executable within the computer system 200. In particular, the tensor encoder 118, the tensor decoder 146 and the steps of the described methods of Figs. 18 and 19 are effected by instructions 231 (see Fig. 2B) in the software 233 that are carried out within the computer system 200. The software instructions 231 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

[0078] The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 200 from the computer readable medium, and then executed by the computer system 200. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system 200 preferably effects an advantageous apparatus for implementing the source device 110 and the destination device 140 and the described methods.

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

[0080] In some instances, the application programs 233 may be supplied to the user encoded on one or more CD-ROMs 225 and read via the corresponding drive 212, or alternatively may be read by the user from the networks 220 or 222. Still further, the software can also be loaded into the computer system 200 from other computer readable media. Computer readable storage46839667_2media refers to any non-transitory 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 tape, CD-ROM, DVD, Blu-ray Disc™, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 201. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of the software, application programs, instructions and / or video data or encoded video data to the computer module 201 include radio or infra-red transmission channels, as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

[0081] The second part of the application program 233 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 214. Through manipulation of typically the keyboard 202 and the mouse 203, a user of the computer system 200 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 217 and user voice commands input via the microphone 280.

[0082] Fig. 2B is a detailed schematic block diagram of the processor 205 and a “memory” 234. The memory 234 represents a logical aggregation of all the memory modules (including the storage devices 209 and semiconductor memory 206) that can be accessed by the computer module 201 in Fig. 2A.

[0083] When the computer module 201 is initially powered up, a power-on self-test (POST) program 250 executes. The POST program 250 is typically stored in a ROM 249 of the semiconductor memory 206 of Fig. 2 A. A hardware device such as the ROM 249 storing software is sometimes referred to as firmware. The POST program 250 examines hardware within the computer module 201 to ensure proper functioning and typically checks the processor 205, the memory 234 (209, 206), and a basic input-output systems software (BIOS) module 251, also typically stored in the ROM 249, for correct operation. Once the POST program 250 has run successfully, the BIOS 251 activates the hard disk drive 210 of Fig. 2A.46839667_2Activation of the hard disk drive 210 causes a bootstrap loader program 252 that is resident on the hard disk drive 210 to execute via the processor 205. This loads an operating system 253 into the RAM memory 206, upon which the operating system 253 commences operation. The operating system 253 is a system level application, executable by the processor 205, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

[0084] The operating system 253 manages the memory 234 (209, 206) to ensure that each process or application running on the computer module 201 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the computer system 200 of Fig. 2A need to be used properly so that each process can run effectively. Accordingly, the aggregated memory 234 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 200 and how such memory is used.

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

[0086] The application program 233 includes a sequence of instructions 231 that may include conditional branch and loop instructions. The program 233 may also include data 232 which is used in execution of the program 233. The instructions 231 and the data 232 are stored in memory locations 228, 229, 230 and 235, 236, 237, respectively. Depending upon the relative size of the instructions 231 and the memory locations 228-230, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 230. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 228 and 229.46839667_2

[0087] In general, the processor 205 is given a set of instructions which are executed therein. The processor 205 waits for a subsequent input, to which the processor 205 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, 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, all depicted in Fig. 2 A. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 234.

[0088] The tensor encoder 118, the tensor decoder 146 and the described methods may use input variables 254, which are stored in the memory 234 in corresponding memory locations 255, 256, 257. The tensor encoder 118, the tensor decoder 146 and the described methods produce output variables 261, which are stored in the memory 234 in corresponding memory locations 262, 263, 264. Intermediate variables 258 may be stored in memory locations 259, 260, 266 and 267.

[0089] Referring to the processor 205 of Fig. 2B, the registers 244, 245, 246, the arithmetic logic unit (ALU) 240, and the control unit 239 work together to perform sequences of microoperations needed to perform “fetch, decode, and execute” cycles for every instruction in the instruction set making up the program 233. Each fetch, decode, and execute cycle comprises:a fetch operation, which fetches or reads an instruction 231 from a memory location 228, 229, 230;a decode operation in which the control unit 239 determines which instruction has been fetched; andan execute operation in which the control unit 239 and / or the ALU 240 execute the instruction.

[0090] Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 239 stores or writes a value to a memory location 232.46839667_2

[0091] Each step or sub-process in the methods of Figs. 18 and 19, to be described, is associated with one or more segments of the program 233 and is typically performed by the register section 244, 245, 246, the ALU 240, and the control unit 239 in the processor 205 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 233.

[0092] Fig. 3A is a schematic block diagram 300 showing functional modules of a backbone portion 310 of a CNN. The diagram 300 which may serve as an implementation of the CNN backbone 116 when the system 100 is configured to perform a ‘YOLOv3’ network. The backbone portion 116 is sometimes referred to as ‘DarkNet-53’, although different backbones are also possible, resulting in a different number of and dimensionality of layers of the tensors 117 for each frame. In one implementation, the backbone portion 310 may be used as a person detector for the purpose of object tracking.

[0093] As shown in Fig. 3 A, the video data 115 is passed to a resizer module 304. The resizer module 304 resizes each frame of the video data 115 to a resolution suitable for processing by the CNN backbone 310, producing resized frame data 312. If the resolution of the video data 115 is already suitable for the CNN backbone 310, operation of the resizer module 304 is not needed. The resized frame data 312 is passed to a convolutional batch normalisation leaky rectified linear (CBL) module 314 to produce tensors 316. The CBL module 314 contains modules as described with reference to a CBL module 360 as shown in Fig 3D.

[0094] The CBL module 360 takes as input a tensor 361 of the resized frame data 312. The tensor 361 is passed to a convolutional layer 362 to produce tensor 363. If the convolutional layer 362 has a stride of one, the tensor 363 has the same spatial dimensions as the tensor 361. If the convolution layer 362 has a larger stride, such as two, the tensor 363 has smaller spatial dimensions compared to the tensor 361, for example, halved in width and height for the stride of two. Regardless of the stride, the size of channel dimension of the tensor 363 may vary compared to the channel dimension of the tensor 361 for a particular CBL block. The tensor 363 is passed to a batch normalisation module 364, which outputs a tensor 365. The batch normalisation module 364 normalises the input tensor 363 and applies a scaling factor and an offset value to produce the output tensor 365. The scaling factor and offset value are derived from a training process. The tensor 365 is passed to a leaky rectified linear activation (“LeakyReLU”) module 366 to produce a tensor 367. The module 366 provides a ‘leaky’ activation function whereby positive values in the tensor are passed through and negative values are severely reduced in magnitude, for example, to 0.1X their former value.46839667_2

[0095] Returning to Fig. 3 A, the tensor 316 is passed from the CBL block 314 to a residual block module 320, such as a ‘resl+2+8’ module (also referred to as a resl 1 module) containing a concatenation of three residual blocks, each residual block containing one (1) residual unit, two (2) residual units, and eight (8) residual units, respectively. The spatial resolution of the tensors is halved horizontally and halved vertically in each of the residual blocks (see Fig. 3B) by a convolution with stride equal to two in a CBL block 344.

[0096] A residual block is described with reference to a ResBlock 340 as shown in Fig. 3B. The ResBlock 340 receives a tensor 341. The tensor 341 is zero-padded by a zero-padding module 342 to produce a tensor 343. The tensor 343 is passed to the CBL module 344 to produce a tensor 345. The CBL module 344 contains a convolution (for example 362) with a stride parameter set to two, resulting in the tensor 345 having half the width and half the height of the tensor 343. The tensor 345 is passed to a residual unit 346. The residual unit 346 contains a series of concatenated residual units, based on the number of residual block (for example, eleven (11) units for the block 320). The last residual unit of the residual units 346 outputs a tensor 347.

[0097] A residual unit is described with reference to a ResUnit 350 as shown in Fig. 3C. The ResUnit 350 takes a tensor 351 as input. The tensor 351 is passed to a CBL module 352 to produce a tensor 353. The tensor 353 is passed to a second CBL unit 354 to produce a tensor 355. An add module 356 sums the tensor 355 with the tensor 351 to produce a tensor 357. The add module 356 may also be referred to as a ‘shortcut’ as the input tensor 351 substantially influences the output tensor 357. For an untrained network, ResUnit 350 acts to pass-through tensors. As training is performed, the CBL modules 352 and 354 act to deviate the tensor 357 away from the tensor 351 in accordance with training data and ground truth data.

[0098] Returning to Fig. 3 A, the Resl 1 module 320 outputs a tensor 322. The tensor 322 is output from the backbone module 310 as one of the layers (tensors 117) and also provided to a Res8 module 324. The Res8 module 324 is a residual block (i.e., 340), which includes eight residual units (i.e. 350). The Res8 module 324 produces a tensor 326. The tensor 326 is passed to a Res4 module 328 and output from the backbone module 310 as one of the layers (tensors 117). The Res4 module is a residual block (i.e., 340), which includes four residual units (i.e., 350). The Res4 module 328 produces a tensor 329. The tensor 329 is output from the backbone module 310 as one of the layers. Collectively, the layer tensors 322, 326, and 329 are output as the tensors 117 and may be referred to as layers 0-2 or L0, LI, and L2, respectively. The backbone CNN 310 may take as input a video frame of resolution 1088×608 and produce46839667_2three tensors, corresponding to three layers, with the following dimensions: [1, 256, 76, 136], [1, 512, 38, 68], [1, 1024, 19, 34], Another example of the three tensors 117 corresponding to three layers may be [1, 512, 34, 19], [1, 256, 68, 38], [1, 128, 136, 76] which are respectively separated at layer index 75, 90, and 105 when the layers are enumerated according to the YOLOv3 software implementation of the backbone 300 and a head 1200.

[0099] Each of the Resl 1 320, Res8 324 and Res4 328 operates in a similar manner to ResBlock 340. Each of the CBL 314, the CBL 344 and the CBL 354 operate in a similar manner to the CBL 360.[000100] Fig. 4 is a schematic block diagram showing functional modules of an alternative backbone portion 400 of a CNN, which may serve as an implementation of the CNN backbone 116 when the system 100 is configured to perform a “FasterRCNN” or “MaskRCNN” ResNet 101 network. Frame data 115 is input and passes through a stem network 408, a res2 module 412, a res3 module 416, a res4 module 420, and a res5 module 424 via tensors 409, 413, 417, 421, 425 respectively. The backbone portion 400 may be used as part of a general object detector or for instance segmentation, with various classes of object supported.[000101] The stem network 408 includes a convolution with a kernel size of 7x7 and a stride of two (2) and a max pooling operation. The res2 module 412, the res3 module 416, the res4 module 420 and the res5 module 424 perform convolution operations, such as LeakyReLU activations. Each module 412, 416, 420 and 424 also performs one halving of the width and height of the processed tensors via a stride setting of two. Each of the tensors 413, 417, 421 and 425 are passed from the res modules 412, 416, 520 and 424 to one of 1x1 lateral convolution modules 446, 444, 442 and 440 respectively. The modules 446, 444, 442, and 440 produce tensors 447, 445, 443 and 441 respectively. The tensor 441 is passed to a 3x3 output convolution module 470, which produces an output tensor P5471.[000102] The tensor 441 is also passed to upsampler module 450 to produce an upsampled tensor 451. A summation module 460 sums the tensors 443 and 451 to produce a tensor 461. The tensor 461 is passed to an upsampler module 452 and a 3x3 lateral convolution module 472. The module 472 outputs a P4 tensor 473. The upsampler module 452 produces an upsampled tensor 453. A summation module 462 sums tensors 445 and 453 to produce a tensor 463. The tensor 463 is passed to a 3x3 lateral convolution module 474 and an upsampler module 454. The module 474 outputs a P3 tensor 475. The upsampler module 454 outputs an46839667_2upsampled tensor 455. A summation module 464 sums the tensors 447 and 455 to produce tensor 465, which is passed to a 3x3 lateral convolution module 476. The module 476 outputs a P2 tensor 477. The upsampler modules 450, 452, and 454 use nearest neighbour interpolation for low computational complexity. The tensors 471, 473, 475, and 477 form the output tensors 117 of the CNN backbone 400. Although Fig. 4 shows a particular backbone portion of the Faster RCNN network architecture (a ‘P-layer split point), different divisions into backbone and head are possible. Splitting the network at tensor 409 is termed a ‘stem’ split point.Splitting the network at tensors 447, 445, 443, and 441 is termed a ‘C-layer’ split point.[000103] Fig. 5 is a schematic block diagram 500 of an example implementation of the tensor encoder 118 capable of operating at a conformance point derived in combination with a tensor compressor 530 and selected tensor functions provided by a platform device 700, described with reference to Fig. 7. Bit-accurate operation of the tensor compressor 530 is defined only in combination with knowledge of a specific platform used to provide low-level functions, such as convolutions and rounding modes.[000104] Figs. 10 and 11 are a schematic block diagrams showing a bitstream structure 1000 with a container for coded feature frame data 10200, 10400. The bitstream structure 1000 provides a “box-like” structure, that is, a structure in which each block of syntax (or “box”) is prefixed with an identifier and a length field in a header. An FCM CPS 1010, with associated header 1014 are an example of the box structure. The header 1014 includes a size 1012 (fcm_unit_size), coded using 32-bits and indicating the size of the header 1014 and the FCM_CPS 1010 in bytes, a type 1012b (fuh_unit_type), identifying the FCM_CPS 1010 as containing an FCM conformance parameter set. The FCM CPS 1010 includes aCPS ID 1012c (conformance_parameter_set_id), providing an identifier for theFCM CPS 1010. Synchronisation to detect the start of the bitstream structure 1000, or to enter at random-access points, is outside the scope of the bitstream structure 1000 itself. That is, synchronisation is performed by external means, such as a bitstream transmission start indication provided by the transmitter 122. The FCM CPS 1010 includes signalling indicating low-level function implementations to be used when performing NN operations such as convolutions, described with reference to Appendix A. Indication of low-level functions may be achieved via identification of the specific platform used to perform said operations, or a more granular specification, such as rounding methods, parallelism in accumulation, use of FMA, and the like. An FCM_VMPS 1020 or “FCM vision model parameter set” signals information needed by the CNN head 150 to complete performance of the machine task, as shown in Appendix A. The FCM_VMPS 1020 is identified by a header 1024 which includes a 46839667_2size 1022 (fcm_unit_size) specifying the size of the header 1024 and the FCM_VMPS 1020 in bytes. The header 1024 includes a type 1022b (fuh_unit_type) identifying the FCM_VMPS 1020 as an FCM vision model parameter set. The FCM_VMPS 1020 includes a VMPS_ID 1022c (vmps_vision_model_parameter_set_id), serving as an identifier for the FCM_VMPS 1020. An FCM_RSD (FCM restoration data) 10100 includes signalling to configure the modules of the tensor encoder 118 and tensor decoder 146 other than the inner codec, discussed with reference to Figs. 5 and 12 respectively. The FCM RSD 10100 is prefixed by a header 10104, which includes a size 10102 and a type 10112. The size 10102 signals the length of the header 10104 and the FCM RSD 10100 in bytes, as a 32-bit value. The type 10112 identifies the FCM RSD 10100 as an FCM restoration data unit, which contains one or more FCM parameter sets such as an FCM SPS 10130, an FCM PPS 10140, and an FCM PH 10150. The FCM RSD 10100 is associated with the FCM CPS 1010 in the header 10104 by a CPS ID 10116 having a value corresponding to that of the CPS ID 1012c, coded as a fixed-length codeword less than one byte, such as four bits. The FCM RSD 10100 is associated with the FCM_VMPS 1020 in the header 10104 by a VMPS_ID 10114 having a value corresponding to that of the VMPS ID 1022c.[000105] The FCM RSD 10100 includes a header containing a fixed 32-bit code identifying that the FCM RSD 10100 contains restoration parameters followed by a 32-bit length code that signals a length, such as the bit length or byte length of the entirely of the FCM RSD 10100. The FCM SPS 10130 or “FCM sequence parameter set” signals information needed to configure the tensor decoder 146 in the current sequence of coded feature frames to produce the tensors 149, with multiple sets of sequence parameters encodeable via unique SPS ID values. The FCM PPS 10140 or “FCM picture parameter set” signals parameters used by the tensor decoder 146 and is associated with at least one coded feature frame in the FCM CVD 10200, or “FCM coded feature data” box and references a previously coded FCM SPS via an SPS ID value. The FCM PPS 10140 may be parsed independently of other picture-level signalling in the FCM RSD 10100 but may be dependent on the FCM SPS 10130. An FCM picture header (FCM PH) 10150 encodes a picture parameter set ID (PPS ID 1150 in Fig. 11) and a POC 1152, creating an association between parameters (such as quantisation range) and a specific picture. A quantisation range or fused- and restored-domain parameters coded in theFCM PPS 10140 are identified by a PPS ID 1120. The FCM PH 10150 includes the PPS ID 1150 which references an FCM PPS, such as the FCM PPS 10140 with matching value for the PPS ID 1120. The FCM PH 10150 is also associated with a picture based on the POC 1152, thus enabling associating a quantisation range or fused- and restored-domain46839667_2refinement parameters with a specific picture or feature frame. For each coded feature frame in the FCM CVD 10200, a corresponding (i.e., having the same indicated POC value) FCM PH is present in the FCM RSD 10100. The bitstream 121 is required to encode an FCM PPS (10140) with a specific value for PPS ID 1120 prior to use by any FCM PH (such as 10150). That is, the FCM PPS is encoded prior to activation or reference by the PPS ID 1150. Where multiple instances of the FCM PPS use the same PPS ID value, the parameters of the most recently signalled FCM PPS prior to activation by a specific picture, i.e., coding of the FCM PH corresponding to the specific picture and with a corresponding PPS ID value are used. Similarly, an FCM SPS, such as the FCM SPS 10130, with some SPS ID value must be coded prior to reference by an FCM PPS, such as the FCM PPS 10140 using the SPS ID value.[000106] Fig. 11 shows an example 1100 corresponding to the FCM RSD 10100 of Fig. 10. In the example of Fig. 11, the FCM PH 10150 signals the (absolute) picture order count (POC) 1152 of a corresponding feature frame in the FCM CVD 10200 as a 32-bit integer value. The POC is a value that is associated with each one of the feature frames in the bitstream, and Each feature frame has specific POC. Also, the POC may be a value corresponding to an output order of the feature frame.[000107] Returning to Fig. 10, the FCM CVD (FCM coded video data) 10200 box contains coded feature frames from the inner codec, i.e., video encoder 542 described with reference to Fig. 5. When the inner codec conforms to a compression standard such as H.264 / AVC, H.265 / HEVC, or H.266 / VVC, the FCM_CVD 10200 includes a sequence parameter set (SPS) 10230, one or more picture parameter sets (PPSs), such as a PPS 10240. The SPS and any PPSs pertain to the coded feature frames, defining profile (collection of coding tools, limits on bit depth and supported chroma formats) and level (maximum sample and bitrate) of the inner codec, and further parameters applicable to enabled coding tools. The FCM CVD 10200 also includes an intra (I) slice 10260 corresponding to a random-access point in the bitstream 121 and located at the beginning of the FCM_CVD 10200, and the FCM_CVD 10200 includes at least one uni-predicted or bi-predicted (P or B) slice, such as P slice 10290. The I slice 10260 contains a one coded feature frame as a sequence of CTUs or macroblocks partitioned such as into a collection of intra-predicted CUs according to a coding tree. In the embodiment described, a POC associated with the coded feature frame or ‘access unit’ (AU) for the I slice 10260 is also signalled in AU header 10210 associated with the I slice 10260. An AU header 10270, using the same structure as described with reference to the AUheader 10210, encodes the length of AU #1 10280. The AU #1 10280 contains a coded feature 46839667_2frame with POC value of 1, encoded using a P slice 10290. The P slice 10290 contains one coded feature frame, which may include inter-predicted coding units referencing earlier coded feature frames, such as obtained from the I slice 10260. Specifically, the P slice 10290 contains CUs for the one coded feature frame which are inter-predicted from other coded feature frames (i.e., slices) in the current FCM_CVD 10200 or in preceding FCM_CVDs, within limits of a decoded picture buffer (DPB) present in the inner codec (i.e., in both the encoder 542 and a decoder 1204). A POC associated with the one coded feature frame in the P slice 10290 is also signalled in the P slice 10290. In one arrangement, a single feature frame is coded in a single slice (i.e. one feature frame per one slice), although it is possible to use multiple slices for one coded feature frame. In each slice, a coded feature frame is identified by a specific POC signalled in the slice header for the slice.[000108] In one arrangement, it is required that POCs 1152 of the FCM PH 10150, i.e., within the FCM RSD 10100, correspond only to POCs found within the FCM CVD 10200. Each FCM CVD 10200 must contain one or more whole coded feature frames, i.e., splitting one coded feature frame between two different FCM CVDs is not permitted, even if no other FCM CVDs are coded between the two FCM CVDs that code the one coded feature frame. The bitstream 121 may contain numerous pairs of FCM RSDs and FCM CVDs, each of which has FCM PPS metadata applied via FCM PH instances first applied to corresponding (by POC) coded feature frames within the pair, i.e., FCM PH instances not spanning from one pair of FCM RSD and FCM CVD to the next pair of FCM RSD and FCM CVD. For example, FCM RSD 10300 has the structure described with reference to the FCM RSD 10100, with parameters applicable to coded feature frames present within the FCM CVD 10400. The FCM CVD 10400 has an internal structure in accordance with the description of the FCM CVD 10200.[000109] For applications where low-latency, i.e., minimized latency, is desired, an arrangement results in each pair of FCM RSD and FCM_CVD (i.e., 10100 and 10200, or 10300 and 10400) in the bitstream 121 containing parameters for one coded feature frame and the one coded feature frame (i.e., AU), respectively (of the same POC). When each FCM_CVD (e.g., 10200 or 10400) contains only one AU the FCM_CVS 10200 includes the SPS 10230, the PPS 10240, the PH 10250, and the I slice 10260, forming one AU, i.e., 10220. The FCM_CVD 10400 would contain the P slice 10290, corresponding to POC #1, forming another AU (i.e., 10280). In the case of H.264 / AVC, H.265 / HEVC, and H.266 / VCC being used as the inner codec, each NAL unit (e.g., the SPS 10230, the PPS 10240, the PH 10250, the I slice 10260, and the P slice 10280) begins with a three-byte NAL unit start code, followed by a NAL unit header of one or two bytes 46839667_2in length, followed by the NAL unit payload which contains the encoded syntax elements of the parameter set or slice. Using the SPS 10230 as an example, a NAL unit start code 10232 containing the byte sequence 0x000001, a NAL unit header 10234 with one or two bytes in length, and a NAL unit payload 10236 are present. NAL unit start codes, such as 10232 delineate each inner codec unit such as the SPS 10230, the PPS 10240, the PH 10250, the I slice 10260. To prevent contents of NAL units from triggering false start code detections, ‘emulation prevention bytes’ are inserted, such that if the pattern ‘0x000001’ appears in the payload, an 0x03 byte is inserted, resulting in the contents ‘0x00000301’ in the bitstream, preventing false detection of an unintended start code. An entropy encoder 838, described with reference to Fig. 8, inserts NAL unit start codes and emulation prevention types and the entropy decoder 1320 separates the received bitstream 143 into separate NAL units based on detected start codes, with emulation prevention bytes removed prior to subsequent parsing. The POC of the coded frame in the FCM_CFD 10200 is known from each AU headers, e.g., 10210, which corresponds to a respective FCM PH, e.g., 10150.[000110] Arrangements where multiple coded pictures are stored within one FCM CFD 10200 require a delineation scheme for AUs that permits identifying the POC of each AU without requiring parsing of the inner-codec bitstream. Within the FCM_CVD 10200, each AU (e.g., 10220 and 10280) is coded with a prefix header (e.g., 10210 and 10270) which includes a size field (e.g,, 10212 for the AU header 10210). The AU header also identifies the coded feature frame POC of the AU independently of any compression-standard specific header that may be contained within the AU, e.g., POC 10214 indicates the POC of the AU 10220 without requiring parsing of the contents of the AU 10220, which are specific to the compression standard used for the inner codec. A size SZ 10234 indicates the size in bytes of all NAL units needed to encode one AU, i.e., contents of the AU 10220, such as the size of the SPS 10230, the PPS 10240, the PH 10250, and the I slice 10260 in bytes. The POC 10214 identifies the picture order count of the AU 10220, avoiding the need to parse contents of the AU 10220, which are specific to which inner codec is used, to know the POC of the AU 10220. In some arrangements the inner codec might not support encoding of a POC value, for example if an image compression standard such as ISO / IEC 10918-1 (JPEG) were used, in which case the POC 10214 is necessary to determine the POC of the following AU.[000111] As shown in Figs. 10 and 11, the structure 1000 contains a plurality of parameter sets (such as FCM CPS 1010, FCM RSD 10100 and FCM_CVD 10400). The FCM_PPS 10140 can be considered to provide a first parameter set of a plurality of parameter sets of the46839667_2bitstream 121. The PPS ID 1120 identifies the present FCM PPS 10140 for which parameters (e.g., quantisation range and / or fused- and restored-domain parameters) are being coded.[000112] A refinement mechanism applies the refinement to the feature maps in the reduced domain and in the restored domain. Referring to Fig. 11, mean in the reduced domain is coded as MUI 1131a. Mean in the restored domain is coded as MU2 1134a. Standard deviation in the reduced domain is coded as SIGMA1 1132a. Standard deviation in the restored domains is coded as SIGMA2 1136a. Values 1131a, 1132a, 1134a, and 1136a are coded using 16-bit floating-point values, such as IEEE-754 16-bit floating point representation or “brain float” representation from Google™, which affords more bits for the exponent at the expense of fewer bits available for the mantissa. Signalling of MUI 1131a and SIGMA1 1132a may be conditional on update flag UF1 1130a. Likewise update flag UF2 1133a may condition signalling of MU2 1134a. An alternative to the explicit flags UF1 1130a and UF2 1133a is to periodically update the mean (mu) and standard deviation (sigma) values based on a POC modulo value. In other words, an update flag may be encoded to (or decoded from) an FCM PPS (such as 10140) of the bitstream, the update flag indicating whether refinement parameters (mean and sigma 1131a / 1132a or 1134a / 1136a) are to be updated. Update periodicity in the reduced and restored domains may differ and may be set to correspond to the periodicity of coding intra frames (I slices) in the bitstream 121, known as the ‘intra period’ of the GOP structure used in the inner codec.[000113] In an arrangement of the source device 110 and the destination device 140, reduced-domain refinement parameters 564 and restored-domain refinement parameters 506 (see Fig. 5) are signalled only in FCM PPS 10140 having a POC divisible by a reduced-domain periodicity reduced_domain_update_period (signalled in the FCM SPS 10130) and a restored-domain periodicity restored_domain_update_period (signalled in the FCM SPS 10130) with a remainder of zero, known as a ‘periodic update’ of the refinement parameters. For example, with a refinement period of 64, opportunity to update the refinement parameters is available for pictures with POC of 0, 64, 128, 192, and so on. When periodic update of the refinement parameters is performed, an FCM PPS 10140 with a POC of zero is required in the bitstream 121 so that the first pictures up to the refinement periods for reduced- and restored-domains are available. The reduced- and restored-domain parameters are only updated with an FCM PPS 10140 with POC divisible by the reduced- or restored-domain update period. In other words, it is not mandatory to update the refinement parameters at each opportunity.46839667_2[000114] In an arrangement of the source device 110 and the destination device 140, a reduced-domain refinement period update flag and a restored-domain refinement period update flag are coded in the FCM PPS 10140. The reduced-domain refinement period update flag and the restored-domain refinement period update flag each provide an opportunity to update the refinement period at any POC value. When updating the refinement period, the modulo remainder is relative to the POC at which the update occurred. For example, if the FCM PPS at POC 10 indicates a refinement period of 32, then reduced-domain and restored-domain refinement parameters are able to be updated from POC 10, 42, 74, 106, and so on, in addition to a mandatory parameter establishment at POC 0. Separate periods may be defined for the reduced- and restored-domains or a single period may apply to both domains.[000115] Fig. 18 shows a method 1800 for performing a first portion of a CNN, compressing tensors using the selected feature reduction topology, and encoding resulting compressed tensors using a video encoder (encoder portion of the “inner codec”) conforming to a selected video compression standard. The tensor encoder 118 (and the example implementation 500) and the method 1800 may be implemented as one or more software application programs 233 executable within the computer system 200 on the source device 110. The tensor encoder 118 and the method 1800 may be effected by instructions 231 (see Fig. 2B) in the software 233 that are carried out within the computer system 200. The software instructions 231 may be formed as one or more code modules, each for performing one or more particular tasks of the method 1800. The method 1800 commences at a platform determination step 1805.[000116] At the step 1805 the processor 205 determines the platform to be used for executing of learned layers contained in the CNN backbone 116 and the tensor encoder 118. The determined platform may be different from the platform provided as the processor 205 due to use of processing modules external to the processor 205 such as GPUs. As a result of the step 1805, platform information is derived. The platform information may include parameters as described with reference to the conformance parameter set (FCM CPS) described in Appendix A. For example, the platform information may relate to one or more of vendor, device model, device stepping, software name and software version and the like. Control in the processor 205 progresses from the step 1805 to a perform neural network first portion step 1810.[000117] At the step 1810, the CNN backbone 116, under execution of the processor 205, performs the first portion of a neural network using frame data 115 from the video source 112 as input. The CNN backbone 116 outputs the tensors 117. The step 1810 generates or produces46839667_2the tensors 117, each of the tensors containing at least one feature map. Control in the processor 205 progresses from the step 1810 to a datatype adjustment step 1815.[000118] At the step 1815, a datatype converter 570 (see Fig. 5), under execution of the processor 205, converts the datatype of tensors 117 received from the CNN backbone 116 to a datatype compatible with the tensor compressor 530. The tensor compressor 530 may operate on binary32 format whereas various CNN backbones that may be used produce output in formats such as float16 or bfloat 16. For example, in a case where the datatype of tensors 117 received from the CNN backbone 116 is float16 and the datatype compatible with the tensor compressor 530 is binary32, the datatype converter 570 converts the datatype of tensors 117 received from the CNN backbone 116 to the datatype which is binary32, and outputs the tensors 117 the datatype of which is converted. The step 1815 outputs converted tensors 574. In some instances, the tensors 574 have a same datatype as the tensors 117 and in other implementations the tensors 574 have a different datatype to the tensors 117. Known technology may be used as the method of converting the datatype. Control in the processor 205 progresses from the step 1815 to a select inner codec step 1820.[000119] At the step 1820, the processor 205 selects one video compression standard out of a plurality of video compression standards and a corresponding profile for the selected video compression standard. AVC, HEVC, and VVC may be options for selection of the compression standard at step 1820 and the video compression standard selected may be dependent on considerations such as the capabilities of the source device 110 and the destination device 140. For the purpose of encoding the feature frame 900, the selection of profiles may be constrained to omit profiles supporting tools such as spatial scalability, and multi-view (3D) coding. Tools such as spatial scalability and multi-view coding tend to be less relevant to compression of video such as the frame 900. The selection of profiles may be constrained to support several bit depths, such as 8-, 10-, and 12-bit coding, monochrome (4:0:0) only or 4:2:0, due to the ubiquity of 4:2:0 support. Where available, “Still picture” profiles can be used where only use intra coding of coded video data is to be performed. A capabilities negotiation may take place between the source device 110 and the destination device 140 whereby a selection is made such that the same compression standard is used in each device, prioritising VVC over HEVC and HEVC over AVC. Selection at step 1820 may be constrained based on a profile of the FCM standard, such that a smaller set of compression standards is available, such as HEVC and AVC, from which one is selected based on the aforementioned capabilities negotiation step. Rather than selecting a repurposed video codec for compressing features, specific FCM profiles may select a customised approach such as 46839667_2compressing quantized values of features using deepCABAC, with or without prediction of values within a feature map or from one feature map to another. Such customised approaches may be targeted applications where achieving low bitrate is a secondary consideration compared to achieving very low complexity, for example. In typical use, the selection of the step 1820 is performed one time and thus does not change during the course of encoding one bitstream. Other arrangements may select a different inner codec during coding of the bitstream 121 provided that the switch from one inner codec to a different inner codec is made prior to encoding a new group-of-pictures (GOP), i.e., prior to a new “intra random access picture” (IRAP) or “instantaneous decoder refresh” (IDR) picture. Control in the processor 205 progresses from the step 1820 to a derive restored-domain refinement parameters step 1830.[000120] At the step 1830, when the restored-domain refinement is enabled(restored feat refine enable flag is set to 1), a refinement parameter extraction unit 504 (Fig.5) derives the mean (mu) and the standard deviation (sigma) over all tensors in the tensors 574 (effectively the tensors 117), over all channels in each tensor such that a single mean and a single standard deviation value is computed for the tensors 574 corresponding to one frame. In one arrangement, the mean for all tensors in the tensors 574 is the average value of all elements of all feature maps of all tensors in the tensors 574. Also, the standard deviation for all tensors in the tensors 574 is the standard deviation for all elements of all feature maps of all tensors in the tensors 574. The mean and sigma of these tensors are known as “restored domain” refinement parameters 506 and are computed periodically, such as once every 32 or 64 frames, which may correspond to the intra period in a GOP structure used in the video encoder 542. The terminology “restored domain” is due to the dimensionality of the tensors 574 subject to parameter extraction matching the dimensions of the tensors 149, provided to the CNN head 150. In a case where the restored-domain mean and standard deviation are coded in the FCM PPS 10140, the restored-domain mean is coded as MU 1 1131a and the restored-domain standard deviation is coded as SIGMA1 1132a. Control in the processor 205 progresses from the step 1830 to a a perform tensor downsampling step 1840.[000121] At the step 1840, a tensor downsampler 520 (Fig. 5) performs a temporal decimation operation on the tensors 574 (effectively the tensors 117) to produced temporal downsampled tensors 524. When a downsampling ratio of two is selected, tensors of every alternate (e.g., feature frames with an odd picture order count) are dropped, resulting in a halving of the frame rate of feature frames for the tensors 524 compared to the frame rate of the frame data 115. Other downsampling ratios, such as three to one, four to one are possible with signalling to support any integer ratio. However, a maximum limit, such as an example maximum ratio of 46839667_2four, is typically needed to prevent the need for excessive tensor buffering. The downsampling ratio is signalled in the FCM PPS 10140 when an fcm_pps_temporal_upsampling_enabled_flag encoded in the FCM PPS 10140 is equal to one, allowing the ratio to altered during the course of one bitstream. The tensor downsampler 520 may be configured into an active state, where tensor downsampling is performed, or into a bypass state, where the tensors 117 are propagated to the tensors 524 with no alteration.Configuration of the tensor downsampler 520 into active or bypassed state may be predetermined, e.g., by user configuration, or may be altered during operation of the source device 110. Alteration of downsampler state during operation of the source device 110 may for example be in response to available bandwidth of the communications channel 130 or the level of detected activity such as the number of bounding boxes in the task result 151. The fcm_pps_temporal_upsampling_enabled_flag in the FCM PPS 10140 is encoded (see 18110 below) regardless of the value of the temporal upsampling enable flag in theFCM SPS 10130 to avoid a parsing dependency of the FCM PPS 10140 on the FCM SPS 10130. However, the fcm_pps_temporal_upsampling_enabled_flag is not permitted to be enabled (1) when the temporal upsampling enable flag in the FCM SPS 10130 is set to disabled (0). Control in the processor 205 progresses from the step 1840 to a perform tensor reduction step 1850.[000122] At the step 1850, the tensor compressor 530 (or ‘feature reduction module’), under execution of the processor 205, compresses the tensors 524 to produce compressed tensor 532. The compressed tensor 532 is fewer in number than the tensors 524 and reduced in dimensionality (i.e., reduced in either or both of channel count and feature map width and height). The compressed tensor 532 forms a representation of the tensors 524 that may be referred to as the ‘reduced domain’ or ‘restored domain’ or ‘feature-reduced domain’ and the operation of the tensor compressor 530 may be referred to as ‘feature reduction’. The tensor compressor 530 may implement the instantiated tensor compressor 530 in the form of precompiled ‘byte code’ or machine code or other form more amenable to direct execution by the processor 205, including by an inferencing engine as part of or associated with the processor 205, such as a graphics processing unit (GPU). The step 1850 operates to produce the tensor 532 from the tensors produced at step 1840. The tensor downsampler 520 may be configured into an ‘active’ state where the instantiated tensor compressor 512 is used to produce the tensors 532 or into a ‘bypass’ state where the tensors 524 are passed along as the tensors 532 without modification. When in the active state, the tensor 532 has at least a smaller tensor count, a smaller channel count, or a smaller spatial size compared to the tensors 524.46839667_2Control in the processor 205 progresses from the step 1850 to a derive reduced-domain refinement parameters step 1860.[000123] At the step 1860, when the reduced-domain refinement is enabled (reduced feat refine enable flag is set to 1), a refinement parameter extraction unit 562, under execution of the processor 205, produces a mean (mu) and standard deviation (sigma) value for the reduced-domain tensor, i.e., for the tensor 532. For example, an average value of all elements of all feature maps of the tensors 532 is derived as the mean for the tensor 532, and a standard deviation of all elements of all feature maps of the tensor 532 is derived as the standard deviation for the tensor 532. In a case where the reduced-domain mean and the reduced-domain standard deviation are coded in the FCM PPS 10140, the reduced-domain mean is coded as MU2 1134a and the reduced-domain standard deviation is coded as SIGMA2 1136a. The mean and standard deviation are typically 16-bit values, derived over the scope of all channels of the tensor 532, forming reduced-domain refinement parameters 564. The unit 562 operates periodically, such as every 32 or 64 frames or when an intra picture is coded by the video encoder 542. Control in the processor 205 progresses from the step 1860 to a quantise tensors step 1870.[000124] At the step 1870, a quantiser module 534, under execution of the processor 205, when configured into an ‘active’ (not ‘bypass’) state quantises floating-point values in the compressed tensor 532 to produce quantised compressed tensor 536. The quantised compressed tensor 536 has integer values and occupies a range within a sample range as defined by the operational bit depth of the video encoder 542. For example, when encoding video using 8-bit, or 10-bit samples, integer values in the interval [0, 255] or [0, 1023], respectively, are permitted. Quantisation firstly normalises a value of each element of all feature maps in the tensor 532 into a [0.0, 1.0] floating-point range, resulting in one minimum and one maximum floating-point value for the tensor 532. A tensor normalised into the [0.0, 1.0] range is then converted and rescaled into an integer sample range, such as [0, 1023] or [0, 255], The minimum and maximum floating-point values for the first normalisation form a quantisation range 526. The quantisation range 526 is signalled in FCM PPS 10140 when the reduced-domain and restored-domain refinement are bypassed (restored feat refine enable flag and reduced feat refine enable flag are both set equal to zero or each of restored feat refine flag and reduced feat refine flag are set equal to zero). The range for the second normalisation (to integer sample range) is dependent on the bit-depth of the video encoder 542. The normalisation to integer range may operate on a minimum and a maximum value that is updated from one frame to the next such that the minimum value is 46839667_2either decreased based on the current tensor 532 or retains the same value as derived for the previous tensor 532 (i.e., the tensors from the previous performance of the step 1860). The maximum value of the integer range is either increased based on the current tensor 532 or retains the same value as computed for the previous tensor 532. The quantiser module 534 can be configured into a ‘bypass’ state where the tensor 532 is passed along as the tensor 536.Configuration into the ‘bypass’ state may be applied when the tensor 532 already contains integer values or when the selected video encoder 542 is capable of encoding tensor values in floating-point format. Control in the processor 205 progresses from the step 1870 to a pack tensors step 1880.[000125] The reduced-domain and restored-domain refinement tools (504 and 562 and 1272 and 1282, to be described) act to derive the mean and standard deviation across all feature maps of tensors in the encoder 500. The restored-domain refinement parameters 506 are produced by the module 504 acting on the tensors 117 received from the CNN backbone 116. The reduced-domain refinement parameters 564 are produced by the module 562 acting on the tensors 532 that are output from the tensor compressor 530. The parameters 506 and 564 are coded by a metadata encoder 544 into the bitstream 121 as mu and sigma values, described with reference to Fig. 11. In the decoder, the mean and standard deviation are used to perform a mean shift and a multiplicative scaling of all feature maps in the reduced domain, i.e., by the module 1272 acting on a tensor 1220 to produce the tensor 1224 and in the restored domain, i.e., by the module 1282 acting on the tensors 1280 to produce the tensors 149. When the modules 1272 and 1282 are bypassed, an alternative is to perform inverse quantisation by a module 1218, whereby the tensor 1216 is scaled according to a quantisation range, decoded from the FCM PPS 10140 to produce the tensor 1220. In other words, to avoid two adjustments, either the inverse quantiser 1218 or both the reduced-domain and restored domain refinement modules 1272 and 1282 need to be bypassed on the decoder side (see Fig. 12). Hence, when either the restored feat refine enable flag or reduced feat refine enable flag are set to one (or at least one of the reduced feat refine flag and the restored feat refine flag are set to one), i.e., the two stages of the refinement can be performed, dequant bypass flag shall be set to one (inverse quantisation is bypassed). Also, when dequant bypass flag is set to zero (inverse quantisation can be performed), the at least one of the restored feat refine enable flag and the reduced feat refine enable flag shall be set to one (or both of the reduced feat refine flag and the restored feat refine flag are set to zero), i.e., the two stages of the refinement is bypassed. Both of inverse quantisation and the two stages of the refinement can be bypassed. If inverse quantisation is bypassed and the two stages of refinement are also bypassed, tensor46839667_2output from the decoder 1200 will always be within a range of [0.0, 1.0] for floating-point values, which although providing an operable system may not be a useful configuration in terms of coupling the decoder 1200 to the CNN head 150 due to the exercised magnitude of the tensors 149 being far from the value encountered during training of the CNN head 150.[000126] At the step 1880, a packer module 538, under execution of the processor 205, packs the feature maps of the tensor 536 into a frame, forming a packed feature frame 540. Operation of the packer module 538 generally results in placement of the two-dimensional feature maps into an arrangement as described with reference to Fig. 9B. When multiple tensors are present as the tensor 536, a frame 900b is of sufficient size to hold feature maps for all the tensors in the tensor 536. Control in the processor 205 progresses from the step 1880 to an encode FCM CPS step 1890.[000127] At the step 1890, a metadata encoder 544, under execution of the processor 205, encodes the platform information of the platform determined at step 1805 to FCM metadata 548, such as part of the FCM CPS 1010. The platform information may include syntax elements such as described with reference to Appendix A. Some arrangements may use a ‘dictionary’ (a collection of key:value string pairs) to provide flexibility to specify additional aspects of the platform information not available at the time of finalising the bitstream syntax of the FCM standard by way of differing ‘key’ strings. For example, detailed specifics on operational modes of tensor functions may be individually signalled, such as specific rounding modes in use. A bitstream must contain the FCM CPS 1010 prior to the FCM CVD 10200 to enable parsing of the contents of the FCM CVD 10200. Encoding the FCM CPS 1010 at step 1890 has an effect of encoding platform information to the bitstream, the platform information indicating a device used for encoding one or more tensors, such as the tensor 536. Control in the processor 205 progresses from the step 1890 to an encode FCM VMPS step 1895.[000128] At the step 1895 the metadata encoder 544, under execution of the processor 205, encodes the FCM VMPS 1020 into the FCM RSD 10100, which forms part of the bitstream 121. Included in the FCM_VMPS 1020 are parameters used by the CNN head 150 to complete performance of the machine task. Dimensions of the frame data 115 may be included, as feature map dimensions do not correspond to the original frame data size due to resizing operations, such as performed by the module 304. Control in the processor 205 progresses from the step 1895 to an encode FCM SPS step 18100.46839667_2[000129] At the step 18100, the metadata encoder 544 encodes sequence-level parameters needed for the FCM decoder into the FCM sequence parameter set 10130 as part of the FCM RSD 10100. The FCM SPS 10130 includes tensor information specifying the dimensionality of the compressed tensor 532 and the placement of feature maps as packing information for the compressed tensor 532 into the feature frame 540. The tensor information includes a maximum channel count and a used channel count. The frame area for a region must be sufficient for the tensor within the region to be packed up to the maximum channel count, i.e., the maximum number of feature maps, and feature restoration corresponding to feature compression performed at step 1850, and temporal upsampling step, corresponding to downsampling performed at step 1840, are also included in the FCMSPS 10130. The selected “inner codec” determined at the step 1820 is encoded into the FCM_SPS 10130. More specifically, if inner decoding bypass flag is set to disabled (i.e., zero, or do not bypass the inner decoding step), the FCM SPS 10130 includes feat_inner_decoder_info(). As described in Appendix A, inner codec and profile to be used is defined by syntax elements in feat_inner_decoder_info(). Control in the processor 205 progresses from the step 18100 to an encode FCM PPS step 18110.[000130] At the step 18110, the metadata encoder 544, under execution of the processor 205, encodes the quantisation range 526 for the compressed tensors 532 into an FCM PPS 10140, as additional FCM metadata 548. The quantization range 526 is only coded when the reduced-domain and restored-domain refinement operation performed by modules 504 and 562, respectively, are bypassed (both of restored feat refine enable flag andreduced feat refine enable flag are set to zero). Quantisation ranges are used in the bitstream 121 to enable inverse quantisation to the correct range by the destination device 140 when reduced-domain and / or restored-domain refinement is not performed. Control in the processor 205 progresses from the step 18110 to an encode FCM PH step 18120.[000131] At the step 18120, the metadata encoder 544, under execution of the processor 205, encodes one FCM PH, such as the FCM PH 10150, into the bitstream 121. The FCM PH is present for each picture (feature frame) present in the FCM CVD 10200 and is by POC value (such as POC 1152) with the corresponding picture (feature frame). For each picture, an FCM PPS 10140 to be used is activated based on a ph_picture_parameter_set_id(PPS ID 1150) in the FCM PH 10150. The FCM PPS may contain necessary parameters, such as quantisation range (in the case when reduced-domain refinement is disabled) for tensor decoding from the reduced domain to the restored domain. For example, in a case where the FCM PH 10150 present for a given picture has a given value of a ph_picture_parameter_set_id 46839667_2(PPS ID 1150), parameters of the FCM PPS identified by the given value of the ph_picture_parameter_set_id are used for the given picture. As such, it is required that a referenced (or ‘activated’) FCM PPS be coded prior to use by any FCM PH in the bitstream 121. Control in the processor 205 progresses from the step 18120 to an encode feature frames step 18130.[000132] At the step 18130, the video encoder 542 (selected at operation of the step 1820), under execution of the processor 205, compresses the one or more feature frames 540 to produce a compressed one or more compressed feature frames, forming video bitstream 546. The encoder 542 is selected to embody one compression approach out of multiple compression approaches in accordance with the selection of step 1820. In the case of the use of H.266 / VVC, operation of the video encoder 542 is described with reference to Fig. 8. In the case of H.265 / HEVC or H.264 / AVC, operation involves generally subsets of the functional modules as described with reference to Fig. 8. The first packed feature frame 540 to be coded results in the SPS 10230 and the PPS 10240, followed by the IRAP picture (I slice) 10260 (referred to as an ‘instantaneous decoder refresh’ picture I H.264 / AVC) as shown in Fig. 10. When using a low-delay coding configuration a subsequent picture would be coded as inter-picture 1124. In the case of a customised compression approach, a method such as directly compressing each value in the tensor 536 using an arithmetic coder such as deepCABAC or variable-length coding such as exponential Golomb coding may be applied, with the frame packing step 1880 omitted. At the step 18130, a bitstream encapsulator 550 operates to merge the video bitstream 546 and the encoded metadata 548 into format of the bitstream 121.[000133] The bitstreams 546, is formed by the entropy encoder 838 of the video encoder 542 typically as a collection of ‘parameter sets’ and ‘slices’. Parameter sets include sequence-level values applicable to the entire video, such as the resolution, the chroma format, and enablement for various coding tools provided by the compression standard. Some encoders choose to disable specific tools to reduce encoding complexity, at the expense of reduced compression performance. Parameter sets also include values applicable to one or more frames in the video, such as offsets applied to quantisation parameters, local adjustment of aspects of the bitstream structure such as maximum permitted depths of various coding tree splits, matrices for calibrating the application of a quantisation parameter to different residual coefficient(s) in a transform block. The selection of coding unit sizes (the coding tree), selection of prediction mode for each coding unit, and residual coefficients are encoded into slices, which may encode an entire frame or may be encode a portion of a frame. Other divisions are also supported, such as ‘tiles’, facilitating parallel decoding by dividing a frame into sections at least supporting 46839667_2independent entropy decoding. Parameter sets and slices are typically encoded into network abstraction layer (NAL) units, each having a prefix start code and a header, described with reference to Fig. 10. A collection of NAL units needed to decode one frame is referred to as an AU.[000134] In some instances, a tensor compressor 510 selects a set of mechanisms that may be used for compressing and decompressing tenors at 530 and outputs a selected tensor decompressor 512 and associated metadata 520 with a weight selection 516. A tensor codec repository 514 and the tensor weight repository 518 (each part of the repository 180) may be populated accordingly. A tensor structural description 522 is output from the tensor codec repository 514 to the encoder 544 based on the selected tensor decompressor 512 and a tensor structural description 524 is output from the tensor weight repository 518 to the encoder 544 based on the selected tensor decompressor 512. Control in the processor 205 progresses from the step 18130 to a determine tensor metadata step 18140.[000135] At the step 18140 a tensor decoder 590, under execution of the processor 205, decodes the bitstream to produce reconstructed tensors 592. The tensor decoder 590 operates as described with reference to Fig. 12, using the same platform as used in the source device 110 and hence the same as used by the other modules of the tensor encoder 118. As a result, the reconstructed tensors 592 are expected to contain the same data as the tensors 149 in a case where the platform of the destination device 140 matches the platform of the source device 110. In a case where the platform of the destination device 140 does not match the platform of the source device 110, the tensors 149 are expected to be substantially similar to the reconstructed tensors 592. The reconstructed tensors 592 are passed to a tensor metadata generator 594. The tensor metadata generator 594 creates one or more values (such as floating-point values or binary strings) representative of the reconstructed tensors 592, output as tensor metadata 596. Accordingly, the metadata relates to the encoded tensors 546. The tensor metadata 596 is smaller in storage requirement than the reconstructed tensors 592. When a binary detection of bit-accurate conformance (or not) of the tensors 149 is sufficient, the tensor metadata 596 may be in the form of a hash (sometimes referred to as a ‘checksum’) of the reconstructed tensors 592, such as CRC32, MD5, SHA1, SHA256, or SHA512. A hashing function produces a result of fixed-length, e.g., 256 bytes, from any length of input data, with results ideally uniformly spaced within the constraints of the fixed-length output and collisions (the same hash result for different input data) minimised. Use of a hash has the property that any difference in the input data results in quite different hash results, and so comparison of two difference hash46839667_2function output to determine the degree of difference in the corresponding input is typically not possible. So, by comparing a hash (e.g., one or more values in the form of SHA256) of the decoded tensors 149 and a check sum (e.g., one or more values in the form of SHA256) of the reconstructed tensors 592, it can be determined whether bit-accurate decoding occurred or not. To allow for detection the degree of discrepancy when differences are present, methods other than hashes may be used. One method to summarise tensor content is to take representative values, such as mean and / or variance, of all or a subset of the feature maps of the tensors. For example, every nth feature map could be used as input for a mean and variance computation. In other implementations, the metadata 596 may be at least one of a hash as described above, a mean, or a variance, of at least one feature map of at least one of the tensors 592. Control in the processor 205 progresses from the step 18140 to an encode tensor metadata step 18150.[000136] At the step 18150, the metadata encoder 544, under execution of the processor 205, encodes the tensor metadata 596 into the bitstream 121. The tensor metadata 596 may be written into an FCM SEI message 10160 (as tensor metadata 1162). The metadata 596 can be at least one of a hash, a mean, or a variance, of at least one feature map of the one or more tensors 532. The FCM SEI message 10160 is associated with the POC 1152 of an adjacent FCM PH 10150, such as the FCM PH 10150 preceding to the FCM SEI 10160 in the bitstream 121 or another FCM PH following the FCM SEI message 10160 in the bitstream 121. The method 1800 terminates and processing progresses to the next instance of the source data 115 (e.g., the next frame from the video source 112).[000137] The steps 1890 to 18150 operate to encode a structure (such as the structure 1000) to the bitstream 121. As described in relation to Figs. 10 and 11, the structure includes an order count for each of a plurality of parameter sets (1020, 10130, 10140, 10150). Each of the parameter sets in the structure encoded at step 18110 (FCM PPS 10140) corresponds to one or more feature frames containing one of feature maps of the tensor 532. The step 18130 can be considered to encode the plurality of tensors to the bitstream by encoding each feature frame to the bitstream based on the order count. The encoding of platform information at step 1890 allows operation of functions invoked in the CNN backbone 116 and the tensor compressor 530 to be specified at runtime, i.e., after finalisation of the FCM standard. In particular, function implementations are permitted to deviate from a predefined bit-accurate behaviour embodied in the standard. Function implementations that deviate from the pre-defined bit-accurate behaviour may follow an alternative behaviour that results in an alternative bit-accurate behaviour, forming a different conformance point for operation of the system 100.46839667_2[000138] Fig. 6 is a schematic block diagram 600 showing one type of multi-scale feature fusion (MSFF) module 600, which may serve as the tensor compressor 530. The MSFF module 600 takes the tensors 524 and produces a compressed tensor 532, having reduced dimensionality compared to the tensors 524 and thus resulting in a reduction in bitrate when encoded as part of a packed frame. The MSFF module 600 uses trained network layers and requires a corresponding module in the tensor decoder 146 to restore tensor dimensionality so the tensors 149 may be supplied to the CNN head 150. The MSFF module 600 takes four tensors as input and requires each one the tensors to have two-hundred and fixty-six (256) channels, so that the MSFF module 600 is compatible with the P-layers of the FasterRCNN or MaskRCNN networks. However, variants of the MSFF module 600 compatible with different numbers of layers and different channel counts are possible.[000139] The MSFF module 600 produces one tensor as output with sixty-four (64) channels and a feature map size corresponding to the P5 layer seen at the input, however variants with different channel count are also possible. Each variant of the MSFF module 600 requires different weights to be used for proper operation. Where several variants of the MSFF module 600 are able to be used in the system 100 for a given network, the packing format may be set to a worst-case feature map count of the compressed tensors of the currently used decoder network topology, and the actual used channel count may be updated at runtime as part of the tensor information.[000140] The MSFC module 600 includes an MSFF block 610 shown in Fig. 6, which produces a single tensor 629 from the plurality of tensors 524 using one or more downsampling filters. The MSFF block 610, under execution of the processor 205, combines each tensor of a first set of tensors (i.e., 602, 603, 604, 605), to produce the combined tensor 629. The combined tensor 629 forms a representation of the FPN layer tensors. Downsample modules 622a, 622b, and 622c operate on the tensors having larger spatial scale, i.e., P4604 at (2h, 2w, 256), and P3 603 at (4h, 4w, 256), and P2602 at (8h, 8w, 256), respectively. Modules 622a, 622b, and 622c perform downsampling to match the spatial scale of the smallest tensor, i.e., P5 605 at (h, w, 256), producing downscaled P5 tensors 623a, 623b, 623c, respectively. A concatenation module 624 performs a channel-wise concatenation of the tensors 605, 623a, 623b, and 623c to produce concatenated tensor 625, of dimensions (h, w, 1024). The concatenated tensor 625 is passed to a squeeze and excitation (SE) module 626 to produce a tensor 627. The SE module 626 sequentially performs a global pooling, a fully-connected layer with reduction in channel count, a rectified linear unit activation unit, a second fully-connected layer restoring the channel count, and a sigmoid activation function to produce a scaling tensor. The tensor 625 is 46839667_2scaled according to the scaling tensor to produce the output as the tensor 627. The SE block 626 is capable of being trained to adaptively alter the weighting of different channels in the tensor passed through, based on the first fully-connected layer output.[000141] The first fully-connected layer output reduces each feature map for each channel to a single value. Each single value is passed through a non-linear activation unit (ReLU) to create a conditional representation of the single value, suitable for weighting of other channels, with restoration to the full channel count performed by the second fully-connected layer. The SE block 626 is thus capable of extracting non-linear inter-channel correlation in producing the tensor 627 from the tensor 625, to a greater extent than is possible purely with convolutional (linear) layers. The tensor 627 is passed to a convolutional layer 628. The convolutional layer 628 implements one or more convolutional layers to produce the combined tensor 629, with channel count reduced to F channels, typically 256 channels (i.e., F = 256). Further reduction in the channel count is achieved by a single-scale feature compression (SSFC) module 650.[000142] The SSFC module 650 receives the tensor 629 and applies a convolution 652 to reduce the channel count from F (256) down to C’ (nominally set to 64 channels) to produce tensor 653. The tensor 653 is then passed to a batch normalisation module 654 to produce batch normalised tensor 655, which is passed to a hyperbolic tangent activation layer 656 to produce the compressed tensor 532. The output of the MSFC module 600 is a one tensor per frame with a fixed feature map size and fixed channel count.[000143] Fig. 7 shows the source device platform 700, and in particular the tensor compressor 530 operable on one of several possible encoder platforms providing low-level tensor functions. For ease of reference, only the compressor 530 of the encoder 118 is shown in terms of input tensors 117 and output bitstream 121 in Fig. 7. The tensor compressor 530 implements a selected feature reduction network, which includes a variety of low-level operations provided by the platform on which the source device 110 operates. For example, the platform includes CPU 720, FPGA 724, VPU 728, and GPU 732. When using the CPU 720 the platform is identified by parameters including vendor, model, and stepping. Furthermore, when using the CPU 720 details of applicable software library(ies) are provided, such as Numpy, DirectML, BLAS / LAPACK, Math kernel library (MKL) versions in use. In the case of using the FPGA 724, exact details of the implementation are specific to the configuration bitstream of the FPGA and cannot be unambiguously identified. Notwithstanding the vendor-specific nature of FPGA implementations, application-specific strings may be provided by the vendor and used within a deployment of source devices and destination devices to provide some form of46839667_2identification that may be meaningful within the context of a deployment from a vendor. The source device 110 uses one of the platforms 720-732 to provide functions such as convolutions, normalisations, and activation functions. The selection of one of the platforms 720-732 and details specific to the selected platform among 720-732 for use of the functions is generally a design decision when implementing the source device 110. It is possible for the source device 110 to include more than one of the platforms 720-732 and be capable of making a selection of which platform to use at runtime, for example, based on resource availability.[000144] Fig. 8 is a schematic block diagram showing functional modules of a video encoder 800 which may be implemented as the video encoder 542. The video encoder 542 may be implemented using a general -purpose computer system 200, as shown in Figs. 2A and 2B, where the various functional modules may be implemented by dedicated hardware within the computer system 200, by software executable within the computer system 200 such as one or more software code modules of the software application program 233 resident on the hard disk drive 205 and being controlled in its execution by the processor 205. Alternatively, the video encoder 542 may be implemented by a combination of dedicated hardware and software executable within the computer system 200. The video encoder 542 and the described methods may alternatively be implemented in dedicated hardware, such as one or more integrated circuits performing the functions or sub functions of the described methods. Such dedicated hardware may include graphic processing units (GPUs), digital signal processors (DSPs), application-specific standard products (ASSPs), application-specific integrated circuits (ASICs), FPGAs or one or more microprocessors and associated memories. In particular, the video encoder 542 comprises modules 810-890 which may each be implemented as one or more software code modules of the software application program 233.[000145] Although the video encoder 542 of Fig. 8 is an example of a versatile video coding (WC) video encoder, other video codecs may also be used to perform the processing stages described herein. For example, HEVC or AVC or other types of encoders may be used. The examples described generate a bitstream of encoded data. If other codecs were used, some implementations may pack data into a different format such as a frame format or the like. The video encoder 800 receives frame data 712, each frame including one or more colour channels. The frame data 712 corresponds to the feature frame 540 in packed form of feature maps of the tensor, as implemented at the step 1880. The frame data 712 may be in 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, at eight (8) to ten (10) bits in sample precision.46839667_2[000146] As seen in Fig. 8, a block partitioner 810 firstly divides the frame data 712 into CTUs, generally square in shape and configured such that a particular size for the CTUs is used. The maximum enabled size of the CTUs may be 32x32, 64x64, or 128×128 luma samples for example, configured by a ‘sps_log2_ctu_size_minus5’ syntax element present in the ‘sequence parameter set’ (i.e., the SPS 10230). The ‘sps_log2_ctu_size_minus5’ syntax element uses values 0, 1, and 2 to correspond to CTU sizes of 32x32, 64x64, and 128×128, respectively The CTU size also provides a maximum CU size, as a CTU with no further splitting will contain one CU. Ternary splitting is prohibited when a CU has one or more dimensions of length 128 luma samples. As a consequence, processing may fully handle each 64x64 quadrant of the 128×128 before progressing from one quadrant to the next quadrant. Large CUs such as 64×128 are processed as a pair of 64×64 regions. As a result of quadrant-based processing (sometimes referred to as “virtual pipeline data units” or “VPDUs”), internal storage in the video encoder 800, and a corresponding video decoder 1204 (also referred to as a picture decoder), is only needed for 64x64 samples even when the CTU size is configured as 128×128. Feature maps are typically smaller than video frame size, due to use of intervening pooling operations or convolution operations with stride parameter greater than one. Feature maps do not require the large CU sizes provided by VVC. Use of a 32×32 CTU size provides sufficient flexibility in block structure to efficiently encode structural detail found in feature maps with a smaller amount of memory required for intermediate storage in the memory 206, i.e., storage for partially decoded data from a bitstream 1206 (Fig. 12) but prior to a frame buffer 1396 (Fig.13), to be described. The bitstream 1206 corresponds to the bitstream 143. Use of a smaller CTU size reduces the variety of CU sizes that are able to be tested in the block partitioner 810, reducing runtime. Constraining the CTU size to 32×32 indicates a reduced memory consumption in the video decoder 1204 required for decoding the bitstream 1206 (143) however the worst-case of 128×128 would need to be supported should such a bitstream be encountered. One instance of the FCM SPS 10130 is needed prior to the first picture in the bitstream 121 and also at any subsequent entry points (or ‘random access points’) into the bitstream 121 from which decoding can commence. The block partitioner 810 further divides each CTU into one or more CBs according to a luma coding tree and a chroma coding tree. The luma channel may also be referred to as a primary colour channel. Each chroma channel may also be referred to as a secondary colour channel. The CBs have a variety of sizes, and may 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 two. Thus, a current CB, represented as 812, is output from the block partitioner 810, progressing in accordance with an iteration46839667_2over the one or more blocks of the CTU, in accordance with the luma coding tree and the chroma coding tree of the CTU.[000147] The CTUs resulting from the first division of the frame data 712 may be scanned in raster scan order and may be grouped into one or more ‘slices’. A slice may be an ‘intra’ (or ‘I’) slice. An intra slice (I slice) indicates that every CU in the slice is intra predicted.Generally, the first picture in a coded layer video sequence (CLVS) contains only I slices, and is referred to as an ‘intra picture’. The CLVS may contain periodic intra pictures, forming ‘random access points’ (i.e., intermediate frames in a video sequence upon which decoding can commence). Alternatively, a slice may be uni- or bi-predicted (‘P’ or ‘B’ slice, respectively), indicating additional availability of uni- and bi-prediction in the slice, respectively.[000148] The video encoder 542 encodes sequences of pictures (feature frames) according to a picture structure. One picture structure is Tow delay’, in which case pictures using interprediction may only reference pictures occurring previously in the sequence. Low delay enables each picture to be output as soon as the picture is decoded, in addition to being stored for possible reference by a subsequent picture. Another picture structure is ‘random access’, whereby the coding order of pictures differs from the display order. Random access allows inter-predicted pictures to reference other pictures that, although decoded, have not yet been output. A degree of picture buffering is needed so the reference pictures in the future in terms of display order are present in the decoded picture buffer, resulting in a latency of multiple frames.[000149] When a chroma format other than 4:0:0 is in use, in an I slice, the coding tree of each CTU may diverge below the 64×64 level into two separate coding trees, one for luma and another for chroma. Use of separate trees allows different block structure to exist between luma and chroma within a luma 64×64 area of a CTU. For example, a large chroma CB may be collocated with numerous 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 resulting blocks of the single tree may be intra predicted or inter predicted.[000150] In addition to a division of pictures into slices, pictures may also be divided into ‘tiles’. A tile is a sequence of CTUs covering a rectangular region of a picture. CTU scanning occurs in a raster-scan manner within each tile and progresses from one tile to the next. A slice46839667_2can be either an integer number of tiles, or an integer number of consecutive rows of CTUs within a given tile.[000151] For each CTU, the video encoder 542 as shown in Fig. 8 operates in two stages. In the first stage (referred to as a ‘search’ stage), the block partitioner 810 tests various potential configurations of a coding tree. Each potential configuration of a coding tree has associated ‘candidate’ CBs. The first stage involves testing various candidate CBs to select CBs providing relatively high compression efficiency with relatively low distortion. The testing generally involves a Lagrangian optimisation whereby a candidate CB is evaluated based on a weighted combination of rate (i.e., coding cost) and distortion (i.e., error with respect to the input frame data 712). ‘Best’ candidate CBs (i.e., the CBs with the lowest evaluated rate / distortion) are selected for subsequent encoding into the bitstream portion 121. Included in evaluation of candidate CBs is an option to use a CB for a given area or to further split the area according to various splitting options and code each of the smaller resulting areas with further CBs, or split the areas even further. As a consequence, both the coding tree and the CBs themselves are selected in the search stage.[000152] The video encoder 542 produces a prediction block (PB), indicated by an arrow 820, for each CB, for example, CB 812. The PB 820 is a prediction of the contents of the associated CB 812. A subtracter module 822 produces a difference, indicated as 824 (or ‘residual’, referring to the difference being in the spatial domain), between the PB 820 and the CB 812. The difference 824 is a block-size difference between corresponding samples in the PB 820 and the CB 812. The difference 824 is transformed, quantised and represented as a transform block (TB), indicated by an arrow 836. The PB 820 and associated TB 836 are typically chosen from one of many possible candidate CBs, for example, based on evaluated cost or distortion.[000153] A candidate coding block (CB) is a CB resulting from one of the prediction modes available to the video encoder 542 for the associated PB and the resulting residual. When combined with the predicted PB in the video encoder 542, the TB 836 reduces the difference between a decoded CB and the original CB 812 at the expense of additional signalling in a bitstream.[000154] Each candidate coding block (CB) (i.e., prediction block (PB) in combination with a transform block (TB)), has an associated coding cost (or ‘rate’) and an associated difference (or ‘distortion’). The distortion of the CB is typically estimated as a difference in sample values,46839667_2such as a sum of absolute differences (SAD), a sum of squared differences (SSD) or a Hadamard transform applied to the differences. The estimate resulting from each candidate PB may be determined by a mode selector 886 using the difference 824 to determine a prediction mode 887. The prediction mode 887 indicates the decision to use a particular prediction mode for the current CB, for example, intra-frame prediction or inter-frame prediction. Estimation of the coding costs associated with each candidate prediction mode and corresponding residual coding may be performed at significantly lower cost than entropy coding of the residual.Accordingly, a number of candidate modes may be evaluated to determine an optimum mode in a rate-distortion sense even in a real-time video encoder.[000155] Determining a preferred mode in terms of rate-distortion is typically achieved using a variation of Lagrangian optimisation. Lagrangian or similar optimisation processing can be employed to both select a preferred partitioning of a CTU into CBs (by the block partitioner 810) as well as the selection of a prediction mode from a plurality of possibilities. Through application of a Lagrangian optimisation process of the candidate modes in the mode selector module 886, the intra prediction mode with the lowest cost measurement is selected as a ‘best’ mode. The lowest cost mode includes a selected secondary transform index 888, which is encoded in the bitstream 546 (corresponding to 121) by the entropy encoder 838.[000156] In the second stage of operation of the video encoder 542 (referred to as a ‘coding’ stage), an iteration over the determined coding tree(s) of each CTU is performed in the video encoder 542. For a CTU using separate trees, for each 64×64 luma region of the CTU, a luma coding tree is firstly encoded followed by a 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 a CTU using a shared tree, a single tree describes the CUs (i.e., the luma CBs and the chroma CBs) according to the common block structure of the shared tree.[000157] The entropy encoder 838 supports bitwise coding of syntax elements using variablelength and fixed-length codewords, and an arithmetic coding mode for syntax elements.Portions of the bitstream such as ‘parameter sets’, for example, the SPS, the picture parameter set (PPS), and the picture header (PH) use a combination of fixed-length codewords and variable-length codewords. Slices, also referred to as contiguous portions, have a slice header that uses variable length coding followed by slice data, which uses arithmetic coding. The slice header defines parameters specific to the current slice, such as slice-level quantisation parameter offsets, and may include an instance of the PH. The slice data includes the syntax46839667_2elements of each CTU in the slice. Use of variable length coding and arithmetic coding requires sequential parsing within each portion of the bitstream. The portions may be delineated with a start code to form ‘network abstraction layer units’ or ‘NAL units’.Arithmetic coding is supported using a context-adaptive binary arithmetic coding process.[000158] Arithmetically coded syntax elements consist of sequences of one or more ‘bins’. Bins, like bits, have a value of ‘0’ or ‘ 1’. However, bins are not encoded in a bitstream portion 716 (corresponding to the bitstream 546) as discrete bits. Bins have an associated predicted (or ‘likely’ or ‘most probable’) value and an associated probability, known as a ‘context’. When the actual bin to be coded matches the predicted value, a ‘most probable symbol’ (MPS) is coded. Coding a most probable symbol is relatively inexpensive in terms of consumed bits in the bitstream portion 121, including costs that amount to less than one discrete bit. When the actual bin to be coded mismatches the likely value, a ‘least probable symbol’ (LPS) is coded. Coding a least probable symbol has a relatively high cost in terms of consumed bits. The bin coding techniques enable efficient coding of bins where the probability of a ‘0’ versus a ‘ 1’ is skewed. For a syntax element with two possible values (i.e., a ‘flag’), a single bin is adequate. For syntax elements with many possible values, a sequence of bins is needed. The convention for converting values of a syntax element into a sequence of bins is termed ‘binarisation’. Where the values ‘0’ and ‘1’ for a bin are equally (or near equally) likely, it is possible to omit use of a context and assume an equiprobable distribution. Bins with a context are termed ‘context-coded bins’ and bins omitting a context are termed ‘bypass-coded bins’. The binarization of a syntax element into one or more bins may result in a combination of context-coded and bypass-coded bins. Unlike directly coding one bit into the bitstream, a bypass-coded bin uses the arithmetic coding engine, which facilitates mixing context-coded and bypass-coded bins into syntax element binarisations.[000159] For a given binarization, the presence of later bins in the sequence may be determined based on the value of earlier bins in the sequence, resulting in variable-length binarisations. Additionally, each bin may be associated with more than one context, with one context selected for use in coding a specific instances of the bin. The selection of a particular context may be dependent on earlier bins in the syntax element, the decoded values of neighbouring syntax elements (i.e., those from neighbouring blocks) and the like. Each time a context-coded bin is encoded, the context that was selected for that bin (if any) is updated in a manner reflective of the new bin value. As such, the binary arithmetic coding scheme is said to be adaptive.46839667_2[000160] The absence of a context for bypass-coded bins saves memory and reduces complexity, and thus bypass bins are used where the distribution of values for the particular bin is not skewed. One example of an entropy coder employing context and adaption is known in the art as CABAC (context adaptive binary arithmetic coder) and many variants of this coder have been employed in video coding.[000161] A QP controller 890 determines a quantisation parameter 892, used to establish a quantisation step size for use by a quantiser 834 and a dequantiser 840. A larger quantisation step size results in primary transform coefficients 828 being quantised into smaller values, reducing bitrate of the bitstream portion 716 at the expense of a reduction in the fidelity of inverse transform coefficients 846.[000162] The entropy encoder 838 encodes the quantisation parameter 892 and, if in use for the current CB, the LFNST index 888, using a combination of context-coded and bypass-coded bins. The quantisation parameter 892 is encoded at the beginning of each slice and changes in the quantisation parameter 892 within a slice are coded using a ‘delta QP’ syntax element. The delta QP syntax element is signalled at most once in each area known as a ‘quantisation group’. The quantisation parameter 892 is applied to residual coefficients of the luma CB. An adjusted quantisation parameter is applied to the residual coefficients of collocated chroma CBs. The adjusted quantisation parameter may include mapping from the luma quantisation parameter 892 according to a mapping table and a CU-level offset, selected from a list of offsets. The secondary transform index 888 is signalled when the residual associated with the transform block includes significant residual coefficients only in those coefficient positions subject to transforming into primary coefficients by application of a secondary transform.[000163] Residual coefficients of each TB associated with a CB are coded using a residual syntax. The residual syntax is designed to efficiently encode coefficients with low magnitudes, using mainly arithmetically coded bins to indicate significance of coefficients, along with lower-valued magnitudes and reserving bypass bins for higher magnitude residual coefficients. Accordingly, residual blocks comprising very low magnitude values and sparse placement of significant coefficients are efficiently compressed. Moreover, two residual coding schemes are present. A regular residual coding scheme is optimised for TBs with significant coefficients predominantly located in the upper-left corner of the TB, as is seen when a transform is applied. A transform-skip residual coding scheme is available for TBs where a transform is not46839667_2performed and is able to efficiently encode residual coefficients regardless of their distribution throughout the TB.[000164] A multiplexer module 884 outputs the PB 820 from an intra-frame prediction module 864 according to the determined best intra prediction mode, selected from the tested prediction mode of each candidate CB. The candidate prediction modes need not include every conceivable prediction mode supported by the video encoder 542. Intra prediction falls into three types, first, “DC intra prediction”, which involves populating a PB with a single value representing the average of nearby reconstructed samples; second, “planar intra prediction”, which involves populating a PB with samples according to a plane, with a DC offset and a vertical and horizontal gradient being derived from nearby reconstructed neighbouring samples. The nearby reconstructed samples typically include a row of reconstructed samples above the current PB, extending to the right of the PB to an extent and a column of reconstructed samples to the left of the current PB, extending downwards beyond the PB to an extent; and, third, “angular intra prediction”, which involves populating a PB with reconstructed neighbouring samples filtered and propagated across the PB in a particular direction (or ‘angle’). In VVC, sixty-five (65) angles are supported, with rectangular blocks able to utilise additional angles, not available to square blocks, to produce a total of eighty-seven (87) angles.[000165] A fourth type of intra prediction is available to chroma PBs, whereby the PB is generated from collocated luma reconstructed samples according to a ‘cross-component linear model’ (CCLM) mode. Three different CCLM modes are available, each mode using a different model derived from the neighbouring luma and chroma samples. The derived model is used to generate a block of samples for the chroma PB from the collocated luma samples. Luma blocks may be intra predicted using a matrix multiplication of the reference samples using one matrix selected from a predefined set of matrices. This matrix intra prediction (MIP) achieves gain by using matrices trained on a large set of video data, with the matrices representing relationships between reference samples and a predicted block that are not easily captured in angular, planar, or DC intra prediction modes.[000166] The module 864 may also produce a prediction unit by copying a block from nearby the current frame using an ‘intra block copy’ (IBC) method. The location of the reference block is constrained to an area equivalent to one CTU, divided into 64x64 regions known as VPDUs, with the area covering the processed VPDUs of the current CTU and VPDUs of the previous CTU(s) within each row or CTUs and within each slice or tile up to the area limit46839667_2corresponding to one 128×128 luma samples, regardless of the configured CTU size for the bitstream. This area is known as an ‘IBC virtual buffer’ and limits the IBC reference area, thus limiting the required storage. The IBC buffer is populated with reconstructed samples 854 (i.e., prior to loop filtering), and so a separate buffer to a frame buffer 872 is needed. When the CTU size is 128×128 the virtual buffer includes samples only from the CTU adjacent and to the left of the current CTU. When the CTU size is 32x32 or 64x64 the virtual buffer includes CTUs from up to the four or sixteen CTUs to the left of the current CTU. Regardless of the CTU size, access to neighbouring CTUs for obtaining samples for IBC reference blocks is constrained by boundaries such as edges of pictures, slices, or tiles. Particularly for feature maps of FPN layers having smaller dimensions, use of a CTU size such as 32x32 or 64x64 results in a reference area more aligned to cover a set of previous feature maps. Where feature map placement is ordered based on SAD, SSE or other difference metric, access to similar feature maps for IBC prediction offers coding efficient advantage.[000167] The residual for a predicted block when encoding feature map data is different to the residual seen for natural video. Natural video is typically captured by an image sensor, or screen content, as generally seen in operating system user interfaces and the like. Feature map residuals tend to contain much detail. The level of detail in feature map residuals is amenable to transform skip coding more than predominantly low-frequency coefficients of various transforms. An intra-predicted luma coding block may be partitioned into a set of equal-sized prediction blocks, either vertically or horizontally, which each block having a minimum area of sixteen (16) luma samples.[000168] Where previously reconstructed neighbouring samples are unavailable, for example at the edge of the frame, a default half-tone value of one half the range of the samples is used. For example, for 10-bit video a value of five-hundred and twelve (512) is used. As no previous samples are available for a CB located at the top-left position of a frame, angular and planar intra-prediction modes produce the same output as the DC prediction mode (i.e. a flat plane of samples having the half-tone value as magnitude).[000169] For inter-frame prediction a prediction block 882 is produced using samples from one or two frames preceding the current frame in the coding order frames in the bitstream by a motion compensation module 880 and output as the PB 820 by the multiplexer module 884. Moreover, for inter-frame prediction, a single coding tree is typically used for both the luma channel and the chroma channels. The order of coding frames in the bitstream may differ from46839667_2the order of the frames when captured or displayed. When one frame is used for prediction, the block is said to be ‘uni-predicted’ and has one associated motion vector. When two frames are used for prediction, the block is said to be ‘bi-predicted’ and has two associated motion vectors. For a P slice, each CU may be intra predicted or uni -predicted. For a B slice, each CU may be intra predicted, uni -predicted, or bi-predicted.[000170] Frames are typically coded using a ‘group of pictures’ structure, enabling a temporal hierarchy of frames. Frames may be divided into multiple slices, each of which encodes a portion of the frame. A temporal hierarchy of frames allows a frame to reference a preceding and a subsequent picture in the order of displaying the frames. The images are coded in the order necessary to ensure the dependencies for decoding each frame are met. An affine inter prediction mode is available where instead of using one or two motion vectors to select and filter reference sample blocks for a prediction unit, the prediction unit is divided into multiple smaller blocks and a motion field is produced so each smaller block has a distinct motion vector. The motion field uses the motion vectors of nearby points to the prediction unit as ‘control points’. Affine prediction allows coding of motion different to translation with less need to use deeply split coding trees. A bi-prediction mode available to VVC performs a geometric blend of the two reference blocks along a selected axis, with angle and offset from the centre of the block signalled. This geometric partitioning mode (“GPM”) allows larger coding units to be used along the boundary between two objects, with the geometry of the boundary coded for the coding unit as an angle and centre offset. Motion vector differences, instead of using cartesian (x, y) offset, may be coded as a direction (up / down / left / right) and a distance, with a set of power-of-two distances supported. The motion vector predictor is obtained from a neighbouring block (‘merge mode’) as if no offset is applied. The current block will share the same motion vector as the selected neighbouring block.[000171] The samples are selected according to a motion vector 878 and reference picture index. The motion vector 878 and reference picture index applies to all colour channels and thus inter prediction is described primarily in terms of operation upon Pus rather than PBs. The decomposition of each CTU into one or more inter-predicted blocks is described with a single coding tree. Inter prediction methods may vary in the number of motion parameters and their precision. Motion parameters typically comprise a reference frame index, indicating which reference frame(s) from lists of reference frames are to be used plus a spatial translation for each of the reference frames, but may include more frames, special frames, or complex affine46839667_2parameters such as scaling and rotation. In addition, a pre-determined motion refinement process may be applied to generate dense motion estimates based on referenced sample blocks.[000172] Having determined and selected the PB 820 and subtracted the PB 820 from the original sample block at the subtractor 822, a residual with lowest coding cost, represented as 824, is obtained and subjected to lossy compression. The lossy compression process comprises the steps of transformation, quantisation and entropy coding. A forward primary transform module 826 applies a forward transform to the difference 824, converting the difference 824 from the spatial domain to the frequency domain, and producing primary transform coefficients represented by an arrow 828. The largest primary transform size in one dimension is either a 32-point DCT-2 or a 64-point DCT-2 transform, configured by a ‘sps_max_luma_transform_size_64 flag’ in the sequence parameter set. If the CB being encoded is larger than the largest supported primary transform size expressed as a block size (e.g., 64x64 or 32x32), the primary transform 826 is applied in a tiled manner to transform all samples of the difference 824. Where a non-square CB is used, tiling is also performed using the largest available transform size in each dimension of the CB. For example, when a maximum transform size of thirty -two (32) is used, a 64 x 16 CB uses two 32x16 primary transforms arranged in a tiled manner. When a CB is larger in size than the maximum supported transform size, the CB is filled with TBs in a tiled manner. For example, a 128×128 CB with 64-pt transform maximum size is filled with four 64x64 TBs in a 2x2 arrangement. A 64x 128 CB with a 32-pt transform maximum size is filled with eight 32x32 TBs in a 2x4 arrangement.[000173] Application of the transform 826 results in multiple TBs for the CB. Where each application of the transform operates on a TB of the difference 824 larger than 32x32, e.g., 64x64, all resulting primary transform coefficients 828 outside of the upper-left 32x32 area of the TB are set to zero (i.e., discarded). The remaining primary transform coefficients 828 are passed to the quantiser module 834. The primary transform coefficients 828 are quantised according to the quantisation parameter 892 associated with the CB to produce primary transform coefficients 832. In addition to the quantisation parameter 892, the quantiser module 834 may also apply a ‘scaling list’ to allow non-uniform quantisation within the TB by further scaling residual coefficients according to their spatial position within the TB. The quantisation parameter 892 may differ for a luma CB versus each chroma CB. The primary transform coefficients 832 are passed to a forward secondary transform module 830 to produce transform coefficients represented by the arrow 836 by performing either a non-separable secondary46839667_2transform (NSST) operation or bypassing the secondary transform. The forward primary transform 826 is typically separable, transforming a set of rows and then a set of columns of each TB. The forward primary transform module 826 uses either a type-II discrete cosine transform (DCT-2) in the horizontal and vertical directions, or bypass of the transform horizontally and vertically, or combinations of a type- VII discrete sine transform (DST-7) and a type- VIII discrete cosine transform (DCT-8) in either horizontal or vertical directions for luma TBs not exceeding 16 samples in width and height. Use of combinations of a DST-7 and DCT-8 is referred to as ‘multi transform selection set’ (MTS) in the VVC standard.[000174] The forward secondary transform of the module 830 is generally a non-separable transform, which is only applied for the residual of intra-predicted CUs and may nonetheless also be bypassed. The forward secondary transform operates either on sixteen (16) samples (arranged as the upper-left 4x4 sub-block of the primary transform coefficients 828) or fortyeight (48) samples (arranged as three 4x4 sub-blocks in the upper-left 8x8 coefficients of the primary transform coefficients 828) to produce a set of secondary transform coefficients. The set of secondary transform coefficients may be fewer in number than the set of primary transform coefficients from which they are derived. Due to application of the secondary transform to only a set of coefficients adjacent to each other and including the DC coefficient, the secondary transform is referred to as a Tow frequency non-separable secondary transform’ (LFNST). Such secondary transforms may be obtained through a training process and due to their non-separable nature and trained origin, exploit additional redundancy in the residual signal not able to be captured by separable transforms such as variants of DCT and DST.Moreover, when the LFNST is applied, all remaining coefficients in the TB are zero, both in the primary transform domain and the secondary transform domain.[000175] The quantisation parameter 892 is constant for a given TB and thus results in a uniform scaling for producing residual coefficients in the primary transform domain for a TB. The quantisation parameter 892 may vary periodically with a signalled ‘delta quantisation parameter’. The delta quantisation parameter (delta QP) is signalled once for CUs contained within a given area, referred to as a ‘quantisation group’. If a CU is larger than the quantisation group size, delta QP is signalled once with one of the TBs of the CU. That is, the delta QP is signalled by the entropy encoder 838 once for the first quantisation group of the CU and not signalled for any subsequent quantisation groups of the CU. A non-uniform scaling is also possible by application of a ‘quantisation matrix’, whereby the scaling factor applied for each residual coefficient is derived from a combination of the quantisation parameter 892 and the46839667_2corresponding entry in a scaling matrix. The scaling matrix may have a size that is smaller than the size of the TB, and when applied to the TB a nearest neighbour approach is used to provide scaling values for each residual coefficient from a scaling matrix smaller in size than the TB size. The residual coefficients 836 are supplied to the entropy encoder 838 for encoding in the bitstream portion 716. Typically, the residual coefficients of each TB with at least one significant residual coefficient of the TU are scanned to produce an ordered list of values, according to a scan pattern. The scan pattern generally scans the TB as a sequence of 4^4 ‘subblocks’, providing a regular scanning operation at the granularity of 4x4 sets of residual coefficients, with the arrangement of sub-blocks dependent on the size of the TB. The scan within each sub-block and the progression from one sub-block to the next typically follow a backward diagonal scan pattern. Additionally, the quantisation parameter 892 is encoded into the bitstream portion 716 using a delta QP syntax element, and a slice QP for the initial value in a given slice or subpicture and the secondary transform index 888 is encoded in the bitstream portion 716.[000176] As described above, the video encoder 542 needs access to a frame representation corresponding to the decoded frame representation seen in the video decoder. Thus, the residual coefficients 836 are passed through an inverse secondary transform module 844, operating in accordance with the secondary transform index 888 to produce intermediate inverse transform coefficients, represented by an arrow 842. The intermediate inverse transform coefficients 842 are inverse quantised by the dequantiser module 840 according to the quantisation parameter 892 to produce the inverse transform coefficients, represented by an arrow 846. The dequantiser module 840 may also perform an inverse non-uniform scaling of residual coefficients using a scaling list, corresponding to the forward scaling performed in the quantiser module 834. The inverse transform coefficients 846 are passed to an inverse primary transform module 848 to produce residual samples, represented by an arrow 850, of the TU. The inverse primary transform module 848 applies DCT-2 transforms horizontally and vertically, constrained by the maximum available transform size as described with reference to the forward primary transform module 826. The types of inverse transform performed by the inverse secondary transform module 844 correspond with the types of forward transform performed by the forward secondary transform module 830. The types of inverse transform performed by the inverse primary transform module 848 correspond with the types of primary transform performed by the primary transform module 826. A summation module 852 adds the residual samples 850 and the PB 820 to produce reconstructed samples (indicated by an arrow 854) of the CU.46839667_2[000177] The reconstructed samples 854 are passed to a reference sample cache 856 and an inloop filters module 868. The reference sample cache 856, typically implemented using static RAM on an ASIC to avoid costly off-chip memory access, provides minimal sample storage needed to satisfy the dependencies for generating intra-frame PBs for subsequent CUs in the frame. The minimal dependencies typically include a Tine buffer’ of samples along the bottom of a row of CTUs, for use by the next row of CTUs and column buffering the extent of which is set by the height of the CTU. The reference sample cache 856 supplies reference samples (represented by an arrow 858) to a reference sample filter 860. The sample filter 860 applies a smoothing operation to produce filtered reference samples (indicated by an arrow 862). The filtered reference samples 862 are used by the intra-frame prediction module 864 to produce an intra-predicted block of samples, represented by an arrow 866. For each candidate intra prediction mode the intra-frame prediction module 864 produces a block of samples, that is 866. The block of samples 866 is generated by the module 864 using techniques such as DC, planar or angular intra prediction. The block of samples 866 may also be produced using a matrix-multiplication approach with neighbouring reference sample as input and a matrix selected from a set of matrices by the video encoder 800, with the selected matrix signalled in the bitstream 121 using an index to identify which matrix of the set of matrices is to be used by the video decoder.[000178] The in-loop filters module 868 applies several filtering stages to the reconstructed samples 854. The filtering stages include a ‘deblocking filter’ (DBF) which applies smoothing aligned to the CU boundaries to reduce artefacts resulting from discontinuities. Another filtering stage present in the in-loop filters module 868 is an ‘adaptive loop filter’ (ALF), which applies a Wiener-based adaptive filter to further reduce distortion. A further available filtering stage in the in-loop filters module 868 is a ‘sample adaptive offset’ (SAO) filter. The SAO filter operates by firstly classifying reconstructed samples into one or multiple categories and, according to the allocated category, applying an offset at the sample level.[000179] Filtered samples, represented by an arrow 870, are output from the in-loop filters module 868. The filtered samples 870 are stored in the frame buffer 872. The frame buffer 872 typically has the capacity to store several (e.g., up to sixteen (16)) pictures and thus is stored in the memory 206. The frame buffer 872 is not typically stored using on-chip memory due to the large memory consumption required. As such, access to the frame buffer 872 is costly in terms of memory bandwidth. The frame buffer 872 provides reference frames (represented by an arrow 874) to a motion estimation module 876 and the motion compensation module 880. The46839667_2reference frames 874 are output as a reconstructed frame 718 of the encoder module 542. In the example of Fig. 8, the reconstructed frame 718 is a result of operation of lossy VVC encoding, that is due to operation of the modules 810 to 890.[000180] The motion estimation module 876 estimates a number of ‘motion vectors’ (indicated as 878), each being a Cartesian spatial offset from the location of the present CB, referencing a block in one of the reference frames in the frame buffer 872. A filtered block of reference samples (represented as 882) is produced for each motion vector. The filtered reference samples 882 form further candidate modes available for potential selection by the mode selector 886. Moreover, for a given CU, the PU 820 may be formed using one reference block (‘uni -predicted’) or may be formed using two reference blocks (‘bi-predicted’). For the selected motion vector, the motion compensation module 880 produces the PB 820 in accordance with a filtering process supportive of sub-pixel accuracy in the motion vectors. As such, the motion estimation module 876 (which operates on many candidate motion vectors) may perform a simplified filtering process compared to that of the motion compensation module 880 (which operates on the selected candidate only) to achieve reduced computational complexity. When the video encoder 542 selects inter prediction for a CU the motion vector 878 is encoded into the bitstream portion 121.[000181] Although the video encoder 542 of Fig. 8 is described with reference to versatile video coding (VVC), other video coding standards or implementations may also employ the processing stages of modules 810-890. The frame data 712 (and bitstream 716) may also be read from (or written to) memory 206, the hard disk drive 210, a CD-ROM, a Blu-ray disk™ or other computer readable storage medium. Additionally, the frame data 712 (and bitstream 716) may be received from (or transmitted to) an external source, such as a server connected to the communications network 220 or a radio-frequency receiver. The communications network 220 may provide limited bandwidth, necessitating the use of rate control in the video encoder 120 to avoid saturating the network at times when the frame data 712 is difficult to compress.[000182] The bitstream 716 may be constructed from one or more slices, representing spatial sections (collections of CTUs) of the frame data 712, produced by one or more instances of the video encoder 542, each producing the bitstream portion 716 and operating in a co-ordinated manner under control of the processor 205. The bitstream portion 716 may also contain one slice that corresponds to one region to be output as a collection of subpictures forming one46839667_2picture, each being independently encodable and independently decodable with respect to any of the other slices or subpictures in the picture.[000183] Figs. 9A & 9B are schematic block diagrams showing an arrangement for holding or packing compressed feature map data from compressed tensor data 536. A feature map, corresponding to one channel of a tensor, is packed or stored in rectangular area of the frame. The feature maps of each channel are packed typically in a left-to-right manner firstly and top-to-bottom manner secondly filling the frame width in the order of incrementing channel count. Fig. 9A shows a frame 900 that contains a region 910 in which feature maps of a tensor are to be packed. For example, each of the feature maps are packed into the frame 900 so that each feature map is sequentially placed from the left edge to the right edge of the top row of the frame 900, and then sequentially placed from the left edge to the right edge of the next row of the frame 900. Frames containing feature maps packed onto the area of the frame may be referred to as “feature frames”. The size of the frame 900 may be specified in terms of width and height in units of samples, smallest CU width / height, or CTU width / height. Fig. 9B shows the feature frame 900b which corresponds to the frame 900 once feature maps, i.e., feature maps obtained from the tensor 536, are packed. Where the tensor compressor 530 was configured to perform the feature reduction network topology described with reference to Fig. 6, the tensor 536 contains feature maps of the tensor corresponding to the P5 layer, such as a feature map 930.[000184] Fig. 12 is a schematic block diagram 1200 showing an example implementation of the tensor decoder 146. In the example of Fig. 12, the tensor decoder 146 includes a configurable tensor decompressor 1250 and a selectable picture decoder 1204. Fig. 19 shows a method 1900 for decoding a bitstream, including decoding tensors and determining the conformance (accuracy) of the decoded tensors based on at least platform information and / or, in some implementations, based on additional tensor metadata obtained from the bitstream 121, and performing a second portion of the CNN. The method 1900 is performed at the destination device 140.[000185] The tensor decoder 1200 (146) and the method 1900 may be implemented as one or more software application programs 233 executable within the computer system 200 on the destination device 140. The tensor decoder 146 and the method 1900 may be affected by instructions 231 (see Fig. 2B) in the software 233 that are carried out within the computer system 200. The software instructions 231 may be formed as one or more code modules, each46839667_2for performing one or more particular tasks. The method 1900 begins at a decode FCM CPS step 1910.[000186] At the step 1910, aFCM metadata demultiplexer 1202 receives a bitstream 1206 (corresponding to 143). The demultiplexer 1202 passes the FCM CPS 1010 received in the bitstream 143 as 1207 to a metadata parser 1208, under execution of the processor 205, to decode the FCM CPS 1010. The FCM CPS 1010, as described with reference to Appendix A, is decoded at step 1910 to determine a set of low-level operations to be used for implementing stages of tensor decompression including the feature restoration of module 1250. In one arrangement, decoding the FCM CPS 1010 at the step 1910 includes decoding (a) a syntax element (platform_indication_vendor) indicating the vendor (e.g. CPU vendor, GPU vendor, and so on) for the device (e.g. CPU, GPU, and so on) used in CNN backbone116 and / or Tensor encoder 118, (b) a syntax element (platform_indication_model) indicating device model number of the device used in CNN backbone116 and / or Tensor encoder 118, (c) a syntax element (platform_indication_sw_library_name) indicating the software library used to provide the set of low-level functions used in conjunction with the decoder network topology for tensor decompression, and (d) a syntax element (platform_indication_sw_library_version) indicating versions of the software library. In another arrangement, information of low-level operations, such as rounding modes, are explicitly decoded from the bitstream 143. Decoded information from the FCM CPS 1010 forms platform information 1294. In decoding the FCM CPS 1010, the step 1910 operates to decode platform information from the bitstream, the platform information indicating a device used for encoding the one or more tensors. Control in the processor 205 progresses from the step 1910 to a decode FCM_VMPS step 1920.[000187] At the step 1920 the demultiplexer 1202 passes the FCM_VMPS 1020 received from the bitstream 143 and contained in the FCM RSD 10100 to the metadata parser 1208. The FCM_VMPS 1020 is decoded to obtain vision model parameters needed by the CNN head 150 to performance the machine task and produce the task result 151. The metadata parser 1208 decodes the FCM VMPS 1020 in accordance with the syntax structure shown in Appendix A to produce vision model parameters (e.g., output_picture_width and output_picture_height in the example of Appendix A), which are passed to the CNN head 150. The output_picture_width specifies the width of the frame data 115, and the output_picture_height specifies the height of the frame data 115. The vision model parameters produced at step 1920 correspond to the parameters 113 of Fig. 1. Vision model parameters may include items such as the dimensions of46839667_2the frame data 115, needed for bounding boxes to be scaled correctly. Control in the processor 205 progresses from the step 1920 to a decode FCM SPS step 1930.[000188] At the step 1930, the metadata parser 1208 parses the FCM SPS 10130 received from the bitstream 143 via the demultiplexor 1202 to obtain tensor information relating to dimensionality of compressed tensors and placement of feature maps as packing information for each tensor in the bitstream 143. The FCM SPS 10130 is parsed to obtain the information encoded at step 18100 relating to sequence-level parameters to configure the tensor decoder 146 in accordance with the configuration used by the tensor encoderl 18. Examples of sequence-level parameters include reduced-domain frame size (i.e., dimensions of the feature frame 900), dimensionality of the tensors 149, enablement or bypass flags for various stages of the tensor decoder 146. The temporal upsampling (i.e., 1260) is enabled with atemporal upsampling enable flag, the inverse quantisation (i.e., 1218) is bypassed with a dequant_bypass_flag, feature restoration (i.e., 1250) is bypassed with a feat_restoration_bypass_flag, unpacking (i.e., 1214) is bypassed with a unpacking_bypass_flag and “inner codec” (i.e., 1204) is bypassed with a inner decoding bypass flag. The selected “inner codec” and associated profile, as determined in the source device 110 at the step 1820, is decoded from the FCM SPS 10130. More specifically, if inner decoding bypass flag is set to disabled (i.e., zero, or do not bypass the inner decoding step), syntax elements in feat_inner_decoder_info() are decoded from the FCM SPS 10130. As described in Appendix A, inner codec and the associated profile to be used is determined by using the syntax elements in feat_inner_decoder_info(). Control in the processor 205 progresses from the step 1930 to a decode FCM PPS step 1940.[000189] At the step 1940, the metadata parser 1208 parses the FCM PPS 10140, if received from the bitstream 143 via the demultiplexer 1202. The FCM PPS 10140 is parsed to obtain information encoded at step 18110. For example, if restored-domain and reduced-domain refinement operations are bypassed (fcm sps refinement bypass flag is set to one), the FCM PPS 10140 may include information relating to quantisation ranges coded as 32-bit values in IEEE-754 binary32 format. The information relating to quantisation ranges can be coded in floating-point format, if reduced-domain and restored-domain refinement tools are not bypassed (fcm sps refinement bypass flag is set to zero), mean and sigma values are decoded for the reduced-domain and restored-domain refinement operation when the corresponding update flags are active. Each FCM PPS includes a ph_picture_parameter_set_id value,46839667_2providing for multiple sets of picture parameters to be available for use. Control in the processor 205 progresses from the step 1940 to a decode feature picture header (PH) step 1950.[000190] At the step 1950, the metadata parser 1208 parses the FCM PH 10150 if received from the bitstream 143 via the demultiplexor 1202. The FCM PH 10150 is parsed to obtain information encoded at step 18120. The FCM PH 10150 includes a ph_picture_parameter_set_id, which must reference a previously signalled FCM PPS. The referenced FCM PPS is said to be activated when referenced by an FCM PH, such as the FCM PH 10150. The parameters in the referenced FCM PPS are effective for the picture having the POC 1152 associated with the FCM PH, e.g., FCM PH 10150. Control in the processor progresses from the step 1950 to a decode tensor metadata step 1955.[000191] At the step 1955, the metadata parser 1208 parses the FCM SEI 10160 if received from the bitstream 143 via the demultiplexer 1202. The FCM SEI 10160 includes a supplementary enhancement message that contains tensor metadata 1295 (1162), which corresponds to the tensor metadata 596. The tensor metadata 1295 (1162) is in some implementations a hash of the reconstructed tensors 592 or a form of summarisation of the tensors 592 such as mean and variance of a subset of the feature maps of the tensors 592.Control in the processor 205 progresses from the step 1955 to a decode one or more feature frames step 1960.[000192] At the step 1960, the picture decoder 1204, under execution of the processor 205, receives bitstream data 1203 from the demultiplexer 1202. The bitstream data 1203 corresponds to the bitstream data 546 representing the frame data 115. That is, the bitstream data 1203 relates to the bitstream 121 before the metadata 548 was encapsulated. The picture decoder operates to decode one or more coded feature frames from the FCM CVD 10200 in the bitstream 1203 (143) to produce one or more decoded feature frames 1210, provided inner decoding bypass flag was set to disabled (i.e., zero, or do not bypass the inner decoding step). Operation of the picture decoder 1204 is described with reference to Fig. 13. Iterations of the step 1960 operate to decode a plurality of feature frames from the bitstream, each feature frame containing a feature map to be provided to the CNN head 150. Additionally, the picture decoder 1204 can operate to identify a POC for each feature frame by decoding information of POC from a corresponding header for the feature frame. For example, the picture decoder 1204 decodes a feature frame from I slice 10230 and identifies the POC for the feature frame by decoding the POC 1152 from the AU header 10210 for the I slice 10230. Each feature frame is46839667_2identified by the POC. Control in the processor 205 progresses from the step 1960 to an unpack tensors step 1970.[000193] At the step 1970, an unpacker 1214, under execution of the processor 205, reads feature maps from the decoded feature frame 1210 in accordance with the packing format as determined at the step 1940 in decoding the FCM VMPS 1112 and described with reference to Figs. 9A & 9B. For each tensor in the reduced domain, a number of feature maps are decoded, the number corresponding to the number of used channels in the tensor as signalled in the reduced-domain tensor information of the FCM SPS 10130. Aspects of the tensor information used for packing and unpacking are reduced-domain tensor dimensionality and placement of each reduced-domain tensor in the decoded feature frame 1210. Feature maps of the feature frame are unpacked to produce the tensor. The number of feature maps (the number of channels) to decode the tensor is decoded from the bitstream 143 as a ‘channel count’. The unpacker 1214 outputs a tensor 1216 by unpacking the feature maps in the decoded feature frame 1210 (e.g. 900B in Fig 9B) The tensor 1216 corresponds to the tensor 536. In some implementations, inverse quantiser 1218 inverse quantises the tensor 1216 using a quantisation range 1270 decoded by the metadata parser 1208 at step 18110. In the example embodiment described hereafter, when the refinement is enabled (fcm sps refinement bypass flag is set to 0), the tensor 1216 is passed along as a tensor 1220 without the process of inverse quantiser 1218. Due to use of the video decoder 1204, the tensors 1216 contain integer elements in the range afforded by the bit depth in use in the video decoder 1204. Control in the processor 205 progresses from the step 1970 to an apply reduced-domain refinement step 1980.[000194] At the step 1980, when the reduced-domain refinement is enabled(fcm sps refinement bypass flag is set to zero or reduced feat refine flag is equal to one), a reduced-domain refinement module 1272, under execution of the processor 205, applies the reduced-domain refinement for a tensor 1220 based on the decoded reduced-domain mu (mean) and sigma (standard deviation) values. In one arrangement, the reduced-domain refinement module 1272 performs the reduced-domain refinement for the tensor 1220 by the following equation (1), to produce a tensor 1224.Xf I ~ ) * °Xf T P-Xf (1)\ °Xrf / In above equation, xrydenotes elements of all feature maps in the tensor 1220.axrf^ represents the decoded reduced-domain mu (mean) and the reduced-domain sigma (standard46839667_2deviation), respectively, x denotes elements of all feature maps in the refined tensor 1224. The value of ig and the value of are obtained by decoding the value 1131a and the value1132a at step 1940. Control in the processor 205 progresses from the step 1980 to a perform tensor restoration step 1990.[000195] At the step 1980 the decoded reduced-domain mu (mean) and the decoded reduced-domain sigma (standard deviation) values are used for the refinement for the tensor 1220 which is derived from one or more feature frames.[000196] At the step 1990 the tensor decompressor 1250 executes a predetermined network topology (for example predetermined by the user) that converts a tensor in the reduced domain into one or more tensors 1254 in a restored domain, corresponding to the dimensionality of the tensors 117 and 149. At step 1990, a tensor compressor repository 1232 receives decompressor information 1230 from the metadata parser 1208 and generates decompressor network topology information 1238. Further, a tensor compressor weight repository 1236 receives weight information 1234 from the metadata parser 1208 and generates the tensor weight information 1240. The tensor decompressor 1250 uses the information 1238 and 1240 to generate the tensors 1254 at step 1990. Use of the information 1238 and 1240 by the decompressor 1250 is described in relation to Fig. 14. Control in the processor 205 progresses from the step 1990 to a perform tensor upsampling step 19100.[000197] At the step 19100, a temporal upsampler 1260, under execution of the processor 205, performs a temporal upsampling (interpolation) for the tensor 1254 to produce tensors 1280. The temporal upsampler is active when fcm_pps_temporal_upsampling_enabled_flag is set to indicate application of temporal upsampling, in accordance with the ratio indicated by temporal_upsampling_ratio_minus2. Each temporal upsampling operation takes two temporally consecutive sets of tensors from the tensors 1254, and produces one or more intermediate tensors which are interleaved with the tensors 1254 forming the tensors 1280. Due to use of the tensors from 1254 from two consecutive frames to produce an to produce intermediate (i.e., temporally interpolated) tensors, structural delay is introduced when temporal upsampling is enabled, hence temporal upsampling is suited to applications that can tolerate a degree of latency. Control in the processor 205 progresses from the step 19100 to a apply restored-domain refinement step 19110.46839667_2[000198] At the step 19110 the restored-domain refinement module 1282 performs the refinement for all tensors of the tensors 1280 to output tensors 1286 in accordance with the decoded restored-domain mu (mean) (e.g., the value 1134a) and the restored-domain sigma (standard deviation) (e.g., the value 1136a). In one arrangement, the restored-domain refinement module 1282 performs the restored-domain refinement for the tensors 1280 by the following equation (2), to produce the tensors 1286.-n (xFr ~ Zn=l KXrr)\ ~ ~X = I -. I X + Uy (2)\V V^=1a2(x” ) / / In above equation, ^denotes elements of all feature maps in a n-th tensor of the tensors 1280 (e.g. n is in the range of 1 to the number of tensors 1280). ( rr) denotes the mean for the n-th tensor of the tensors 1280, and this value is calculated by the restored-domain refinement module 1282. <j2(x”r) denotes the square of the standard deviation of the n-th tensor of the tensors 1280, and this value is calculated by the restored-domain refinement module 1282. ( / zx, < JX) represents the decoded restored-domain mu (mean) and the restored-domain sigma (standard deviation), respectively. xndenotes elements of all feature maps in the refined n-th tensor of the tensors 149. For example, the value of p.xand the value of &xareobtained by decoding the value 1134a and the value 1136a at step 1940.[000199] The decoded restored-domain mu (mean) and the decoded restored-domain sigma (standard deviation) values are used for the refinement for the tensors 1280 which is based on one or more feature frames to be input to the unpacker 1214.[000200] The reduced-domain and restored-domain refinement tools (1272 and 1282) act to adjust magnitude of values of samples in the encoder 500, affecting tensors 506 and 564, as does the inverse quantiser 1218 which affects the tensor 1220. To avoid two adjustments, either the inverse quantiser 1218 or both the reduced-domain and restored domain refinement modules 1272 and 1282 need to be bypassed. Setting at least one of the two SPS flags fcm sps refinement bypass flag and fcm sps inverse quantisation bypass flag to one ensures that either inverse quantisation or the two stages of refinement are performed and not both. If inverse quantisation is bypassed and the two stages of refinement are also bypassed, tensor output from the decoder 1200 will always be within a range of [0.0, 1.0] for floatingpoint values, which although providing an operable system may not be a useful configuration in terms of coupling the decoder 1200 to the CNN head 150 due to the exercised magnitude of the tensors 149 being far from the value encountered during training of the CNN head 150. In46839667_2some implementations, the tensors 1286 are passed to a data type converter 1290 and converted to a data type corresponding to the tensors 117. The data type converter 1290 outputs the tensors 149. In some implementations, no data conversion is required and the tensors 1286 are passed through as the tensors 149 without any change in type. Control in the processor 205 progresses from the step 19110 to a determine destination device platform step 19120.[000201] The steps 1960 to 19110 operate to producing the tensor(s) 149 from the bitstream 143, using the predetermined (decoded) platform (in some implementations, device) for tensor compressor 1250. The steps 1960 to 19110 can also be considered to use a manner decoded at step 1990 to producing the tensor(s) 149.[000202] At the step 19120, the processor 205 on the destination device 140 determines the platform used in the destination device 140 for performance of feature restoration by the tensor decompressor 1250. The processor 205 determines information such as the platform vendor, the device model number, device stepping value, software libraries in use, software library version. Platforms available for providing low-level functions used by the tensor decompressor 1250 are described with reference to Fig. 14. Control in the processor 205 progresses from the step 19120 to a conformance mode determination step 19130.[000203] At the step 19130, the processor 205 on the destination device 140 compares the platform determined at the step 19120 with the decoded platform information 1294 obtained from the step 1910. In this case, the processor 205 compares the determined platform at the step 19120 with the decoded platform information 1294 with regard to at least one of the vendor of the device, the device model number, the stepping number of the device, the software library, and the software library version, to determine whether the determined platform and the platform information are matched. For example, the processor 205 compares the vendor of the determined platform at the step 19120 with the vendor indicated by the decoded platform information (specifically platform_indication_vendor). If the vendor of the determined platform at the step 19120 and the vendor indicated by the decoded platform information are matched, the processor 205 determines that the determined platform and the platform information are matched. If not, the processor 205 determines that the determined platform and the platform information are not matched. In other example, the processor 205 compares the device model number of the determined platform with the device model number indicated by the decoded platform information (specifically platform_indication_model). If the device model number of the determined platform and the device model number indicated by the46839667_2decoded platform information are matched, the processor 205 determines that the determined platform and the platform information are matched. If not, the processor 205 determines that the determined platform and the platform information are not matched. If the determined platform and the platform information 1294 are found to match (“Y” at step 1930), control in the processor 205 progresses from the step 19130 to a set conformance information step 19180. If the platform information 1194 is found not match (“N” at step 19130) control in the processor 205 progresses from the step 19130 to a determine derived tensor metadata step 19140. In some arrangements, all syntax elements relating to platform information forming the decoded platform information 1294 need to match the corresponding information determined at the step 19120 in order for a “Y” result to be found and for control in the processor to progress to the step 19180, otherwise (not all syntax elements of the platform information are matched) then control in the processor 205 progresses to the step 19140 (step 19130 returns a “N”).[000204] In other words, at the step 19130, the conformance determiner 1296 operates to determine accuracy of the produced one or more tensors 149 with respect to the reconstructed tensors 592, based on the platform information platform information decoded at step 1910 and the predetermined device (determined at step 19120) of the decompressor 1250. If the conformance determiner 1296 determines a match (returns “Y”), a high level of accuracy (typically bit-level accuracy) is expected. If not, a lesser level of accuracy is expected.[000205] At the step 19140 the metadata parser 1208, under execution of the processor 205, decodes the FCM SEI 10160 to obtain the tensor metadata 1295 (1162), which corresponds to the metadata 596 encoded at the step 18150. Control in the processor 205 progresses from the step 19140 to a determine tensor metadata step 19150.[000206] At the step 19150 a conformance determiner 1296 produces metadata for the tensors 149, e.g., a hash of the tensors 149 or a mean and variance of a subset of feature maps of the tensors 149. In some implementations, the conformance determiner 1296 may also execute the comparison of step 19130. Control in the processor 205 progresses from the step 19150 to a check tensor metadata discrepancy step 19160.[000207] At the step 19160, the processor 205 compares the tensor metadata produced at step 19150 with the tensor metadata 1295 (1162). For example, the processor 205 compares a hash (e.g., one or more values in the form of SHA256) of the decoded tensors 149 and a hash (e.g.,46839667_2one or more values in the form of SHA256) of the reconstructed tensors 592 or compares mean and variance values produced for the decoded tensors 149 at the step 19150 with the tensor metadata 1295 (1162) obtained from the step 19140. The hash of the decoded tensors 149 are obtained at the step 19150, and the hash of the reconstructed tensors 592 is obtained from the tensor metadata 1295 (1162). If the differences between all means and variances of the decoded tensors 149 (i.e., resulting from the step 19150) decoded means and variances obtained from the step 19140 are within a predetermined threshold, an acceptably high level of accuracy is expected, and then the step 19160 returns “Y” and control in the processor 205 progresses from the step 19160 to the step 19180. The predetermined threshold can vary based on factors such as acceptable accuracy, end application, destination device parameters and the like and is typically determined via experimentation. If the difference between the means and variances obtained from the decoded tensors 149 and the hash of the reconstructed tensors 592 is not within the predetermined threshold, a lesser and potentially low of accuracy is expected, and the step 19160 returns “N” and control progresses from the step 19160 to a set conformance flag to FALSE step 19170. When hashes are compared at the step 19160, the threshold used for discrepancies is zero as the result from a hash function is typically uncorrelated with the degree of difference seen in the input data. In other words, when comparing hash function results, control in the processor 205 proceeds to step 19180 (returns “Y”) only when the hashed produced at the steps 19140 and 19150 are equal, otherwise control in the processor proceeds to step 19170 (returns “N”). Also, when the step 19160 returns “N”, the processor 205 may place less weight upon the task result 151. Placing less weight on the task result 151 may be achieved by requiring a higher threshold for comparison of the mAP or MOTA before taking some action such as informing the user that some event has occurred.[000208] At the step 19170, a conformance information 159 (conformance flag) output by the conformance determiner 1296 is set to FALSE, indicating that the decoded tensors 149 are not conforming / accurate. In other words, the conformance information 159 set to FALSE indicates that the decoded tensors 149 do not correspond to the reconstructed tensors 529 with sufficient precision for the task result 151 to be deemed an acceptably reliable result. When the task result 151 is not deemed a highly reliable result, the destination device 140 may alter later processing using the task result 151, for example by raising thresholds of object detection to compensate for the higher risk of false detections. Control in the processor 205 progresses from the step 19170 to the step 19190.46839667_2[000209] At the step 19180, the conformance information 159 (conformance flag) is set to TRUE, indicating that the decoded tensors 149 are conforming / accurate. In other words, the conformance information 159 set to TRUE indicates indicating that the decoded tensors 149 correspond sufficiently to the reconstructed tensors 592. In this case the destination device 140 may produce the task result 151 more accurately but changes in performance in later stages are not required. Control in the processor 205 progresses from the step 19180 to a perform neural network second portion step 19190.[000210] In setting the conformance information 159, the steps 19170 and 19180 output information of the result of the determination made at either of the steps 19130 or 19160. In some implementations, the conformance information 159 is output as a flag. In other implementations, other ways of outputting conformance information may be used, for example entering a message in a run-time log or the like.[000211] When the reduced-domain and restored-domain refinement tools are disabled or bypassed, the following inverse quantisation may be performed by the inverse quantiser 1218 at step 1970. Then inverse quantiser 1218, under execution of the processor 205, performs inverse quantisation on the integer tensor 1216 to produce inverse quantised tensor 1220, provided fcm sps inverse quantisation bypass flag is set to zero (i.e., do not bypass inverse quantisation). The inverse quantiser 1218 converts the integer tensor 1216 into the tensor 1220 using a quantisation range so that a value of feature maps of integer tensor 1216 is converted into a floating-point value. To perform inverse quantisation, the quantisation range is decoded from the FCM PPS or FCM PH in the bitstream. The quantisation ranges indicate a maximum and minimum value (or lower and upper bound) used in the floating-point domain at the output tensor 1220. The inverse quantiser 1218 operates to decode the quantisation range and produce one or more floating-point tensor (1220) from the integer tensor produced at the unpacker 1214. The quantisation range indicates a range of values, and the tensor 1220 are produced so that a value of each element of each feature map of the tensor 1220 has a value within the quantisation range. The quantisation range derived from a given FCM PPS is used for the inverse-quantisation for the integer tensor 1216 which is derived from the one or more feature frames with corresponding FCM PHs (i.e., with corresponding POCs) referencing the FCM PPS in which the quantisation range was signalled.[000212] At the step 19190, the CNN head 150, under execution of the processor 205, performs the remaining layers of the neural network implemented by the system 100, using the46839667_2tensors 149 as input and decoded from the FCM VMPS 1020. The step 19190 processes the tensors 149 using neural network layers of the CNN head 150 to output the task result 151. The method 1900 terminates on execution of the step 19190 and the processor 205 may reinvoke the method 1900 upon receiving the next packed frame in the bitstream 143.[000213] In some implementations the task result 151 can be used in conjunction with the result of the determination at step 19130 or 19160. For example, an indicator or alert may be issued to identify if the task result is considered accurate or not.[000214] Fig. 13 is a schematic block diagram 1300 showing functional modules of an example implementation of the video decoder 1204. The video decoder 1204 may be implemented as one or more software application programs 233 executable within the computer system 200. The video decoder 1204 may be effected by instructions 231 (see Fig. 2B) in the software 233 that are carried out within the computer system 200. The software instructions 231 may be formed as one or more code modules, each for performing one or more particular tasks.[000215] The bitstream 1203 (corresponding to 1206, 143) is input to an entropy decoder module 1320. The entropy decoder module 1320 extracts syntax elements from the bitstream 143 by decoding sequences of ‘bins’ and passes the values of the syntax elements to other modules in the video decoder 1204. The entropy decoder module 1320 uses variablelength and fixed length decoding to decode SPS, PPS or slice header using an arithmetic decoding engine to decode syntax elements of the slice data as a sequence of one or more bins. Each bin may use one or more ‘contexts’, with a context describing probability levels to be used for coding a ‘one’ and a ‘zero’ value for the bin. Where multiple contexts are available for a given bin, a ‘context modelling’ or ‘context selection’ step is performed to choose one of the available contexts for decoding the bin. The process of decoding bins forms a sequential feedback loop, where each slice may be decoded in entirety by a given entropy decoder 1320 instance.[000216] The entropy decoder module 1320 applies an arithmetic coding algorithm, for example ‘context adaptive binary arithmetic coding’ (CAB AC), to decode syntax elements from the bitstream 143. The decoded syntax elements are used to reconstruct parameters within the video decoder 1204. Parameters include residual coefficients (represented by an arrow 1324), a quantisation parameter 1374, a secondary transform index 1370, and mode selection information such as an intra prediction mode (represented by an arrow 1358). The mode46839667_2selection information also includes information such as motion vectors, and the partitioning of each CTU into one or more CBs. Parameters are used to generate PBs, typically in combination with sample data from previously decoded CBs.[000217] The residual coefficients 1324 are passed to an inverse secondary transform module 1336 where either a secondary transform is applied or no operation is performed (bypass) according to a secondary transform index. The inverse secondary transform module 1336 produces reconstructed transform coefficients 1332. That is, the module 1336 produces primary transform domain coefficients from secondary transform domain coefficients. The reconstructed transform coefficients 1332 are input to a dequantiser module 1328. The dequantiser module 1328 performs inverse quantisation (or ‘scaling’) on the residual coefficients 1332, that is, in the primary transform coefficient domain, to create reconstructed intermediate transform coefficients, represented by an arrow 1340, according to the quantisation parameter 1374. The dequantiser module 1328 may also apply a scaling matrix to provide non-uniform dequantization within the TB, corresponding to operation of the dequantiser module 840. Should use of a non-uniform inverse quantisation matrix be indicated in the bitstream 1203, the video decoder 1204 reads a quantisation matrix from the bitstream 143 as a sequence of scaling factors and arranges the scaling factors into a matrix. The inverse scaling uses the quantisation matrix in combination with the quantisation parameter to create the reconstructed intermediate transform coefficients 1340.[000218] The reconstructed transform coefficients 1340 are passed to an inverse primary transform module 1344. The module 1344 transforms the coefficients 1340 from the frequency domain back to the spatial domain. The inverse primary transform module 1344 applies inverse DCT-2 transforms horizontally and vertically, constrained by the maximum available transform size as described with reference to the forward primary transform module 826. The result of operation of the module 1344 is a block of residual samples, represented by an arrow 1348. The block of residual samples 1348 is equal in size to the corresponding CB. The residual samples 1348 are supplied to a summation module 1350.[000219] At the summation module 1350, the residual samples 1348 are added to a decoded PB (represented as 1352) to produce a block of reconstructed samples, represented by an arrow 1356. The reconstructed samples 1356 are supplied to a reconstructed samplecache 1360 and an in-loop filtering module 1388. The in-loop filtering module 1388 produces46839667_2reconstructed blocks of frame samples, represented as 1392. The frame samples 1392 are written to the frame buffer 1396. The frame buffer 1396 outputs the feature frames 1210.[000220] The reconstructed sample cache 1360 operates similarly to the reference sample cache 856 of the video encoder 542. The reconstructed sample cache 1360 provides storage for reconstructed samples needed to intra predict subsequent CBs without the memory 206 (e.g., by using the data 232 instead, which is typically on-chip memory). Reference samples, represented by an arrow 1364, are obtained from the reconstructed sample cache 1360 and supplied to a reference sample filter 1368 to produce filtered reference samples indicated by arrow 1372. The filtered reference samples 1372 are supplied to an intra-frame prediction module 1376. The module 1376 produces a block of intra-predicted samples, represented by an arrow 1380, in accordance with the intra prediction mode parameter 1358 signalled in the bitstream 1203 and decoded by the entropy decoder 1320. The intra prediction module 1376 supports the modes of the encoder-side module 864, including IBC and MIP. The block of samples 1380 is generated using modes such as DC, planar or angular intra prediction.[000221] When the prediction mode of a CB is indicated to use intra prediction in the bitstream 143, the intra-predicted samples 1380 form the decoded PB 1352 via a multiplexer module 1384. Intra prediction produces a prediction block (PB) of samples, which is a block in one colour component, derived using ‘neighbouring samples’ in the same colour component. The neighbouring samples are samples adjacent to the current block and by virtue of being preceding in the block decoding order have already been reconstructed. Where luma and chroma blocks are collocated, the luma and chroma blocks may use different intra prediction modes. However, the two chroma CBs share the same intra prediction mode.[000222] When the prediction mode of the CB is indicated to be inter prediction in the bitstream 1206, a motion compensation module 1334 produces a block of inter-predicted samples, represented as 1338. The block of inter-predicted samples 1338 are produced using a motion vector, decoded from the bitstream 143 by the entropy decoder 1320, and reference frame index to select and filter a block of samples 1398 from the frame buffer 1396. The block of samples 1398 is obtained from a previously decoded frame stored in the frame buffer 1396. For bi-prediction, two blocks of samples are produced and blended together to produce samples for the decoded PB 1352. The frame buffer 1396 is populated with filtered block data 1392 from the in-loop filtering module 1388. As with the in-loop filtering module 868 of the video encoder 542, the in-loop filtering module 1388 applies any of the DBF, the ALF and SAO46839667_2filtering operations. Generally, the motion vector is applied to both the luma and chroma channels, although the filtering processes for sub-sample interpolation in the luma and chroma channel are different.[000223] Fig. 14 is a schematic block diagram showing an implementation 1400 using a platform amongst various platforms for the destination device 140, which may serve as the platform for the tensor decompressor 1250. For ease of reference, only the decompressor 1250 of the decoder 146 is shown in terms of input bitstream 143 and output tensors 149 in Fig. 14. As indicated in Fig. 14, resources required to perform feature restoration may be allocated from one or more resources (or platforms), such as one or more of a CPU 1420, an FPGA 1424, a vector processing unit (VPU) 1428, and a GPU 1432. Each of the resources 1420, 1424, 1428, and 1432 can be implemented on the module 201 or can be executed across one or more similar devices. Details of 1420-1432 corresponds with to those described for 720-1732 respectively with reference to Fig. 7.[000224] Fig. 15 is a schematic block diagram showing a tensor decompressor 1500 using a multi-scale feature reconstruction stage, which may used in implementing the tensor decompressor 1250. The tensor decompressor 1500 includes a single-scale feature compression (SSFC) decompressor 1510. The SSFC decompressor 1510 receives the tensor 1224 having a reduced channel count, such as 64 channels, and passes the tensor 1224 to a convolution layer 1512, which outputs a tensor 1513 having a restored channel count, such as 256 channels. The tensor 1513 is passed to a batch normalisation module 1514 to produce a tensor 1515. The tensor 1515 is passed to a PreLU module 1516 to produce a tensor 1520. The tensor decompressor 1500 includes a MSFR module 1530. The MSFR module 1530 operates to produce a plurality of tensors from the tensor 1520 produced by execution of step 1990, described with reference to Fig. 19, using one or more trained convolutional layers. Upsample modules 1532, 1534, and 1536 upsample the tensor 1520 horizontally and vertically by factors of two, four, and eight, respectively, to produce tensors 1533, 1535, and 1537. The tensor 1537 forms one (P’2, 1557) output from the MSFR module 1530 and is passed to a downsample module 1542.[000225] The downsample module 1542 downsamples the tensor 1537 by a factor of two horizontally and vertically to produce a tensor 1543 having the same dimensionality as the tensor 1535. The tensor 1543 is provided to a convolution layer 1548 which outputs a tensor 1549. A summation module 1554 adds the tensors 1535 and 1549 to produce a tensor 1555 as an output (P’3) of the MSFR module 1530.46839667_2[000226] A downsample module 1540 downsamples the tensor 1535 by a factor of two horizontally and vertically to produce a tensor 1541 having the same dimensionality as the tensor 1533. The tensor 1541 is provided to a convolution layer 1546 which outputs a tensor 1547. A summation module 1552 adds the tensors 1533 and 1547 to produce a tensor 1553 as an output (P’4) of the MSFR module 1530.[000227] A downsample module 1538 downsamples the tensor 1533 by a factor of two horizontally and vertically to produce a tensor 1539 having the same dimensionality as the tensor 1520. The tensor 1539 is provided to a convolution layer 1544 which outputs a tensor 1545. A summation module 1550 adds the tensors 1520 and 1545 to produce a tensor 1551 as an output (P’5) of the MSFR module 1530. The tenors P’2 1557, P’3 1555, P’4 1553 and P’5 1551 form the tensors 1254 of Fig. 12.[000228] Fig. 16A is a schematic block diagram showing an example implementation 1600 of the head portion 150 of a CNN for object detection, corresponding to a portion of a “YOLOv3” network excluding the “DarkNet-53” backbone portion. The CNN head portion 150 of Fig. 16A can be used when the CNN backbone is implemented as in Fig. 3 A for example.Depending on the task to be performed in the destination device 140, different networks may be substituted for the CNN head portion 150. Incoming tensors 149 are separated into the tensor of each layer (i.e., tensors 1610, 1620, and 1634). The tensor 1610 is passed to a CBL module 1612 to produce tensor 1614. The tensor 1614 is passed to a detection module 1616 and an upscaler module 1622. The detection module outputs bounding boxes 1618, in the form of a detection tensor. The bounding boxes 1618 are passed to a non-maximum suppression (NMS) module 1648.[000229] To produce bounding boxes addressing co-ordinates in the original video data 115, prior to resizing for the backbone portion of the network 116, scaling by the original video width and height is performed at the upscaler module 1622. The upscaler module 1622 receives the tensor 1614 and the tensor 1620 and produces an upscaled tensor 1624, which is passed to a CBL module 1626. The CBL module 1626 produces a tensor 1628 as output. The tensor 1628 is passed to a detection module 1630 and an upscaler module 1636. The detection module 1630 produces a detection tensor 1632, which is supplied to the NMS module 1648.[000230] The upscaler module 1636 is another instance of the module 1622. The upscaler module 1636 receives the tensor 1628 and the tensor 1634 and outputs an upscaled tensor 1638. The upscaled tensor 1638 is passed to a CBL module 1640, which outputs a tensor 1642 to a 46839667_2detection module 1644. The detection module 1644 produces a detection tensor 1646, which is supplied to the NMS module 1648.[000231] The CBL modules 1612, 1626, and 1640 each contain a concatenation of five CBL modules (e.g., CBL model 360 shown in Fig. 3D). The upscaler modules 1622 and 1636 are each instances of an upscaler module 1660 as shown in Fig. 16B. The module 1648 receives the tensors 1618, 1632 and 1646 and outputs the task result 151.[000232] As shown in Fig. 16B, the upscaler module 1660 accepts a tensor 1662 (for example the tensor 1614 of Fig. 16A) as an input. The tensor 1662 is passed to a CBL module 1666 (having structure of the module 360) to produce a tensor 1668. The tensor 1668 is passed to an upsampler 1670 to produce an upsampled tensor 1672. A concatenation module 1674 produces a tensor 1676 by concatenating the upsampled tensor 1672 with a second input tensor 1664 (for example the tensor 1620 input to the upscaler 1622 in Fig. 16A).[000233] The detection modules 1616, 1630, and 1644 are instances of a detection module 1680 as shown in Fig. 16C. The detection module 1680 receives a tensor 1682. The tensor 1682 is input to a CBL module 1684 having structure of the module 360. The CBL module 1684 generates a tensor 1686. The tensor 1686 is passed to a convolution module 1688, which implements a detection kernel to output a tensor 1690. In some arrangements, the detection kernel applies a 1 × 1 kernel to produce the output on feature maps at each of the three layers of the tensor. The detection kernel is 1 × 1 × (B × (5 + C) ), where B is the number of bounding boxes a particular cell can predict, typically three (3), and C is the number of classes, which may be eighty (80), resulting in a kernel size of two-hundred and fifty five (255) detection attributes (i.e. tensor 1290). The constant “5” represents four boundary box attributes (box centre x, y and size scale x, y) and one object confidence level (“objectness”). The result of a 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 at each layer, typically three layers, resulting in a large number of candidate bounding boxes. A process of non-maximum suppression is applied by the NMS module 1648 to the resulting bounding boxes to discard redundant boxes, such as overlapping predictions at similar scale, resulting in a final set of bounding boxes as output for object detection.[000234] Fig. 17 is a schematic block diagram showing a head portion 1700 of a CNN. The head portion 1700 can be implemented as the CNN head portion 150 where the CNN backbone 116 is implemented as the backbone 400 for example. The head portion 1700 forms part of an46839667_2overall network known as ‘Faster RCNN’ and includes a feature network (i.e., backbone portion 400), a region proposal network, and a detection network. Input to the head portion 1700 are the tensors 149, which include P2-P6 layer tensors 1710, 1712, 1714, 1716, and 1718. The P2-P5 layer tensors 1710, 1712, 1714, and 1716, correspond to the P2 to P 5 outputs 477, 475, 473, and 471 of Fig. 4. The P2-P6 tensors 1710, 1712, 1714, 1716, and 1718 are input to a region proposal network (RPN) head module 1720. The P6 tensor 1718 is produced by a max pool module 1742, operating on P5 tensor 1716 to perform a 2×2 max pooling operation. The RPN head module 1720 performs a convolution on the input tensors, generating an intermediate tensor. The intermediate tensor is fed into two subsequent sibling layers, (i) one for classifications and (ii) one for bounding box, or ‘region of interest’ (RO I), regression. A resultant output is classification and bounding boxes 1722. The classification and bounding boxes 1722 are passed to an NMS module 1724. The NMS module 1724 prunes out redundant bounding boxes by removing overlapping boxes with a lower score to produce pruned bounding boxes 1726. The bounding boxes 1726 are input to a region of interest (RO I) pooler 1728. The ROI pooler 1728 uses some of the layer tensors of the tensor 149 (described further hereafter) and the bounding boxes 1726 to produce fixed-size feature maps from various input size maps using max pooling operations. In the max pooling operation a subsampling takes the maximum value in each group of input values to produce one output value in the output tensor.[000235] Input to the ROI pooler 1728 arethe P2-P5 feature maps 1710, 1712, 1714, and 1716, and region of interest proposals 1726. Each proposal (ROI) from 1726 is associated with a portion of the feature maps (1710-1716) to produce a fixed-size map. The fixed-size map is of a size independent of the underlying portion of the feature map 1710-1716. One of the feature maps 1710-1716 is selected such that the resulting cropped map has sufficient detail, for example, according to the following rule: floor(4 + log2(sqrt(box_area) / 224)), where 224 is the canonical box size. The ROI pooler 1728 operates to crop incoming feature maps according to the proposals 1726 producing a tensor 1730.[000236] The tensor 1730 is fed into a fully connected (FC) neural network head 1732. The FC head 1732 performs two fully connected layers to produce class score and bounding box predictor delta tensor 1734. The class score is generally an 80-element tensor, each element corresponding to a prediction score for the corresponding object category. The bounding box prediction deltas tensor is an 80×4 = 320 element tensor, containing bounding boxes for the corresponding object categories. Final processing is performed by an output layers module 1736, receiving the tensor 1734 and performing a filtering operation to produce a 46839667_2filtered tensor 1738. Low-scoring (low classification) objects are removed from further consideration. A non-maximum suppression module 1740 receives the filtered tensor 1738 and removes overlapping bounding boxes by removing the overlapped box with a lower classification score, resulting in an inference output tensor 1742, corresponding to the tensor 151.[000237] In an arrangement of the source device 110 and the destination device 140, network weights are signalled in the bitstream 121 as a delta relative to another set of network weights (the ‘base weights’) that are known to the system 100 or may be obtained via external means, such as from the tensor codec repository 180. The base weights may be indicated via reference using an identifier number stored in the bitstream 121. Signalling of network weights as a delta relative to other network weights may be accomplished using a syntax such as ‘MPEG Incremental Neural Network Representation’, under development as part of ISO / IEC 15938-17.[000238] Previous solutions used a container structure in which each FCM PPS (corresponding to VCM NAL PRD) included a separate 32-bit POC. As multiple FCM PPS instances could be included in one VCM RDS, previous solutions incurred high overhead cost for refinement parameters due to numerous instances of POC coding due to the FCM PPS. Methods presented herein enable efficient representation of tensors in a format being amenable to compression using contemporary block-based compression standards such as VVC, HEVC, AVC or other standards. Metadata related to the reduced-domain and restored-domain refinement and feature restoration is represented in a manner that alleviates excessive overhead in associating the metadata for pictures with specific coded feature frames by virtue of delta POC coding and inference mechanisms. Overhead is further amortised across a plurality of coded feature frames rather than wrapping each coded feature frame and associated metadata in separate containers. Block-based compression, although not intuitively applicable to data such as compressed feature maps or coefficients for projecting basis vectors to reconstruct feature maps, uncover additional unexpected redundancy in blocks such as by use of various transforms including trained secondary transforms. Although methods presented herein are described with reference to the ‘Faster RCNN’ and ‘ YOLOv3’ network architectures and specific divisions of these networks into ‘backbone’ and ‘head’ portions, the methods are applicable to any neural network operating on multi-dimensional tensor data and are applicable to different divisions of such networks into ‘backbone’ and ‘head’ portions.[000239] It should be noted that although the source device 110 and the destination device 140 are described with reference to the video source 112 comprising video and image data, other46839667_2types of content such as audio data or textual data may also be supplied as input to neural networks applicable to such types of input and the resulting intermediate feature maps may be compressed and decompressed by the modules 118 and 146 with suitable encoder and decoder network topologies respectively.[000240] In an arrangement where the tensor compressor 530 performs a principal component analysis (PCA) method such as singular value decomposition (SVD) the resulting basis vectors tensor and coefficients tensor are coded in the feature frame 900. The tensor decompressor 1250 performs a projection (matrix multiplication) to produce the tensors 1254 from the basis vectors tensor and coefficients tensor. When PCA methods are used for the modules 530 and 1250, reduced-domain refinement is not performed (i.e., is bypassed) however restored-domain refinement may be enabled.[000241] Arrangements may perform a datatype conversion on the tensor 149 to match the expected datatype of values in tensors to be supplied to the CNN head 150, see theoutput datatype idc syntax element described with reference to Appendix A for example output datatypes. Datatype conversion is performed as the final step of the tensor decoder 146, i.e., datatype conversion is performed on the result of the module 1282 if restored-domain refinement is enabled, or on the result of the module 1280 (i.e., output of the temporal upsampler module 1260) if restored-domain refinement is disabled, or, if the temporal upsampler module 1260 is also disabled or bypassed then datatype conversion is performed on the tensors 1254 from the tensor decompressor module 1250. Where a floating-point output format is shorter than the internal format used in the module 1200 prior to datatype conversion, for example output format is floatl6 or bfloatl6 and internal forma is float32, the exponent of each value in the tensor is clipped into the smaller range afforded by the output format and the mantissa of each value in the tensor is truncated, with rounding, to the smaller precision.[000242] Convolutions involving floating-point values are one source of discrepancy amongst different platforms, arrangements may reduce such discrepancies to a degree by performing “quantised integer convolutions” in place of floating-point convolutions. Quantised integer convolutions operate internally using integer arithmetic, which generally is free of platform discrepancy issues with conversion to and from floating-point values at the input and output of the convolution. In converting from floating-point values to integer values, rounding behaviour is one aspect subject to platform differences.46839667_2[000243] In an arrangement of the source device 110 and the destination device 140 syntax elements described with reference to the FCM CPS 1010 are coded as part of theFCM VMPS 1020. The CPS ID (1012c and 10116) are omitted as the platform information signalled in the FCM_VMPS 1020 is determined via the signalled VMPS_ID 1022c and 10114.[000244] Although use of the platform information to determining the conformance of the output of the tensor decoder 146 is described with reference to tensor or feature compression as used for transmitting intermediate features from the CNN backbone 116 to the CNN head 150, conformance determination via the described signalling is also possible when using a video compression system that utilises low-level functions, such as learned convolutions and the like, to assist in the compression. Signalling enabling selection of a profile for the inner codec, as described with reference to Appendix A, may similarly be applied in systems that compress and decompress video data using an “inner codec” in conjunction with other pre- and postprocessing stages, such as temporal and spatial resampling methods.[000245] Available datasets with ground truth for training for processes such as detection, segmentation, tracking training include the Openimage, COCO, PedTrackPP (A collection of videos from “Pexels” and “Pixabay” content websites, with additional ground-truth), and PWD datasets. The arrangements described can use training techniques known in the machine vision industries, such as adaptive learning rate methods (for example the Adam optimizer), supervised learning methods, unsupervised learning methods, regression analysis and the like.INDUSTRIAL APPLICABILITY[000246] The arrangements described are applicable to the computer and data processing industries and particularly for the digital signal processing for the encoding and decoding of signals such as video and image signals, achieving high compression efficiency.[000247] Some implementations described use of an inserted NAL unit that identifies the platform details used by the tensor encoder and anticipated to be used by the tensor decoder, establishing a conformance point. In particular, the conformance point may be defined with respect to platforms that are created after finalisation of the standard. The arrangements described accordingly provide flexibility to use different platforms after the FCM standard is developed. The arrangements described also provide a mechanism to identify if a particular application is expected to be compliant and thereby bit-accurate. If not, the arrangements described also provide a mechanism to determine if the decrease in conformance or accuracy is sufficient to provide an acceptable implementation, based on a particular application.46839667_2[000248] The foregoing describes only some embodiments of the present invention, and modifications and / or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.46839667_2APPENDIX AAn example FCM CPS, FCM VMPS, FCM SPS, FCM PPS, and FCM PH message format and associated semantics for representing metadata associated with tensor decompressor structure, tensor packing, and complexity indication in a bitstream are as follows:Table 1. FCM unit typesfuh_unit_type Identifier FCM unit type Description0 FCM_VMPS Vison model parameter Vison model parameter set (VMPS) set1 FCM_RSD Restoration data (RSD) Restoration related data 2 FCM_CVD Coded video data (CVD) Coded video3 FCM_CPS Conformance parameter information for set (CPS) establishing conformance point43...31 - - ReservedGeneral FCM unit syntaxfcm_unit( numBytesInF CMUnit ) { Descriptor numBytesInFCMUnit = fcm_unit_header( )fcm_unit_payload( numBytesInFCMUnit - 8 )}FCM unit header syntaxReturns the fcm unit size value. Header size is always 8 bytes.fcm_unit_header( ) { Descriptor fcm unit size / / 1012 (for FCM CPS), 1022 (for FCM VMPS), 10102 u(32) (for FCM RSD / FCM CVD)46839667_2fuh unit type / * FCM CPS, FCM VMPS, FCM RSD, FCM CVD * / u(5) if( fuh_unit_type == FCM_RSD fuh_unit_type == FCM_CVD ) {fuh vmps id / / VMPS ID 10114 u(4) fuh_cps_id / / Conformance parameter set ID CPS ID 10116 u(4) fuh_reserved_zero_23bits u(19) }elsefuh_reserved_zero_27bits u(27) return fcm unit size}General FCM unit payload syntaxfcm_unit_payload( numBytesInFCMUnitPayload ) { Descriptor if( fuh unit type == FCM_CPS( )conformance_parameter_set( )if( fuh_unit_type == FCM_VMPS )vision_model_parameter_set( )if( fuh_ unit type == FCM RSD )restoration_data( numBytesInFCMUnitPayload )if( fuh_ unit type == FCM CVD )coded_video_data( numBytesInFCMUnitPayload )}FCM conformance parameter setconformance_parameter_set( payloadSize ) { / / FCM_CPS 1010 Descriptor conformance parameter set id / / CPS ID 1012c u(4) four zero bits u(4) platform indication vendor UTF-8 platform indication model UTF-846839667_2platform indication stepping UTF-8 platform indication sw library name UTF-8 platform indication sw library version UTF-8 }FCM vision model parameter setvision_model_parameter_set_rbsp ( ) { / / FCM_VMPS Descriptor vmps vision model parameter set id / / VMPS ID 1022c u(4) img wid ue(v) img hei ue(v) scaled img wid ue(v) scaled img hei ue(v) output datatype idc ue(v) rbsp_trailing_bits( )}General Feature Sequence Parameter Setfeat_seq_parameter_set_rbsp ( ) { / / FCM_SPS 10130 Descriptor fsps_feat_seq_parameter_set_id....inner decoding bypass flagif(!inner_decoding_bypass_flag ) {feat_inner_decoder_info( )}dequant bypass flagunpacking bypass flagfeat restoration bypass flagif(!feat_restoration_bypass_flag )feat_restoration_info( )}46839667_2temporal upsampling enable flag u(1) restored feat refine enable flag u(1) reduced feat refine enable flag u(1) if (restored feat refine enable flag ) {... u(8) }if(reduced_feat_refine_enable_flag) {... u(8) }rbsp_trailing_bits( )}Feature Inner Decoder Information (part of the FCM SPS 10130)feat_inner_decoder_info( ) { Descriptor inner coding idx u(8) inner coding level u(8) inner_coding_max_bit_depth_minus8 u(4) inner coding max chroma format u(2) inner coding max pred constraint u(2) inner coding min throughput constraint u(1) byte_alignment()FCM unit header semanticsfcm_unit_size specifies the size of the FCM unit (fem unit header and fcm_unit_payload) in bytes.fuh_cps_id specifies which conformance parameter set (FCM CPS) is applicable to the subsequent FCM unit (FCM restoration data or FCM coded video data). It is a requirement of bitstream conformance that the FCM CPS coded with a value N for conformance_parameter_set_id is present in the bitstream prior to coding of any FCM RSD syntax structure that references the FCM_CPS with value N (i.e., signalling N in fuh_cps_id). Where two FCM_CPS syntax structure are coded with the same value N for46839667_2conformance_parameter_set_id prior to an FCM RSD referencing an FCM CPS with CPS ID = N, signalled via fuh cps id, parameters from the most recently coded FCM CPS are used.FCM conformance parameter set semantics:four_zero_bits pads the bitstream to byte alignment.platform_indication_vendor specifies the vendor of the device (e.g, GPU vendor) used to perform tensor encoding and NN part 1 operation.platform_indication_model specifies the device model number of the device (e.g., GPU) used to perform tensor encoding and NN part 1 operation.platform indication stepping specifies the “stepping” number of the device (e.g., CPU) used to perform tensor encoding and NN part 1 operation. When not applicable, theplatform indication stepping string may be left empty (zero-length string). Although ordinarily “stepping” is defined as a number, UTF-8 coding may be used to permit future variations in naming enumeration or convention.platform indication sw library name specifies the software library used (e g., CUDA library, other numeric library) to perform, or assist in the performance of, numerical operations. platform_indication_sw_library_version specifies the software library version used for performance of numerical operations.FCM VMPS semantics:vmps_conf_parameter_set_id associates the vision model parameter set identified by vmps_vision_model_parameter_set_id with the conformance parameter set identified by conformance_parameter_set_id. It is a requirement of bitstream conformance that the referenced conformance parameter set is present in the bitstream 121 prior to activation in any instance of vision model parameter set.FCM SPS semantics:inner coding idx specifies which inner codec is used according to the following enumeration:46839667_2Feature frame compression standard inner coding idx(inner codec)0 H.264 / AVC1 H.265 / HEVC2 H.266 / VVC3 AV-14-255 Reserved for future use.inner_coding_level specifies the level in accordance with the selected inner codec of the inner coding idx and the “level idc” syntax element of the selected inner codec. Note:“level idc” corresponds to “general level idc” in the H.265 / HEVC and H.266 / VVC standards and defines limits including on coded feature frame size and coded picture buffer size (compressed frame size in the bitstream 121). A value “255” defined to indicate unconstrained level is prohibited in FCM when processing video frame data 115.inner_coding_max_bit_depth_minus8 specifies the maximum bit depth, such that values 0-8 correspond to bit depths from 8 to 16, applied to luma and chroma (if present).inner coding max chroma format specifies the maximum chroma format as follows:inner coding max chroma format Permitted chroma format(s)0 4:0:0 only1 4:2:0 (and 4:0:0 if available)2 4:2:2 and 4:2:0 (and 4:0:0 if available)4:4:4 and 4:2:0 (and 4:2:2 if available and 34:0:0 if available).inner_coding_max_pred_constraint specifies the maximum level of prediction capability needed by the inner codec, as follows:46839667_2inner coding max pred constraint Prediction capability0 Intra only (I slice only)1 Intra + uni -predict! on (I, P slices)Intra + uni- and bi-prediction (I, P, and B 2slices)inner coding min throughput constraint specifies the minimum entropy coding throughput capability needed by the inner codec, inner coding min throughput constraint equal to zero indicates use of a profile that does not specifically target high-throughput applications and inner coding min throughput constraint equal to one indicates use of a profile that targets high-throughput applications (if available).The following table shows example permitted combinations of the syntax elements inner coding idx, inner coding level, inner_coding_max_bit_depth_minus8, inner coding max chroma format, and inner coding min throughput constraint with the resulting inner codec compression standard and profile in use:inner coding idx0 1 2Profile constraints flags(H.264 / (H.265 / HE (H.266 / VV 3 (AV-1) AVC) VC) C) inner_coding_max_bit_depth_minus8 =0inner coding max chroma format = 1High Main Main 10 Main inner_coding_max_pred_constraint = 1profile profile profile1profile1inner coding min throughput constraint= 046839667_2inner_coding_max_bit_depth_minus8 =2inner coding max chroma format = 1 High 10 Main 10 Main 10 Main inner_coding_max_pred_constraint = 1 profile profile profile profile inner coding min throughput constraint= 0inner_coding_max_bit_depth_minus8 =2 Main 10Main 10 inner coding max chroma format = 1 High 10 StillStill Picture inner_coding_max_pred_constraint = 0 Intra Pictureprofile inner coding min throughput constraint profile= 0inner_coding_max_bit_depth_minus8 =High24:4:4 Main 10 inner coding max chroma format = 3 Main 10 High Predicti 4:4:4 inner_coding_max_pred_constraint = 1 4:4:4 profile profile2ve profile inner coding min throughput constraintprofile1= 0inner_coding_max_bit_depth_minus8 =2 CAVLHigh inner coding max chroma format = 1 C 4:4:4Throughp N / A N / A inner_coding_max_pred_constraint = 0 intraut 4:4:4 10 inner coding min throughput constraint profile3= 1Notes:1. Where a standard does not have a profile exactly matching the specified constraints, another profile that exceeds the specified constraints (if available) is used instead. For example, for 10-bit coding of 4:4:4 video, AVC provides a “High 4:4:4 Predictive” profile, which is more capable than the specified constraints due to support for bit depths up to 14 bits. When a more capable profile is used than the signalled maximum46839667 2constraints, the chosen profile is the one that has the least additional capability beyond the capability indicated in the signalled maximum constraints. Among the “maximum constraints”, the “additional capability” is assessed in priority order of least increased bit depth, least increased chroma format, and least increased prediction mode support (i.e., inter-prediction is needed or not). Another example is H.266 / VVC, which does not define an 8-bit “Main” profile, hence the “Main 10” (10-bit profile) is used even if the maximum bit depth is constrained to be 8 bits. For AV-1, the “Main” profile supports 8- and 10-bit coding up to 4:2:0 chroma format.2. In the case of AV-1, the specification of a maximum chroma format of 4:4:4 does not mandatorily also require 4:2:2 support. Hence, the AV-1 “High” (supporting 4:0:0, 4:2:0 and 4:4:4) is used instead of the AV-1 “Professional” profile (supporting 4:0:0, 4:2:0, 4:2:2, amd 4:4:4).3. When high throughput is needed (for example if feature restoration is bypassed) then for H.264 / AVC use of context-adaptive variable length coding (CAVLC) avoids the bottleneck of the binarisations and context modelling associated with CABAC. For H.265 / HEVC, specifically designed high throughput profiles may be used which do use CABAC but introduce parallelism methods to alleviate the bottleneck of arithmetic coding and associated binarization and context modelling steps. For H.266 / VVC and AV-1, at this time there is no specific profile addressing high-throughput applications and hence inner coding min throughput constraint must be set to 0 to use any profile of H.266 / VVC or AV-1 (unless in future such a profile is defined).Regarding inner coding profile selection based on constraints flags, in the case of constraints specifying maximum capability, i.e., inner_coding_max_bit_depth_minus8,inner coding max chroma format, inner coding max pred constraint, if no profiles exist for a given compression standard that meet the signalled minimum capability than the given compression standard may not be used. If one profile exists for a given compression standard that meets the signalled minimum capability then that profile is used. If a set P containing more than one profile exists for a given compression standard that meets the signalled minimum capability then one of the profiles is selected such that the selected profile is the one having the minimum capability in terms whilst exceeding the signalled minimum capability. The set P can be reduced to a single profile by repeatedly excluding (removing) more capable profiles until only one profile remains. Amongst profiles in set P, among profiles with the same capability in46839667_2terms of prediction mode, the one with greater capability in terms of chroma format is removed. Among remaining profiles, for those with the same capability in terms of chroma format, the one with greater capability in terms of bit depth is removed.Where a constraint is specified in terms of a minimum requirement, such asinner coding min throughput constraint, when the constraint is inactive (set to 0) the more commonly used or widely deployed category of profiles is used. For H.264 / AVC, the “High” profiles are generally widely deployed and for H.265 / HEVC the “Main” profiles are generally widely deployed and hence likely available candidates for selection. When the constraint, e.g., inner coding min throughput constraint, is active, then if profiles addressing the constraint is are available, then one is selected based on the maximum constraints, i.e., inner_coding_max_bit_depth_minus8, inner coding max chroma format, inner_coding_max_pred_constraint. For example, if high throughput is required then for H.264 / AVC a CAVLC profile is used and for H.265 / HEVC one of the High Throughput profiles is used. As H.266 / VVC and AV-1 do not provide profiles specific to high-throughput, enablement of inner coding min throughput constraint is prohibited (if enabled then no profile can be used with H.266 / VVC or AV-1 compression standards).46839667_2

Claims

CLAIMS1. A method of determining accuracy of producing one or more tensors from a bitstream, the method comprising:decoding platform information from the bitstream, wherein the platform information indicates a device used for encoding the one or more tensors;producing the one or more tensors from the bitstream, using a predetermined device;determining accuracy of the produced one or more tensors, based on the platform information and the predetermined device; andoutputting information of the result of the determination.

2. The method according to claim 1, wherein the platform information includes at least one of a vendor, a device model, and a device stepping number.

3. The method according to claim 1, wherein the one or more tensors are processed using neural network layers to produce a task result, the task result being used in conjunction with the result of the determination.

4. The method according to claim 1, wherein the bitstream includes metadata forming a summary of the content of the one or more tensors, wherein the metadata is at least one of a hash, a mean, or a variance, of at least one feature map of the one or more tensors.

5. The method according to claim 1, wherein the result of the determination is output as a flag.

6. The method according to claim 1, wherein the platform information includes at least one of a software library and a software library version.

7. The method according to claim 6, wherein the software library version is one of a Numpy, DirectML, BLAS / LAPACK, and a Math kernel library (MKL) version.46839667_28. The method according to claim 2, wherein the information indicating a manner used for encoding the one or more tensors is decoded from the bitstream, the information indicating a manner comprising metadata of the encoded tensors.

9. The method according to claim 8, wherein the metadata is a hash relating to the encoded tensors.

10. The method according to claim 9, wherein the hash is one of SHA1, SHA256, or SHA512.

11. The method according to claim 8, wherein the metadata comprises a mean and / or variance, of one or more of the encoded tensors.

12. A non-transitory computer-readable storage medium which stores a program for executing a method of determining accuracy of producing one or more tensors from a bitstream, the method comprising:decoding platform information from the bitstream, wherein the platform information indicates a device used for encoding the one or more tensors;producing the one or more tensors from the bitstream, using a predetermined device;determining accuracy of the produced one or more tensors, based on the platform information and the predetermined device; andoutputting information of the result of the determination.

13. A system comprising:a memory; anda processor, wherein the processor is configured to execute code stored on the memory for implementing a method of determining accuracy of producing one or more tensors from a bitstream, the method comprising:46839667_2decoding platform information from the bitstream, wherein the platform information indicates a device used for encoding the one or more tensors;producing the one or more tensors from the bitstream, using a predetermined device;determining accuracy of the produced one or more tensors, based on the platform information and the predetermined device; andoutputting information of the result of the determination.46839667_2

Images