- 29 9月, 2020 6 次提交
-
-
由 Harry Mallon 提交于
Signed-off-by: NHarry Mallon <harry.mallon@codex.online> Signed-off-by: NRick Kern <kernrj@gmail.com>
-
由 Harry Mallon 提交于
Signed-off-by: NHarry Mallon <harry.mallon@codex.online> Signed-off-by: NRick Kern <kernrj@gmail.com>
-
由 Michael Niedermayer 提交于
Fixes: signed integer overflow: -1846510390 + -361755993 cannot be represented in type 'int' Fixes: 23941/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5654696631730176 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Michael Niedermayer 提交于
Fixes: left shift of negative value -121 Fixes: 23911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGX_fuzzer-4986800258154496 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
由 Andreas Rheinhardt 提交于
Reviewed-by: NJan Ekström <jeebjp@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Michael Niedermayer 提交于
Fixes: Infinite loop Fixes: 25844/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5660803318153216 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: NPeter Ross <pross@xvid.org> Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>
-
- 28 9月, 2020 8 次提交
-
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
-
由 Anton Khirnov 提交于
A common pattern e.g. in libavcodec is replacing/updating buffer references: unref old one, ref new one. This function allows simplifying such code and avoiding unnecessary refs+unrefs if the references are already equivalent.
-
由 Pavel Koshevoy 提交于
Allow setparams to be used with hw backed frames and avoid an assertion failure in avfilter_config_links.
-
由 Jun Zhao 提交于
Add AC-3/EAC-3 to allowed extensions file list. From HTTP Live Streaming 2nd Edition draft-pantos-hls-rfc8216bis-07 section 3.1.3.Packed Audio, HLS demuxer need to support MP3/AC-3/EAC-3. Reviewd-by: NSteven Liu <liuqi05@kuaishou.com> Signed-off-by: NJun Zhao <barryjzhao@tencent.com>
-
由 Jun Zhao 提交于
misc style fixes. Reviewed-by: NSteven Liu <liuqi05@kuaishou.com> Signed-off-by: NJun Zhao <barryjzhao@tencent.com>
-
由 Paul B Mahol 提交于
-
- 27 9月, 2020 26 次提交
-
-
由 Andrew Klaassen 提交于
This patch adds the coefficients for the linear gamma function (1,0,1,0) to the colorspace filter. Signed-off-by: NAndrew Klaassen <clawsoon@yahoo.com> Signed-off-by: NRonald S. Bultje <rsbultje@gmail.com>
-
由 Paul B Mahol 提交于
-
由 Andreas Rheinhardt 提交于
Otherwise the result of such tests will not accurately reflect the current state. Reviewed-by: NJan Ekström <jeebjp@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Zane van Iperen 提交于
Signed-off-by: NZane van Iperen <zane@zanevaniperen.com>
-
由 Zane van Iperen 提交于
It seems that in files where the BASF block isn't first, v1.1 ASF streams are allowed to be non-22050. Either this format is really inconsistent, or FX Fighter and Croc just ignored the sample rate field, requiring the v1.1 restriction in the first place. This bumps the version to 1.2 in these streams so they're not "corrected". Found in Alien Odyssey games files in: ./GRAPHICS/COMMBUNK/{{COMADD1,COMM2_{1,2,3E},COMM3_{2,3,4,5,6}},FADE{1,2}}.BRP Signed-off-by: NZane van Iperen <zane@zanevaniperen.com>
-
由 Zane van Iperen 提交于
Signed-off-by: NZane van Iperen <zane@zanevaniperen.com>
-
由 Zane van Iperen 提交于
Signed-off-by: NZane van Iperen <zane@zanevaniperen.com>
-
由 Zane van Iperen 提交于
We can't actually use them though. Signed-off-by: NZane van Iperen <zane@zanevaniperen.com>
-
由 Zane van Iperen 提交于
Signed-off-by: NZane van Iperen <zane@zanevaniperen.com>
-
由 Andriy Gelman 提交于
Signed-off-by: NAndriy Gelman <andriy.gelman@gmail.com>
-
由 Paul B Mahol 提交于
-
由 Andreas Rheinhardt 提交于
This proved beneficial for performance: For the sample [1] the number of decicycles in one decode call decreased from 155851561 to 108158037 for Clang 10 and from 168270467 to 128847479 for GCC 9.3. For x86-32 compiled with GCC 9.3 and run on an x64 Haswell the number increased from 158405517 to 202215769, so that the cached bitstream reader is only enabled if HAVE_FAST_64BIT is set. These values are the average of 10 runs each looping five times over the input. [1]: samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2593/fraps_flv1_decoding_errors.avi Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
The fraps decoder already checked for overreads manually (and errored out in this scenario), yet it still enabled implicit checks, leading to worse performance and more code size. This commit disables the implicit bitstream reader checks. For the sample [1] this improves performance from 195105896 to 155851561 decicycles for Clang 10 and from 222801887 to 168270467 decicycles when compiled with GCC 9.3. These values are the average of 10 runs each looping ten times over the input. [1]: samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2593/fraps_flv1_decoding_errors.avi Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Unused since 3594788b. Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
The Ut video format uses Huffman trees which are only implicitly coded in the bitstream: Only the lengths of the codes are coded, the rest has to be inferred by the decoder according to the rule that the longer codes are to the left of shorter codes in the tree and on each level the symbols are descending from left to right. Because longer codes are to the left of shorter codes, one needs to know how many non-leaf nodes there are on each level in order to know the code of the next left-most leaf (which belongs to the highest symbol on that level). The current code does this by sorting the entries to be ascending according to length and (for entries with the same length) ascending according to their symbols. This array is then traversed in reverse order, so that the lowest level is dealt with first, so that the number of non-leaf nodes of the next higher level is known when processing said level. But this can also be calculated without sorting: Simply count how many leaf nodes there are on each level. Then one can calculate the number of non-leaf nodes on each level iteratively from the lowest level upwards: It is just half the number of nodes of the level below. This improves performance: For the sample from ticket #4044 the amount of decicycles for one call to build_huff() decreased from 1055489 to 446310 for Clang 10 and from 1080306 to 535155 for GCC 9. Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
The Ut Video format stores Huffman tables in its bitstream by coding the length of a given symbol; it does not code the actual code directly, instead this is to be inferred by the rule that a symbol is to the left of every shorter symbol in the Huffman tree and that for symbols of the same length the symbol is descending from left to right. With one exception, this is also what our de- and encoder did. The exception only matters when there are codes of length 32, because in this case the first symbol of this length did not get the code 0, but 1; this is tantamount to pretending that there is a (nonexistent) leaf of length 32. This is simply false. The reference software agrees with this [1]. [1]: https://github.com/umezawatakeshi/utvideo/blob/2700a471a78402e5c340150b38e8a793ef3676f1/utv_core/HuffmanCode.cpp#L280Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Now that the HuffEntries are no longer sorted by the MagicYUV decoder, their symbols are trivial: The symbol of the element with index i is i. They can therefore be removed. Furthermore, despite the length of the codes being in the range 1..32 bits, the actual value of the codes is <= 4096 (for 12 bit content). The reason for this is that the longer codes are on the left side of the tree, so that the higher bits of these codes are simply zero. By using an uint16_t for the codes and removing the symbols entry, the size of each HuffEntry is decreased from eight to four, saving 16KB of stack space. Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
The MagicYUV format stores Huffman tables in its bitstream by coding the length of a given symbol; it does not code the actual code directly, instead this is to be inferred by the rule that a symbol is to the left of every shorter symbol in the Huffman tree and that for symbols of the same length the symbol is ascending from left to right. Our decoder implemented this by first sorting the array containing length and symbol of each element according to descending length and for equal length, according to ascending symbol. Afterwards, the current state in the tree got encoded in a variable code; if the next array entry had length len, then the len most significant bits of code contained the code of this entry. Whenever an entry of the array of length len was processed, code was incremented by 1U << (32 - len). So two entries of length len have the same effect as incrementing code by 1U << (32 - (len - 1)), which corresponds to the parent node of length len - 1 of the two nodes of length len etc. This commit modifies this to avoid sorting the entries before calculating the codes. This is done by calculating how many non-leaf nodes there are on each level of the tree before calculating the codes. Afterwards every leaf node on this level gets assigned the number of nodes already on this level as code. This of course works only because the entries are already sorted by their symbol initially, so that this algorithm indeed gives ascending symbols from left to right on every level. This offers both speed- as well as (obvious) codesize advantages. With Clang 10 the number of decicycles for build_huffman decreased from 1561987 to 1228405; for GCC 9 it went from 1825096 decicyles to 1429921. These tests were carried out with a sample with 150 frames that was looped 13 times; and this was iterated 10 times. The earlier reference point here is from the point when the loop generating the codes was traversed in reverse order (as the patch reversing the order led to performance penalties). Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
The MagicYUV format stores Huffman tables in its bitstream by coding the length of a given symbol; it does not code the actual code directly, instead this is to be inferred by the rule that a symbol is to the left of every shorter symbol in the Huffman tree and that for symbols of the same length the symbol is ascending from left to right. With one exception, this is also what our decoder did. The exception only matters when there are codes of length 32, because in this case the first symbol of this length did not get the code 0, but 1; e.g. if there were exactly two nodes of length 32, then they would get assigned the codes 1 and 2 and a node of length 31 will get the 31-bit code 1 which is a prefix of the 32 bit code 2, making the Huffman table invalid. On the other hand, if there were only one symbol with the length 32, the earlier code would accept this un-Huffman-tree. Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
The MagicYUV decoder currently sets both the length and the symbol field of an array of HuffEntries; hereby the symbol of the ith entry (0-based) is just i. Then said array gets sorted so that entries with greater length are at the end and entries with the same length are ordered so that those with smaller symbols are at the end. Afterwards the newly sorted array is traversed in reverse order. This commit instead inverts the ordering and traverses the array in its ordinary order in order to simplify understanding. Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
由 Andreas Rheinhardt 提交于
Every plane of each slice has to contain at least two bytes for flags and the type of prediction used. Reviewed-by: NPaul B Mahol <onemda@gmail.com> Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
-