mirror of https://github.com/FFmpeg/FFmpeg.git
Tag:
Branch:
Tree:
6a4f851df7
master
oldabi
release/0.10
release/0.11
release/0.5
release/0.6
release/0.7
release/0.8
release/0.9
release/1.0
release/1.1
release/1.2
release/2.0
release/2.1
release/2.2
release/2.3
release/2.4
release/2.5
release/2.6
release/2.7
release/2.8
release/3.0
release/3.1
release/3.2
release/3.3
release/3.4
release/4.0
release/4.1
release/4.2
release/4.3
release/4.4
release/5.0
release/5.1
release/6.0
release/6.1
release/7.0
release/7.1
N
ffmpeg-0.6.3
n0.10
n0.10.1
n0.10.10
n0.10.11
n0.10.12
n0.10.13
n0.10.14
n0.10.15
n0.10.16
n0.10.2
n0.10.3
n0.10.4
n0.10.5
n0.10.6
n0.10.7
n0.10.8
n0.10.9
n0.11
n0.11-dev
n0.11.1
n0.11.2
n0.11.3
n0.11.4
n0.11.5
n0.12-dev
n0.5.10
n0.5.11
n0.5.12
n0.5.13
n0.5.14
n0.5.15
n0.5.5
n0.5.6
n0.5.7
n0.5.8
n0.5.9
n0.6.4
n0.6.5
n0.6.6
n0.6.7
n0.7.1
n0.7.10
n0.7.11
n0.7.12
n0.7.13
n0.7.14
n0.7.15
n0.7.16
n0.7.17
n0.7.2
n0.7.3
n0.7.4
n0.7.5
n0.7.6
n0.7.7
n0.7.8
n0.7.9
n0.8
n0.8.1
n0.8.10
n0.8.11
n0.8.12
n0.8.13
n0.8.14
n0.8.15
n0.8.2
n0.8.3
n0.8.4
n0.8.5
n0.8.6
n0.8.7
n0.8.8
n0.8.9
n0.9
n0.9.1
n0.9.2
n0.9.3
n0.9.4
n1.0
n1.0.1
n1.0.10
n1.0.2
n1.0.3
n1.0.4
n1.0.5
n1.0.6
n1.0.7
n1.0.8
n1.0.9
n1.1
n1.1-dev
n1.1.1
n1.1.10
n1.1.11
n1.1.12
n1.1.13
n1.1.14
n1.1.15
n1.1.16
n1.1.2
n1.1.3
n1.1.4
n1.1.5
n1.1.6
n1.1.7
n1.1.8
n1.1.9
n1.2
n1.2-dev
n1.2.1
n1.2.10
n1.2.11
n1.2.12
n1.2.2
n1.2.3
n1.2.4
n1.2.5
n1.2.6
n1.2.7
n1.2.8
n1.2.9
n1.3-dev
n2.0
n2.0.1
n2.0.2
n2.0.3
n2.0.4
n2.0.5
n2.0.6
n2.0.7
n2.1
n2.1-dev
n2.1.1
n2.1.2
n2.1.3
n2.1.4
n2.1.5
n2.1.6
n2.1.7
n2.1.8
n2.2
n2.2-dev
n2.2-rc1
n2.2-rc2
n2.2.1
n2.2.10
n2.2.11
n2.2.12
n2.2.13
n2.2.14
n2.2.15
n2.2.16
n2.2.2
n2.2.3
n2.2.4
n2.2.5
n2.2.6
n2.2.7
n2.2.8
n2.2.9
n2.3
n2.3-dev
n2.3.1
n2.3.2
n2.3.3
n2.3.4
n2.3.5
n2.3.6
n2.4
n2.4-dev
n2.4.1
n2.4.10
n2.4.11
n2.4.12
n2.4.13
n2.4.14
n2.4.2
n2.4.3
n2.4.4
n2.4.5
n2.4.6
n2.4.7
n2.4.8
n2.4.9
n2.5
n2.5-dev
n2.5.1
n2.5.10
n2.5.11
n2.5.2
n2.5.3
n2.5.4
n2.5.5
n2.5.6
n2.5.7
n2.5.8
n2.5.9
n2.6
n2.6-dev
n2.6.1
n2.6.2
n2.6.3
n2.6.4
n2.6.5
n2.6.6
n2.6.7
n2.6.8
n2.6.9
n2.7
n2.7-dev
n2.7.1
n2.7.2
n2.7.3
n2.7.4
n2.7.5
n2.7.6
n2.7.7
n2.8
n2.8-dev
n2.8.1
n2.8.10
n2.8.11
n2.8.12
n2.8.13
n2.8.14
n2.8.15
n2.8.16
n2.8.17
n2.8.18
n2.8.19
n2.8.2
n2.8.20
n2.8.21
n2.8.22
n2.8.3
n2.8.4
n2.8.5
n2.8.6
n2.8.7
n2.8.8
n2.8.9
n2.9-dev
n3.0
n3.0.1
n3.0.10
n3.0.11
n3.0.12
n3.0.2
n3.0.3
n3.0.4
n3.0.5
n3.0.6
n3.0.7
n3.0.8
n3.0.9
n3.1
n3.1-dev
n3.1.1
n3.1.10
n3.1.11
n3.1.2
n3.1.3
n3.1.4
n3.1.5
n3.1.6
n3.1.7
n3.1.8
n3.1.9
n3.2
n3.2-dev
n3.2.1
n3.2.10
n3.2.11
n3.2.12
n3.2.13
n3.2.14
n3.2.15
n3.2.16
n3.2.17
n3.2.18
n3.2.19
n3.2.2
n3.2.3
n3.2.4
n3.2.5
n3.2.6
n3.2.7
n3.2.8
n3.2.9
n3.3
n3.3-dev
n3.3.1
n3.3.2
n3.3.3
n3.3.4
n3.3.5
n3.3.6
n3.3.7
n3.3.8
n3.3.9
n3.4
n3.4-dev
n3.4.1
n3.4.10
n3.4.11
n3.4.12
n3.4.13
n3.4.2
n3.4.3
n3.4.4
n3.4.5
n3.4.6
n3.4.7
n3.4.8
n3.4.9
n3.5-dev
n4.0
n4.0.1
n4.0.2
n4.0.3
n4.0.4
n4.0.5
n4.0.6
n4.1
n4.1-dev
n4.1.1
n4.1.10
n4.1.11
n4.1.2
n4.1.3
n4.1.4
n4.1.5
n4.1.6
n4.1.7
n4.1.8
n4.1.9
n4.2
n4.2-dev
n4.2.1
n4.2.10
n4.2.2
n4.2.3
n4.2.4
n4.2.5
n4.2.6
n4.2.7
n4.2.8
n4.2.9
n4.3
n4.3-dev
n4.3.1
n4.3.2
n4.3.3
n4.3.4
n4.3.5
n4.3.6
n4.3.7
n4.3.8
n4.4
n4.4-dev
n4.4.1
n4.4.2
n4.4.3
n4.4.4
n4.4.5
n4.5-dev
n5.0
n5.0.1
n5.0.2
n5.0.3
n5.1
n5.1-dev
n5.1.1
n5.1.2
n5.1.3
n5.1.4
n5.1.5
n5.1.6
n5.2-dev
n6.0
n6.0.1
n6.1
n6.1-dev
n6.1.1
n6.1.2
n6.2-dev
n7.0
n7.0.1
n7.0.2
n7.1
n7.1-dev
n7.2-dev
v0.5
v0.5.1
v0.5.2
v0.5.3
v0.6
v0.6.1
${ noResults }
9 Commits (6a4f851df7b627256b35314c59e80dfaf5dbfe23)
Author | SHA1 | Message | Date |
---|---|---|---|
Andreas Rheinhardt | b629deab3d |
avcodec/bitstream: Allow static VLC tables to be bigger than needed
Right now the allocated size of the VLC table of a static VLC has to exactly match the size actually used for the VLC: If it is not enough, abort is called; if it is more than enough, an error message is emitted. This is no problem when one wants to initialize an individual VLC via one of the INIT_VLC macros as one just hardcodes the needed size. Yet it is an obstacle when one wants to initialize several VLCs in a loop as one then needs to add an array for the sizes/offsets of the VLC tables (unless max_depth of all arrays is one in which case the sizes are derivable from the number of bits used). Yet said size array is not necessary if one disables the warning for too big buffers. The reason is that the amount of entries needed for the table is of course generated as a byproduct of initializing the VLC. To this end a flag that disables the warning has been added. So one can proceed as follows: static VLC vlcs[NUM]; static VLC_TYPE vlc_table[BUF_SIZE][2]; for (int i = 0, offset = 0; i < NUM; i++) { vlcs[i].table = &vlc_table[offset]; vlcs[i].table_allocated = BUF_SIZE - offset; init_vlc(); /* With INIT_VLC_STATIC_OVERLONG flag */ offset += vlcs[i].table_size; } Of course, BUF_SIZE should be equal to the number of entries actually needed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> |
4 years ago |
Andreas Rheinhardt | f55da066ec |
avcodec/bitstream: Add second function to create VLCs
When using ff_init_vlc_sparse() to create a VLC, three input tables are used: A table for lengths, one for codes and one for symbols; the latter one can be omitted, then a default one will be used. These input tables will be traversed twice, once to get the long codes (which will be put into subtables) and once for the small codes. The long codes are then sorted so that entries that should be in the same subtable are contiguous. This commit adds an alternative to ff_init_vlc_sparse(): ff_init_vlc_from_lengths(). It is based upon the observation that if lengths, codes and symbols tables are permuted (in the same way) so that the codes are ordered from left to right in the corresponding tree and if said tree is complete (i.e. every non-leaf node has two children), the codes can be easily computed from the lengths and are therefore redundant. This means that if one initializes such a VLC with explicitly coded lengths, codes and symbols, the codes can be avoided; and even if one has no explicitly coded symbols, it might still be beneficial to remove the codes even when one has to add a new symbol table, because codes are typically longer than symbols so that the latter often fit into a smaller type, saving space. Furthermore, given that the codes here are by definition ordered from left to right, it is unnecessary to sort them again; for the same reason, one does not have to traverse the input twice. This function proved to be faster than ff_init_vlc_sparse() whenever it has been benchmarked. This function is usable for static tables (they can simply be permuted once) as well as in scenarios where the tables are naturally ordered from left to right in the tree; the latter e.g. happens with Smacker, Theora and several other formats. In order to make it also usable for (static) tables with incomplete trees, negative lengths are used to indicate that there is an open end of a certain length. Finally, ff_init_vlc_from_lengths() has one downside compared to ff_init_vlc_sparse(): The latter uses tables that can be reused by encoders. Of course, one could calculate the needed table at runtime if one so wishes, but it is nevertheless an obstacle. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> |
4 years ago |
Andreas Rheinhardt | 9eb7d8b45d |
avcodec/vlc, bitstream: Allow to use BE codes to initialize LE VLC
This is easily possible because ff_init_vlc_sparse() already transforms both LE as well as BE codes to a normal form internally before processing them further. This will be used in subsequent commits. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> |
4 years ago |
Andreas Rheinhardt | 6401a5d4b8 |
Revert "avcodec/vlc: Add macro for ff_init_vlc_sparse()"
This reverts commit
|
4 years ago |
Andreas Rheinhardt | 61669b7c40 |
avcodec/vlc: Add macro for ff_init_vlc_sparse()
ff_init_vlc_sparse() supports arrays of uint8_t, uint16_t and uint32_t as input (and it also supports padding/other elements in between the elements). This makes the typical case in which the input is a simple array more cumbersome. E.g. for an array of uint8_t one would either need to call the function with arguments like "array, sizeof(array[0]), sizeof(array[0])" or with "array, 1, 1". The former is nicer, but longer, so that the latter is mostly used. Therefore this commit adds a macro that expands to the sizeof() construct. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> |
4 years ago |
Luca Barbato | 0ac1fec1c3 |
bitstream: Move VLC reading functions into the vlc.h header
This makes the bitstream.h header leaner. Signed-off-by: Diego Biurrun <diego@biurrun.de> |
8 years ago |
Steinar H. Gunderson | 08b098169b |
speedhq: fix out-of-bounds write
Certain alpha run lengths (for SHQ1/SHQ3/SHQ5) could be stored in both long and short versions, and we would only accept the short version, returning -1 (invalid code) for the others. This could cause an out-of-bounds write on malicious input, as discovered by Andreas Cadhalpun during fuzzing. Fix by simply allowing both versions, leaving no invalid codes in the alpha VLC. Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com> |
8 years ago |
Steinar H. Gunderson | 2a293ec7ac |
avcodec: add Newtek SpeedHQ decoder
This decoder can decode all existing SpeedHQ formats (SHQ0–5, 7, and 9), including correct decoding of the alpha channel. 1080p is decoded in 142 fps on one core of my i7-4600U (2.1 GHz Haswell), about evenly split between bitstream reader and IDCT. There is currently no attempt at slice or frame threading, even though the format trivially supports both. NewTek very helpfully provided a full set of SHQ samples, as well as source code for an SHQ2 encoder (not included) and assistance with understanding some details of the format. |
8 years ago |
Clément Bœsch | aef2d3d2b5 |
lavc: fix previous merge
|
9 years ago |
Alexandra Hájková | ffa190d047 |
Move VLC and RL_VLC_ELEM structure definitions to a separate header
Use the newly created vlc.h directly instead of including get_bits when needed. The VLC and RL_VLC_ELEM structures are independent from the bitreader. Signed-off-by: Luca Barbato <lu_zero@gentoo.org> |
9 years ago |