Decoding device and decoding method

Abstract

To enable the decoding of data in a variable-length code sequence compressed using entropy coding with low latency.SOLUTION: A decoding device is configured to acquire a predetermined number of bits of data per clock cycle from a variable-length code sequence data encoded using entropy coding, and decode the predetermined number of bits of data per clock cycle using reference information obtained from the multiple predetermined numbers of bits of data.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to an apparatus and method for decoding variable length code sequence data compressed using entropy coding. [Background technology]

[0002] In data compression, code assignment is used to reduce the average amount of data per symbol. Entropy coding is used to reduce the average amount of data per symbol by representing frequently occurring symbols with shorter bit lengths and less frequently occurring symbols with longer bit lengths.

[0003] A decoding technique using Huffman codes for entropy coding has been proposed (see, for example, Patent Document 1). In Patent Document 1, the second-stage table is referenced at the next operation timing based on the result of the first-stage table, making it difficult to decode multiple codes in one clock cycle. This poses a problem of long latency when decoding data of variable-length code sequences. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 06-326616 "Method for constructing a Huffman decoding table" [Non-patent literature]

[0005] [Non-Patent Document 1] Ben Rudiak-Gould. Huffyuv v2.1.1. http: / / rationalqm.us / www.math.berkeley.edu / benrg / huffyuv.html. (Accessed on 12 / 14 / 2023). [Non-patent document 2] Atsuto Murakami, Kotaro Asai, Shunichi Sekiguchi (eds.). High-Efficiency Video Coding Technology HEVC / H.265 and Its Applications. Ohmsha, Feb 2013, pp. 18-19. [Non-patent document 3] Iwahashi, M., "Forest of Knowledge," Group 2, Volume 5, Chapter 5, Institute of Electronics, Information and Communication Engineers. https: / / www.ieice-hbkb.org / files / ad_base / view_pdf.html?p= / files / 02 / 02gun_05hen_05.pdf, 4 2013. (Accessed 12 / 15 / 2023). Summary of the Invention [Problem to be solved by the invention]

[0006] An object of the present disclosure is to enable variable-length code string data compressed using entropy coding to be decoded with low latency. [Means for solving the problem]

[0007] A transmission system according to the present disclosure includes a transmitting device that transmits data of a variable-length code sequence using entropy coding, and a decoding device that decodes the data of the variable-length code sequence transmitted from the transmitting device. The decoding device according to the present disclosure executes a decoding method according to the present disclosure. In the decoding method according to the present disclosure, the decoding device according to the present disclosure performs a decoding process using a clock and data of two bit lengths received immediately before the clock.

[0008] Specifically, the decoding device of the present disclosure includes: Obtaining a predetermined number of bits of variable-length code string data encoded using entropy code for each clock; Using reference information obtained from the plurality of pieces of data each having the predetermined number of bits, the data each having the predetermined number of bits is decoded for each clock.

[0009] The decoding device of the present disclosure may detect the starting position and code length of the code from the data of the predetermined number of bits, and obtain the starting position and code length of the code contained in the data of the predetermined number of bits as the reference information.

[0010] In the present disclosure, by calculating an inaccessible leading bit indicating how many bits from the beginning of the data of the predetermined number of bits are not the beginning of the code, information indicating a reliable code length among the code lengths detected from the data of the predetermined number of bits may be obtained as the reference information. In this way, the decoding device of the present disclosure can decode the data of the variable-length code sequence using the obtained reliable code length.

[0011] The data of the variable-length code sequence may be video data, in which case the entropy code may be a Huffman code.

[0012] The predetermined number of bits may be determined by the code length of a Huffman code.

[0013] The above disclosures can be combined as much as possible. [Effects of the Invention]

[0014] According to the present disclosure, data of a variable-length code string compressed using entropy coding can be decoded with a small latency. [Brief explanation of the drawings]

[0015] [Figure 1] An example of compression processing using HuffYUV is shown below. [Figure 2] 10 shows an example of encoding processing performed by a transmitting device when compressing moving images. [Figure 3] 10 shows an example of decompression processing performed by a receiving device. [Figure 4] 1 illustrates an example of a decompression algorithm of the present disclosure. [Figure 5] An example of a Huffman code string is shown below. [Figure 6] An example of a Huffman tree is shown below. [Figure 7] A specific example of a 32-bit Huffman code string is shown below. [Figure 8] This shows how Huffman codes are decoded in parallel using DIS. [Figure 9] This is an example of a 16-bit Huffman code sequence when N=16. [Figure 10] This is an example in which 32-bit Huffman code sequences #0 to #2 are created using 16-bit Huffman code sequences #0 to #3. [Figure 11] This is an example of how the code length of a 32-bit Huffman code sequence #0 is obtained in 16 parallel processes. [Figure 12] This is an example of how the code lengths of 32-bit Huffman code sequences #0 and #1 are obtained. [Figure 13] This is an example of how the leading unusable bits of a 32-bit Huffman code string are calculated in advance. [Figure 14] 1 illustrates an example of a decoding device according to the present disclosure. [Figure 15] 10 shows an example of compressed coded data of 2N bits length, an intermediate data format, and a final data format when N=15. [Figure 16] FIG. 10 is an explanatory diagram of the operation of a decoding unit. [Figure 17] 1 illustrates an example of a decoding device according to the present disclosure. [Figure 18] 10 is an example of calculating the code length of a compressed code string. [Figure 19] 10 shows an example of a marker output from the decoding start possibility determination module. [Figure 20] 10 shows an example of output from a decoding start possibility determination module at each clock. [Figure 21] An example of decoder implementation is shown below. [Figure 22] An example of three lookup tables is shown below. [Figure 23] An example of two lookup tables is shown below. DETAILED DESCRIPTION OF THE INVENTION

[0016] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. Note that the present disclosure is not limited to the embodiments shown below. These implementation examples are merely illustrative, and the present disclosure can be implemented in various forms with various modifications and improvements based on the knowledge of those skilled in the art. Note that components with the same reference numerals in this specification and drawings indicate the same components.

[0017] A transmission system according to the present disclosure includes a transmitting device that transmits data of a variable-length code sequence using entropy coding, and a decoding device that decodes the data of the variable-length code sequence transmitted from the transmitting device. In the present disclosure, latency is reduced in a decoding process using entropy coding. In this embodiment, an example will be described in which the data of the variable-length code sequence is video data.

[0018] When transmitting high-quality video over a communication channel and displaying it on a video output device, the data bandwidth of the video often exceeds the bandwidth of the communication channel. For example, the video bandwidth for 4K resolution, 60 fps, 4:4:4 / RGB, 8 bit / color is 17.82 Gbps, but the bandwidth limit for communication services provided to individuals by line carriers is approximately 10 Gbps. Therefore, video compression and decompression technology is generally used when transmitting video over a communication channel.

[0019] The upper limit of the operating frequency of a system on an FPGA (Field Programmable Gate Array) is around 300 MHz. On the other hand, outputting 4K resolution at 60 fps requires a pixel clock of nearly 500 MHz. For this reason, if entropy coding is used to compress 4K resolution video, the throughput (decoded data per clock cycle) from inputting the code string to obtaining the decoded data will be less than 1.

[0020] For this reason, when streaming video, such as when video is transmitted and displayed on a video output device, it is not possible to encode and transmit pixel values ​​themselves or the differences between adjacent pixel values, and video compression requires operations such as converting a set of pixel values ​​into a coefficient sequence using DCT (discrete cosine transform) etc. However, because such video compression methods involve conversion to the frequency domain and inverse conversion, there is a problem that the latency of compression and decompression is greater than that of video compression methods that encode and transmit only the differences between adjacent pixel values.

[0021] HuffYUV is one of the video compression methods that uses entropy coding. In HuffYUV, codes are assigned using Huffman codes. In HuffYUV, one code corresponds to one pixel value (more precisely, the error between adjacent pixel values), so if pixel values ​​can be compressed and decompressed at a throughput higher than the video frequency, it is easy to incorporate into a video streaming system. In this disclosure, an example will be described in which the entropy code is a Huffman code.

[0022] For example, a HuffYUV compressor compresses one pixel value per clock at an operating frequency of 148.5 MHz, and a HuffYUV decompressor outputs one pixel value per clock at an operating frequency of 148.5 MHz. This allows streaming of video at a video frequency of 148.5 MHz.

[0023] On the compression side, it can be implemented by giving the error between adjacent pixel values ​​as an address to memory and outputting the compressed code stored in the memory. For example, as shown in Figure 1, One possible implementation strategy is to output the compressed codes stored in the compression memory table as 01000, 000100101, 00000110000, and 101 when the error (8-bit integer value) between each pixel and its adjacent pixel value is 3, 15, 136, 42, or 255. This will make memory access the focus of the operation, making it easier to increase the operating frequency and throughput.

[0024] (Video compression using HuffYUV) FIG. 2 shows an example of the encoding process performed by a transmitting device when compressing video. When compressing video using HuffYUV, preprocessing 411 is performed first. This preprocessing 411 is a color space conversion called decorrelation. HuffYUV supports YUV2 and RGB color spaces, but if the input video is in RGB color space, decorrelation can be performed as desired. This operation converts the values ​​of the R and B color components into the difference between the values ​​of the R and B color components and the G color component, converting the RGB color space to an (RG, G, BG) color space. According to the HuffYUV specifications (see, for example, Non-Patent Document 1), this operation improves the compression rate.

[0025] After preprocessing 411 is performed, pixel value prediction 412 is performed. Pixel value prediction 412 is an operation that converts pixel values ​​into some kind of predicted value. In the case of natural video, such as when a subject is photographed with a camera, there is little bias in the probability of pixel values ​​occurring within the frame itself. However, there is often spatial and temporal correlation between pixel values ​​in video, and pixels that are close in distance spatially and temporally often have similar pixel values. In the case of HuffYUV, intra-frame prediction is used, so pixel values ​​are predicted using only the spatial correlation between pixel values.

[0026] There are various methods for predicting pixel values ​​within a frame, and for example, Murakami et al. (see, for example, Non-Patent Document 2) explain that "a simple intraframe predictive coding method is one in which a difference with the immediately preceding pixel (the pixel on the left) is calculated and the difference value is used as coded data. Although the probability of occurrence of the pixel value itself cannot be determined in advance, the difference value with the immediately preceding pixel is often 0 or close to 0, so a bias in the occurrence probability is obtained, making it possible to reduce the amount of information." In HuffYUV, the method of calculating the difference with the immediately preceding pixel (the pixel on the left) and using the difference value as coded data is implemented as the left prediction method, and this disclosure also uses this prediction method to confirm the operation of video compression and decompression.

[0027] HuffYUV uses the following prediction methods, including the Left prediction method: (i) Left prediction method (YUV2, RGB color space) Generally, the pixel to the left is used as the predicted value for the current pixel. As an exception, if the leftmost pixel in each row is the rightmost pixel in the row above, the predicted value is used. Also, the predicted value for the first pixel in the video stream (the pixel in the upper left corner of the frame) is 0. (ii) Gradient prediction method (YUV2, RGB color space) Basically, the calculation result of (the pixel to the left + the pixel above - the pixel to the top left) is used as the predicted value for the current pixel. As an exceptional case, for the leftmost pixel of each row, the calculation result of (the rightmost pixel in the row above + the pixel above - the rightmost pixel two rows above) is used as the predicted value. Also, the predicted value for the first pixel in the video stream (the pixel in the top left of the frame) is set to 0, and only the first row is predicted using the left prediction method. (iii) Median prediction method (YUV2 color space only) Basically, the median of the three values ​​{left pixel, above pixel, predicted value obtained by gradient prediction} is used as the predicted value for the current pixel. As an exceptional case, the predicted value for the first pixel in the video stream (the pixel in the upper left of the frame) is set to 0, and left prediction is used only for the prediction of the four pixels from the left end of the first and second lines.

[0028] After pixel value prediction 412, code assignment 415 is performed. Code assignment 415 is an operation of calculating the difference between the actual pixel value and the predicted value and encoding that value. In HuffYUV, a Huffman table is defined in advance, in which difference values ​​and Huffman codes correspond one-to-one, and code assignment is performed by static Huffman encoding using this table. In this disclosure, the Huffman table is referred to as a decoding table. Note that HuffYUV does not perform the operations of frequency conversion 413 and quantization 414.

[0029] Iwahashi (see, for example, Non-Patent Document 3) explains frequency transformation as follows: "Several general-purpose components, ranging from gradual changes in brightness to line sketches, are prepared and shared between the encoding and decoding sides. The size and position of these components are then examined for each image and encoded as information, thereby representing the image signal with a smaller amount of data than encoding the image's luminance values ​​themselves." Frequency transformation is adopted in many codecs. JPEG, H.264 / MPEG-4 AVC, and H.265 / MPEG-H HEVC use the discrete cosine transform (DCT), which performs frequency transformation using a cosine function, while JPEG2000 uses the discrete wavelet transform. Generally, frequency transformation causes signal imbalance between low- and high-frequency components, resulting in greater information imbalance. This leads to better compression efficiency during code assignment. Meanwhile, HuffYUV generates information imbalance by calculating the difference between predicted values ​​and pixel values, and does not perform the operation equivalent to frequency transformation 413.

[0030] Quantization 414 is the process of expressing a certain number of bits. Generally, the amount of data can be reduced by expressing a number with a limited number of bits, but in HuffYUV, pixel values, predicted values, and differences between predicted values ​​and pixel values ​​are all handled in 8 bits, and quantization does not reduce the amount of data.

[0031] (Video decompression using HuffYUV) Figure 3 shows an example of the video decompression process performed by a receiving device. When decompressing video using HuffYUV, the operations are performed in the reverse order of when the video was compressed. When decompressing video, decoding 421 is performed first. In decoding 421, the input Huffman code string is decoded using a decoding table predefined in HuffYUV, and values ​​are extracted.

[0032] Next, the obtained values ​​are used to perform predictive decoding 424. The values ​​obtained by decoding 421 are either the pixel values ​​themselves (only the first pixel in the video stream) or the difference between the predicted value and the actual pixel value. Therefore, these are used to calculate the original pixel value.

[0033] Finally, post-processing 425 is performed. This post-processing 425 is a color space conversion that restores the decorrelation performed in pre-processing 101. Note that since the frequency conversion 413 and quantization 414 operations are not performed during compression, inverse quantization 422 and inverse conversion 423 are not performed during decompression either.

[0034] HuffYUV uses intra-frame prediction, allowing for independent image compression for each frame. Therefore, according to experiments conducted by the inventors, the compression rate varies depending on the number of frames elapsed. It was found that by compressing using HuffYUV's RGB (decorated) color space and left prediction method, video can be compressed to approximately 32.5% to 50% of the original data at a resolution of 1920 x 1080, and to approximately 30% to 45% of the original data at a resolution of 3840 x 2160. It was also found that the compression rate increases as the resolution increases. This is thought to be because the difference between adjacent pixel values ​​becomes smaller as the resolution increases, increasing the proportion of Huffman codes with shorter code lengths.

[0035] This disclosure uses a lossless video compression and decompression algorithm based on HuffYUV. Video is compressed independently for each frame. Therefore, unless otherwise specified, the following explanation will treat all operations as being completed within the same frame. Also, the height of a frame is HEIGHT, the width is WIDTH, and the pixel located in the jth row and ith column is expressed as pixel(i,j). In other words, the top left pixel of a frame can be expressed as pixel(0,0), and the bottom right pixel of a frame can be expressed as pixel(HEIGHT-1,WIDTH-1).

[0036] The proposed video compression algorithm is based on the HuffYUV RGB (decorated) color space and left prediction method, but the only difference is the compression method for the first pixel of the video stream (the pixel located in the upper left corner of each frame). Specifically, in HuffYUV, only the pixel value of the first pixel of the video stream is output without being Huffman coded, whereas in the proposed video compression algorithm, the pixel value of the first pixel of the video stream is also Huffman coded and output.

[0037] (Video compression algorithm) The video compression algorithm is explained below. Each input 24-bit RGB pixel value is divided into 8-bit color components, and then the difference between each color component and the color component of the pixel to the left is calculated. Here, for the pixel (0,0) in the top left corner of the frame, there is no pixel to the left, so the pixel value of that pixel is used as the calculation result for the difference.

[0038] Furthermore, for the leftmost pixel (i,0) on the second line or later in the frame, there is no pixel to the left, but as with the HuffYUV algorithm, the rightmost pixel (i-1,WIDTH-1) on the previous line is treated as the pixel to the left and the difference value is calculated.

[0039] The calculated difference value is then subjected to static Huffman coding using a previously prepared decoding table. The decoding table used is the same as the Huffman table used in the HuffYUV RGB·Left·no decorr method, and static Huffman coding converts the 8-bit difference value into a 2-15-bit Huffman code.

[0040] In general, it is difficult to expect bias in the frequency of occurrence of each pixel in a natural image. However, each pixel tends to have similar pixel values ​​to its surrounding pixels, and when calculating the difference value between the surrounding pixels, the normal probability of the calculation result can be expected to be concentrated near 0. Therefore, the difference values ​​calculated above are expected to be small absolute values ​​such as -2, -1, 0, 1, and 2, although negative values ​​will actually bias towards values ​​such as 254 and 255 due to underflow. In response to this, applying Huffman coding, a typical entropy coding method, can be expected to convert the 8-bit difference value into a shorter bit length.

[0041] (Video decompression algorithm) FIG. 4 shows an example of a video decompression algorithm according to the present disclosure. The video compression algorithm according to this embodiment outputs 24-bit RGB pixel values ​​as Huffman codes for each color component, and these codes are continuous to form a Huffman code string. The video decompression algorithm according to the present disclosure is composed of two types of operations. Specifically, in Huffman code string decoding 431, the Huffman code string for each color component is decoded, and in pixel value recalculation 432, the pixel values ​​are recalculated using the decoded values ​​(i.e., "difference values"). Huffman code string decoding 431 corresponds to code decoding 421, and pixel value recalculation 432 corresponds to predictive decoding 424.

[0042] (Decoding Huffman Codes 431) Figure 5 shows an example of a Huffman code string. As shown in the figure, the Huffman code string output from the video compression algorithm is formatted as a series of codes obtained by Huffman-encoding the difference values ​​of each pixel. Here, the Huffman code can be decoded into a unique value by tracing the Huffman tree shown in Figure 6, bit by bit from the beginning. For example, the Huffman code string 00000000010000010001000001 in Figure 5 can be decoded into the unique values ​​"0000000001" as "136," "000001" as "243," "0001" as "21," and "000001" as "101." Note that this Huffman tree corresponds to the Huffman table.

[0043] (Recalculating pixel values ​​432) The value output by decoding the Huffman code sequence is a "difference value." This value is the pixel value itself only for pixel (0,0), and for the other pixels (i,j), it is the difference between the pixel value and the pixel value to the left. For this reason, in pixel value recalculation 432, a buffer is provided to store the calculated pixel values, and by using this buffer to add up the difference values, the 24-bit RGB pixel values ​​of the original image can be restored.

[0044] (DBL·DIS data type) Reference information for decoding Huffman code strings in parallel will now be described. In this disclosure, the following three types of data types are created from Huffman code strings in order to simultaneously decode Huffman codes in parallel. ·Decompressable Bit Length(DBL) ·Decompressable Index Structure (DIS) Extended Data with DIS However, ExtendedData with DIS is a set of a 32-bit Huffman code sequence and the corresponding DIS.

[0045] These data types indicate the start position of a Huffman code within bits 0 through 15 of a 32-bit Huffman code string. This prevents a Huffman decoder from decoding the Huffman code from the wrong position, resulting in an unintended value being decoded. A concrete example is shown in Figure 7. In the figure, codes A, B, C, D, E, F, G, and H are stored in a 32-bit Huffman code string. However, only the last two bits of code A and only the first four bits of code H are stored separately. Here, DBL and DIS mark the start positions of Huffman codes in the 32-bit Huffman code string at indexes [0] through

[15] . In the figure, the start of code B at index [2], the start of code C at index [7], and the start of code D at index

[10] are marked.

[0046] Next, we will explain the detailed structure of DBL and DIS. First, DecompressableBitLength (DBL) is defined using the first decodable index and length[i]. The first decodable index indicates the beginning of the first Huffman code that appears in a 32-bit Huffman code string. To explain a specific example based on Figure 7, the first decodable index is 2, which prevents the last 2 bits of code A (indexes [0] to [1]) from being mistaken for the beginning of the code.

[0047] length[i] indicates the code length when the code is decoded starting from index i in the 32-bit Huffman code sequence. If index i points to the correct start position of the code, the code length of that code is stored; if index i is not the correct start position of the code, 0 is stored. To illustrate a specific example using Figure 7, index [2] is assigned a length of 5, index [7] is assigned a length of 3, and index

[10] is assigned a length of 11. This indicates that starting the Huffman code decoding from index [2] will decode the 5-bit code B, starting the Huffman code decoding from index [7] will decode the 3-bit code C, and starting the Huffman code decoding from index

[10] will decode the 11-bit code D. The other indices are assigned a length of 0 because they do not point to the correct start position of the code.

[0048] Based on the length of this DBL, multiple decoders 303 can be prepared and used to decode Huffman codes simultaneously in parallel. For example, in the case of Figure 7, 16 decoders 303 are installed in parallel, and each decoder 303 is given a length and a 15-bit bit string with a range shifted by 1 bit. Each decoder 303 outputs a decoded value based on the given 15-bit bit string, but it is unclear at this point whether the decoded value can be trusted. Here, the DBL length given to the decoder 303 is used to determine whether these decoded values ​​can be trusted. The decoded values ​​of #2, #7, and #10, which are given a length ≠ 0, can be trusted, while the decoded values ​​of #0-1, #3-6, #8-9, and #11-15, which are given a length = 0, can be untrusted.

[0049] Next, the Decompressible Index Structure (DIS) is defined using index[i] and elementNum. index[i] indicates the position of the beginning of a Huffman code in the first 16-bit portion of a 32-bit Huffman code string. In other words, index[i] indicates where in the 32-bit Huffman code string the beginning of a variable-length code string is located. The number of Huffman codes whose beginnings are in the first 16-bit portion of a 32-bit Huffman code string is (16 / maximum code length) to (16 / minimum code length). The minimum and maximum code lengths of the Huffman codes used in this disclosure are 2 and 15, respectively. Therefore, the number of Huffman codes whose beginnings are in the first 16-bit portion of a 32-bit Huffman code string is 1 to 8, and by setting the maximum number of elements in index to 8, parallel decoding of 32-bit Huffman code strings is possible.

[0050] elementNum indicates the number of the first Huffman code in the first 16 bits of the 32-bit Huffman code string. This value indicates how many decodable codes there are in DBL / DIS. For example, if there are two decodable codes, some value may be stored in indexes [2] to [7], but these should not be trusted. However, in this case, elementNum stores 2, so the decoder can determine which indexes should not be trusted.

[0051] By converting the data type from DBL to DIS, the number of decoders 303 installed in parallel can be reduced from 16 to (16 / minimum code length (bits)). The Huffman codes used in this disclosure are 2 to 15 bits long, so when DBL is used, 16 decoders 303 are required, whereas when DIS is used, decoding capabilities equivalent to those of DBL can be obtained with just 8 decoders 303. Note that the purpose of DIS is solely to reduce the number of decoders 303, so DIS may not be used if this is not necessary.

[0052] (Parallel decoding of Huffman codes using DIS) Figure 8 shows how Huffman codes are decoded in parallel using DIS. As mentioned above, the number of decoders has been reduced to 8 compared to 16 when DBL is used. A 15-bit bit sequence, DIS.index[i] to DIS.index[i]+14, is extracted from the 32-bit Huffman code sequence and provided to decoder #i (0≦i≦7). In Figure 8, decoder #0 is provided with a bit sequence ranging from [2] to

[16] of the 32-bit Huffman code sequence because DIS.index[0]=2, and decoder #1 is provided with a bit sequence ranging from [7] to

[21] of the 32-bit Huffman code sequence because DIS.index[1]=7.

[0053] Then, for the decoded values ​​obtained from decoder #i (0≦i≦7), DIS.elementNum is used to determine whether to trust them. In Figure 8, elementNum = 3, so outputs from decoder #0, decoder #1, and decoder #2 are trusted, but outputs from decoder #3 and onwards are not trusted. This allows the 32-bit Huffman code string to be decoded from the correct location using DIS.

[0054] (How to create a DBL) The method for creating a DBL from a Huffman code string will now be explained. First, a series of Huffman code strings is divided into N (bit) strings to create N-bit Huffman code strings #0, 1, 2, .... In this case, N must be equal to or greater than the maximum code length of the Huffman code to be decoded, and no single code will span three or more N-bit Huffman code strings. Figure 9 shows how a 16-bit Huffman code string is created when N=16.

[0055] Next, the N-bit Huffman code strings are formed into 2N-bit Huffman code strings. At this time, the N-bit Huffman code strings are shifted and bundled together in pairs, such that 2N-bit Huffman code string #0 = {N-bit Huffman code string #0, N-bit Huffman code string #1}, 2N-bit Huffman code string #1 = {N-bit Huffman code string #1, N-bit Huffman code string #2}, etc. Figure 10 shows how 32-bit Huffman code strings #0 to #2 are created using 16-bit Huffman code strings #0 to #3.

[0056] By performing this operation, it is possible to ensure that all codes whose leading bits are in the first N-bit Huffman code string of a 2N-bit Huffman code string are included in the 2N-bit Huffman code string. However, it should be noted that at this point, the decoder 303 cannot determine where the leading bit of each code is included. In the case of Figure 10, the leading bits of the following codes are present in the first 16-bit Huffman code string of a 32-bit Huffman code string: ·32bit Huffman code string #0: code A, code B, code C, code D ·32bit Huffman code string #1: code E, code F, code G, code H ·32bit Huffman code string #2: code I, code J, code K, code L All of the codes are present in the 32-bit Huffman code string.

[0057] Next, the read position of the 2N-bit Huffman code string is shifted by one bit at a time to obtain the code lengths in N parallel sequences. The i-th code length obtainer #i obtains the code lengths [i] to [i + maximum code length] of the 2N-bit Huffman code string. Note that the code length obtainer returns the code length of the code starting from the beginning of the extracted Huffman code string. Therefore, the code lengths obtained in N parallel sequences will differ depending on the position from which the Huffman code string was extracted, and it is not possible at this point to know which code lengths can be trusted.

[0058] As explained above, the code length can be obtained in 16 parallel sequences from 32-bit Huffman code sequence #0. For example, code length obtainer #0 returns a code length of 5 based on the 15 bits from [0] to

[14] of 32-bit Huffman code sequence #0. This means that the code length of code A, which exists in [0] to [4], has been obtained. On the other hand, code length obtainer #1 returns a code length of 2 based on the 15 bits from [1] to

[15] of 32-bit Huffman code sequence #0. This means that the bit sequence from [1] to [2] happens to match another Huffman code with code length 2, and that code length 2 has been obtained. As such, depending on the position from which the Huffman code sequence is extracted, there are cases where the correct code length is obtained and cases where it is not.

[0059] Next, the correspondence between the "prohibited leading bits" of each 2N-bit Huffman code sequence #i and #i+1 is calculated. "Prohibited leading bits" refers to the number of bits from the beginning of a 2N-bit Huffman code sequence that are not the beginning of a code. Figure 11 shows how the code length extractor provided in the Huffman code decoding unit 431 acquires the code lengths of 32-bit Huffman code sequences #0 and #1 in 16 parallel sequences. For example, the beginning of 32-bit Huffman code sequence #0 is the beginning of code A. Therefore, the prohibited leading bit of 32-bit Huffman code sequence #0 is 0. On the other hand, the beginning of 32-bit Huffman code sequence #1 is the third bit of code D, so the 8 bits [0] to [7] are not the beginning of a code. Therefore, the prohibited leading bit of 32-bit Huffman code sequence #1 is 8.

[0060] The purpose of introducing the "not leading bit" is to determine which results of the code length extractors operating in N parallel fashion are to be trusted. It is confirmed that the beginning of the code is at bit 0 for the first 2N-bit Huffman code sequence #0. For example, in the case of Figure 12, the beginning of the first code appears at bit 0 of the 32-bit Huffman code sequence #0, so the code length value of 5 from code length extractor #0 can be trusted. If the output value of 5 from code length extractor #0 can be trusted, then the output value of 5 from code length extractor #5, the output value of 3 from code length extractor #10, and the output value of 11 from code length extractor #13 can also be trusted. This allows the locations of codes A through D to be identified. However, the beginning of the code is not necessarily at bit 0 for the subsequent 2N-bit Huffman code sequences #i. 12, for example, the beginning of the first code E appears at the 8th bit of the 32-bit Huffman code sequence #1, so the output values ​​of code length obtainers #0 to #7 must not be trusted, but rather the output value of 2 from code length obtainer #8, the output value of 2 from code length obtainer #10, the output value of 12 from code length obtainer #12, and the output value of 4 from code length obtainer #15 must be trusted. Therefore, information on the leading invalid bit 8 is required to prevent the output values ​​of code length obtainers #0 to #7 of the 32-bit Huffman code sequence #1 from being trusted.

[0061] The leading insignificant bits of a 2N-bit Huffman code sequence can be calculated using the following pseudocode: Source Code 4.4 Beginning int p; / / Leading non-zero bit of 2Nbit Huffman code string #i int p_next; / / The first non-starting bit of 2N-bit Huffman code string #(i+1) while(p < N){ p+= Output value of code length obtainer [p] } p_next = p - N; Source code 4.4 end

[0062] When the first incompatible bit of the 2N-bit Huffman code string #i is given, the output value from the reliable code length extractor is added in the while loop on line 4, and the calculation ends when it exceeds N. Then, the number of bits that the code protrudes into the latter N-bit Huffman code string is calculated and this is taken as the first incompatible bit of the 2N-bit Huffman code string #(i+1).

[0063] In this case, for the Huffman code decoding 431, it is desirable to keep the calculation interval between the first impossible bit of a 2N-bit Huffman code string #i and the first impossible bit of a 2N-bit Huffman code string #(i+1) as short as possible. However, the number of while loops in source code 4.4 varies depending on the output value of the code length obtainer. In the worst case, the loop count may be (N / minimum code length), making it difficult to sufficiently shorten the calculation interval. Therefore, in the implementation of this disclosure, the first impossible bit of a 2N-bit Huffman code string #(i+1) corresponding to all possible first impossible bits of a 2N-bit Huffman code string #i is calculated in advance. This shortens the calculation interval between the determination of the first impossible bit of a 2N-bit Huffman code string #i and the determination of the first impossible bit of a 2N-bit Huffman code string #(i+1). FIG. 13 shows the calculation of all the leading incapable bits that can be given to the 32-bit Huffman code strings #0 and #1 and the leading incapable bits to be given to the next 32-bit Huffman code string, based on source code 4.4.

[0064] After calculating the correspondence between code length and "leading bit" in N parallel steps, DBL is created. In the first line, the leading bit of 2N-bit Huffman code string #i is given (note that, as mentioned above, the leading bit of 2N-bit Huffman code string #0 is always 0), and the following operations are performed: In step S101, the dbl.first decodable index is calculated. In step S102, the length of DBL is calculated. Step S103: Based on the correspondence of the leading impermissible bits calculated in advance, the leading impermissible bit of the 2N-bit Huffman code string #(i+1) is determined.

[0065] We will particularly focus on the part that calculates the length of DBL. The non-leading bit t means that "when scanning a 2N-bit Huffman code sequence from index 0 to N-1, t bits cannot be the beginning of the code." Therefore, in the pseudocode, variable p, along with the non-leading bit, is treated as a variable that indicates "how many more bits cannot be the beginning of the code." The for statement scans the index from 0 to N-1 while decrementing variable p. Then, when p == 0, index i is the beginning of the code, so the code length is set to length[i] of DBL and simultaneously added to variable p. Furthermore, when p ≠ 0, it can be determined that index i is not the beginning of the code, so dbl.index[i] is set to 0.

[0066] (How to create a DIS) Figure 7 shows the correspondence between DBL and DIS for a 32-bit Huffman code string. The elementNum of DIS indicates the number of the beginning of the Huffman code in the first 16 bits of the 32-bit Huffman code string. In this figure, the beginning of the Huffman code is at index [2], index [7], and index

[10] in the 32-bit Huffman code string, so elementNum is 3. The elementNum of DIS can be created by counting the number of non-zero elements in the length array of DBL.

[0067] The DIS index indicates the index of the beginning of the Huffman code in the first 16 bits of the 32-bit Huffman code string. In this diagram, the beginning of the Huffman code is at index [2], index [7], and index

[10] of the 32-bit Huffman code string, so the DIS index elements are 2, 7, and 10. Note that the DIS index has 8 elements, so any value between 2 and 15 may be assigned to DIS index [3] and onwards, but this does not affect decoding. The DIS index can be created by enumerating the indices of the non-zero elements in the DBL length array.

[0068] FIG. 14 shows an example of a decoding device according to the present disclosure. In this embodiment, an example will be described in which a decoding device 91 decodes a variable-length code sequence (hereinafter referred to as a code stream) encoded using Huffman codes. The decoding device 91 includes a data width expansion unit 11, a data format conversion unit 12, a FIFO 16, and a decoding unit 17, and executes the decoding method according to the present disclosure. The data width expansion unit 11 and the data format conversion unit 12 perform decryption 431 of the Huffman code sequence. The decoding unit 17 performs recalculation 432 of pixel values.

[0069] The data width expander 11 receives N bits of the code stream every clock. Meanwhile, the data width expander 11 outputs 2N-bit data by concatenating two N-bit inputs received at a given clock and the clock immediately before. The data width expander 11 is capable of outputting every clock. While the present embodiment illustrates an example in which 2N-bit data is used by concatenating two N-bit inputs received at a given clock and the clock immediately before, the present disclosure only requires that data of two or more maximum codeword lengths after encoding be concatenated and decoded at once. That is, the number of N bits may be three or more. Furthermore, when reading this data, it is not necessary to read the first 16 bits in one clock and the subsequent 16 bits in one clock.

[0070] The FIFO 16 temporarily stores 2N-bit data output from the data width expansion unit 11. The depth of the FIFO 16 is set to be greater than the number of latency clocks for processing by the data format conversion unit 12. An operation timing chart of the FIFO 16 is omitted.

[0071] The data format conversion unit 12 derives an "intermediate data format" for 2N-bit data, and then converts it into a "final data format." Here, we will explain how the "intermediate data format" and "final data format" affect the decoding of compressed code data. FIG. 15 shows 2N-bit compressed code data (denoted as "compressed code data 201" in the figure) when N=15, as well as the corresponding "intermediate data format" (denoted as "intermediate data format 202" in the figure) and "final data format" (denoted as "final data format 203" in the figure). The value of N=15 is determined by the maximum code length of the entropy code. For example, when the code length of a Huffman code is 2 to 15 bits, N=15.

[0072] Compressed code data 201 shows data of 2N bits in length (30 bits in the figure because N=15) as compressed code data. Here, the compressed code obtained by compressing symbol "A" is stored in bits 0 to 2, the compressed code obtained by compressing symbol "B" in bits 3 to 4, and the compressed code obtained by compressing symbol "C" in bits 5 to 6, and symbols "E" to "J" are also stored as shown in the figure. However, although the compressed code obtained by compressing symbol "J" could actually be multiple bits in length, processing is performed in 2N-bit units, so in the figure only the first bit of the compressed code is included in bit 29.

[0073] The intermediate data format 202 indicates the position of the beginning of a code from bits 0 to N in the compressed code data 201. If the beginning of a code is present at a certain position, the code length of that code is stored. If the beginning of a code is not present at a certain position, 0 is stored. For example, in the case of FIG. 15, the compressed code obtained by compressing the symbol "A" is located at bits 0 to 2, so the code length "3" of the compressed code obtained by compressing the symbol A is stored in the portion representing bit 0 of the intermediate data format 202. On the other hand, bits 1 and 2 are not the beginning of the compressed code, so "0" is stored in the position corresponding to these bits. In this way, there is a correspondence between the code position and code length between the compressed code data 201 and the intermediate data format 202, which is represented by arrows in the figure.

[0074] The final data format 203 is a data format that further aggregates the information in the intermediate data format 202. The final data format 203 stores the start positions of decodable codes in the N-bit compressed code data and the number of decodable codes. This information can be prepared using the intermediate data format 202, and the correspondence between this information is represented by the arrows between the intermediate data format 202 and the final data format 203 in FIG. 15.

[0075] Next, an overview of the operation of the decoding unit 17 will be described with reference to Fig. 16. The decoding unit 17 is a module that receives N-bit compressed code data as input and outputs the decoded result of the code included in the beginning of the input data. Note that the decoding unit 17 alone is capable of decoding only one code at a time. Therefore, in order for the decoding unit 17 to be able to handle ceil(N / M_min), which is the maximum number of codes that can be included in N-bit compressed code data, ceil(N / M_min) decoding units 17 must also be implemented in parallel.

[0076] Meanwhile, the decoder 17 receives N-bit compressed code data as input, while a module "group" of the decoder 17 is provided with 2N-bit compressed code data and a "final data format" as shown in Fig. 14. Therefore, for accurate decoding, an additional mechanism is required to inform each decoder 17 whether the N-bit compressed code data provided thereto can be decoded based on information about the number of decodable codes in the "final data format," which extracts N-bit compressed code data from the 2N-bit compressed code data so that a decodable code is included at the beginning based on information about the start position of decodable codes in the "final data format." The decoding process using the decoder 17 will now be described.

[0077] In the figure, compressed code data 301 and final data format 302 are used as input examples. A decoder 303 provided in the decoding unit 17 uses this information to extract N bits of data starting from bit 0 of the 2N-bit compressed code data. The first three bits of this data store a compressed code obtained by compressing symbol A, and the remaining part stores compressed codes of other symbols. A decoding result A (decoded symbol 304) corresponding to this N-bit data is then obtained. Note that one method of decoding this is to prepare a memory in which the decoding result is saved, provide N-bit data as an address, and obtain the decoded result; however, since various decoding methods are possible, specific steps will not be described in this application.

[0078] As an example, consider a case where ceil(N / M_min) decoders 17 are used to perform decoding using compressed code data 201 and a final data format 203. In this case, the first decoder 303 obtains "0", which is the first element of the "start position of decodable code" in the final data format 203, and performs decoding using bits 0 to 14 of the compressed code data 201 as input. Next, the second decoder 303 obtains "3", which is the second element of the "start position of decodable code" in the final data format 203, and performs decoding using bits 3 to 17 of the compressed code data 201 as input. By performing this operation for all decoders 303, multiple decoded values ​​can be obtained.

[0079] The number of elements in the "final data format" can be calculated as ceil(N / M_min) because the maximum number of compressed codes included in an N-bit code is ceil(N / M_min) when the bit length for adding a decodable marker is N bits and the minimum code length is M_min bits. Therefore, by providing ceil(N / M_min) decoders 17, it is possible to decompress in parallel all codes that can be included in the N-bit compressed code data within one clock cycle.

[0080] As described above, the decoding device 91 according to the present disclosure can decompress in parallel all codes that may be included in compressed code data.

[0081] (Second embodiment) An example of a decoding device according to the present disclosure is shown in Fig. 17. This embodiment includes a data width expansion module 101, a decoder 107, a code length acquisition decoder 102, a leading unusable bit length calculation module 103, a decoding start possibility determination module 104, an intermediate data format conversion module 105, and a 2N bit width FIFO 106.

[0082] The data width expansion module 101 functions as the data width expansion unit 11. The decoder 107 functions as the decoding unit 17. The code length acquisition decoder 102, the leading unusable bit length calculation module 103, the decoding start possibility determination module 104, and the intermediate data format conversion module 105 function as the data format conversion unit 12. The 2N bit width FIFO 106 functions as the FIFO 16.

[0083] Furthermore, the number of decoded values ​​obtained by decoder 107 ranges from 1 to ceil(N / M_min). On the other hand, when considering connecting the present disclosure to an external mechanism, it may be desirable for the number of decoded values ​​output in one clock cycle to be a fixed number. Therefore, the decoding device 91 of this embodiment includes a FIFO 108 with a barrel shifter function.

[0084] The FIFO 108 with barrel shifter function receives 1 to ceil(N / M_min) decoded values ​​as input and outputs a fixed number of decoded values ​​using a barrel shifter mechanism. This module can be easily created using existing technologies such as a barrel shifter and serial-parallel conversion.

[0085] (Third embodiment) Only the first 15-bit block of a compressed code string is guaranteed to have a leading bit length of 0. The leading bit length of other 15-bit blocks can be obtained by giving the leading bit length to the 15-bit block before it and calculating "how many bits of code will protrude." Since markers are added to the 15-bit marked range every clock, it is necessary to calculate "how many bits of code will protrude (leading bit length of the next 15-bit block)" within one clock cycle after the leading bit length of your own 15-bit block is given. This section explains how to calculate "how many bits of code will protrude (leading bit length of the next 15-bit block)" within one clock cycle after the leading bit length of your own 15-bit block is given.

[0086] Because the minimum code length is 2 bits, when the given leading bit length is 0, the while loop can be executed eight times. This means that eight additions, variable updates, magnitude comparisons, and subtractions can occur within one clock cycle, making it difficult to increase the operating frequency. Using Vitis HLS 2021.1 and the Zynq7020, it was not possible to synthesize a circuit with an operating frequency of 150 MHz and a throughput of one output per clock.

[0087] The pair of "leading bit length that cannot be given to one's own 15-bit block" and "how many bits the code will protrude (leading bit length that cannot be given to the next 15-bit block)" is calculated and stored in advance. As soon as the leading bit length that cannot be given to one's own 15-bit block, the above pair is referenced to obtain the leading bit length of the next 15-bit block. By preparing the calculation results in advance, the work done in one clock cycle can be limited to "accessing memory". Since preparation is made for all patterns of leading bit lengths that cannot be given, the required throughput of this module is 1 (15-bit block) / 1 clock, but it does not matter how many clocks it takes for latency.

[0088] In the actual implementation, the calculation of the pair of "the length of the leading bits that cannot be given to one's own 15-bit block" and "how many bits the code will protrude (the length of the leading bits that cannot be given to the next 15-bit block)" took 15 clocks, and was calculated by creating the table shown in Figure 18 row by row from left to right. This method allows for pipeline processing, so a throughput of 1 (15-bit block) / 1 clock was achieved.

[0089] (Fourth embodiment) In this embodiment, the marker adding process will be described. The marker adding process is performed using the following modules. (i) 0th bit decoding start possibility determination module 104 (ii) Decoding start possibility determination module 104 for 1 to 14 bits In this way, the marker assignment process is realized by 15 decoding start possibility determination modules 104. Each module is responsible for a respective bit of the 15-bit block. For example, the D#0 module is responsible for the 0th bit of the 15-bit block.

[0090] 19 shows an example of marker output. In the figure, the decoding start possibility determination modules 104 are represented as D#0 to D#14. If the bit they are responsible for is the beginning of the code, the decoding start possibility determination modules D#0 to D#14 output the code length as a marker, otherwise they output 0. For example, if the code length of the 4th bit is 2, the decoding start possibility determination module D#0 for the 4th bit outputs a marker of "2". For example, in the example shown in the figure, the leading bit length that cannot be assigned to the 2 Kbit is 0.

[0091] The 0th decoding start possibility determination module D#0 receives the leading impossible bit. If the code length of the 0th bit is 3, the 0th decoding start possibility determination module D#0 outputs a marker of "3".

[0092] Here, the ith decoding start possibility determination module D#i receives a signal indicating "how many more bit codes continue" from the adjacent decoding start possibility determination module D#i-1. For example, the decoding start possibility determination module D#0 outputs to the decoding start possibility determination module D#1 that a 2-bit code continues, the decoding start possibility determination module D#1 outputs to the decoding start possibility determination module D#2 that a 1-bit code continues, and the decoding start possibility determination module D#2 outputs to the decoding start possibility determination module D#3 that a 0-bit code continues.

[0093] In this way, if this value is other than 0, the decoding start possibility determination module D#i sends how many more bits of code continue to the right (i+1th) decoding start possibility determination module D#i+1. If this value is 0, the i-th bit is the beginning of the code, so the decoding start possibility determination module D#i sends the code length of the code starting from the i-th bit -1 to the right (i+1th) decoding start possibility determination module D#i+1, and at the same time outputs the code length at the marker output of its own module.

[0094] For each 30-bit chunk, 15 decoders are prepared in parallel, each shifting its position by 1 bit, and a valid decoded value is obtained by "trusting the decoded value of data with a marker in the first bit" and "not trusting the decoded value of data without a marker in the first bit." As a result, in this embodiment, the marker value of 300202040002070 is output from the decoding start possibility determination modules D#0 to D#14.

[0095] In this case, as shown in Figure 20, if the output of the Nth clock is 0111111101011, the output of the N+1th clock will be a compressed code string with the leading bit shifted by 3 bits corresponding to a code length of 3, the output of the N+2th clock will be a compressed code string with the leading bit shifted by 2 bits corresponding to a code length of 3, and the output of the N+3th clock will be a compressed code string with the leading bit shifted by 2 bits corresponding to a code length of 3.

[0096] As shown in Fig. 21, the decoder 107 can refer to a decoding table corresponding to Fig. 1 and reads out decoded values ​​corresponding to the compressed code sequence. In this embodiment, since the compressed code sequence is 0111111101011, the decoder 107 outputs a decoded value of "1" corresponding to the code sequence "011", a decoded value of "0" corresponding to the code sequence "11", a decoded value of "0" corresponding to the code sequence "11", a decoded value of "255" corresponding to the code sequence "101", and a decoded value of "1" corresponding to the code sequence "011". These output values ​​correspond to the errors with adjacent pixel values.

[0097] (Fifth embodiment) In this embodiment, the configuration of a code length acquisition decoder will be described. There are two possible methods for implementing a code-code length memory table. The first is to use BRAM, and the second is to create a lookup table. In this embodiment, 15 code length acquisition decoders are required. The 15 code length acquisition decoders can be configured by connecting three five-input lookup tables.

[0098] An example of three lookup tables is shown in Fig. 22. The first lookup table LUT0 is looked up for bit 0 to bit 1, the second lookup table LUT1 is looked up for bit 2 to bit 3, and the third lookup table LUT2 is looked up for bit 2. For bits 0 to 1, if the value is "01" or "10", the code length "2" is output.

[0099] When the value from bit 0 to bit 1 is "00", the value from bit 2 to bit 3 is compared with the second lookup table LUT1. When the value from bit 2 to bit 3 is "00" or "01", the code length "4" is output. When the value from bit 0 to bit 1 is "11", the value of bit 2 is compared with the third lookup table LUT3. When the value of bit 2 is "0" or "1", the code length "3" is output.

[0100] In this disclosure, since the number of code length types is smaller than the number of code types, so-called "pruning" can be performed to implement the process efficiently. As a result, by connecting two lookup tables as shown in Figure 23, it is possible to implement the process equivalent to 15 code length acquisition decoders.

[0101] (Other embodiments) The decoding device 91 and the encoding device 92 of the present disclosure can also be realized by a computer and a program, and the program can be recorded on a recording medium or provided via a network.

[0102] In the above embodiment, the data types DBL and DIS are defined, but the data types may not be DBL and DIS, and may be any data type that indicates the number of decodable codes or the starting position of the decodable codes for a bit string of a length determined per clock or a bit string that is a bundle of such bit strings.

[0103] Here, in this disclosure, the 2N-bit Huffman code sequence #i (1) Results of code length acquisition using N parallel operations (2) Leading bit not allowed After obtaining the above, a data type is created to determine which result of the code length obtainers operated in N parallel is to be trusted. This data type can have any configuration as long as it is possible to specify which result of the code length obtainers operated in N parallel is to be trusted.

[0104] Specifically, the following configurations a to c are possible. Configuration a. Data indicating the instance number #i of the first trusted code length acquirer. A data array consisting of bN elements, in which only elements corresponding to instances of trusted code length acquirers store some data indicating that "the output can be trusted." Configuration c: A data array in which the instance number #i of the trusted code length acquirer is stored.

[0105] In the above embodiment, the data type consisting of the data types of configurations a and b is called DBL, and the data type consisting of configuration c is called DIS. As mentioned above, any configuration may be used for decoding as long as the purpose is to identify which result of the code length obtainers operated in N parallel is to be trusted.

[0106] In the above embodiment, decoding of static Huffman codes defined in HuffYUV is described as a specific example, but the present disclosure is not limited to static Huffman codes or video encoding for the purpose of data compression, and can be applied to any encoding method in which the symbols to be encoded and their corresponding codes are predetermined.

[0107] The present invention provides the following two advantages. (1) When watching streaming video, it is possible to implement low-latency video compression processing in hardware, such as transmitting only the difference between adjacent pixel values ​​without requiring conversion operations, and it provides Huffman decoding performance with a throughput of 1 (decoded data / clock cycle) or more to obtain decoded data after a certain code string is input. (2) When decoding multiple codes at each clock from a stream in which one code spans two input data strings and the first few bits of the input data string may not be the beginning of the code, a "parallel decoding pipeline" process can be used, which calculates decodable positions simultaneously in parallel so as to cover all potential patterns of decoding start positions when decoding the input data string. Then, from these parallel-calculated decoding results, the parallel decoding pipeline selects the correct result using the decoding start position revealed by the decoding of the previous input data string, shifts the input data string so that decoding can start from bit 0, and proceeds with the decoding process. This method increases resources by preparing multiple "parallel decoding pipelines." Let the bit width of the input data string be N (bits) and the minimum code length of the Huffman code be M. min , the maximum code length is M max (However, M min ≦M max ≦N), the total number of code length extractors and barrel shifters consumed by the entire parallel decoding pipeline is (M max ×(ceil(N / M min In the present invention, it is possible to process the same functions as above with N code length obtainers and one barrel shifter, thereby making it possible to save on consumed resources. [Explanation of symbols]

[0108] 11: Data width expansion section 12: Data format conversion section 16:FIFO 17: Decryption unit 21: Encoding section 22: Data format conversion unit 23: Data width reduction section 91: Decryption device 92: Encoding device 101: Data width expansion module 102: Decoder for code length acquisition 103: Leading bit length calculation module 104: Decryption start possibility determination module 105: Intermediate data format conversion module 106:2N bit width FIFO 107: Decoder 108: FIFO with barrel shifter function 411: Preprocessing section 412: Prediction Department 413: Frequency conversion unit 414: Quantization section 415: Code assignment unit 421: Code Decoding Unit 422: Inverse quantization section 423: Inverse conversion unit 242: Predictive decoding unit 425: Post-processing section 431: Huffman code decoding section 432: Pixel value recalculation unit

Claims

1. Obtaining a predetermined number of bits of variable-length code string data encoded using entropy code for each clock; decoding the data of the predetermined number of bits for each clock using reference information obtained from the plurality of data of the predetermined number of bits; Decryption device.

2. Detecting the start position and code length of the code from the data of the predetermined number of bits; acquiring, as the reference information, the start position and code length of a code included in the data of the predetermined number of bits; The decoding device according to claim 1 .

3. calculating leading bits indicating how many bits from the beginning of the data of the predetermined number of bits are not the beginning of the code, thereby obtaining, as the reference information, information indicating a reliable code length among the code lengths detected from the data of the predetermined number of bits; decoding the data of the variable-length code string using the obtained reliable code length; The decoding device according to claim 1 .

4. the data of the variable-length code sequence is video data, the entropy code is a Huffman code; The decoding device according to claim 1 .

5. the predetermined number of bits is determined by the maximum code length of the entropy code; The decoding device according to claim 1 .

6. a transmitting device that transmits data of a variable-length code sequence using an entropy code; a decoding device according to any one of claims 1 to 5, which decodes data of a variable-length code sequence transmitted from the transmitting device; A transmission system comprising:

7. Obtaining a predetermined number of bits of variable-length code string data encoded using entropy code for each clock; decoding the data of the predetermined number of bits for each clock using reference information obtained from the plurality of data of the predetermined number of bits; Decryption method.

Images