Flexible Huffman tree approximation for low-latency coding

Abstract

Techniques are described for encoding symbols using a new algorithm that provides a flexible Huffman tree approximation and can be used for low-latency encoding. For example, the new algorithm can perform encoding using one or more of the following stages: Shannon-based binning, code space optimization, tree completion, and code allocation.

Description

Background Art

[0001] Since their introduction, Huffman trees have become the de facto standard for optimized coding. Their applications span a wide range, from real-time multimedia to data center storage. The Huffman structure is well understood, and numerous research papers have explored its properties and implementation in both software and hardware. In particular, Huffman coding, from a formal algorithmic perspective, is optimal within the constraints of integer-length codes.

[0002] Although Huffman coding is optimal within the constraints of integer-length codes, Huffman coding can be inefficient in terms of the computational resources required to implement the algorithm. Additionally, Huffman coding poses interesting challenges for hardware implementation. Summary of the Invention

[0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] Techniques are described for encoding symbols using a new algorithm that provides a flexible Huffman tree approximation and can be used for low-latency encoding. For example, the new algorithm can perform encoding using one or more of the following stages: Shannon-based binning, code space optimization, tree completion, and code allocation.

[0005] As described herein, various other features and advantages may be incorporated into these techniques as desired. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a block diagram depicting an example process for encoding data using a flexible Huffman tree approximation.

[0007] Figures 2A-2D Depicted is a block diagram of an example process for executing a new algorithm for encoding symbols using a flexible Huffman tree approximation.

[0008] Figure 3 is a flow chart of an example method for encoding symbols.

[0009] Figure 4 is a flow chart of an example method for encoding symbols.

[0010] Figure 5 is a diagram of an example computing system in which some described embodiments may be implemented.

[0011] Figure 6is an example cloud support environment that can be used with the techniques described in this article. DETAILED DESCRIPTION

[0012] Overview

[0013] As described herein, various techniques and technical solutions can be applied to approximate the Huffman coding algorithm (also referred to as the Huffman algorithm, Huffman decoding, or Huffman coding) without using the Huffman coding algorithm. For example, these techniques can be applied to encode (e.g., compress) data, which results in compression that is close to (e.g., within one percent) that of Huffman coding but is more efficient (e.g., in terms of computing resources, latency, hardware implementation, etc.) than Huffman coding.

[0014] The technology involves a new algorithm for approximating the Huffman algorithm, also known as Quantized Interval Huffman Approximation (QuIHA).

[0015] Depending on the implementation, the new algorithm may have one or more of the following properties:

[0016] * It produces good compression ratios, typically within 0.05% of true Huffman coding, which is provably optimal.

[0017] *It is suitable for high-speed implementation in field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0018] *For the two-pass compression algorithm, it is a drop-in replacement for the Huffman algorithm and does not require modifications to the decompressor or the compression format specification.

[0019] The new algorithm can be applied to code symbols generated from input data. For example, the input data can be a file to be compressed, data to be sent via a network, etc. The input data can be any type of data (e.g., text data, binary data, video data, audio data, etc.). The new algorithm is a lossless compression algorithm in which symbols are encoded (e.g., compressed) in a lossless manner. The new algorithm generates symbols encoded with prefix codes, which are 1 bit or more long, similar to Huffman coding. Prefix codes are terms used to encode symbols using variable bit length codes.

[0020] For example, the new algorithm can be applied as part of an encoding or compression process. For example, input data can be received (e.g., a data file, streaming media, etc.). The input data can be processed to generate symbols (e.g., as an initial stage of a deflate compression algorithm, as part of a video or image encoder, etc.). The symbols (e.g., including symbol counts and frequency information) can be processed by the new algorithm (e.g., including performing Shannon-based binning, code space optimization, tree completion, and / or performing other techniques associated with the new algorithm), and codes (e.g., prefix codes) can be assigned based on the processed symbols. The input data can then be output in an encoded or compressed format using the codes (e.g., prefix codes) generated from the new algorithm.

[0021] The new process is based on two basic realizations. First, symbols with similar frequencies should be likely to be assigned the same or similar code lengths. Therefore, symbols can be organized into bins based on symbol frequency (a Shannon-based binning process is described further below). Second, the symbol length assignments are actually independent of the symbol IDs themselves. Therefore, a count of the symbols in each bin can be used rather than a list or set of symbols, and entire bins can be processed at once. Processing entire bins of symbols at once is more efficient in terms of computational resources than processing symbols on a symbol-by-symbol basis as is done with Huffman coding.

[0022] The new algorithm introduces the concept of code space. The code space covers all possible symbol encodings within a certain maximum code length constraint. For example, Xpress8 (Xpress8 is composed of The compression technique provided by ) has a maximum code length of 15 bits, so the code space constraint 2 15 = 32K = 32,768 possible codes of bit length 15. A 1b (one-bit) symbol uses half the code (16K code), a 2b (two-bit) symbol uses a quarter the code (8K code), etc. Table 1 below illustrates the used code space for each bit length up to 15.

[0023]

[0024]

[0025] Table 1

[0026] In some implementations, the new algorithm is implemented in four stages. In the first stage (Shannon-based binning), symbols are assigned initial code lengths based on the original Shannon algorithm. This algorithm may underutilize the code space and is suboptimal compared to the Huffman algorithm. As symbols are processed, they are placed into code length bins (CLBs) based on their Shannon codes. The results are further improved by breaking the CLBs into quantization intervals (QIs) based on symbol frequency.

[0027] Because the first phase underutilizes the code space, the subsequent code space optimization phase improves code length allocation by lifting some symbols from their initial CLB to above the CLB, essentially reducing their code length by 1 bit. This is where the QI comes in. It's more optimal to shorten more frequently occurring symbols. By preferentially lifting the most frequent symbols in the QI, the algorithm achieves a near-optimal compression ratio.

[0028] The results of code space optimization are quite good. However, the code space optimization phase is still an approximate heuristic that may not fully utilize the code space. Some decompressors, such as Xpress8, require the code space to be fully partitioned, which is equivalent to saying that the symbol code tree is a full binary tree where all parent nodes have two children. The third phase, tree completion, fixes the resulting tree and can achieve slight improvements in compression ratio. These improvements are so slight that this phase can be considered optional unless required by the decompression algorithm.

[0029] The final stage is code assignment. The symbols are traversed and the actual prefix codes are assigned. This stage follows the standard procedure, given the previously calculated code lengths for each symbol.

[0030] Below is an overview of some potential features of the new algorithm. Depending on the implementation, one or more of the following features may be implemented.

[0031] * Uses an approximation of the Huffman algorithm, resulting in a slightly reduced compression ratio but a much faster hardware implementation.

[0032] * Organize symbols into bins based on symbol frequency. Assign symbols in the same bin the same / similar code length.

[0033] *Use simple Shannon codes for initial code length estimation.

[0034] *Further optimize code length based on symbol frequency binning.

[0035] * Further optimize code length to complete the Huffman tree where necessary.

[0036] Shannon-based binning

[0037] In the techniques described herein, Shannon-based binning is performed as part of the new algorithm. In some implementations, Shannon-based binning is performed in the first phase of the new algorithm.

[0038] The new algorithm operates on symbols. Symbols are received as input to the new algorithm. Symbols can represent words (e.g., character bytes) and / or other letters (e.g., lengths, distance pairs). In some implementations, the symbols are generated using the initial stages of the Deflate compression algorithm. The initial stages of the Deflate compression algorithm are known as Lemple-Zif 77 (also known as LZ77). For example, the new algorithm can receive symbols from the initial stages of the Deflate compression algorithm and, instead of performing Huffman encoding, encode the symbols using the new algorithmic techniques described herein. In other implementations, the symbols are generated using another process (e.g., from the initial stages of another compression algorithm).

[0039] Shannon-based binning is performed to determine the initial code length for the symbol and the symbol is placed into a corresponding code length bin (CLB) based on the assigned initial code length. To determine the initial code length, Equation 1 is used to calculate the Shannon code length. The information content I() is then rounded up using a ceiling operation according to Equation 2.

[0040]

[0041] CLB(sym)=ceil(I(sym)) (Equation 2)

[0042] In Equation 1, symCnt[] is the number of occurrences of each symbol, and symTot is the total symbols in the input (e.g., the total number of symbols generated by the initial stage of the Deflate compression algorithm from the input file to be compressed). Note that symbols that do not occur (symCnt[sym] == 0) do not require code allocation and can be skipped.

[0043] In some hardware implementations, symCnt and symTot are calculated on the fly during the LZ77 stage. As each symbol is generated, symTot and SymC[sym] are incremented. The histogram of symbols is thus immediately available at the beginning of symbol table construction.

[0044] For example, the Xpress8 compression format uses 512 symbols (i.e., 512 9-bit symbols). Thus, using Xpress8, symCnt[] contains the number of occurrences of each of the 512 symbols in the input data to be compressed. Other compression formats may use a different number of symbols.

[0045] The number of code length bins corresponds to the maximum code length of the compression format being used. For example, the Xpress8 compression format has a maximum code length of 15 bits. Therefore, when using Xpress8, there are 15 CLBs: one for a 1-bit code, one for a 2-bit code, one for a 3-bit code, and so on. In some implementations, code lengths lower than the maximum code length can be used. For example, if the compression format is less restrictive or provides a more efficient implementation, a lower code length can be used.

[0046] The allocated CLB for a given symbol represents the initial symbol length in bits. In some implementations, the new algorithm keeps track of the remaining code space (e.g., after symbols are allocated to CLBs). The code space is defined by the maximum code length in use. For example, for Xpress8, the maximum code length is 15 bits, and the code space is 32,768 (which is the maximum available code space and represents the maximum number of codes when all codes are 15 bits long). The remaining code space can be tracked using Equation 3.

[0047] rem_code_space -= 2 maximum_code_length-CLB(sym) (Equation 3)

[0048] The remaining code space (rem_code_space or RCS) is initialized to the maximum code space, which in this example is 32,768. Shannon code is, of course, a legitimately implementable code that guarantees that rem_code_space will never become negative. Then, as symbols are assigned to CLBs, the remaining code space is updated. For example, if a symbol is assigned to a 6-bit CLB, the remaining code space is updated: rem_code_space = 32,768 – 512 = 32,256. If the symbol is then assigned to a 4-bit CLB, the remaining code space is updated: rem_code_space = 32,256 – 2,048 = 30,208.

[0049] In some implementations, each CLB is divided into a number of quantization intervals (QIs). Each QI represents a continuous portion of the information content for each CLB. More specifically, a fractional portion of the information content is divided into QIs. In some implementations, the fractional portion is divided equally into a number of QIs. In some implementations, the fractional portion can be divided equally into four QIs using Equation 4.

[0050] QI(sym)3-floor((CLB(sym)-I(sym))*4) (Equation 4) QI 0 contains the most frequent symbol of a given CLB, and QI 3 contains the least frequent symbol of a given CLB. In other implementations, a different number of QIs can be used, or a different process for dividing the fractional part can be used (e.g., other than dividing the fractional part equally).

[0051] During Shannon-based binning, counts may be maintained for the number of symbols assigned to each CLB and / or each QI. In some implementations, the only counts for Shannon-based binning are the number of symbols assigned to each of the QIs for each of the CLBs. For example, if there are 15 CLBs, each with four QIs, then 60 counts may be maintained (e.g., a 15x4 count array).

[0052] Code space optimization

[0053] In the techniques described herein, code space optimization is performed as part of the new algorithm. In some implementations, code space optimization is performed in the second phase of the new algorithm. Code space optimization is performed to shorten symbols to shorter code length bins (e.g., from a given b-bit CLB to b-1-bit CLB). For example, a symbol can be shortened (also referred to as "lifting") by moving the symbol from a 6-bit CLB to a 5-bit CLB (which is the next shorter code length bin). For example, code space optimization can be performed because Shannon-based binning can produce underutilized code space.

[0054] In some implementations, code space optimization is performed after determining (e.g., as maintained during Shannon-based binning) that the remaining code space is greater than 0. If the remaining code space is equal to zero, then code space optimization can be skipped (e.g., the code space is already fully utilized and no symbols need to be moved).

[0055] In some implementations, the remaining code space is updated during code space optimization. For example, when a symbol is moved to the next smaller CLB, the remaining code space is updated according to Equation 5. Code space optimization can proceed until the remaining code space is close to or equal to zero.

[0056] rem_code_space -= 2 max-b (Equation 5)

[0057] In Equation 5, max is the maximum code length (e.g., 15 bits for Xpress8) and "b" is the number of bits in the CLB we are moving from. For example, if we are moving a symbol from a 6-bit CLB to a 5-bit CLB, the remaining code space will be reduced by 512.

[0058] In some implementations, code space optimization is performed by first lifting symbols in the most frequent QIs. For example, QI 0 can be traversed first in all CLBs starting with CLB 2 (2-bit CLBs; CLB 1 cannot be shortened). For each QI, as many symbols as possible can be shortened so that the code space is not over-allocated (e.g., as maintained by the remaining code space). The following algorithm can be used to shorten symbols in QIs and CLBs.

[0059]

[0060] Note that reduction_per_sym is always a power of two and can be represented by just the exponent rather than an integer as shown. Division becomes a right shift, and multiplication becomes a left shift. As a performance optimization, the loop can be terminated when rem_code_space is zero. Additionally, once rem_code_space < 2 (15-clb) , there is no need to reconsider the low-numbered CLBs.

[0061] Lifting symbols (the ShortenSymbols(...) call) simply involves keeping track of how many symbols have been shortened. A higher-numbered QI can only have shortened symbols if all previous, lower-numbered QIs have been completely shortened. This is because the only thing that will prevent a previous QI from being completely shortened is insufficient remaining code space, which similarly limits later QIs.

[0062] As a result, the number of shortened symbols per QI does not need to be tracked. Instead, this can be accomplished using two fields per CLB. The first field, maxShortenedQi[clb], indicates the largest (least frequent) QI with shortened symbols. The second field, symShortened[clb], indicates how many symbols in this QI are shortened. All QIs smaller than maxShortenedQi are fully shortened. All QIs larger than maxShortenedQi do not have shortened symbols.

[0063]

[0064] Tree Complete

[0065] In the techniques described herein, tree completion can be performed as part of the new algorithm. In some implementations, tree completion is an optional phase. For example, Shannon-based binning and code space optimization phases may still leave the code space underutilized (when represented as a binary tree structure). In other words, the remaining code space may still be non-zero. The code tree interpretation is that a binary tree may not be full binary but contain a parent node with only one child node. Note that all Huffman trees are full binary trees. Some decompressors may expect this property to hold for incoming nodes. It is important to keep in mind that a full binary tree is not necessarily a Huffman (optimal) tree. However, all Huffman trees are full binary trees.

[0066] The tree completion phase promotes nodes lower in the tree to higher levels (lower length), thus filling empty child nodes higher in the tree. The algorithm handles trees of arbitrary shapes, but some constraints can be observed and exploited for efficient hardware implementation. For example, empty Constraints can be placed at any level of the tree except the first level (length 1).

[0067] In some implementations, tree completion considers only the code length of a symbol without considering the corresponding QI. Furthermore, tree completion may shorten a symbol by more than one bit to reduce the residual code space (RCS) to zero more quickly. Tree completion operates on a code length histogram (CLH), which is a per-length cumulative view of QIPops across QIs. Conceptually, tree completion uses a binary representation of the RCS as an indicator of node vacancies and surpluses in the binary code tree. The output of tree completion includes a code length score board (CLSB) that tracks FROM-TO node facilitation counts. The CLSB is used in the final code allocation phase to shorten the code length of symbols.

[0068] In some implementations, the operations outlined below are performed for tree completion:

[0069] Iterate on CLH until RCS! = 0

[0070] 1. Get the MSb of the RCS which provides the result of FLOOR(log2(RCS)); this is the length TO to which the longer length symbols will be upgraded; if RCS is a power of 2 and the CLH entry corresponding to the TO (destination) code length bin is greater than 0, then decrement that length by 1; this length corresponds to the tree level with the node shortage.

[0071] 2. Reduce the RCS by the code space obtained by a single symbol at the TO length.

[0072] 3. Increase the CLH entry for TO length.

[0073] 4. Get the surplus length FROM where symbols are to be removed; this is determined by the LSb of the updated CLH with the constraint that FROM length > TO length; this length corresponds to the tree level of the surplus nodes.

[0074] 5. Reduce the CLH entry of FROM length.

[0075] 6. Updated CLSB to account for upgrades.

[0076] In some implementations, the tree completion phase fills in any missing nodes so that the code space is represented as a full binary tree.

[0077] Code Assignment

[0078] In the techniques described herein, code allocation is performed as part of the new algorithm. In some implementations, code allocation is performed in the final phase of the new algorithm (e.g., phase 3 or phase 4, depending on whether tree completion is performed). During code allocation, the final code length for each symbol can be calculated by recalculating the CLB and QI and following per-QI adjustment information. Code allocation can be performed using a Huffman algorithm (e.g., a Canonical Huffman coding algorithm or another Huffman variant) given the bit length for each symbol.

[0079] In some implementations, the number of symbols of each length is maintained in real time through the previous stage. Therefore, this information is known at the beginning of code allocation without explicitly revisiting the symbols. Given this information, the code space is divided by code length, thereby initializing a code pointer (i.e., a first code) for each of the 15 possible code lengths (or using a different number of possible code lengths, depending on the compression format being used). For each symbol, its code length is recalculated as described herein (e.g., as described at 232), and it is assigned the current code pointer for its length. Its code pointer is then updated to the next code.

[0080] Example Block Diagram

[0081] Figure 1 is a block diagram 100 depicting an example process for encoding data using a new algorithm that implements a flexible Huffman tree approximation. The operations performed by the example process are generally described as a data compression tool 105. However, these operations may be performed by various combinations of software and / or hardware resources.

[0082] In the box Figure 1In the embodiment of the present invention, input data 110 is received. The input data 110 can be any type of data (e.g., text data, binary data, video data, audio data, etc.). At 120, symbol information is generated from the received input data 110. The symbol information can include symbol count and frequency information. In some implementations, the symbol information is generated using the Lemple-Zif 77 (also known as LZ77) algorithm (e.g., as an initial stage of the Deflate compression algorithm).

[0083] At 130, Shannon-based binning is performed. Shannon-based binning is performed to determine an initial code length for the symbol and place the symbol into a corresponding code length bin based on the assigned initial code length. In some implementations, each CLB is divided into a number of QIs. Each QI represents a continuous portion of the CLB based on the Shannon code length.

[0084] Code space optimization is performed at 140. Code space optimization is performed to shorten symbols into shorter code length bins.

[0085] At 150, tree completion is performed. In some implementations, tree completion is an optional phase. Tree completion promotes lower nodes in the tree to higher levels (lower lengths), thus filling higher "holes" in the tree.

[0086] At 160, code allocation is performed. During code allocation, the final code length for each symbol can be calculated (e.g., by recalculating the CLB and QI, and following per-QI adjustment information). Using the symbol information, a prefix code can be generated for encoding the input data 110. In some implementations, the prefix code is generated according to a code allocation portion of a Huffman coding algorithm (e.g., according to a code allocation portion of a canonical Huffman coding algorithm).

[0087] At 170, the input data 110 is encoded using the code assigned at 160. The encoded data is output as compressed data 180.

[0088] In some implementations, one or more of the operations depicted in block diagram 100 are implemented in hardware. For example, a hardware component (eg, an ASIC or FPGA) may implement some or all of the operations as part of a data compression process.

[0089] In some implementations, block diagram 100 is implemented as part of a cloud computing service. For example, a cloud computing service may provide a data storage service. One or more of the operations depicted in block diagram 100 may be used to compress data when the data is stored by the data storage service.

[0090] In some implementations, block diagram 100 is implemented as part of a network data compression tool. For example, a source device (e.g., a desktop or laptop computer, a server, a smartphone, or another type of computing device) or a network device (e.g., a router, a gateway, a firewall, a switch, or another type of network device) can receive input data for transmission via a computer network and compress the input data using some or all of the operations described in block diagram 100. The compressed data can then be decompressed by a subsequent network device or destination device (e.g., a desktop or laptop computer, a server, a smartphone, or another type of computing device), or it can be stored in its compressed format (e.g., at the destination device).

[0091] Example high-level operation block diagram

[0092] Figures 2A-2D Depicted is an example high-level operational block diagram of the Flexible Huffman approximation algorithm. The block diagram depicts many implementation details that may or may not be used in a particular implementation. For ease of illustration, the block diagram depicts an example implementation of the new algorithm for a maximum code length of 15 bits (and 15 CLBs) (with up to 512 symbols), and using four quantization intervals (4 QIs). Other implementations may have different maximum code lengths, different numbers of symbols, and / or different numbers of quantization intervals. The following notation is followed in Figures 2A-2D In the example implementation depicted in:

[0093] SH: symbolic histogram (also called symCnt[])

[0094] SH[i]: symbol histogram count for symbol i

[0095] TC: Total Symbol Count (also known as SymTot)

[0096] QI: Quantization Interval

[0097] CL: Code Length (also known as CLB)

[0098] SBT: Scoreboard Table (also known as QIPop)

[0099] OBT: Optimized Boundary Table

[0100] CLH: Code Length Histogram

[0101] CLSB: Code Length Score Board

[0102] RCS: Remaining Code Space (also known as rem_code_space)

[0103] FBT: Full Binary Tree

[0104] Generally, the stages of the new algorithm are depicted in a block diagram in order from left to right. Figure 2A A first portion 200 of a block diagram depicting the implementation of a Shannon-based binning phase 202 is depicted. In the Shannon-based binning phase 202, the algorithm iterates over all histogram entries, generating a Shannon code length corresponding to each symbol entry and scoring them per code length and per quantization bin. The remaining code space is also tracked (e.g., according to Equation 3) while iterating over the histogram entries to obtain the remaining code space for subsequent optimization steps.

[0105] The Shannon-based binning stage 202 generally performs operations corresponding to those discussed above with respect to Equations 1 and 2 to determine the initial code length. The Shannon-based binning stage 202 also divides the code length bins into quantization intervals based on the fractional portion of the Shannon code (e.g., according to Equation 4). Scores (counts) are maintained per code length bin and per quantization interval, as depicted at 204. For example, a table containing symbol distributions over CL and QI may be created.

[0106] The Shannon-based binning stage 202 divides the fractional portion of the Shannon code length into QIs. In some implementations, the fractional portion is divided as depicted in Table 2. Note that the fractional portion of 0 is mapped to the last (lowest priority) QI because the symbol does not need to be optimized when its ideal code length is an integer.

[0107]

[0108]

[0109] Table 2

[0110] The code length table 206 (CLT) (which is 512 by 4 bits in this example) contains the integer portion of the ideal code length used as the baseline code length. It is the first optimization priority. In some implementations, maintaining the CLT is optional, as indicated by the dashed line (e.g., the code length can be recalculated at the code allocation stage).

[0111] A per-symbol quantization interval lookup table (LUT) 208 (which in this example is 512 by 2 bits) contains quantization intervals indicating the second-optimization priority of the symbol's code. To save memory resources, the per-symbol quantization interval LUT can instead be recalculated at a later stage. In some implementations, maintaining the per-symbol quantization interval LUT is optional, as indicated by the dashed line (e.g., the quantization intervals can be recalculated at the code allocation stage).

[0112] Figure 2BA second portion 210 of the block diagram is depicted describing the implementation of a code space optimization phase 212 (also referred to in the figure as code length optimization).

[0113] As depicted at 214, a code length and quantization interval score board table (SBT) is maintained. The SBT may contain 15x4 entries. The SBT provides per-code length optimization priorities.

[0114] In some implementations, the code space optimization stage 212 processes the SBT using two nested loops, first on the QI and then on the code length, both in ascending (priority) order. At each step, the optimizer calculates the number of symbols whose signs can be decremented by 1 so that the remaining code space does not become negative. The optimization goal is to reach exactly 0, which is not always possible depending on the symbol distribution. In this way, the optimizer effectively compresses the code tree.

[0115] An optimization boundary table (OBT) (e.g., having 15 entries) is generated, as depicted at 216. The per-CL optimization boundary table includes a QI and a symbol count indicating how many symbols can be optimized at the corresponding QI with all identical CL symbols, where higher priority QIs are implicitly optimized.

[0116] Figure 2C The third portion 220 of the block diagram depicts the implementation of the tree completion phase 222. The tree completion phase 222 generates a full binary tree, which implies a remaining code space of zero. The tree completion phase 222 includes a code length adjustment sub-phase 224, which iterates over the CLT in ascending symbol order, reducing the symbol length based on the CL / QI assignments from the OBT. The code length adjustment sub-phase 224 also constructs a CL histogram (CLH) (which has 15 entries in this example) that tracks the distribution of symbol code lengths required to enforce the strict binary tree property. In some implementations, the code length adjustment sub-phase 224 is optional.

[0117] The tree completion phase 222 includes a generate full binary tree (FBT) sub-phase 226 that iterates at most twice over the length histogram, using the remaining code space binary representation to guide the length reduction (sign promotion) at each iteration step, so that the remaining code space is 0. In some implementations, the full binary tree (FBT) sub-phase 226 performs the following phases:

[0118] When the remaining code space (RCS) > 0

[0119] - Get the MSb of RCS which provides the result of FLOOR(log2(RCS)); this is the length TO by which higher length symbols will be upgraded; if RCS is a power of 2 and the CLH entry corresponding to the TO (destination) code length bin is greater than 0, then subtract 1

[0120] - Updated RCS, CLH, CLSB to account for upgrade; CLSB tracks symbol count shortage / surplus per code length

[0121] - Get the excess length FROM where symbols will be removed; this is determined by the LSb of the updated CLH with the constraint that FROM length > TO length

[0122] The tree completion phase 222 includes a generate adjacency matrix (AM) sub-phase 228 which iterates twice over the CLSB, converting it into a hardware optimized fast lookup table that serves as the adjacency matrix for FROM-TO symbol length upgrades. At most 2 symbols can be upgraded from one length to another.

[0123] Figure 2D A fourth portion 230 of the block diagram is depicted describing the implementation of the code allocation stage 232. The code allocation stage 232 follows the canonical Huffman codebook generation algorithm, except that it performs symbol length reduction on the fly.

[0124] The code assignment phase 232 includes a create per-length first code sub-phase 234, which iterates over the CLH in ascending order of length, generating a first code for each length based on the histogram counts of the lengths. The first code (which in this example contains 15 entries) is provided to a set per-symbol code sub-phase 236. The set per-symbol code sub-phase 236 iterates over all symbols in ascending order, adjusting the length of each symbol for each AM as needed and assigning codes based on the final CL of each symbol. In some implementations, the set per-symbol code sub-phase 236 uses the previously generated code length table 206. In other implementations, the set per-symbol code sub-phase 236 recalculates the initial code length and quantization interval as done in the Shannon-based binning phase 202 (but without performing binning), and recalculates the code length as depicted in the operation of the set per-symbol code sub-phase 236.

[0125] The code assignment stage 232 codes are assigned to symbols according to the encoding algorithm being used. In this implementation, the code assignment stage 232 generates a canonical Huffman code as output.

[0126] Method for encoding symbols using a flexible Huffman tree approximation

[0127] In any of the examples herein, a method for encoding symbols using a new algorithm that implements a flexible Huffman tree approximation can be provided.

[0128] Figure 3is a flow chart of an example method 300 for encoding symbols using a new algorithm. For example, the example method 300 can be performed by a computing device (e.g., via software running on the computing device) and / or by a hardware component of the computing device (e.g., by an ASIC for an FPGA).

[0129] At 310, Shannon-based binning is performed to determine the initial code length for the symbol and the symbol is placed into corresponding code length bins (CLBs) based on the allocated initial code length. Shannon-based binning can be performed as part of the first stage of the encoding process. In some implementations, the CLB is divided into quantization intervals. In some implementations, the symbol is received from another compression or encoding tool, such as a tool using the deflate compression algorithm. For example, the data to be compressed can be received (e.g., as a file, as stream data, or in another format). The data can be processed to generate symbol information, which can be provided as input to the example method 300.

[0130] At 320, code space optimization is performed to shorten at least some of the symbols to shorter code length bins. For example, lifting symbols can be performed based on the amount of remaining code space. Code space optimization can be performed as part of the second stage of the encoding process. In some implementations, code space optimization is performed when the remaining code space is greater than a threshold (e.g., when the code space is greater than zero). For example, if the remaining code space is less than or equal to the threshold, then code space optimization can be skipped.

[0131] At 330, tree completion is performed by processing the binary tree representation of the symbols to convert the binary tree into a full binary tree. In some implementations, tree completion is not performed (eg, tree completion may be an optional stage).

[0132] At 340, prefix codes are assigned to symbols based at least in part on the code length binning. In some implementations, prefix codes are assigned according to a code assignment portion of a Huffman encoding algorithm (eg, according to a code assignment portion of a canonical form Huffman encoding algorithm).

[0133] Figure 4 4 is a flow chart of an example method 400 for encoding symbols using a new algorithm. For example, the example method 400 can be performed by a computing device (e.g., via software running on the computing device) and / or by a hardware component of the computing device (e.g., by an ASIC for an FPGA).

[0134] At 410, symbol information is received. The symbol information is generated from input data (e.g., input file, stream data, etc.). The symbol information includes symbols generated from the input data and frequency information. In some implementations, the symbol information is generated from a compression algorithm (e.g., using the LZ77 algorithm).

[0135] At 420, Shannon-based binning is performed to determine an initial code length for the symbol and the symbol is placed into a corresponding code length bin (CLB) based on the assigned initial code length. Shannon-based binning can be performed as part of the first stage of the encoding process. In some implementations, the CLB is divided into quantization intervals.

[0136] At 430, code space optimization is performed to shorten at least some of the symbols to shorter code length bins. For example, lifting symbols can be performed based on the amount of remaining code space. Code space optimization can be performed as part of the second stage of the encoding process. In some implementations, code space optimization is performed when the remaining code space is greater than a threshold (e.g., when the code space is greater than zero). For example, if the remaining code space is less than or equal to the threshold, then code space optimization can be skipped.

[0137] At 440, tree completion is performed by processing the binary tree representation of the symbols to convert the binary tree into a full binary tree. In some implementations, tree completion is not performed (eg, tree completion may be an optional stage).

[0138] At 450, prefix codes are assigned to symbols based at least in part on the code length binning. In some implementations, prefix codes are assigned according to a code assignment portion of a Huffman encoding algorithm (eg, according to a code assignment portion of a canonical form Huffman encoding algorithm).

[0139] The input data is encoded using the assigned code (e.g., using the assigned Huffman code) at 460. The encoded input data (which is now in a compressed format) can be output (e.g., saved as a compressed file on a storage device, sent as a compressed data stream to a network device, etc.).

[0140] Integer implementation

[0141] The new algorithm can be implemented efficiently (eg, in hardware such as ASICs and FPGAs) using integer implementation.

[0142] Register transfer level (RTL) implementations should avoid expensive and inaccurate floating-point calculations, especially log2 and division. Furthermore, CLBs must never be smaller than the exact value, or the code space may overflow, resulting in functional incorrectness. To address these potential issues, efficient and accurate integer calculations have been developed using the following transformation.

[0143] CLB(sym)=clb

[0144] ceil(I(sym))=clb

[0145] clb-1<I(sym)<=clb

[0146] clb-1<-log2(symCnt[sym] / symTot)<=clb

[0147] clb-1<log2(symTot / symCnt[sym])<=clb

[0148] 2 clb-1 <symTot / symCnt[sym]<=2clb

[0149] 2 clb-1 *symCnt[sym]<symTot<-2 clb *symCnt[sym]

[0150] 2 clb *symCnt[sym]<symTot*2<=2*2 clb *symCnt[sym]

[0151] 2 clb *symCnt[sym]<symTot*2

[0152]

[0153] symTot<=2 clb *symCnt[sym]<symTot / 2

[0154] The CLB can be calculated by first aligning the high-order bits of symCnt[sym] with the high-order bits of symTot and then comparing with symTot. The number of bits shifted is called clb'.

[0155] clb=clb′if symTot<=2 clb′ *symCnt[sym]

[0156] clb=clb′+1otherwise

[0157] QI is an optimization, and exact calculation does not affect correctness. QI is calculated using the cut points between symTot and 2*symTot. The cut points are pre-calculated once. In this implementation, simple linear cut points are used, but from an information-theoretic perspective, log-based models are undoubtedly more accurate. Using four QIs, the following QI cut points, depicted in Table 3, will be used in this implementation.

[0158]

[0159] Table 3 – Quantization interval boundaries

[0160] In this way, the QI can also be calculated using integer arithmetic. Integering is not critical when calculating the cutoff points.

[0161] Hardware Implementation

[0162] The new algorithm can be efficiently implemented in hardware (such as ASICs and FPGAs). For example, the technique can enable parallel computation of multiple symbols. The number of symbols processed per cycle will depend on factors such as chip area constraints, target frequency, and the technology being used. Common implementations can process up to 4 symbols per cycle. During Shannon-based binning, symCnt can be implemented, for example, in arrays and SRAM. Since access to symbol counts is sequential, multiple symbol consecutive counts can be easily read at once. The calculation of CLB and QI is completely independent for each symbol, so multiple symbols can be processed in parallel.

[0163] Updates to a QIPop involve simple logic and additions. Multiple additions to the same entry can be merged together into a single addition, thereby allowing multiple symbols to be scored in parallel.

[0164] Code space optimization loops (for example, in Figure 2B (depicted at 212 in ) is serialized on the update to the RCS. Thus, each iteration is processed one at a time. Thus, each iteration of loop 212 is serialized. However, the loop can be reduced to simple integer operations, typically implemented in a single cycle. In addition, code space optimization will typically run only a few iterations.

[0165] Code allocation involves a second pass through the symbols. Multiple symbols can have their final code lengths calculated by: 1) reading the symbol counts and calculating the Shannon-based CLB and QI in parallel, 2) applying the OBT CLB updates from the code space optimization in parallel, and 3) applying the AM update tree completion in parallel, and 4) allocating codes based on the FCT in parallel. Just as with the Shannon-based binning, the symbol counts, CLB, and QI can all be read and calculated in parallel, typically using the same hardware pipeline. Updates to the OBT can be optimized by merging updates for multiple symbols when they have the same CLB and QI, allowing multiple symbols to be processed in a single cycle. Similarly, updates to the AM can be merged when multiple symbols have the same CLB (after OBT adjustments). This produces the final code length for multiple symbols in each cycle.

[0166] Finally, codes are assigned by consulting the FCT based on the final code length. When multiple symbols have the same final code length in the same cycle, their updates to the FCT can be combined, converting multiple additions into a single small addition. This results in the final assigned code for multiple symbols in each cycle.

[0167] Computing System

[0168] Figure 5 A generalized example of a suitable computing system 500 is depicted in which the described techniques may be implemented. Computing system 500 is not intended to suggest any limitation as to scope of use or functionality, as these techniques may be implemented in a wide variety of general-purpose or special-purpose computing systems.

[0169] refer to Figure 5 , the computing system 500 includes one or more processing units 510, 515 and memories 520, 525. Figure 5 In FIG, the basic configuration 530 is included within the dashed line. The processing units 510, 515 run computer executable instructions. The processing unit can be a general-purpose central processing unit (CPU), a processor in an application-specific integrated circuit (ASIC), or any other type of processor. The processing unit can also include multiple processors. In a multi-processing system, multiple processing units run computer executable instructions to increase processing power. For example, Figure 5 A central processing unit 510 and a graphics processing unit or co-processing unit 515 are shown. Tangible memory 520, 525 can be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two accessible by the processing unit(s). The memory 520, 525 stores software 580 that implements one or more of the techniques described herein in the form of computer-executable instructions suitable for execution by the processing unit(s).

[0170] The computing system may have additional features. For example, the computing system 500 includes a storage device 540, one or more input devices 550, one or more output devices 560, and one or more communication connections 570. An interconnection mechanism (not shown), such as a bus, controller, or network, interconnects the components of the computing system 500. Typically, operating system software (not shown) provides an operating environment for other software running in the computing system 500 and coordinates the activities of the components of the computing system 500.

[0171] Tangible storage 540 may be removable or non-removable and include magnetic disks, tapes or cartridges, CD-ROMs, DVDs, or any other medium that can be used to store information and that can be accessed within computing system 500. Storage 540 stores instructions for software 580 implementing one or more techniques described herein.

[0172] Input device(s) 550 may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system 500. For video encoding, input device(s) 550 may be a camera, a video card, a TV tuner card, or similar device that accepts video input in analog or digital form, or a CD-ROM or CD-RW that reads video samples into the computing system 500. Input device(s) 560 may be a display, a printer, speakers, a CD burner, or another device that provides output from the computing system 500.

[0173] Communication connection(s) 570 enable communication to another computing entity via a communication medium. The communication medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in a manner that encodes information in the signal. By way of example and not limitation, the communication medium may utilize electrical, optical, RF, or other carriers.

[0174] These techniques can be described in the general context of computer-executable instructions (such as those included in program modules), run on a target real or virtual processor in a computing system. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of program modules can be combined or split between program modules as needed. Computer-executable instructions for program modules can be run in a local or distributed computing system.

[0175] The terms "system" and "device" are used interchangeably herein. Unless the context clearly indicates otherwise, neither term implies any limitation to a particular type of computing system or computing device. In general, a computing system or computing device may be local or distributed and may include any combination of specialized and / or general-purpose hardware and software that implements the functionality described herein.

[0176] For purposes of illustration, the detailed description uses terms such as "determine" and "use" to describe computer operations in a computing system. These terms are high-level abstractions for operations performed by a computer and should not be confused with actions performed by a human. The actual computer operations corresponding to these terms vary depending on the implementation.

[0177] Cloud support environment

[0178] Figure 6 6 is a generalized example of a suitable cloud support environment 600 in which the described embodiments, techniques, and technologies can be implemented. In the example environment 600, various types of services (e.g., computing services) are provided by a cloud 610. For example, the cloud 610 may include a number of computing devices, which may be centrally located or distributed, that provide cloud-based services to various types of users and devices connected via a network such as the Internet. The implementation environment 600 can be used in different ways to complete computing tasks. For example, some tasks (e.g., processing user input and presenting a user interface) can be performed on a local computing device (e.g., connected devices 630, 640, 650), while other tasks (storage of data to be used in subsequent processing) can be performed in the cloud 610.

[0179] In example environment 600, cloud 610 provides services for connected devices 630, 640, and 650 with various screen capabilities. Connected device 630 represents a device with a computer screen 635 (e.g., a medium-sized screen). For example, connected device 630 can be a personal computer, such as a desktop computer, laptop computer, notebook, netbook, etc. Connected device 640 represents a device with a computer screen 645 (e.g., a small-sized screen). For example, connected device 640 can be a mobile phone, smartphone, personal digital assistant, tablet computer, etc. Connected device 650 represents a device with a large screen 655. For example, connected device 650 can be a television screen (e.g., a smart TV) or another device connected to a television (e.g., a set-top box or game console). One or more of connected devices 630, 640, and 650 can include touchscreen capabilities. Touchscreens can accept input in different ways. For example, capacitive touchscreens detect touch input when an object (e.g., a fingertip or stylus) distorts or interrupts the current running across the surface. As another example, a touch screen can use an optical sensor to detect touch input when a light beam from the optical sensor is interrupted. Physical contact with the surface of the screen is not necessary for input to be detected by some touch screens. Devices without screen capabilities can also be used in example environment 600. For example, cloud 610 can provide services for one or more computers (e.g., server computers) that do not have a display.

[0180] Services can be provided by cloud 610 through service provider 620 or through other providers of online services (not depicted). For example, cloud services can be customized to the screen size, display capabilities, and / or touch screen capabilities of a particular connected device (e.g., connected devices 630, 640, 650).

[0181] In example environment 600, cloud 610 provides the techniques and technical solutions described herein to various connected devices 630, 640, 650, at least in part using service provider 620. For example, service provider 620 can provide centralized technical solutions for various cloud-based services. Service provider 620 can manage service subscriptions for users and / or devices (e.g., for connected devices 630, 640, 650 and / or their respective users).

[0182] Example Implementation

[0183] Although some of the operations in the disclosed methods are described in a particular order for ease of presentation, it should be understood that this description encompasses rearrangement unless a particular order is required by specific language as set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Furthermore, for simplicity, the accompanying drawings may not illustrate the various ways in which the disclosed methods can be used in conjunction with other methods.

[0184] Any of the disclosed methods may be implemented as computer-executable instructions or computer program products stored on one or more computer-readable storage media and executed on a computing device (i.e., any available computing device, including a smartphone or other mobile device that includes computing hardware). A computer-readable storage medium is a tangible medium (one or more optical media disks, such as DVDs or CDs, volatile media (such as DRAM or SRAM), or non-volatile media (such as flash memory or a hard drive)) that can be accessed within a computing environment. By way of example and with reference to Figure 5 , computer-readable storage media include memories 520 and 525 and storage device 540. The term computer-readable storage media does not include signals and carrier waves. In addition, the term computer-readable storage media does not include communication connections, such as 570.

[0185] Any of the computer-executable instructions for implementing the disclosed technology and any data created and used during the implementation of the disclosed embodiments can be stored on one or more computer-readable storage media. The computer-executable instructions can be a dedicated software application or part of a software application that is accessed or downloaded via a web browser or other software applications (such as remote computing applications). Such software can, for example, be run on a single local computer (e.g., any appropriate commercial computer) or in a network environment using one or more network computers (e.g., via the Internet, a wide area network, a local area network, a client-server network (such as a cloud computing network) or other such networks).

[0186] For clarity, only certain selected aspects of a software-based implementation are described. Other details well known in the art have been omitted. For example, it should be understood that the disclosed technology is not limited to any particular computer language or program. For example, the disclosed technology can be implemented by software written in C++, Java, Perl, or any other suitable programming language. Similarly, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be elaborated in this disclosure.

[0187] Additionally, any of the software-based embodiments (including, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) may be uploaded, downloaded, or remotely accessed via any suitable communication means, including, for example, the Internet, the World Wide Web, an intranet, a software application, cables (including fiber optic cables), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communications means.

[0188] The disclosed methods, apparatus, and systems should in no way be construed as limiting. Instead, the present disclosure is directed to all novel and non-obvious features and aspects of the various disclosed embodiments, individually and in various combinations and subcombinations with one another. The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.

[0189] The technology from any example can be combined with the technology described in any one or more of the other examples. In view of the many possible embodiments to which the principles of the disclosed technology can be applied, it should be appreciated that the illustrated embodiments are examples of the disclosed technology and should not be construed as limiting the scope of the disclosed technology.

Claims

1. A computing device comprising: processor; as well as Memory; The computing device is configured to perform operations for encoding a plurality of symbols, the operations comprising: As part of a first phase, performing Shannon-based binning to determine an initial code length for the symbol and placing the symbol into a corresponding code length bin (CLB) based on the determined initial code length; As part of the second phase, performing code space optimization to shorten at least some of the symbols into shorter code length bins; and As part of a third stage, assigning prefix codes to the symbols based at least in part on the code length binning; Among them, the implementation of Shannon-based binning includes: assigning each symbol to one of the code length bins corresponding to the Shannon code length of the symbol; and The code length is binned into quantization intervals.

2. The computing device of claim 1 , wherein performing Shannon-based binning comprises: Dividing each code length bin in the code length bins into a plurality of quantization intervals; Each symbol is assigned to one of the quantization intervals within one of the code length bins.

3. The computing device of claim 2 , wherein performing Shannon-based binning comprises: A count of symbols in each of the quantization intervals that have been placed into each of the code length bins is maintained.

4. The computing device of claim 1 , wherein performing code space optimization comprises: For each code length bin in one or more code length bins: One or more most frequently occurring symbols in the code length bin are moved to the next shorter code length bin having a shorter code length.

5. The computing device of claim 1 , wherein each code length bin is divided into a plurality of quantization intervals, and wherein performing code space optimization comprises: For each code length bin in one or more code length bins: One or more symbols associated with the most frequent quantization interval in the code length bin are moved to the next shorter code length bin having a shorter code length.

6. The computing device of claim 1 , wherein performing code space optimization comprises: Determine whether the remaining code space is greater than zero; If the remaining code space is greater than zero, performing code space optimization including moving at least one symbol to the next shorter code length bin; If the remaining code space is equal to zero, proceed to the next stage without moving any symbols.

7. The computing device of claim 1 , the operations further comprising: As part of a new stage, following the second stage and preceding the third stage, tree completion is performed by processing the binary tree representing the symbols to transform the binary tree into a full binary tree.

8. The computing device of claim 7, wherein processing the binary tree comprises: Nodes lower in the binary tree are promoted to fill missing nodes higher in the binary tree.

9. The computing device of claim 1 , the operations further comprising: The plurality of symbols representing data to be compressed is received, wherein the plurality of symbols is generated from a Deflate algorithm.

10. The computing device of claim 1, wherein the prefix code is assigned according to a canonical form Huffman coding.

11. The computing device of claim 1, wherein the operations are performed by a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC) of the computing device.

12. A method implemented by a computing device for encoding a plurality of symbols, the method comprising: performing Shannon-based binning to determine an initial code length for the symbol and placing the symbol into a corresponding code length bin (CLB) based on the determined initial code length; performing code space optimization to shorten at least some of the symbols into shorter code length bins; as well as assigning prefix codes to the symbols based at least in part on the code length binning; Among them, the implementation of Shannon-based binning includes: assigning each symbol to a code length bin of the code length bins corresponding to the Shannon code length of the symbol; as well as The code length is binned into quantization intervals.

13. The method of claim 12, wherein performing Shannon-based binning comprises: Dividing each code length bin in the code length bins into a plurality of quantization intervals; Each symbol is assigned to one of the quantization intervals within one of the code length bins.

14. A method for encoding a plurality of symbols implemented by a computing device, the method comprising: receiving symbol information generated from input data, wherein the symbol information includes the symbol and an associated frequency of the symbol; As part of the first phase, performing Shannon-based binning to determine an initial code length for the symbol and placing the symbol into a corresponding code length bin (CLB) based on the determined initial code length; as part of the second phase, performing code space optimization to shorten at least some of the symbols into shorter code length bins; performing tree completion as part of a third stage by processing a binary tree representing the symbols to transform the binary tree into a full binary tree; As part of a fourth stage, assigning prefix codes to the symbols based at least in part on the code length binning; as well as encoding the input data using the determined prefix code to generate compressed output data; Among them, the implementation of Shannon-based binning includes: assigning each symbol to a code length bin of the code length bins corresponding to the Shannon code length of the symbol; as well as The code length is binned into quantization intervals.

Images