Encoder, decoder and data processing system
Granted 27 Jan 2015 · no office action yet
Assignee: Toshiba
Law firm: Law firm · Log in to unlock
Attorney: Attorney · Log in to unlock
Inventors: Sho Kodama · Examiner: Joseph Lauture · AU 2845 · TC 2800
Life of the application
5 dated eventsAbstract
According to one embodiment, a data processing system has an encoder and a decoder. The encoder is configured to variable-length encode input data to generate an encoded stream. The decoder is configured to decode the encoded stream to generate output data. The encoder has a variable length encoder, a code converter, and a buffer. The variable length encoder is configured to variable-length-encode the input data to generate first variable length codes. The code converter is configured to convert n first variable length codes into a second variable length code. The buffer is configured to buffer the second variable length code to generate the encoded stream.
Description
9 parts›CROSS REFERENCE TO RELATED APPLICATIONS
This application is based upon and claims the benefit of priority from the prior Japanese Patent Application No. 2013-192070, filed on Sep. 17, 2013, the entire contents of which are incorporated herein by reference.
›FIELD
Embodiments described herein relate generally to an encoder, a decoder and a data processing system.
›BACKGROUND
It is possible to shorten processing time by cutting out two or more variable length codes for each cycle when decoding an encoded stream obtained by variable-length-encoding input data. For this purpose, a plurality of variable length codes included in the encoded stream is packed to be processed in parallel. However, when a plurality of variable length codes is packed, the number of patterns of code lengths thereof increases.
If the number of patterns of code lengths increases, the number of entries of a table used for deriving the code length of the variable length code increases, and thus, delay in process might become greater.
›BRIEF DESCRIPTION QF THE DRAWINGS
FIG. 1 is a block diagram of a schematic configuration of a data processing system according to a first embodiment.
FIG. 2 is a flowchart of an example of processing operation of the encoder 1 .
FIG. 3 is a view for illustrating an example of a process of the variable length encoder 11 .
FIG. 4 is a block diagram of an example of an internal configuration of the code converter 12 .
FIG. 5 is a view of an example of the conversion table 12 a.
FIG. 6 is a flowchart of an example of a procedure for generating the conversion table 12 a in FIG. 5 .
FIG. 7 is a flowchart of an example of a process of the decoder 2 .
FIG. 8 is a view of relationship between the prefix Pre-T and the code length.
FIG. 9 is a view of an example of a procedure for generating the conversion table 12 a.
FIGS. 10 to 13 are views of the conversion table 12 a generated by the procedure in FIG. 9
FIG. 14 is a view of relationship between the prefix Pre-T and the code length.
FIG. 15 is a view of input/output relationship of a variable length encoder 11 in a case in which the input data is 0 to 3.
FIG. 16 is a view of combinations of prefixes Pre 0 to Pre 2 of codes VLC 0 to VLC 2 .
FIG. 17 is a flowchart of an example of a procedure for generating the conversion table 12 a by using the binary tree.
FIG. 18 is a view of the binary tree based on the procedure in FIG. 17 .
FIG. 19 is a view of the conversion table 12 a generated by the procedure in FIG. 17 .
FIG. 20 is a view of relationship between the code VLC-T and the code length.
›DETAILED DESCRIPTION · 1 of 5
In general, according to one embodiment, a data processing system has an encoder and a decoder. The encoder is configured to variable-length encode input data to generate an encoded stream. The decoder is configured to decode the encoded stream to generate output data.
The encoder has a variable length encoder, a code converter, and a buffer. The variable length encoder is configured to variable-length-encode the input data to generate first variable length codes. The code converter is configured to convert n first variable length codes into a second variable length code. The buffer is configured to buffer the second variable length code to generate the encoded stream.
The decoder has a code length deriving module, a cutout module, a code reverse-converter, and a variable length decoder. The code length deriving module is configured to derive a code length of the second variable length code by using at least a part of the second variable length code as an index. The cutout module is configured to cut out the second variable length code from the encoded stream based on the derived code length. The code reverse-converter is configured to convert the second variable length code into the n first variable length codes. The variable length decoder is configured to decode the first variable length code to generate the output data.
A number of patterns of code lengths of the first variable length code is m. The number of indices is smaller than m n . Hereinafter, embodiments are specifically described with reference to the drawings.
First Embodiment
FIG. 1 is a block diagram of a schematic configuration of a data processing system according to a first embodiment. A data processing system 100 is provided with an encoder 1 and a decoder 2 . The data processing system 100 is configured to generate an encoded stream by encoding input data by the encoder 1 , and to obtain output data by decoding the encoded stream by the decoder 2 .
The encoder 1 will be described. The encoder 1 includes a variable length encoder 11 , a code converter 12 , and a packing buffer (output module) 13 . The variable length encoder 11 performs Golomb-Rice encoding of the input data to generate a Golomb-Rice code (first variable length code) VLC. The code converter 12 converts n (n is an integer not smaller than 2) Golomb-Rice codes VLCs into one code (second variable length code) VLC-T. The packing buffer 13 buffers the code VLC-T and outputs the same as the encoded stream when a predetermined bit length is obtained.
FIG. 2 is a flowchart of an example of processing operation of the encoder 1 . The variable length encoder 11 first performs the Golomb-Rice encoding of the input data to generate the Golomb-Rice code VLC (S 1 ).
FIG. 3 is a view for illustrating an example of a process of the variable length encoder 11 in which relationship between a value of the input data inputted to the variable length encoder 11 and a value of the code VLC outputted from the variable length encoder 11 is illustrated. The code VLC is formed of a variable length prefix Pre and a fixed length suffix Suf and a least significant bit thereof is the suffix Suf. Meanwhile, in FIG. 3 , the input data is assumed to be one of ten values from 0 to 9. In this case, the code VLC may have five patterns of code lengths of 2 to 6.
When the input data is 0 and 1, the prefix Pre is 1-bit “1”. When the input data is 2 or larger, the prefix Pre has a value obtained by combining ceil {(input data−1)/2}-bit “0” and one “1” (ceil {x} is a ceiling function and {x} represents a minimum integer not smaller than x). The suffix Suf is a 1-bit value which is “0” when the input data is an even number and “1” when this is an odd number. When the input data is 2, for example, prefix Pre=“01” and suffix Suf=“0”, so that VLC=“010”. Next, the code converter 12 packs three codes VLCs to convert the packed three codes VLCs into one code VLC-T (S 2 ). A high-speed process at the time of decoding may be realized by packing a plurality of codes. Hereinafter, the three codes VLCs are made VLC 0 , VLC 1 , and VLC 2 , prefixes thereof are made Pre 0 to Pre 2 and suffixes thereof are made Suf 0 to Suf 2 . The packing buffer 13 buffers the generated code VLC-T (S 3 ) and outputs the same as the encoded stream.
FIG. 4 is a block diagram of an example of an internal configuration of the code converter 12 . The code converter 12 includes a conversion table 12 a , a combining module 12 b , and a table generator 12 c.
The conversion table 12 a generates a prefix Pre-T and a suffix Suf-T of the code VLC-T from the prefixes Pre 0 to Pre 2 of the codes VLC 0 to VLC 2 , respectively. The lengths of the prefix Pre-T and the suffix Suf-T are variable.
The combining module 12 b combines the generated prefix Pre-T and suffix Suf-T and the suffixes Suf 0 to Suf 2 to generate the code VLC-T. That is to say, the code VLC-T is formed of the variable length prefix Pre-T and suffix Suf-T and fixed length suffixes Suf 0 to Suf 2 . Therefore, a code length of the code VLC-T is obtained by adding 3 bits of the suffixes Suf 0 to Suf 2 to a bit length of the prefix Pre-T and a bit length of the suffix Suf-T.
FIG. 5 is a view of an example of the conversion table 12 a . The conversion table 12 a specifies the prefix Pre-T and the suffix Suf-T from the prefixes Pre 0 to Pre 2 . Such relationship between the prefixes Pre 0 to Pre 2 and the prefix Pre-T and suffix Suf-T is generated by the table generator 12 c in advance. Meanwhile, “group” and “code length of VLC-T” are also illustrated in FIG. 5 .
As an example, in a case of (VLC 0 , VLC 1 , VLC 2 )=(“010”, “011”, “11”), “01011” is obtained by combining the prefixes Pre 0 to Pre 2 , so that Pre-T=“001” and Suf-T=“100”. As a result, VLC-T =“001100011”.
FIG. 6 is a flowchart of an example of a procedure for generating the conversion table 12 a in FIG. 5 . First, all combinations of the prefixes (Pre 0 & Pre 1 & Pre 2 ) generated by the three codes VLC 0 to VLC 2 are enumerated (S 11 ). In the example in FIG. 3 , there are five patterns of prefixes, so that 5 3 =125 types of combinations of the prefixes are generated by the codes VLC 0 to VLC 2 .
›DETAILED DESCRIPTION · 2 of 5
Subsequently, the combinations having a same total bit length among the generated combinations of three prefixes (Pre 0 & Pre 1 & Pre 2 ) are grouped and groups D 0 to Dm are generated by the table generator 12 c (S 12 ). Meanwhile, the above-described total bit length becomes longer in order from the group D 0 to group Dm. In the example in FIG. 3 , the total bit length of the combination of the prefixes (Pre 0 & Pre 1 & Pre 2 ) is 3 bits at a minimum and 15 bits at a maximum, and 13 groups D 0 to D 12 are generated. An initial value of k is set to 0 (S 13 ) and the table generator 12 c sequentially selects a group Dk (S 14 ).
The prefix Pre-T and the suffix Suf-T are assigned to the group Dk in a following manner. The prefix Pre-T of the group Dk is obtained by combining “0” with a most significant bit of the prefix of a group Dk−1 (S 15 ). Then, the suffix Suf-T having the bit length of ceil {log 2(|Dk|)} is assigned to the combination of the prefixes included in the group Dk (S 16 ). Herein, |Dk| represents the number of combinations included in the group Dk. However, Pre-T of the group D 0 is set to “1” (S 15 ). The suffix is not assigned to the group D 0 (S 16 ).
For example, the prefix Pre-T of the group D 1 is obtained as Pre-T=“01” by combining “0” with the most significant bit of the prefix “1” of the group D 0 (S 15 ). The suffix Suf-T has the bit length of ceil {log 2(|D 1 |)}=2 bits for the number of combinations included in the group D 1 |D 1 |=4. The table generator 12 c assigns the suffixes Suf-T “00”, “01”, and “10” to the combinations of the prefixes (Pre 0 & Pre 1 & Pre 2 )=“1101”, “1011”, and “0111” in the group D 1 , respectively (S 16 ).
Hereinafter, the prefix Pre-T and the suffix Suf-T are assigned to all the groups D 0 to Dm while incrementing k by 1 (S 17 and S 18 ). According to this, an inherent prefix Pre-T of different bit length is assigned to each of the groups D 0 to Dm.
The conversion table 12 a illustrated in FIG. 5 is generated in the above-described manner. In FIG. 5 , it should be noted that there is one-to-one correspondence between the value of the prefix Pre-T and the code length of the code VLC-T. For example, when the prefix Pre-T is “1”, the code length of the code VLC-T has 4 bits. When the prefix Pre-T is “01”, the code length of the code VLC-T has 7 bits. According to this, it is possible to derive the code length of the code VLC-T by using the prefix Pre-T of the code VLC-T as an index.
Subsequently, the decoder 2 will be described. The decoder 2 includes an encoded stream buffer 21 , a code length deriving module 22 , a variable length code cutout module 23 , a code reverse-converter 24 , and a variable length decoder 25 .
The encoded stream buffer 21 buffers the encoded stream and shifts the encoded stream by the code length of the variable length code. The code length deriving module 22 derives the code length of each code VLC-T included in the encoded stream. The code length is supplied to the encoded stream buffer 21 and the variable length code cutout module 23 .
The variable length code cutout module 23 cuts out each code VLC-T from the encoded stream based on the supplied code length. The code reverse-converter 24 performs a process opposite to that of the code converter 12 on the code VLC-T to generate the Golomb-Rice codes VLC 0 to VLC 2 . The variable length decoder 25 performs Golomb-Rice decoding of the Golomb-Rice code VLC to generate the output data.
FIG. 7 is a flowchart of an example of a process of the decoder 2 . First, the encoded stream buffer 21 buffers the encoded stream (S 21 ). Subsequently, the code length deriving module 22 refers to the prefix Pre-T in the encoded stream to derive the code length of each code VLC-T (S 22 ). Meanwhile, as is clear from FIG. 5 , in the code VLC-T, a part from the top to first “1” is the prefix Pre-T. FIG. 8 is a view of relationship between the prefix Pre-T and the code length. There is one-to-one correspondence between the value of the prefix Pre-T and the code length of the code VLC-T. Therefore, the code length deriving module 22 may detect the prefix Pre-T in the encoded stream and may uniquely derive the code length of the code VLC-T by using the prefix Pre-T as the index. When the code length is derived, the variable length code cutout module 23 cuts out the code VLC-T from the encoded stream (S 23 ).
In this embodiment, the number of entries in the table for deriving the code length is 13. The number of entries corresponds to the number of groups. If the code converter 12 does not perform a converting process at the time of encoding, there are 5 3 =125 types of prefixes of the three codes VLCs having five patterns of code lengths. That is to say, the table having 125 entries is required for deriving the code length. In more general, when there are m patterns of code lengths of the code VLC and one code VLC-T is generated from n codes VLCs, entries are required.
On the other hand, in this embodiment, the codes VLC 0 to VLC 2 are converted into the code VLC-T having the prefix Pre-T corresponding to the total bit length of the combination of the prefixes Pre 0 to Pre 2 . There are 13 types, namely from 3 to 15, of total bit lengths of the combinations of the prefixes Pre 0 to Pre 2 , so that the number of entries of the table may be reduced to 13. That is to say, in this embodiment, the number of entries may be made smaller than the general number of entries m n .
Subsequently, the code reverse-converter 24 performs the process opposite to that of the code converter 12 to the code VLC-T to generate the Golomb-Rice codes VLC 0 to VLC 2 (S 24 ). Specifically, the code reverse-converter 24 first refers to a conversion table to specify the suffix Suf-T from the prefix Pre-T. For example, when prefix Pre-T=“001”, the bit length of the suffix Suf-T is 3 bits and it is possible to specify the value of the suffix Suf-T. Meanwhile, as the conversion table to be referred to, the code reverse-converter 24 may have the conversion table similar to the conversion table 12 a in advance or the conversion table may be is generated by using a table generator similar to the code converter 12 .
›DETAILED DESCRIPTION · 3 of 5
Further, the code reverse-converter 24 specifies the prefixes Pre 0 to Pre 2 forming VLC 0 to VLC 2 , respectively, from the prefix Pre-T and the suffix Suf-T. For example, when prefix Pre-T=“001” and suffix Suf-T=“001”, (Pre 0 , Pre 1 , Pre 2 )=(“1”, “001”, “1”).
Then, the code reverse-converter 24 specifies the suffixes Suf 0 to Suf 2 forming the codes VLC 0 to VLC 2 , respectively, from the bits added after the suffix Suf-T of the code VLC-T. From above, the code reverse-converter 24 may obtain the three codes VLC 0 to VLC 2 from the code VLC-T. Then, the variable length decoder 25 performs the Golomb-Rice decoding of the Golomb-Rice codes VLC 0 to VLC 2 to generate the output data (S 25 ).
In the first embodiment, the codes VLC 0 to VLC 2 are converted into the code VLC-T including the prefix Pre-T corresponding to a total sum of prefix lengths thereof. Therefore, the code length may be easily derived by the table having a small number of entries at the time of decoding.
Second Embodiment
In a second embodiment, a conversion table 12 a is different from that of the first embodiment. Hereinafter, differences from the first embodiment will be mainly described.
A schematic configuration of a data processing system of this embodiment is substantially similar to that illustrated in FIGS. 1 and 4 . A procedure of generating the conversion table 12 a by a table generator 12 c is different from that of the first embodiment.
FIG. 9 is a view of an example of a procedure for generating the conversion table 12 a . FIGS. 10 to 13 are views of the conversion table 12 a generated by the procedure in FIG. 9 . S 31 to S 33 in FIG. 9 are similar to S 11 to S 13 in FIG. 6 . Subsequently, the table generator 12 c selects two groups Dk and Dk+1 whose total bit lengths of combinations of prefixes are consecutive (S 34 ). A prefix Pre-T and a suffix Suf-T are assigned to every two groups Dk and Dk+1 in a following manner.
The prefix Pre-T is similar to that of the first embodiment (S 35 ). The table generator 12 c determines whether following equation (1) is satisfied (S 36 ).
Lp ( a )≧ceil{log 2(| Dk|+|Dk+ 1|)}, aεDk (1)
A left member Lp(a) of equation (1) represents the total bit length of the combination of the prefixes in the group Dk. For example, in a case of k=0, that is to say, when groups D 0 and D 1 are selected, Lp(a)=3.
When equation (1) is satisfied, the table generator 12 c sets a bit length of the suffix Suf-T to ceil {log 2(|Dk|+|Dk+1|)} bits (S 37 ). On the other hand, when equation (1) is not satisfied, the table generator 12 c sets the bit length of the suffix Suf-T for Dk and Dk+1 to ceil {log 2(|Dk|)} bits and ceil {log 2(|Dk+1|)} bits, respectively (S 38 ). Then, the table generator 12 c assigns an inherent value to each combination included in the groups Dk and Dk+1.
When equation (1) is not satisfied, following equation (1′) holds.
Lp ( a )≧ceil{log 2(| Dk|+|Dk+ 1|)}, aεDk (1′)
A right member of equation (1′) being the bit length of Suf-T corresponding to groups Dk and Dk+1 is larger than Lp(a), so that a compression rate is degraded as a result of code conversion regarding at least the group Dk. The degradation is represented as Pre-T+Suf-T−Lp(a). Therefore, in such a case, it is tried to reduce bits of Suf-T for Dk by setting the suffix length of Dk not to equation (1) but to ceil {log 2(|Dk|)}. Although the compression rate might be further degraded regarding Dk+1, an original code length of Dk is shorter than that of Dk+1 in consideration of selecting order of the group and generation probability of shorter code is higher as a precondition to the variable length code, so that Suf-T for Dk is preferentially reduced.
The above-described process is performed for every group (S 39 and S 40 ).
In this embodiment, one inherent prefix Pre-T is assigned to every two groups. There is one-to-one correspondence between the prefix Pre-T and a code length of a code VLC-T.
As for the group D 0 , the code length of the code VLC-T is 6 while a total code length of the codes VLC 0 to VLC 2 is 6. The compression rate is not degraded by the conversion into the code VLC-T. As for the group D 1 also, the compression rate is not degraded by the conversion into the code VLC-T.
As for a group D 2 , the code length of the code VLC-T is 9 while the total code length of the codes VLC 0 to VLC 2 is 8. The compression rate is merely degraded by 1 bit by the conversion into the code VLC-T. As for another group also, the compression rate is merely degraded by 2 bits at a maximum by the conversion into the code VLC-T.
In this manner, according to the method of this embodiment, the degradation in compression rate may be inhibited as compared to the first embodiment. FIG. 14 is a view of relationship between the prefix Pre-T and the code length. In this embodiment, the number of entries may be reduced to seven and the code length of the code VLC-T may be derived by using the prefix Pre-T as an index.
In the second embodiment, one prefix Pre-T is assigned to every two consecutive groups and the bit length of the suffix Suf-T is set based on equation (1). Therefore, the degradation in compression rate when the codes VLC 0 to VLC 2 are converted into one code VLC-T may be inhibited and the number of entries may be reduced.
Third Embodiment
In a third embodiment, a conversion table 12 a is generated by using a binary tree. Hereinafter, differences from the first and second embodiments will be mainly described.
In order to simplify the description, in this embodiment, it is supposed that input data may be one of four values from 0 to 3.
FIG. 15 is a view of input/output relationship of a variable length encoder 11 in a case in which the input data is 0 to 3. FIG. 16 is a view of combinations of prefixes Pre 0 to Pre 2 of codes VLC 0 to VLC 2 . A total bit length of the combination includes four types of 3 to 6 bits and they are made groups D 0 to D 3 , respectively.
FIG. 17 is a flowchart of an example of a procedure for generating the conversion table 12 a by using the binary tree. FIG. 18 is a view of the binary tree based on the procedure in FIG. 17 . Further, FIG. 19 is a view of the conversion table 12 a generated by the procedure in FIG. 17 . Meanwhile, in this embodiment, it is also possible that a code VLC-T generated by a code converter 12 does not include a suffix Suf-T.
›DETAILED DESCRIPTION · 4 of 5
S 41 to S 43 in FIG. 17 are similar to S 11 to S 13 in FIG. 6 , respectively. A table generator 12 c performs a following process at S 44 to S 48 for a group Dk.
First, the table generator 12 c adds a leaf node corresponding to each combination (S 44 ). Each leaf node includes a first label and a second label. The first label is the total bit length of the prefixes in the group Dk. The second label is a total bit length of the suffix of the group Dk, that is to say, 3. For example, three combinations “1101”, “1011”, and “0111” are included in the group D 1 , so that three leaf nodes L 1 to L 3 illustrated in FIG. 18 are added. The first label is 4 and the second label is 3.
Subsequently, the table generator 12 c adds a parent node whose child nodes are optional two leaf nodes as an internal node (S 46 ) until the number of leaf nodes which does not have the parent node becomes smaller than two (S 45 ). At that time, the first and second labels of the child nodes are taken over as the first and second labels of the internal node. For example, in the group D 1 , at first, there are three leaf nodes L 1 to L 3 which do not have the parent node. Therefore, the parent node whose child nodes are the leaf nodes L 1 and L 2 is added as an internal node I 1 illustrated in FIG. 18 , for example. According to this, only the leaf node L 3 does not have the parent node.
Subsequently, the table generator 12 c selects two nodes (when simply referred to as the “node”, this may be any of the internal node and the leaf node, the same applies hereinafter) which do not have the parent node until the number of nodes which do not have the parent node becomes smaller than two (S 47 ) and further adds the parent node whose child nodes are the two nodes as the internal node (S 48 ). When there is a plurality of internal nodes and leaf nodes which do not have the parent node, the leaf node is preferentially selected. At that time, the first and second labels of the child nodes are taken over as the first and second labels of the internal node. In an example of the group D 1 , at first, there are two nodes which do not have the parent node: the internal node I 1 and the leaf node L 3 . Therefore, the parent node whose child nodes are the internal node I 1 and the leaf node L 3 is added as an internal node I 2 in FIG. 18 . According to this, only the internal node I 2 does not have the parent node.
The above-described process is performed for all groups D 0 to Dm (S 49 and S 50 ). Subsequently, the table generator 12 c performs a following process at S 51 to S 54 across the groups.
The table generator 12 c selects two nodes which do not have the parent node until the number of nodes which do not have the parent node becomes one (S 51 ) and adds the parent node whose child nodes are the two nodes as the internal node (S 52 ). Two nodes are selected in descending order of a value of the first label as a selection criterion. When there is a plurality of nodes having a maximum value of the first label, two nodes are selected in descending order of a value of the second label therefrom. The first and second labels of the internal node are average values of the first and second labels of the child nodes. The internal node generated at the end becomes a root node and the binary tree is completed. For example, in FIG. 18 , the parent node whose child nodes are an internal node I 3 for the group D 2 and a leaf node L 4 for the group D 3 is added as an internal node I 4 . Subsequently, the parent node whose child nodes are the internal nodes 12 and 14 is added as an internal node I 5 . Further, the parent node whose child nodes are a leaf node L 5 for the group D 0 and the internal node I 5 is added as an internal node I 6 . At that time, only the internal node I 6 does not have the parent node. Therefore, the internal node I 6 becomes a root node R.
When the root node R is generated, the table generator 12 c assigns “0” or “1” to each branch (S 53 ). For example, “1” is assigned to the branch from the root node R to the leaf node L 5 and “0” is assigned to the branch from the root node R to the internal node I 5 . To other branches also, “0” or “1” is assigned. Meanwhile, “0” and “1” are optionally assigned to the branches and it is not limited to that in FIG. 18 .
Then, the table generator 12 c follows the binary tree from the root node and sets the code VLC-T for each combination of the prefixes corresponding to the leaf node (S 54 ). For example, “1” is assigned to the leaf node L 5 (combination of the prefixes “111”). Also, “0111” is assigned to the leaf node L 1 (combination of the prefixes “1101”).
In the above-described manner, the conversion table 12 a illustrated in FIG. 19 is generated. Meanwhile, the code VLC-T is obtained by combining suffixes Suf 0 to Suf 2 with the prefix Pre-T. Therefore, a code length of the code VLC-T is obtained by adding 3 bits of the suffixes Suf 0 to Suf 2 to a bit length of the prefix Pre-T. As is clear from FIG. 19 , the bit number of the converted prefix Pre-T does not become larger than the total bit number of the combination of the prefixes Pre 0 to Pre 2 and degradation in compression rate by the conversion does not occur.
FIG. 20 is a view of relationship between the code VLC-T and the code length. In this embodiment, a code length deriving module 22 derives the code length based on the prefix Pre-T or a part of top bits thereof. For example, regardless of whether the prefix Pre-T is “0111” or “0110”, the code length of the code VLC-T is 7 bits. Therefore, when top 3 bits of the code VLC-T are “011” (that is to say, regardless of whether a fourth bit is “0” or “1”), the code length of the code VLC-T is uniquely determined to be 7 bits.
If the code converter 12 does not convert, the code length deriving module 22 requires a table having eight entries. On the other hand, in this embodiment, the number of entries may be reduced to six as illustrated in FIG. 20 .
In this manner, in the third embodiment, the conversion table 12 a is generated by using the binary tree. Therefore, it is possible to reduce the number of entries of the table required for deriving the code length while inhibiting the degradation in compression rate by the conversion.
›DETAILED DESCRIPTION · 5 of 5
At least a part of the data processing system explained in the above embodiments can be formed of hardware or software. When the data processing system is partially formed of the software, it is possible to store a program implementing at least a partial function of the data processing system in a recording medium such as a flexible disc, CD-ROM, etc. and to execute the program by making a computer read the program. The recording medium is not limited to a removable medium such as a magnetic disk, optical disk, etc., and can be a fixed-type recording medium such as a hard disk device, memory, etc.
Further, a program realizing at least a partial function of the data processing system can be distributed through a communication line (including radio communication) such as the Internet etc. Furthermore, the program which is encrypted, modulated, or compressed can be distributed through a wired line or a radio link such as the Internet etc. or through the recording medium storing the program.
While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fail within the scope and spirit of the inventions.
Claims as granted
20 claimsLog in to read the claims of this application.
Log in to unlockClassifications
7 codes- H04N19/176
- H03M7/40
- H04N19/61
- H03M7/42
- H03M7/30
Claim changes
SoonSee which claims were amended, added or cancelled during examination, with every added and removed word marked.
The published claims of this application are not paired with the granted ones in what we hold.
File wrapper
See the full prosecution history — every USPTO and applicant action on this file, in order.
Log in to unlockDocuments
Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.
Log in to unlockChain of title
See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.
Log in to unlock