EA044215B1 - ENTROPY CODING OF SIGNAL Amplification - Google Patents

Description

State of the art

A backward-compatible hybrid encoding technology has previously been proposed, for example in WO 2014/170819 and WO 2018/046940, the contents of which are incorporated herein by reference.

A method is proposed that involves: parsing the data stream into first portions of encoded data and second portions of encoded data; implements a first decoder for decoding first portions of encoded data when the signal is first transmitted; implements a second decoder for decoding the second portions of the encoded data into recovery data, the recovery data determining how to modify the first signal transmission; and applies the reconstruction data to the first signal transmission to obtain a second signal transmission.

It further proposes an extension in which a set of residual elements can be used to reconstruct the reproduction of the first time sample of the signal. A set of spatiotemporal correlation elements associated with the first time sample is generated. The set of spatiotemporal correlation elements indicates the degree of spatial correlation between the plurality of residual elements and the degree of temporal correlation between the first reproduction-based reference data and the second reproduction-based reference data of the second time sample of the signal. A set of spatiotemporal correlation elements is used to generate the output.

Typical video encoding technologies involve applying an entropy encoding operation to the output data. There is a need for a simple and fast entropy encoding scheme with low complexity for applying data compression to reconstruction data or residuals of the above proposed technologies or other such residual data.

Disclosure of the Invention

According to aspects of the invention, a method is provided for entropy encoding or decoding residual data, wherein the residual data can be used to correct or enhance base stream data, such as a video frame encoded using a legacy video encoding technology.

According to an aspect of the invention, a method for encoding a video signal is provided. The method includes: receiving an input frame; processing the input frame to generate residual data, the residual data forming part of the extended stream and allowing the decoder to reconstruct the input frame based on the reference reconstructed frame; and applying a run-length encoding operation to the residual data, the run-length encoding operation comprising generating a run-length encoded byte stream containing a set of characters representing non-zero values of the residual data and counts of consecutive zero values of the residual data, the method being characterized by the following steps: applying a canonical Huffman encoding operation on a character set for generating Huffman encoded data containing a set of codes representing a run-length encoded byte stream; comparing the data size of at least a run length encoded portion of the byte stream with the data size of at least a corresponding portion of the Huffman encoded data; and outputting the run length encoded byte stream or the Huffman encoded data to the output bit stream (102, 103) based on which one has the smaller data size.

Thus, the encoding method provides an uncomplicated, simple and fast solution for compressing residual data. The solution takes advantage of the unique characteristics of the residual data, such as the relative occurrence of null values, the likely grouping of null values based on the scanning order of the residual data generation transform process (if a transform is used), and the relative diversity of data values, as well as their potential relative frequency/rarity in the residual data. .

The set of characters in the encoded byte stream can be sequential. Counting consecutive zero values can also be called a run of zeros. The residual data on which the run length encoding operation is performed may represent quantized residual data, preferably a quantized set of transform coefficients. The quantized set of transform coefficients can be ordered by layer, that is, by sets of coefficients of the same type, by plane, by quality level, or by surface. These terms are further described and defined herein. The symbols may be sequential in the appropriate scanning order of the transform operation, so that the residual data can be easily compared to the reference reconstructed frame.

Preferably, the run length encoding operation includes: encoding non-zero residual data data values into at least a first symbol type; and encoding the counts of consecutive zero values into a second symbol type such that the residual data is encoded as a sequence of symbols of different types. Thus, the residual data can be encoded as a sequence of characters containing the data value type and a series of zeros. Types provide speed and ease of decoding at the decoder, but also facilitate subsequent entropy encoding operations, as described below. Structuring the data into a minimized set of fixed-length codes of different types is used to perform subsequent steps.

In some embodiments, the run length encoding operation includes the following steps: encoding the residual data data values into a first symbol type and a third symbol type, the first and third symbol types, each containing a portion of the data value so that the portions can be combined at the decoder for reconstruction data values. Each character type can have a fixed size and can be a byte. Data values exceeding a threshold or larger than the size available in the character type can be easily transferred or stored using a byte stream. Structuring data into bytes or characters not only facilitates decoding, but also facilitates entropy encoding of fixed-length characters, as discussed later in this document. The addition of a third character type makes it easy to distinguish the three character types from each other on the decoder side. Where we talk about character types, the terms blocks, bytes (where the character is a byte), contexts, or types may be used.

The run length encoding operation may include the following steps: comparing the size of each residual data value to be encoded with a threshold value; and encoding each data value into a symbol of a first symbol type if the size is below the threshold, and encoding a portion of each data value into a symbol of the first symbol type and a portion of each data value into a symbol of a third symbol type if the size is above the threshold.

If the size exceeds a threshold, the method may comprise setting a flag in the symbol of the first symbol type indicating that a portion of the represented data value is encoded into an additional symbol of the third symbol type. The flag may be an overflow flag or an overflow bit, and may in some examples be the least significant bit of a character or byte. If the least significant bit of the character is a flag, the data value or part of the data value may be contained in the remaining bits of the byte. Setting the overflow bit as the least significant bit makes it easier to combine with subsequent characters.

The method may further include inserting a flag into each character indicating the type of character encoded next in the run-length encoded byte stream. The flag may be an overflow bit as described above, or may additionally be a run flag or run bit indicating whether the next character contains a run of zeros, or a data value, or part of a data value. If the flag represents whether the next character contains a run (or a count of consecutive zeros), the flag can be a bit of the character, preferably the most significant bit of the character. A count of consecutive zeros or a data value may be contained in the remaining bits of the symbol. So a "run of zeros" or character of the second type contains 7 available bits of a byte for counting, and a "data" or character of the first type contains 6 available bits for a data value where the overflow bit is not set and 7 available bits for a data value where The overflow bit is set.

In general, the flag can be different for each character type and can indicate the type of character next in the stream.

In preferred embodiments of the above aspect, the method further includes applying an additional entropy encoding operation to the set of symbols generated by the run length encoding operation. Thus, fixed-length characters intentionally created by the run-length encoding operation structure can be converted to variable-length codes to reduce the overall data size. The run-length encoding structure is designed to produce fixed-length symbols at high frequency to facilitate further enhanced entropy encoding operation and to achieve an overall reduction in data size. An optional entropy encoding operation uses the probability or frequency of a character appearing in the byte stream produced by the run-length encoding operation.

In a preferred example, the additional entropy encoding operation is a Huffman encoding operation or an arithmetic encoding operation. Preferably, the method further includes applying a Huffman encoding operation to the set of symbols to generate Huffman encoded data comprising a set of codes representing a run length encoded byte stream. The Huffman encoding operation takes as input symbols a run-length encoded byte stream and outputs a set of variable length codes in the bit stream. Huffman coding is an encoding technique that can effectively shorten fixed-length codes. The run length encoded byte structure means that the two types of characters are likely to be replicated frequently, meaning that only a few bits are required for each repeated character. Across the entire plane, the same data value is likely to be replicated (especially when the residual data is quantized), and hence the variable length code may be small (but repeatable).

Huffman coding is also well optimized for software implementation (as expected here) and is computationally efficient. This uses minimal memory, and decoding is faster than other entropy encoding methods because the processing steps are simple step-by-step movements through the tree. The computational benefits arise from the shape and depth of the tree created using a specially designed run length encoding operation.

Encoding operations can be performed on a group of coefficients, that is, on a layer, on a frame plane, on a quality level, or on an entire surface or frame. That is, the statistics or parameters of each operation can be determined based on the group of data values and null data values to be encoded, or the characters representing these values.

The Huffman encoding operation may be a canonical Huffman encoding operation such that the Huffman encoded data contains a code length for each unique character in a character set, the code length representing the length of the code used to encode the corresponding character. Canonical Huffman coding helps reduce the number of encoding parameters that need to be communicated between encoder and decoder in metadata by ensuring that identical code lengths are attached to symbols in a consistent manner. The codebook for the decoder can be output and only the lengths of the codes need to be sent. Thus, the canonical Huffman encoder is particularly effective for shallow trees where there are a large number of different data values.

In some examples, the method further includes comparing the data size of at least a portion of the run length encoded byte stream with the data size of at least a portion of the Huffman encoded data; and outputting the run-length encoded byte stream or Huffman encoded data in the output bit stream based on the comparison. Thus, each block or section of input data is sent selectively to reduce the overall data size, ensuring that the decoder can easily distinguish between encoding types. The difference may be within a threshold or tolerance, so that although one scheme may result in less data, the computational efficiency may mean that one scheme is preferable.

To distinguish between schemes, the method may further include adding a flag to the configuration metadata accompanying the output bitstream indicating whether the bitstream represents a run-length encoded byte stream or Huffman encoded data. This is a fast and efficient way to transmit signals. Alternatively, the decoder may identify the scheme used from the data structure, for example, Huffman encoded data may have a header part and a data part, while run length encoded data may only contain a data part, and thus the decoder may be able to distinguish between two schemes.

The Huffman encoding operation may create a separate frequency table for symbols of the first symbol type and symbols of the second symbol type. In addition, a separate Huffman encoding operation can be applied for each character type. These concepts contribute to the particular efficiency of the variable code length coding scheme. For example, if the same data value is replicated across a plane, as is likely when encoding video where the scene may have similar colors or errors/enhancements, those values may only require a few codes (where the codes are not corrupted by character type series zeros). Thus, this embodiment of the invention is particularly advantageous for use in combination with the run length encoding operation described above. As noted above, when values are quantized, symbols can be replicated and cannot be too many different values in one frame or group of coefficients.

The use of a different frequency table for each symbol type provides a particular advantage in the Huffman encoding operation after a specially designed run length encoding operation.

Thus, the method may include determining the type of symbol to be encoded next, selecting a frequency table based on the type of the next symbol, decoding the next symbol using the selected frequency table, and outputting the encoded symbol in sequence. The frequency table may correspond to a unique codebook.

The method may include creating a stream header that may include an indication of a plurality of code lengths such that the decoder can output the code lengths and corresponding symbols for a canonical Huffman decoding operation. The code length may be, for example, the length of each code used to encode a particular character. Therefore, the code length has a corresponding code and a corresponding symbol. The stream header may be a first type of stream header and further comprise an indication of a symbol associated with a corresponding code length of the plurality of code lengths. Alternatively, the stream header may be a second type of stream header, and the method may further include ordering a plurality of code lengths in the stream header based on a predetermined order of symbols corresponding to each of the code lengths, such that the code lengths can be associated with a corresponding symbol at the decoder. Each type provides efficient signaling of encoding parameters depending on the symbols and lengths to be decoded. Code lengths may be signaled as the difference between a length and another length, preferably signaled by a minimum code length.

The second type of stream header may additionally contain a flag indicating that the character is in

- 3 044215 predefined order of possible character set does not exist in the character set in the run-length encoded byte stream. Thus, the header should contain only the required length.

The method may further include comparing the number of unique codes in the Huffman-encoded data with a threshold value and generating a first type of stream header or a second type of stream header based on the comparison.

The method may further include comparing a number of non-null symbols or data symbols with a threshold value and generating a first type of stream header or a second type of stream header based on the comparison.

In accordance with a further aspect of the invention, a method for decoding a video signal may be provided, the method comprising: extracting a coded bit stream; decoding the encoded bitstream to generate residual data, and, restoring the original frame of the video signal based on the residual data and the reference reconstructed frame, wherein the step of decoding the encoded bitstream comprises: applying a run length encoding operation to generate the residual data, wherein the run length encoding operation includes identifying a set of characters representing non-zero residual data values and a set of characters representing counts of consecutive zero residual data values; parsing the character set to obtain non-zero residual data values and count consecutive zero values; and generating residual data based on non-zero data values and counting successive zero values, wherein the method is characterized in that the step of decoding the encoded bitstream includes: extracting a flag from configuration metadata accompanying the encoded bitstream (102, 103) indicating whether the encoded bitstream contains stream run-length encoded byte stream or Huffman encoded data; and selectively applying a canonical Huffman encoding operation to the encoded bitstream (102, 103) based on the flag to generate a set of symbols representing non-zero values of the residual data data and a set of symbols representing counts of successive zero values of the residual data, wherein the step of applying the length encoding operation series to generate residual data is performed on character sets.

The run length encoding operation may comprise: identifying symbols of a first symbol type representing non-zero values of the residual data data; identifying symbols of a second symbol type representing counts of consecutive zero values such that the sequence of symbols of the different types is decoded to generate residual data; and parsing the set of characters according to the corresponding type of each character.

The run length encoding operation may comprise identifying symbols of a first symbol type and symbols of a third symbol type, wherein the first and third symbol types each represent a portion of a data value; parsing a character of the first character type and a character of a third character type to obtain parts of the data value; and combining the derived parts of the data value into a data value.

The method may further include: extracting an overflow flag from a symbol of the first symbol type indicating whether part of the data value of the symbol of the first symbol type is contained in a subsequent third symbol type.

The method may further include extracting a flag from each character indicating the next type of character that is expected in the character set.

It can be assumed that the start symbol is a symbol of the first type, such that the start symbol is parsed to obtain at least part of the data value.

The step of decoding the encoded bitstream may include applying a Huffman encoding operation to the encoded bitstream to generate a set of symbols representing non-zero data values of the residual data and a set of symbols representing counts of consecutive zero values of the residual data, wherein the step of applying a run length encoding operation to generate the residuals data processing is performed on character sets.

The Huffman encoding operation may be a canonical Huffman encoding operation.

The method may further include retrieving a flag from configuration metadata accompanying the encoded bitstream indicating whether the encoded bitstream contains a run length encoded byte stream or Huffman encoded data; and selectively applying a flag-based Huffman encoding operation.

The method may further include: identifying a symbol of an initial type that is expected to be output in the encoded bitstream; applying a Huffman encoding operation to the encoded bit stream to obtain an initial symbol based on a set of encoding parameters associated with the initial type of the expected symbol; extracting a flag from the initial symbol indicating the next type of symbol that is expected to be obtained from the bit stream; and, further, applying a Huffman encoding operation to the bitstream to obtain a subsequent symbol based on a set of encoding parameters associated with the subsequent symbol type, which,

- 4 044215 is expected to be obtained from the bitstream.

The method may further include iteratively extracting a flag from the decoded symbol indicating the next symbol type expected to be obtained from the bit stream, and applying a Huffman encoding operation to the bit stream to obtain the next symbol based on a set of encoding parameters associated with the subsequent symbol type. , which is expected to be obtained from the bitstream.

Thus, the method may include the steps of decoding a symbol using a Huffman encoding operation, decoding a symbol using a run length encoding operation, identifying a symbol type expected to result from a run length encoding operation, and decoding the next symbol using a Huffman encoding operation.

The method may further include: retrieving a stream header containing an indication of a plurality of code lengths to be used for a canonical Huffman encoding operation; associating each code length with a corresponding symbol in accordance with a canonical Huffman encoding operation; and identifying a code associated with each symbol based on code lengths in accordance with a canonical Huffman encoding operation. Thus, codes can be associated with consecutive symbols whose code lengths are identical.

The stream header may include an indication of a symbol associated with a corresponding code length of the plurality of code lengths, and the step of associating each code length with a symbol includes associating each code length with a corresponding symbol in the stream header.

The step of associating each code length with a corresponding symbol involves associating each code length with a symbol from a set of predetermined symbols according to the order in which each code length was extracted.

The method may further comprise not associating a symbol from a set of predetermined symbols with a corresponding code length, where a stream header flag indicates that the code length does not exist in a stream header for that character.

According to an aspect of the invention, a method for encoding a video signal is provided. The method includes: receiving an input frame; processing the input frame to generate residual data, the residual data allowing the decoder to reconstruct the input frame from the reference reconstructed frame; and applying a Huffman encoding operation to the residual data, wherein the Huffman operation comprises generating an encoded bitstream comprising a set of codes encoding a set of symbols representing the residual data.

According to a further aspect of the invention, a method for decoding a video signal may be provided, the method comprising: extracting an encoded bit stream; decoding the encoded bit stream to generate residual data, and recovering the original frame of the video signal from the residual data and a reference reconstructed frame, wherein the step of decoding the encoded bit stream comprises: applying a Huffman encoding operation to generate the residual data, wherein the Huffman encoding operation includes generating a set symbols representing residual data by comparing the encoded bit stream with a reference mapping of codes in the corresponding symbol, generating residual data based on data values other than zero, and counting consecutive zero values.

According to a further aspect, an apparatus for encoding a data set into a coded data set may be provided. The device is configured to encode the input video in accordance with the above steps. The device may include a processor configured to perform a method in accordance with any of the above aspects.

According to a further aspect, an apparatus for decoding the data set into a reconstructed video from the data set may be provided. The device is configured to decode the output video in accordance with the above steps. The device may comprise a processor configured to perform a method in accordance with any of the above aspects.

An encoder and decoder can also be provided.

In accordance with additional aspects of the invention, computer-readable media may be provided that, when executed by a processor, cause the processor to perform any of the methods in accordance with the foregoing aspects.

According to a further aspect, an encoded bit stream may be provided containing an encoded version of the residual data for the extended stream, wherein the residual data is configured to be used with a reference reconstructed frame to reconstruct the original frame of the video signal, wherein the encoded residual data comprises the result of applying a run length encoding operation to the residual data, wherein the run length encoding operation results in a set of characters representing non-zero data values of the residual data, and a set of characters representing counts of consecutive zero values of the residual data; wherein the set of symbols is analyzed by the decoder to obtain non-zero values

- 5 044215 data of residual data and counts of consecutive zero values, wherein the non-zero data values and counts of consecutive zero values are configured to be used to obtain residual data at a decoder, wherein the encoded bitstream is characterized by the following: the configuration metadata includes a flag indicating whether the encoded bitstream represents bitstream run-length encoded byte stream or Huffman encoded data, wherein in response to a flag indicating that the encoded bitstream contains Huffman encoded data, a set of characters representing non-zero data values of the residual data, and a set of characters, representing counts of consecutive zero values, further Huffman encoded in the encoded bit stream; and wherein the flag is configured to be used to instruct the decoder to apply a Huffman encoding operation to the encoded bit stream to generate a set of symbols representing non-zero values of the residual data data and a set of symbols representing counts of consecutive zero values before applying the run length encoding operation at the decoder.

Detailed Description of the Invention

Examples of systems and methods in accordance with the invention will now be described with reference to the accompanying drawings, in which:

in fig. 1 illustrates a high-level diagram of the encoding process;

in fig. 2 illustrates a high-level diagram of a decoding process;

in fig. 3 illustrates a high-level diagram of the residual data generation process;

In fig. 4 illustrates a high-level diagram of the process for generating additional residual data with a different quality level;

in fig. 5 illustrates a high-level diagram of a process for reconstructing a frame from residual data;

in fig. 6 illustrates the hierarchical data structure;

in fig. 7 illustrates an additional hierarchical data structure;

in fig. 8 illustrates an example of the encoding process;

in fig. 9 illustrates an example of a decoding process;

in fig. 10 illustrates the structure of the first data symbol;

in fig. 11 illustrates the structure of the second data symbol;

in fig. 12 illustrates the structure of a trigger symbol;

in fig. 13 illustrates the header structure of the first stream;

in fig. 14 illustrates the header structure of the second stream;

in fig. 15 illustrates the header structure of the third stream;

in fig. 16 illustrates the header structure of the fourth stream;

in fig. 17A-17E illustrate Huffman trees and FIG. 18 illustrates a run length encoding finite state machine.

The present invention relates to methods. In particular, the present invention relates to methods for encoding and decoding signals. Data processing methods may include, but are not limited to, data acquisition, retrieval, output, ingestion and data recovery.

The encoding technology discussed in this document is a flexible, adaptable, highly efficient, and computationally inexpensive encoding format that combines a video encoding format, a base codec (such as AVC, HEVC, or any other existing or future codec) with an encoded data enhancement layer, encoded using other technologies.

The technology used uses a downsampled source signal encoded with a base codec to generate the base stream. The enhanced stream is generated using an encoded set of residual data that corrects or improves the base stream, for example by increasing the resolution or increasing the frame rate. There can be several levels of extended data in a hierarchical structure. It is worth noting that the base stream is generally expected to be decodable by a hardware decoder, while the extension stream is expected to be suitable for implementing software processing with suitable power consumption.

Methods and systems are needed to efficiently transmit and store extended encoded information.

It is important that any entropy encoding operation used in a new encoding technology is tailored to the specific requirements or constraints of the extension stream and has low complexity. Such requirements or limitations include: potential reduction in computational capabilities resulting from the need to software decode the extension stream; the need to combine the decoded residual data set with the decoded frame; the likely structure of the residual data, that is, a relatively high proportion of null values with highly variable data values over a wide range; nuances of the input quantized block of coefficients; and the structure of the expansion stream, which is a set of discrete residual frames divided into planes, layers, etc. Entropy coding must also be suitable for multiple expansion levels in the expansion stream.

Research conducted by the inventors has determined that current entropy coding schemes used in video, such as context-sensitive adaptive binary arithmetic coding (CABAC) or context-adaptive variable-length coding (CAVLC), are unlikely to be suitable. For example, prediction engines may be unnecessary or may not provide sufficient benefits to offset their computational burden given the structure of the input data. Moreover, arithmetic coding is typically computationally expensive, and implementing appropriate software is often undesirable.

Note that the limitations placed on the enhancement stream mean that a simple and fast entropy encoding operation is essential to enable the enhancement stream to effectively correct or enhance individual frames of the underlying decoded video. Note that in some scenarios, the underlying stream is also decoded almost simultaneously before being combined, which puts a strain on resources.

This document preferably conforms to the requirements of the following ISO/IEC documents: Call for Proposals for Low Complexity Video Coding Enhancements ISO/IEC JTC1/SC29/WG11 N17944, Macau, China, Oct. 2018 and Requirements for Low Complexity Video Coding Enhancements ISO/IEC JTC1/SC29/WG11 N18098, Macau, China, Oct. 2018. Moreover, the approaches described here can be incorporated into PERSEUS® products supplied by V-Nova International Ltd.

The general structure of the proposed encoding scheme, in which the methods described in this document can be applied, uses the original downsampled signal encoded with a base codec, adds a first layer of correction data to the decoded output of the base codec to generate a corrected image, and then adds an additional enhancement data layer to an upsampled version of the corrected image.

Thus, the threads are considered as a base thread and an extension thread. It is worth noting that the base stream is generally expected to be decoded by a hardware decoder, while the enhancement stream is expected to be suitable for implementation by software processing with suitable power consumption.

This structure creates many degrees of freedom that provide greater flexibility and adaptability to many situations, making the encoding format suitable for many use cases, including Over-The-Top (OTT) transmission, live broadcast, Ultra High Definition (UHD) live broadcast and etc.

Although the decoded output of the base codec is not intended for viewing, it is fully decoded video at a lower resolution, making the output compatible with existing decoders and, where deemed appropriate, can also be used as lower resolution output.

In general, residual data refers to the difference between the value of a reference array or reference frame and the actual array or frame of data. It should be noted that this general example is independent of the encoding operations performed and the nature of the input signal. A reference to residual data, in the context of this document, refers to data derived from a set of residual data, such as a set of residual data itself or the result of a set of data processing operations that are performed on a set of residual data.

In some of the examples presented herein, a number of encoded streams may be generated and independently sent to the decoder. That is, in the example signal encoding methods, the signal may be encoded using at least two encoding layers. The first level of encoding may be performed using a first encoding algorithm, and the second level may be encoded using a second encoding algorithm. The method may include: obtaining a first portion of a bit stream by encoding a first signal level; obtaining a second portion of the bitstream by encoding a second signal layer; and transmitting the first part of the bit stream and the second part of the byte stream as two independent bit streams.

It should be noted that the entropy encoding method proposed herein is not limited to the set of LoQs illustrated in the figures, but provides the utility of any residual data used to provide expansion or correction of a video frame reconstructed from a coded stream encoded using legacy video encoding technology , such as HEVC. For example, the utility of the coding method in encoding residual data of different LoQs is particularly advantageous.

Note that in FIG. 1-5 illustrate examples of encoding and decoding schemes in which the entropy encoding techniques presented herein may provide utility, but it will be understood that the encoding technique may typically be used to encode residual data.

- 7 044215

Some examples presented herein relate to a general encoding and decoding process that provides a hierarchical, scalable, flexible encoding technology. The first portion of the bit stream or the first independent bit stream may be decoded using a first decoding algorithm, and the second portion of the bit stream or the second or independent bit stream may be decoded using a second decoding algorithm. The first decoding algorithm can be decoded by a traditional decoder using legacy equipment.

Returning to the initial process described above providing a base stream and two layers of enhancement in the enhancement stream, an example of a generalized encoding process is shown in the flowchart illustrated in FIG. 1. The input video at full resolution 100 is processed to generate different coded streams 101, 102, 103. The first coded stream (the coded base stream) is created by feeding the base codec (such as AVC, HEVC or any other codec) a downscaled version of the input video sampling. The coded base stream may be called a base layer or base layer. A second coded stream (layer 1 coded stream) is created by processing the residual data obtained by processing the difference between the reconstructed base video codec and the downsampled version of the input video. A third codestream (level 0 codestream) is created by processing the residual data obtained by processing the difference between the upsampled version of the adjusted version of the reconstructed base coded video and the input video.

The downsampling operation can be applied to the input video to create a downsampled video, which must be encoded using the underlying codec. Downsampling can be performed in both the vertical and horizontal directions, or alternatively only in the horizontal direction.

Each spreading stream encoding process may not necessarily include an upsampling step. In fig. 1, for example, the first expansion stream is conceptually a correction stream, while the second expansion stream is upsampled to provide a level of expansion.

Looking at the process of generating enhanced streams in more detail, to generate a layer 1 coded stream, the coded base stream is decoded 114 (ie, a decode operation is applied to the coded base stream to generate a decoded base stream). A difference is then created between the decoded base stream and the input downsampled video 110 (ie, a subtraction operation is applied to the input downsampled video and the decoded base stream to generate a first set of residual data).

In this document, the term residual data is used in the same way as a term known in the art, that is, it refers to the error between a reference frame and a desired frame. In this paper, the reference frame is the decoded base stream and the desired frame is the downsampled input video. Thus, the residual data used in the first enhancement layer can be considered as corrected video since it corrects the decoded base stream into the downsampled input video that was used in the base encoding operation.

Again, the entropy encoding operation described below is suitable for any residual data, such as any data associated with a set of residual data.

The difference is then encoded 115 to generate a layer 1 coded stream 102 (ie, an encoding operation is applied to the first set of residual data to generate a first extension stream).

As noted above in the document, the enhanced stream may comprise a first enhancement layer 102 and a second enhancement layer 103. The first enhancement layer 102 may be considered an adjusted stream. The second enhancement layer 103 can be considered as an additional enhancement layer that converts the corrected stream to the original input video.

An additional enhancement layer 103 is created by encoding an additional set of residual data that represents the difference 119 between the upsampled version 117 of the decoded layer 1 stream 118 and the input video 100 .

As noted in this document, the upsampled stream is compared to the input video, resulting in an additional set of residual data (ie, the difference operation is applied to the re-created upsampled stream to generate an additional set of residual data). A further set of residual data is then encoded 121 as a layer 0 encoded extension stream (ie, the encoding operation is then applied to the additional set of residual data to generate an encoded additional extension stream).

Thus, as illustrated in FIG. 1 and described above in this document, the output of the encoding process is a base stream 101 and one or more extension streams 102, 103, which preferably comprise a first extension layer and an additional extension layer.

The corresponding generalized decoding process is depicted in the flowchart illustrated

- 8 044215 bathroom in fig. 2. The decoder receives three streams 101, 102, 103 generated by the encoder, along with headers containing additional decoding information. The coded base stream is decoded by a base decoder corresponding to the base codec used in the encoder, and its output is combined with the decoded residual data obtained from the layer 1 code stream. The combined video is upsampled and further combined with the decoded residual data obtained from the layer 1 code stream. 0.

During the decoding process, the decoder can analyze the headers (global configuration, image configuration, data block) and configure the decoder based on these headers. To recreate the input video, the decoder may decode each of the base stream, the first enhancement stream, and the additional enhancement stream. Stream frames can be synchronized and then combined to produce decoded video.

Illustrated in each of FIGS. 1 and 2, level 0 and level 1 encoding operations may include transform, quantization, and entropy encoding steps. Similarly, in the decoding stage, the residual data can be passed through an entropy decoder, a dequantizer, and an inverse transform module. Any suitable encoding and corresponding decoding operation may be used. However, it is preferable that the level 0 and level 1 encoding steps can be performed in software.

Thus, the methods and apparatuses provided herein are based on a general algorithm that is built upon an existing encoding and/or decoding algorithm (such as MPEG standards such as AVC/H.264, HEVC/H.265, etc., as well as a non-standard algorithm such as VP9, AV1 and others) that works as a base layer for an enhancement layer that works according to a different encoding and/or decoding algorithm. The idea behind the general algorithm is hierarchical encoding/decoding of a video frame, as opposed to the block-based approaches used in the MPEG family of algorithms. Hierarchical frame encoding involves creating residual data for the full frame, then the decimated frame, and so on.

The residual video compression data for a full-length video frame may be called LoQ-0 (e.g., 1920x1080 for an HD video frame), while the decimated frame data may be called LoQ-x, where x denotes the number of hierarchical decimations. In the examples illustrated in FIGS. 1 and 2, the variable x has a maximum value of 1 and hence there are 2 hierarchical levels for which residual compression data will be generated.

In fig. 3 illustrates an example of how LoQ-1 can be generated on an encoder. In this figure, the general algorithm and methods are described using the AVC/H.264 encoding/decoding algorithm as the base algorithm, but it is understood that other encoding/decoding algorithms can be used as the base algorithms without any impact on the manner in which the general algorithm.

Of course, it will be understood that the blocks illustrated in FIG. 3 are simply examples of how broad concepts can be implemented.

The circuit illustrated in FIG. 3 shows the process of generating entropy coding of residual data for the LoQ-1 hierarchy level. In this example, the first step is to decimate the incoming uncompressed video by a factor of 2. This decimated frame is then passed through the underlying encoding algorithm (in this case the AVC/H.264 encoding algorithm), creating and storing an entropy-encoded reference to the frame. A decoded version of the encoded reference frame is then generated, and the difference between the decoded reference frame and the decimated frame (LoQ-1 residual data) will form the input data for the block transform.

A transform (such as the Hadamard-based transform in this illustrated example) converts this difference into 4 components (or planes), namely A (mid), H (horizontal), V (vertical), and D (diagonal). These components are then quantized using variables called step width (for example, the residual value can be divided by the step width and the selected nearest integer value). A suitable entropy encoding process is the subject of this invention and is described in detail later in this document. This quantized residual data is then entropy encoded to remove any redundant information. The quantized encoded coefficients or components (Ae, He, Ve and De) are then placed into a serial stream with definition packets inserted at the beginning of the stream, this final step is performed using a file serialization procedure. The packet data may include information such as the specification of the encoder, the type of upsampling applied, whether the A and D planes are discarded or not, and other information that allows the decoder to decode the streams.

Both the reference data (half-size entropy encoded frame) and LoQ-1 entropy encoded residual data can be buffered, transmitted, or stored for use by the decoder during the reconstruction process.

- 9 044215

To generate LoQ-0 residual data, the quantized output is forked and inverse quantization and transform processes are performed on it to recover the residual data

LoQ-1, which are then added to the decoded reference data (encoded and decoded) to produce back a video frame very similar to the originally decimated input frame.

This process perfectly mimics the decoding process and hence the initially decimated frame is not used.

In fig. 4 illustrates an example of how LoQ-0 can be generated on an encoder. To obtain residual LoQ-0 data, a frame of size LoQ-1 is reconstructed as described in the previous section.

The next step is to upsample the reconstructed frame to full size (by 2). At this stage, various algorithms can be used to improve the upsampling process, such as nearest, bilinear, exact or cubic algorithms. This reconstructed full-length frame, called a predicted frame, is then subtracted from the original uncompressed video input, which creates some residual data (LoQ-1 residual data).

Similar to the LoQ-1 process, the difference is then converted, quantized, entropy encoded, and the file is serialized, which then produces the third and final data. This may be buffered, transmitted, or stored for later use by the decoder. As can be seen, a component called the predicted average (described below) can be obtained using an upsampling process and used in place of the A (average) component to further improve the efficiency of the encoding algorithm.

In fig. 5 schematically illustrates how the decoding process can be performed in a specific example. Entropy encoded data, entropy encoded LOQ-1 residual data, and entropy encoded LOQ-O residual data (eg, as file-serialized data). The entropy encoding data comprises a reduced-size encoding base (eg, half size, i.e., with dimensions W/2 and H/2 relative to a full frame having dimensions W and H).

The entropy encoded data is then decoded using a decoding algorithm corresponding to the algorithm that was used to encode the data (in the example, the AVC/H.264 decoding algorithm). At the end of this step, a decoded video frame of reduced size (eg, half size) is created (denoted in this example as AVC/H.264 video).

In parallel, the LoQ-1 entropy encoded residual data is decoded. As discussed earlier in this document, LoQ-1 residual data is encoded using four coefficients or components (A, V, H and D), which, as illustrated in this figure, are sized to correspond to one-quarter the size of the full frame, namely W /4 and N/4. This is because, as discussed in previous patent applications US 13/893669 and PCT/EP2O13/O59847, the contents of which are incorporated herein by reference, the four components contain all information related to the residual data and are generated by applying a 2x2 transform kernels to the residual data, the dimensions of which for LoQ-1 will be W/2 and H/2, that is, the same dimension of the data encoded by reduced size entropy. The four components are entropy decoded, then dequantized, and finally converted back to the original LoQ-1 residual data using an inverse transform (in this case a 2x2 inverse Hadamard transform).

The decoded LoQ-1 residual data is then added to the decoded video frame to create a reduced-size (in this case half-size) reconstructed video frame, identified as a Half-2D size restoration.

This reconstructed video frame is then upsampled, which brings it to full resolution (so, in this example, from half-width (W/2) and half-height (H/2) to full-width (W) and full-height (H)) using upsampling filter such as bilinear, bicubic, exact, etc. The reconstructed upsampled video frame will be a predicted frame (full-length, WxH), to which residual LoQ-0 decoding data is then added.

In particular, the residual data encoded in LoQ-0 is decoded. As discussed earlier in this document, LoQ-0 residual data is encoded using four coefficients or components (A, V, H and D), the size of which, as illustrated in this figure, is half the size of the full frame, namely W/2 and N/2. This is because, as discussed in previous patent applications US 13/893669 and PCT/EP2O13/O59847, the contents of which are incorporated herein by reference, the four components contain all information related to the residual data and are generated by applying a 2x2 transform kernels to residual data, the dimensions of which for LoQ-0 would be W and H, that is, the same dimension of the full frame. Four

- 10 044215 components are entropy decoded (see process described later in the document), then dequantized and finally converted back to the original LoQ-0 residual data using an inverse transform (in this case a 2x2 inverse Hadamard transform).

The decoded LoQ-0 residual data is then added to the predicted frame to create a reconstructed full video frame - the output frame.

The data structure is illustrated as an example in FIG. 6. As discussed earlier in this document, the above description has been made with reference to specific dimensions and basic algorithms, but the above methods are applicable to other sizes and/or basic algorithms, and the above description is given only as an example of the more general concepts described.

In the encoding/decoding algorithm described earlier in this document, there are typically 3 planes (such as YUV or RGB) with two LoQ quality levels, which are described as LoQ0 (or upper level, full resolution) and LoQ-1 (or lower level, full resolution) reduced size resolution, e.g. half resolution) in each plane. Each plane can represent a different color component for the video signal.

Each LoQ contains four components or layers, namely A, H, V and D. This gives a total of 3x2x4=24 surfaces, of which 12 are full size (eg WxH) and 12 are reduced size (eg W/2xH/2). Each layer may contain coefficient values for a particular one of the components, for example layer A may contain the value of coefficient A in the upper left corner for each 2x2 block of the input image or frame.

In fig. 7 illustrates an alternative view of the proposed hierarchical data structure. The encoded data can be divided into parts. Each payload can be hierarchically ordered into chunks. That is, each payload is grouped into a plane, then within each plane of each layer is grouped into layers, and each layer contains a set of tiles for that layer. A layer represents each level of expansion (first or subsequent), and a layer represents a set of transform coefficients.

The method may include extracting fragments for two levels of expansion for each plane. The method may comprise extracting 16 layers for each layer (eg if a 4x4 transform is used). Thus, each payload is ordered into a set of tiles for all layers at each level, and then a set of tiles for all layers at the next level of the plane. The payload then includes a set of fragments for the first level layers of the next plane, and so on.

Thus, the method can decode the headers and output entropy-coded coefficients grouped by plane, levels, and layers belonging to the image extension being decoded. Thus, the output can be array surfaces (n Planes)x(n Level)χ(n Layer) with surface elements [n Planes]^ Level][n Layer].

Note that the entropy encoding methods presented herein can be performed on a per-group basis, that is, can be performed on a per-surface, per-plane, per-layer (LoQ) basis, or per-layer basis. Note that entropy encoding can be performed on any residual data and not necessarily quantized and/or transformed coefficients.

As illustrated in FIG. 4 and 5, the proposed encoding and decoding operations include an entropy encoding step or operation. It is further proposed that the entropy encoding operation comprise one or more of a run length encoding (RLE) component and a Huffman encoding component. These two components can interact with each other to provide additional benefits.

As noted and illustrated in FIG. 8, the input to the entropy encoder is a surface (eg, residual data derived from a quantized set of residual data, as illustrated in this example), and the output of the process is an entropy-coded version of the residual data (Ae, He, Ve, De). However, as stated earlier in this document, it should be noted that entropy coding can be performed on any residual data and not necessarily quantized and/or transformed coefficients. In fig. 9 illustrates a corresponding high-level decoder with inverse inputs and outputs. That is, the entropy decoder takes entropy-coded residual data (Ae, He, Ve, De) as input and outputs residual data (eg, quantized residual data in this illustrated example).

Note that, as illustrated in FIG. 8, RLE decoding prior to Huffman decoding is generally shown, but as will be clear throughout this application, this order is not limiting and the steps may be interchangeable, interrelated, or in any order.

Similarly, we note that run-length encoding may be provided without Huffman encoding, and in comparative cases run-length encoding and Huffman encoding may not be performed (either replaced by alternative lossless entropy encoding, or entropy encoding

- 11 044215 coding is not performed at all). For example, in a productive example with a reduced emphasis on data compression, the encoding pipeline may not contain entropy encoding, but the residual data may benefit from tiered storage for distribution.

A relative run length encoder (RLE) can compress data by encoding sequences of the same data value as one data value and counting that data value. For example, the sequence 555500022 could be encoded as (4,5)(3,0)(2,2). That is, there is a series of four fives, a series of three zeros, followed by a series of two twos.

A modified RLE encoding operation is proposed to encode residual data. To take advantage of the residual data structure, it is suggested that only runs of zeros be encoded. That is, each value is sent as a quantity, with each zero sent as a series of zeros. The modified RLE encoding operations described herein can be used, for example, to provide entropy encoding and/or decoding on one or more LoQ layers, for example as shown in FIG. 1-5.

Thus, the entropy encoding operation involves analyzing the residual data and encoding the zero values as a series of consecutive zeros.

As noted earlier in this document, to provide an additional level of data compression (which may be lossless), the entropy encoding operation additionally applies a Huffman encoding operation to the serially encoded data.

Huffman encoding and run-length encoding were previously combined together, for example in facsimile encoding (eg ITU Recommendations T.4 and T.45) and the JPEG file interchange format, but over the last 30 years they have been replaced by other encoding methods. The present disclosure provides methods and techniques for implementing Huffman coding in combination with RLE coding, methods and techniques for efficiently exchanging data and metadata between an encoder and decoder, and methods and techniques for reducing the overall data size of such a combination when used for encoding residual data.

Huffman code is an optimal prefix code that is used for data compression (such as lossless compression). A prefix code is a system of codes for which there is no code work in the system that is a prefix of any other code. That is, the Huffman encoding operation takes a set of input symbols and converts each input symbol into its corresponding code. The selected code is based on the frequency of occurrence of each character in the original data set. Thus, smaller codes can be associated with characters that occur more frequently to reduce the overall data size.

To facilitate Huffman coding, the input data is preferably structured as characters. The output of the run length encoding operation is preferably structured to be a stream of bytes of encoded data.

In one example, the run-length encoding operation outputs two types of bytes or characters. The first character type represents a non-zero pixel value, and the second character type represents a series of consecutive zero values. That is, the number of null values that consistently occur in the original data set.

In an additional example, two bytes or characters may be concatenated to encode certain data values. That is, for example, when a pixel value is greater than a threshold, two bytes or characters can be used to encode the data value in the character. These two symbols can be combined in a decoder to recreate the original pixel data value.

Each character or byte may contain 6 or 7 bits of data and one or more flags or bits indicating the type of the character.

In an exemplary embodiment, run-length encoded data can be efficiently encoded by inserting into each character one or more flags indicating the next character that is expected in the byte stream.

To facilitate synchronization between the encoder and decoder, the first byte of the run-length encoding data stream may be the data value type of the symbol. This byte can then point to the next byte type that was encoded.

In some embodiments, the flag indicating the next byte may differ depending on the type of character. For example, a flag or bit may be located at the beginning or end of a byte, or both. For example, at the beginning of a byte, a bit may indicate that the next character may be a series of zeros. At the end of the byte, the bit may be an overflow bit indicating that the next character contains part of the data value that must be combined with the data value in the current character.

The following describes a specific example of the implementation of the run length encoding operation. The RLE contains three contexts: RLC_RESIDUAL_LSB, RLC_RESIDUAL_MSB and RLC_ZERO_RUN. The structure of these bytes is illustrated in FIG. 10, 11 and 12.

In the first symbol type, RLC_RESIDUAL_LSB, illustrated in FIG. 10, the least significant 6 bits of a non-zero pixel are encoded. An execute bit may be provided to indicate that the next byte encodes a run of zeros count. The overflow bit can be set if the pixel value does not correspond to 6 data bits. When the overflow bit is set, the context of the next byte will be of type RLC_RESIDUAL_MSB. That is, the next character will contain a byte of data that can be combined with the bits of the current character to encode the data value. If the overflow bit is set, the next context cannot be a series of zeros, and so the character can be used to encode data.

In fig. Figure 10 illustrates an example of this type of symbol. If the value of the data to be encoded is greater than the threshold value of 64 or the pixel value does not correspond to 6 bits of data, the overflow bit may be set by the encoding process. If the overflow bit is set as the least significant bit of the byte, then the remaining bits of the byte can encode data. If the pixel value fits within 6 bits, the overflow bit cannot be set and the run bit can be turned on, which indicates whether the next character is a data value or a series of zeros or not.

The second symbol type, RLC_RESIDUAL_MSB, illustrated in FIG. 11 encodes bits 7 through 13 of pixel values that do not fit into 6 bits of data. Bit 7 of this character type encodes whether the next byte is a series of zeros or not.

The third symbol type, RLC_ZERO_RUN, illustrated in FIG. 12, encodes 7 bits of zero run count. That is, the symbol contains the number of consecutive zeros in the residual data. The character progress bit is high if more bits are required to encode the count. The execute bit may be the most significant bit of the byte. That is, when there is a run of consecutive zeros that requires more than 7 available bits, such as 178 or 255, the execute bit indicates that the next bit will point to an additional run of zeros.

Optionally, the additional symbol may contain a second run of zeros, which may be combined with the first run, or may contain a set of value bits, which may be combined with the bits of the first symbol at the decoder to indicate a count.

As stated earlier in this document, in order for the decoder to start operating in a known context, the first symbol in the codestream may be a symbol residual data value type, that is, it may be an RLC_RESIDUAL_LSB type.

In a specific example, the RLE data may be organized into blocks. Each block can have an output capacity of 4096 bytes. RLE may switch to a new block in the following cases:

the current block is full;

the current RLE data is a run and there are less than 5 bytes left in the current block; and/or the current RLE data results in an LSB/MSB pair and there are less than 2 bytes remaining in the current block.

Thus, the run length encoding operation can be performed on the residual data of a new encoding technique that involves encoding into a stream a set of data values and counting consecutive zero values. In a particular implementation, the output of a run-length encoding operation may be a stream of bytes or characters, where each byte is one of three types or contexts. Byte specifies the next byte type expected in the byte stream.

It should be noted that these structures are provided as examples, and that various bit encoding schemes may be used following the functional principles described herein. For example, the encoding of the least significant and most significant bits may be exchanged and/or different bit lengths may be used. In addition, flag bits can be located at various predefined positions in a byte.

As noted earlier in this document, a Huffman encoding operation can be applied to a byte stream to further reduce the data size. The process can create a frequency table of the relative occurrence of each character in the stream. From the frequency table, the process can generate a Huffman tree. A Huffman code for each character can be generated by traversing the tree from the root until the character is reached, assigning a code bit for each branch taken.

In a preferred embodiment, a canonical Huffman encoding operation may be used for use with run-length coded symbol length specific quantized data residuals (ie, residual data). Canonical Huffman codes can reduce the storage requirements of a set of codes depending on the structure of the input data. The canonical Huffman procedure provides a way to create a code that implicitly contains information about which codeword applies to which symbol. Huffman codes can be specified with a set of conditions, for example, all codes of a given length can have lexicographically sequential values in the same order as the characters they represent, and shorter codes lexicographically precede longer codes. In a canonical implementation of Huffman encoding, only the codewords and the lengths of each code must be transmitted in order for the decoder to reproduce each symbol.

After applying the canonical Huffman encoding operation, the size of the output data can be compared with the size of the data after performing the run length encoding operation. If the data size is smaller, then smaller data can be transferred or stored. Data size comparisons can be made based on data block size, layer size, plane or surface, or volume.

- 13 044215 total frame or video size. To signal to the decoder how the data has been encoded, a flag may be passed in the data header that the data is encoded using Huffman encoding, RLE encoding, or both. In an alternative implementation, the decoder may be able to determine from characteristics of the data that the data has been encoded using a particular encoding operation. For example, as discussed below, the data may be divided into a header and a data portion, where canonical Huffman encoding is used to signal the code lengths of the encoded characters.

Canonical Huffman-encoded data contains a part that tells the decoder the length of the code used for each symbol, and a part that contains a bitstream representing the encoded data. In the specific implementation proposed herein, code lengths may be reported in the header portion and data lengths may be reported in the data portion. Preferably, the header portion will be signaled for each surface, but may be signaled for each block or other division depending on the configuration.

In the proposed example, the header may differ depending on the number of non-zero codes encoded. The number of non-zero codes to be encoded (eg, for each surface or block) may be compared with a threshold and header used based on the comparison. For example, if there are more than 31 non-zero code characters, the header may sequentially indicate all the characters, starting with a predetermined signal such as 0. In order, the length of each character may be signaled. If there are fewer than 31 non-zero code characters, each character value may be signaled in a header with the corresponding code length for that character.

In fig. Figures 13-16 illustrate specific implementations of header formats and how code lengths can be written to a stream header depending on the number of non-zero codes.

In fig. Figure 13 illustrates a situation where there may be more than 31 non-zero characters in the data. The header includes a minimum code length and a maximum code length. The code length for each character is sent sequentially. The flag indicates that the length of the character is not zero. The code length bits are then sent as the difference between the code length and the minimum signal length. This reduces the overall size of the header.

In fig. 14 illustrates a header similar to the header illustrated in FIG. 13, but used where there are fewer than 31 non-zero codes. The header further includes the number of characters in the data, followed by the value of the character and the codeword length for that character, again sent as a difference.

In fig. Figures 15 and 16 illustrate additional headers that need to be sent in special cases. For example, if all frequencies are zero, the stream header may be as illustrated in FIG. 14, specifying two values 31 in the minimum and maximum length fields to indicate the exception. If there is only one code in the Huffman tree, the stream header could be as shown in Figure 16, using the value 0 in the minimum and maximum length fields to indicate the exception, followed by the character value to be used.

In this last example, where there is only one character value, this may indicate that there is only one data value in the residual data.

Thus, the encoding process can be summarized as follows:

Residual data analysis to determine data values and successive counts of zero values.

Generates a character set in which each character is a byte, and each byte contains either a data value or a series of zeros, and specifies the next character in the character set. Symbols may contain an overflow bit, indicating that the next symbol includes part of the data value included in the current symbol, or a run bit, indicating that the next symbol is a series of zeros.

Convert each fixed-length character into a variable code using canonical Huffman encoding. Canonical Huffman coding analyzes characters to identify the frequency with which each character occurs in a set of characters, and assigns a code to the character based on the frequency and value of the character (for the same code length).

Generate and output a set of code lengths, each associated with a symbol. The code length is the length of each code assigned to each character.

Combining variable length codes into a bitstream.

Output the encoded bitstream.

In the particular implementation described, it should be noted that the maximum code length depends on the number of symbols encoded and the number of samples used to obtain the Huffman frequency table. For N characters, the maximum code length is N-1. However, for a symbol to have a k-bit Huffman code, the number of samples used to output the frequency table must be at least:

- 14 044215

where Fi is the i-th Fibonacci number.

For example, for 8-bit symbols, the theoretical maximum code length is 255. However, for HD 1080p video, the maximum number of samples used to output the frequency table for the RLE residual data context is 1920x1080/4=518,400, which is between S26 and S27. Therefore, in this example, no character can have a Huffman code greater than 26 bits. For 4K this number increases to 29 bits.

For completeness, FIG. 17 illustrates an example of Huffman character set encoding, in this example the characters are alphanumeric. As noted above, the Huffman code is an optimal prefix code that can be used for lossless data compression. A prefix code is a code system for which the system does not have a code word that is a prefix of any other code.

To find the Huffman code for a given set of characters, you need to create a Huffman tree.

Symbols first by frequency,

Symbol Frequency A 3 IN 8 WITH 10 D 15 E 20 F 43

The bottom two elements are removed from the list and turned into leaves with a parent node whose frequency is equal to the sum of the frequencies of the bottom two elements. A partial tree is illustrated in FIG. 17a.

The cycle then repeats, combining the two lowest elements, as illustrated in FIG. 17b.

New list:

Symbol Frequency D 15 E 20 * 21 F 43

This is repeated until there is only one element left in the list, as illustrated in FIG. 17c, , 17d, 17e and in tables.

Symbol Frequency * 21 * 35 F 43

Symbol Frequency F 43 * 56

Symbol Frequency * 99

- 15 044215

After constructing a tree to generate a Huffman code for a character, the triple traverses from the root to that character, outputting 0 each time the left branch is taken and 1 each time the right branch is taken. In the example above, this produces the following code:

The code length of a character is the length of its corresponding code.

To decode the Huffman code, the tree is traversed starting at the root, choosing the left path if a 0 is read and the right path if a 1 is read. The character is found when a leaf is struck.

As described earlier in the document, RLE symbols may be encoded using Huffman encoding. The preferred example uses canonical Huffman encoding. An implementation of canonical Huffman encoding may use a Huffman encoding procedure and convert the resulting code into canonical Huffman codes. That is, the table is rearranged so that like lengths are sequential in the same order as the characters they represent, and so that the later code is always higher in value than the earlier. If the characters are in alphabetical order, they can be rearranged in alphabetical order. If the symbols are values, they may be in sequential value order, and the corresponding codewords are modified to meet the above restrictions. Canonical Huffman coding and/or other Huffman coding approaches described herein may differ from the base example illustrated in FIG. 17a-17e.

In the examples described above herein, a Huffman encoding operation may be applied to data symbols encoded using a modified run length encoding operation. The next step is to create a frequency table for each RLE context or state. Each character type encoded using the RLE encoding operation can have its own set of Huffman codes. An implementation may have a different Huffman encoder for each RLE context or state.

It is assumed that one stream header can be sent for each RLE context or symbol type, that is, multiple stream headers can indicate code lengths for each code set, ie, for each Huffman encoder or frequency table.

Below is an example of the specific steps involved in implementing an encoder. In one implementation, encoding the data output from RLE is done in three main steps:

1. Initializing encoders (for example, using the InitialiseEncode function):

A. initializing each encoder (one per RLE state) with the corresponding frequency table created by the RLE;

b. creating a Huffman tree;

V. calculating the code length of each character; And

d. determination of the minimum and maximum code length.

2. Write the code length and code table into the stream header (for example, using the WriteCodeLengths function) for each encoder:

A. assigning codes to symbols (for example, using the AssignCodes function). Note that the function used to assign character codes is slightly different from the example illustrated in FIG. 19a-19e above, since it ensures sequential execution of all codes of a given length, i.e. uses canonical Huffman coding;

b. recording the minimum and maximum code length in the stream header; And

V. writing the code lengths of each character to the stream.

3. RLE data encoding:

A. assignment of the current RLE context RLC_RESIDUAL_LSB;

b. encoding the current character in the input stream using an encoder appropriate for the current context;

V. using the RLE state machine to obtain the next context (see FIG. 20). If this is not the last character of the stream, go to b; And

d. If the RLE data is only one block and the encoded stream is larger than the RLE, store the RLE encoded stream rather than the Huffman encoded stream.

For each RLE block, Huffman encoders produce a corresponding Huffman encoded part.

- 16 044215

Thus, the result of the encoding process described here is either a Huffman-encoded bitstream or a run-length-encoded byte stream. Thus, the corresponding decoder uses the corresponding Huffman decoding operation in the reverse manner of the encoding operation. However, the decoding operation described below has nuances to improve efficiency and adapt to the specifics of the encoding operation described earlier in the document.

When the encoder signals in a header or other configuration metadata that an RLE or Huffman encoding operation was used, the decoder may first identify that a Huffman decoding operation should be applied to the stream. Just as described above, the decoder can identify from the data stream whether Huffman coding was used by determining the number of parts of the stream. If there is a header part and a data part, then the Huffman decoding operation must be applied. If there is only part of the data in the stream, then only part of the RLE decoding can be applied.

The entropy decoder performs inverse decoding transformations. In this example, Huffman decoding is followed by run length decoding.

The following example describes a decoding process in which a bitstream has been encoded using the canonical Huffman encoding operation and the run-length encoding operation as described above in the stream encoding example. However, it should be understood that Huffman encoding operations and run length encoding operations can be used separately to decode streams encoded in a different manner.

The input to the process is an encoded bitstream. The bitstream can be obtained from a stored file or streamed locally or remotely. An encoded bit stream is a sequence of sequential bits with no immediately discernible structure. Only after applying the Huffman encoding operation to the bit stream can a sequence of characters be output.

Thus, the process first applies a Huffman encoding operation to the bitstream.

The first encoded character is assumed to be a data value type character. Thus, if a Huffman encoding operation uses different frequency tables or parameters, the Huffman encoding operation can use the correct codebook for the symbol type.

A canonical Huffman encoding operation must first extract suitable encoding parameters or metadata to facilitate decoding of the bitstream. In the example here, the parameters are a set of code lengths extracted from the stream header. For simplicity, a single set of code lengths exchanged between the encoder and decoder will be described, but note that, as above, multiple sets of code lengths may be signaled, so that an encoding operation may use different parameters for each type of symbol it expects to decode.

The encoding operation will assign the code lengths received in the stream header to the corresponding symbol. As noted above, the stream header can be sent in different types. If the stream header includes a set of code lengths with corresponding symbols, each code length can be associated with a corresponding symbol value. If code lengths are sent sequentially, the decoder can associate each received code length with a symbol in a predetermined order. For example, code lengths can be extracted in the order of 3, 4, 6, 2, etc. The encoding process can then associate each length with a corresponding character. Here the order is sequential - (character, length)-(0.3) (1.4) (3.6) (4.2).

As illustrated in FIG. 15, some symbols may not be sent, but a flag may indicate that the symbol has a corresponding zero code length, that is, the symbol does not exist in the bitstream to be decoded (or is not used).

The canonical Huffman encoding operation can then assign a code to each character based on the code length. For example, if the code length is 2, the code for this character will be '1x'. Here x indicates that the value is not significant. In certain implementations the code will be '10'.

If the lengths are identical, the canonical Huffman encoding operation assigns codes based on the sequential order of the symbols. Each code is assigned in such a way that as the bit stream is analyzed, the decoder can continue to check the next bit until there is only one possible code. For example, the first consecutive character of length 4 may be assigned code 1110, and the second consecutive character of length 4 may be assigned code 1111. Thus, when analyzing the bitstream, if the first bits of the bitstream are 1110x, it is only possible to encode the first consecutive character of length 4 with a bitstream .

Accordingly, once the encoding operation has established the set of codes associated with each symbol, the encoding operation can proceed to parse the bitstream. In some embodiments, the encoding operation will construct a tree to establish the symbol associated with the bitstream code. That is, the encoding operation will take each bit of the bitstream and traverse the tree according to the value of the bit in the bitstream until a leaf is found. Once a sheet is found, the symbol associated with the sheet is displayed. The process continues at the root of the tree

- 17 044215 with the next bit of the bitstream. Thus, the encoding operation can output a set of symbols derived from a set of codes stored in the encoded bitstream. In preferred embodiments, each character is a byte, as described elsewhere herein.

The character set can then be passed to the run length encoding operation. The run-length encoding operation identifies the character type and parses the character to extract the data value or run of zeros. Based on the data values and the series of zeros, the operation can recreate the original residual data that was encoded.

As noted earlier in this document, the output of Huffman encoding is likely to be a set of symbols. The task in the next stage of decoding is to extract relevant information from these symbols, given that each symbol contains data in a different format, and each symbol will represent different information, even though the information will not be immediately distinguishable from the symbol or byte .

In preferred examples, the encoding operation is accessed by a state machine, as illustrated in FIG. 18. In general, the encoding operation first assumes that the first character is a data value type (the data value can, of course, be 0). From this, the encoding operation can identify whether the byte includes an overflow flag or a run flag. The overflow and trigger flags are described above in the document and illustrated in FIG. 10.

An encoding operation may first check the least significant bit of a character (or byte). In this context, it is an overflow flag (or bit). If the least significant bit is set, the encoding operation determines that the next character will also be a data value and will be of type RLC_RESIDUAL_MSB. The remaining bits of the character will be the least significant bits of the data value.

The encoding process proceeds to parse the next character and extract the least significant bits as the remainder of the data value. The bits of the first character can be combined with the bits of the second character to reconstruct the data value.

In this current symbol illustrated in FIG. 11, there will also be an execution flag, here is the most significant bit. If this is set, the next character will be the start character rather than the data character.

In the trigger symbol illustrated in FIG. 12, the encoding operation checks the most significant bit to indicate whether the next symbol is a start symbol or a data symbol, and extracts the remaining bits as a series of zeros. That is, the maximum series of 127 zeros.

If a data character indicates no overflow (in the overflow flag, here the least significant bit), then the character will also contain in its most significant bit an execute bit, and the encoding operation will be able to determine from this bit that the next character in the set is a run character or a data. Thus, the encoding operation can extract the data value from bits 6-1. There are 31 data values available here without overflow.

As already noted, the state machine illustrated in FIG. 18 simply illustrates the process.

Starting with the RLC_RESIDUAL_LSB character, if the overflow bit=0 and the execute bit=0, then the next character will be the RLC_RESIDUAL_LSB character. If the overflow bit=1, then the next character will be RLC_RESIDUAL_MSB. If overflow bit=1, there will be no progress bit. If run bit=1 and overflow bit=0, then the next bit will be the RLC_ZERO_RUN character.

In an RLC symbol RLC_RESIDUAL_MSB, if the execute bit is 0, the next symbol will be the RLC_RESIDUAL_LSB symbol. If the run bit is 1, the next character will be the RLC_ZERO_RUN character.

In the RLC_ZERO_RUN symbol, if the run bit is 0, the next bit will be the RLC_RESIDUAL_LSB symbol. If the run bit is 1, the next bit will be the RLC_ZERO_RUN character.

Of course, bits can be inverted (0/1, 1/0, etc.) without loss of functionality. Likewise, positions within flag characters or bytes are merely illustrative.

The run-length encoding operation can identify the next character in a character set and extract either a data value or a run of zeros. The encoding operation can then combine these values and zeros to recreate the residual data. The order may be in order of extraction or, alternatively, in some predetermined order.

Thus, the encoding operation can output residual data that was encoded into the byte stream.

It has been described earlier in this document how several metadata or encoding parameters can be used during the encoding process. On the decoding side, the encoding operation may include feedback between operations. That is, the expected next character can be extracted from the current character (eg, using overflow and execute bits), and the expected next character can be passed to a Huffman encoding operation.

The Huffman encoding operation may optionally generate a separate codebook

- 18 044215 for each character type (and extract multiple stream headers or build a table of multiple codes and characters).

Assuming that the first character will be a data value, the Huffman encoding operation decodes the first code to match a character of that type. From a matched symbol, the encoding operation can identify the overflow bit and/or the execute bit and identify the next symbol type. The Huffman encoding operation can then use the appropriate codebook for that character type to extract the next code in the bitstream. The process carries over in this iterative manner, using the currently decoded symbol to extract the next symbol indication and modify the codebooks accordingly.

It has been described above in this document how a decoding operation can combine a Huffman encoding operation, preferably a canonical Huffman encoding operation, and a run length encoding operation to reconstruct residual data from the encoded bit stream. It should be understood that run-length encoding techniques may be applied to a byte stream that has not been encoded using a Huffman encoding operation. Similarly, the Huffman encoding operation can be applied without the subsequent run length encoding step.

An example of specific steps in implementing a decoder is described below. In the example implementation, if a stream consists of more than one part, the following steps are performed:

1. Reading code lengths from the stream header (for example, using the ReadCodeLengths function):

A. setting code lengths for each character;

b. Assigning codes to characters based on code lengths (for example, using the AssignCodes function); and c. generating a table to search for subsets of codes of the same length. Each table element records the first index of a given length and the corresponding code (firstldx, firstCode).

2. Decoding RLE data:

A. Assigning an RLE context to the RLC_RESIDUAL_LSB symbol.

b. Decoding the current code, searching for the correct code length in the generated table and indexing the array of codes using: firstldx -(current_code - firstCode). This works because all codes for a given length are sequential in the construction of the Huffman tree.

V. Using the RLE state machine to obtain the next context (see Fig. 18). If the stream is not empty, go to b.

The run length decoder reads run length encoded data one byte at a time. By construction, the context of the first data byte is guaranteed to be RLC_RESIDUAL_LSB. The decoder uses the state machine illustrated in FIG. 18 to determine the context of the next data byte. The context tells the decoder how to interpret the current data byte, as described earlier in this document.

Note that in this particular implementation example, the run-length state machine is also used by the Huffman encoding and decoding process to know which Huffman code to use for the current symbol or codeword.

In both an encoder and a decoder, for example, implemented in a streaming server or client device, or in a client device decoding data from a data store, the methods and processes described herein may be embodied in code (e.g., program code ) and/or data. The encoder and decoder may be implemented in hardware or software, which is well known in the field of data compression. For example, hardware acceleration using a specially programmed graphics processing unit (GPU) or a specially designed field programmable gate array (FPGA) can provide some efficiency. For completeness, such code and data may be stored on one or more computer-readable media, which may comprise any device or medium that can store code and/or data for use by a computer system. When a computer system reads and executes code and/or data stored on a computer-readable medium, the computer system executes methods and processes embodied in data structures and code stored on the computer-readable medium. In some embodiments, one or more steps of the methods and processes described herein may be performed by a processor (eg, a processor of a computer system or storage system).

In general, any functionality described in this text or illustrated in the drawings may be implemented using software, firmware (eg, fixed logic circuits), programmable or non-programmable hardware, or a combination of these implementations. The terms component or feature, as used herein, typically represent software, firmware, hardware, or a combination thereof. For example, when implemented in software, the terms component or function may refer to software code that performs specific tasks when executed on a processing device or devices. The illustrated division of components and functions into separate blocks may reflect any actual or conceptual physical grouping and distribution of such software

- 19 044215 provision and/or equipment and tasks.

The present application has described a method for encoding and decoding a signal, in particular a video signal and/or an image signal.

In particular, a method of encoding a signal is described, including receiving an input frame and processing the input frame to generate at least one first set of residual data, said residual data allowing a decoder to reconstruct an original frame from a reference reconstructed frame.

In one embodiment, the method includes obtaining a reconstructed frame from a decoded frame obtained from a decoding module, wherein the decoding module is configured to generate said decoded frame by decoding a first encoded frame that has been encoded according to the first encoding method. The method further comprises downsampling the input frame to obtain a downsampled frame and transmitting said downsampling frame to an encoding module configured to encode said downsampling frame in accordance with a first encoding method to generate a first encoded frame. Obtaining the reconstructed frame may further include upsampling the decoded frame to generate the reconstructed frame.

In another embodiment, the method includes obtaining a reconstructed frame from a combination of a second set of residual data and a decoded frame obtained from a decoding module, wherein the decoding module is configured to generate said decoded frame by decoding a first encoded frame that has been encoded according to the first encoding method. The method further includes downsampling the input frame to obtain a downsampled frame and transmitting said downsampling frame to an encoding module configured to encode said downsampling frame in accordance with a first encoding method to generate a first encoded frame. The method further includes generating said second set of residual data by taking the difference between the decoded frame and the downsampled frame. The method further includes encoding said second set of residual data to create a first set of encoded residual data. Encoding of said second set of residual data may be performed according to a second encoding method. The second encoding method involves transforming the second set of residual data into a transformed second set of residual data. Transforming the second residual data set includes selecting a subset of the second residual data set and applying a transformation to said subset to create a corresponding subset of the transformed second residual data set. One of a subset of the transformed second residual data set may be obtained by averaging a subset of the second residual data set. Obtaining the reconstructed frame may further include upsampling the combination of the second set of residual data and the decoded frame to generate the reconstructed frame.

In one embodiment, generating the at least one set of residual data includes taking the difference between a reference reconstructed frame and an input frame. The method further includes encoding said first set of residual data to create a first set of encoded residual data. Encoding of said first set of residual data may be performed according to a third encoding method. The third encoding method involves transforming the first residual data set into a transformed first residual data set. Transforming the first residual data set includes selecting a subset of the first residual data set and applying a transformation to said subset to generate a corresponding subset of the transformed first residual data set. One of the subsets of the transformed first residual data set may be obtained by the difference between the average of the subset of the input frame and the corresponding element of the combination of the second residual data set and the decoded frame.

In particular, a method of decoding a signal is described, comprising receiving an encoded frame and at least one set of encoded residual data. The first encoded frame may be encoded using a first encoding method.

The at least one set of residual data may be encoded using a second and/or third encoding method.

The method further includes transmitting the first encoded frame to a decoding module, wherein the decoding module is configured to generate a decoded frame by decoding the encoded frame that has been encoded according to the first encoding method.

The method may further include decoding the at least one set of encoded residual data according to a corresponding encoding method used to encode it.

In one embodiment, the first set of encoded residual data is decoded by applying a second decoding method corresponding to said second encoding method to obtain a first set of decoded residual data. The method further comprises combining the first set of residual data with the decoded frame to obtain a combined frame. The method further comprises upsampling the combined frame to obtain a reference decoded frame.

The method further includes decoding the second set of encoded residual data by applying a third decoding method corresponding to said third encoding method to obtain a second set of decoded residual data. The method further includes combining the second set of decoded residual data with the reference decoded frame to obtain a reconstructed frame.

In another embodiment, the method includes upsampling a decoded frame to obtain a reference decoded frame.

The method further includes decoding the encoded residual data set by applying a second or third decoding method corresponding to the second or third encoding method to obtain a decoded residual data set. The method further comprises combining the set of decoded residual data with a reference decoded frame to obtain a reconstructed frame.

The following statements describe preferred or illustrative aspects described and illustrated herein.

A method of encoding input video into a plurality of coded streams such that the coded streams can be combined to reconstruct the input video, the method comprising:

receiving input video at full resolution;

downsampling input full resolution video to create downsampled video;

downsampling the video using the first codec to create a base code stream;

recover video from encoded video to create reconstructed video;

comparing the recovered video with the original video and creating one or more additionally encoded streams based on the comparison.

The input video compared to the reconstructed video may be downsampled video.

According to one example of a method, comparing a reconstructed video to an input video includes: comparing the reconstructed video to a downsampled video to create a first set of residual data, and wherein creating one or more additional encoded streams includes encoding the first set of residual data to create a coded first level flow.

The input video versus the reconstructed video may be a full resolution input video, and the reconstructed video may be upsampled.

According to one example method, comparing the reconstructed video to an input video includes: upsampling the reconstructed video to create an upsampled reconstructed video, and comparing the reconstructed upsampling video and the input full resolution video to create a second set of residual data, and thereby creating one or more additional codestreams includes encoding a second difference to create a second layer codestream.

Accordingly, in one example, the method involves generating a base codestream, a first layer codestream, and a second layer codestream according to the example methods described above. Each of the first layer coded stream and the second layer coded stream may contain extension data used by the decoder to extend the base coded stream.

Residual data can act as differences between two videos or frames.

Encoded streams may be accompanied by one or more headers that contain parameters indicating aspects of the encoding process to facilitate decoding. For example, the headers may contain the codec used, the transform applied, the quantization applied, and/or other decoding parameters.

The document has described above how a ranking and selection step can be applied to the residual data, a time coefficient subtraction step can be performed, and quantization can be adapted. Each of these steps can be predefined and selectively applied, or can be applied based on analysis of the incoming video, downsampled video, reconstructed video, upsampled video, or any combination of the above to improve the overall performance of the encoder. Stages can be applied selectively based on a predefined set of rules or applied directly based on analysis or performance feedback.

-

Claims (15)

One example method further includes: sending an underlying encoded stream. One example method further includes: sending a first layer encoded stream. One example method further includes: sending a second layer encoded stream. According to a further aspect of the present invention, a decoding method is provided. A method for decoding a plurality of encoded streams into a reconstructed output video, comprising: receiving a first base code stream; decoding a first base code stream according to a first codec to generate a first output video; receiving one or more additionally encoded streams; decoding one or more additionally encoded streams to generate a set of residual data; and combining the set of residual data with the first video to generate a decoded video. In one example, the method comprises retrieving a plurality of decoding parameters from a header. Decoding parameters may indicate which procedural steps were included in the encoding process. In one example, a method may include receiving a first layer encoded stream and receiving a second layer encoded stream. In this example, the step of decoding one or more additionally encoded streams to generate a residual data set includes: decoding the first layer encoded stream to obtain a first set of residual data; wherein the step of combining the residual data set with the first video to generate a decoded video includes: combining the first set of residual data with the first output video to generate a second output video; upsampling the second output video to create a second upsampled output video; decoding the second layer encoded stream to obtain a second set of residual data, and combining the second set of residual data with a second output video to produce a reconstructed output video. The method may further include displaying or outputting the reconstructed output. CLAIM 1. A method for encoding a video signal, including: obtaining an input frame (100); processing the input frame (100) to generate residual data (110, 119), wherein the residual data forms part of the extended stream and allows the decoder to reconstruct the input frame based on the reference reconstructed frame; applying a run-length encoding operation to the residual data (110, 119), wherein the run-length encoding operation includes generating a run-length-encoded byte stream containing a set of characters representing non-zero data values of the residual data, and counts of consecutive zero values of the residual data; and wherein the method is characterized by the following steps: applying a canonical Huffman encoding operation to a set of characters to generate Huffman encoded data comprising a set of codes representing a run-length encoded byte stream; comparing the data size of at least a run length encoded portion of the byte stream with the data size of at least a corresponding portion of the Huffman encoded data; and outputting the run length encoded byte stream or the Huffman encoded data to the output bit stream (102, 103) based on which one has the smaller data size. 2. The method of claim 1, wherein the operation of encoding run lengths includes: encoding non-zero data values of the residual data into at least a first symbol type and encoding counts of consecutive zero values into a second symbol type such that the residual data is encoded as a sequence of symbols of different types. . 3. The method of claim 1 or claim 2, wherein the run length encoding operation comprises: encoding the data values of the residual data into a first symbol type and a third symbol type, wherein the first and third symbol types each contain a portion of the data value such that the portions may be combined in the decoder to reconstruct the data values. 4. The method according to claim 3, wherein the run length encoding operation includes: comparing the size of each residual data value to be encoded with a threshold value and encoding - 22 044215 encoding each data value into a first character type if the size is below the threshold, and encoding part of each data value into the first character type and part of each data value into a third character type if the size is above the threshold. 5. The method of claim 4, further comprising: if the size exceeds a threshold value, setting a flag in the symbol of the first symbol type indicating a portion of the represented data value is encoded into an additional symbol of the third symbol type. 6. The method according to any one of claims 2 to 5, which further includes: inserting a flag into each character indicating the type of character encoded next in the run-length encoded byte stream. 7. The method of any one of the preceding claims, further comprising: adding a flag to the configuration metadata accompanying the output bitstream indicating whether the bitstream represents a run-length encoded byte stream or Huffman encoded data. 8. The method as claimed in any one of the preceding claims, wherein the Huffman encoding operation comprises: generating a separate frequency table for symbols of the first symbol type and symbols of the second symbol type. 9. The method of any one of the preceding claims, further comprising: generating a stream header comprising an indication of a plurality of code lengths such that the decoder can output the code lengths and corresponding symbols for a canonical Huffman decoding operation. 10. The method of claim 9, wherein the stream header is one of the following: a first type of stream header comprising an indication of a character associated with a corresponding code length of the plurality of code lengths. 11. The method of claim 9, wherein the stream header is a second stream header type, wherein for the second stream header type, the method further includes ordering a plurality of code lengths in the stream header based on a predetermined order of symbols corresponding to each of the code lengths such that the lengths codes can be associated with the corresponding symbol in the decoder. 12. The method of claim 11, wherein the second stream header type further comprises a flag indicating that a character in the predetermined order of a possible character set does not exist in the character set in the run-length encoded byte stream. 13. The method as claimed in any one of claims 10 to 12, further comprising: comparing the number of unique codes in the Huffman-encoded data with a threshold value and generating a first stream header type or a second stream header type based on the comparison. 14. A method for decoding a video signal, including: receiving encoded bitstream (102, 103); decoding the encoded bit stream (102, 103) to generate residual data for the extended stream; and recovering the original video frame from the residual data and a reference reconstructed frame, the step of decoding the encoded bit stream (102, 103) comprising: applying a run length encoding operation to generate residual data, wherein the run length encoding operation includes: identifying a set of characters representing non-zero values of the residual data data and a set of characters representing counts of successive zero values of the residual data; analyzing a set of symbols to obtain non-zero data values of the residual data and counting consecutive zero values, and generating residual data from the non-zero data values and counts of consecutive zero values, the method being characterized in that the step of decoding the encoded bitstream includes: retrieving a flag from the configuration metadata accompanying the encoded bitstream (102, 103) indicating whether the encoded bitstream contains a run length encoded byte stream or Huffman encoded data; and selectively applying a canonical Huffman encoding operation to the encoded bitstream (102, 103) based on the flag to generate a set of symbols representing non-zero values of the residual data data and a set of symbols representing counts of successive zero values of the residual data, wherein the step of applying the length encoding operation series to generate residual data is performed on character sets. 15. The method according to claim 14, in which the operation of encoding run lengths includes: identifying symbols of a first symbol type representing non-zero values of the residual data data; identification of symbols of a second symbol type representing counts of consecutive zero values, such that the sequence of symbols of different types is decoded to generate the remaining