- 09 12月, 2020 40 次提交
-
-
由 Andreas Rheinhardt 提交于
Besides removing code duplication the method for determining the offset of each VLC table in the VLC_TYPE buffer also has the advantage of not wasting space for skipped AIC mode 1 VLCs. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
RealVideo 4.0 has a VLC that encodes two intra types per code; each intra type is in the range 0..8 (inclusive) and up until now the VLC used symbols in the range 0..80; one type was encoded as the remainder when dividing the symbol by 9 whereas the other type was encoded as symbol / 9. This is suboptimal; a better way would be to use the high and low nibble to encode each symbol. But an even better way is to use 16bit symbols so that the two intra types can be directly written as a 16bit value. This commit implements this; in order to avoid huge tables the symbols are stored as uint8_t with high and low nibbles encoding one type each; they are only unpacked to uint16_t during initialization. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
After permuting the codes, symbols and lengths tables used to initialize the VLC so that the codes are ordered from left to right in the Huffman tree, the codes become redundant as they can be easily computed from the lengths at runtime; in this case one has to use explicit symbol tables, but all the symbols used here fit into an uint8_t, whereas some codes needed uint16_t. This saves about 1.6KB. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
After permuting the codes, symbols and lengths tables used to initialize the VLCs so that the codes are ordered from left to right in the Huffman tree, the codes become redundant as they can be easily computed from the lengths at runtime (or at compile time with --enable-hardcoded-tables); in this case one has to use explicit symbol tables, but all the symbols used here fit into an uint8_t, whereas some codes needed uint16_t. Furthermore, the codes had holes because the range of the symbols was not contiguous; these have also been removed. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
If both codes, lengths and symbols tables are ordered so that the codes are sorted from left to right in the tree, the codes can be easily derived from the lengths and therefore become redundant. This is exploited in this commit to remove the codes tables for the mobiclip decoder; notice that tables for the run-length VLC were already ordered correctly. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Up until now, VLCs that were part of an array of VLCs were often not initialized in a loop, but separately. The probable reason for this was that these VLCs differed slightly in the parameters to be used for them (i.e. the number of codes or the number of bits to be used differs), so that one would have to provide these parameters e.g. via arrays. Yet these problems have actually largely been solved by now: The length information is contained in a run-length encoded form that is the same for all VLCs and both the number of codes as well as the number of bits to use for each VLC can be easily derived from them. There is just one problem to be solved: When the underlying tables have a different number of elements, putting them into an array of arrays would be wasteful; using an array of pointers to the arrays would also be wasteful. Therefore this commit combines the tables into bigger tables. (Given that all the length tables have the same layout this applies only to the symbols tables.) Finally, the array containing the offset of the VLC's buffer in the big buffer has also been removed. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Several of the quantisation VLCs come in pairs and up until now the number of bits used for each VLC was set to the same value for both VLCs in such a pair even when one of the two required only a lower number. This is a waste given that the get_vlc2() call is compatible with these two VLCs using a different number of bits (it uses vlc->bits). Given that the code lengths are descending it is easily possible to know the length of the longest code for a given VLC: It is the length of the first one. With this information one can easily use the least amount of bits. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
After permuting both length, code as well as symbol tables so that the codes are ordered from left to right in the tree, it became apparent that the length of the codes decreases from left to right. Therefore one can run-length encode the lengths to save space. This commit implements this. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
By switching to ff_init_vlc_from_lengths() one can make a table of codes of type uint8_t superfluous, saving space. Other VLCs (those without dedicated symbols table and with codes of type uint8_t) have been made to use ff_init_vlc_from_lengths(), too, because it reduces codesize (ff_init_vlc_from_lengths() has two parameters less than ff_init_vlc_sparse()) and because it allows to use the offset parameter in future commits. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
By switching to ff_init_vlc_from_lengths() one can replace tables of codes of type uint16_t with tables of symbols of type uint8_t, saving space. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
By using ff_init_vlc_from_lengths(), we do not have to keep track of the codes themselves, but can offload this to ff_init_vlc_from_lengths(). Furthermore, the old code presumed sizeof(int) == 4; this is no longer so. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
By switching to ff_init_vlc_from_lengths() one can replace a table of codes of type uint32_t with a table of symbols of type uint8_t saving space. The old tables also had holes in it (because of the symbols) which are now superfluous, saving ever more space. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
The VLC tables to be used for parsing RealVideo 1.0 DC coefficients are weird: The luma table contains a block of 2^11 codes beginning with the same prefix and length that all have the same symbol (i.e. value only depends upon the prefix); the same goes for the chroma block (except it's only 2^9 codes). Up until now, these entries (which generally could be parsed like ordinary entries with subtables) have been treated specially: They have been treated like open ends of the tree, so that get_vlc2() returned a value < 0 upon encountering them; afterwards it was checked whether the right prefix was used and if so, the appropriate number of bytes was skipped. But there is actually an easy albeit slightly hacky way to support them directly without pointless subtables: Just modify the VLC table so that all the entries sharing the right prefix have a length that equals the length of the whole entry. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
These tables were huge (14 bits) because one needed 14 bits in order to find out whether a code is valid and in the VLC table or a valid code that required hacky workarounds due to RealVideo 1.0 using multiple codes for the same symbol and the code predating the introduction of symbols tables for VLCs. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
The RealVideo 1.0 decoder uses VLCs to parse DC coefficients. But the values returned from get_vlc2() are not directly used; instead -(val - 128) (which is in the range -127..128) is. This transformation is unnecessary as it can effectively be done when initializing the VLC by modifying the symbols table used. There is just one minor complication: The chroma table is incomplete and in order to distinguish an error from get_vlc2() (due to an invalid code) the ordinary return range is modified to 0..255. This is possible because the only caller of this function is (on success) only interested in the return value modulo 256. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
RealVideo 1.0 uses an insane way to encode DC coefficients: There are several symbols that (for no good reason whatsoever) have multiple encodings, leading to longer codes than necessary. More specifically, the tree for the 256 luma symbols contains 255 codes belonging to 255 different symbols on the left; going further right, the tree consists of two blocks of 128 codes each of length 14 encoding consecutive numbers (including two encodings for the symbol missing among the 255 codes on the left); this is followed by two blocks of codes of length 16 each containing 256 elements with consecutive symbols (i.e. each of the blocks allows to encode all symbols). The rest of the tree consists of 2^11 codes that all encode the same symbol. The tree for the 256 chroma symbols is similar, but is missing the blocks of length 256 and there are only 2^9 consecutive codes that encode the same symbol; furthermore, the chroma tree is incomplete: The right-most node has no right child. All of this caused problems when parsing these codes; the reason is that the code for this predates commit b613bacc which added support for explicit symbol tables and thereby removed the requirement that different codes have different symbols. In order to address this, the trees used for parsing were incomplete: They contained the 255 codes on the left and one code for the remaining symbol. Whenever a code not in these trees was encountered, it was dealt with in special cases (one for each of the blocks mentioned above). This commit reduces the number of special cases: Using a symbols table allows to treat the blocks of consecutive symbols like ordinary codes; only the blocks encoding a single symbol are still treated specially (in order not to waste memory on tables for them). In order to not increment the size of the tables used to initialize the VLCs both the symbols as well as the lengths are now run-length encoded. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
This can be achieved by switching to ff_init_vlc_from_lengths() which allows to replace two uint16_t tables for codes with uint8_t tables for the symbols by permuting the tables so that the codes are ordered from left to right in the tree in which case they can be easily computed from the lengths at runtime. And after doing so, it became apparent that the tables for the symbols are actually the same for luma and chroma, so that one can even omit one of them. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Permuting the tables used to initialize the Cook VLCs so that the code tables are ordered from left to right in the tree revealed that the length of the codes are ascending from left to right. Therefore one can run-length encode them to avoid the big length tables; this saves a bit more than 1KB. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Up until now, the Cook decoder used tables for the lengths of codes and tables of the codes itself to initialize VLCs; the tables for the codes were of type uint16_t because the codes were so long. It did not use explicit symbol tables. This commit instead reorders the tables so that the code tables are sorted from left to right in the tree. Then the codes can be easily derived from the lengths and therefore be omitted. This comes at the price of explicitly coding the symbols, but this is nevertheless a net win because most of the symbols tables can be coded on one byte. Furthermore, Cook actually does not use a contiguous range of symbols for its main VLC tables and the old code compensated for that by adding holes (codes of length zero) to the tables (that are skipped by ff_init_vlc_sparse()). This is no longer necessary with the new approach. All in all, this saves about 1.7KB. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
This is possible by switching to ff_init_vlc_from_lengths() which allows to replace the table for the codes (which need an uint16_t) by a table of symbols which fit into an uint8_t. Also switch to an ordinary INIT_VLC macro while just at it. Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-