- 21 Jun, 2017 10 commits
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Ronald S. Bultje authored
This was added in e3e3c825, probably as a workaround for the fact that the quant table was not permutated and the IDCT coefficients are, meaning that you'd only get correct reconstruction if the IDCT permutation was an identity matrix, which happens to be the case when you use the simple IDCT. The quant table permutation bug was fixed in 42dd1434, meaning this workaround is no longer necessary. In practical terms, before 42dd1434, the PSNR between decodes of the fate-mdec using simple (C) or simplemmx IDCTs was 35. After 42dd1434, it's 90.
-
Ronald S. Bultje authored
-
Memphiz authored
Properly use the b.eq form instead of the nonstandard form (which both gas and newer clang accept though), and expand the register lists that used a range (which the Xcode 6.2 clang, based on clang 3.5 svn, didn't support). Signed-off-by: Martin Storsjö <martin@martin.st>
-
Memphiz authored
Properly use the b.eq/b.ge forms instead of the nonstandard forms (which both gas and newer clang accept though), and expand the register list that used a range (which the Xcode 6.2 clang, based on clang 3.5 svn, didn't support). This is cherrypicked from libav commit a970f9de. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Michael Niedermayer authored
Reviewed-by: James Darnley <jdarnley@obe.tv> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: runtime error: left shift of negative value -1 Fixes: 2299/clusterfuzz-testcase-minimized-4843509351710720 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: runtime error: signed integer overflow: 262144 * -16120 cannot be represented in type 'int' Fixes: 2292/clusterfuzz-testcase-minimized-6156080415506432 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: runtime error: signed integer overflow: -1575818955 + -915383657 cannot be represented in type 'int' Fixes: 2224/clusterfuzz-testcase-minimized-6208559949807616 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 20 Jun, 2017 10 commits
-
-
Luca Barbato authored
The early check for inconsistent in-source vs out-of-source build cannot generate a config.log otherwise. (Cherry-picked from libav commit 0ee78020) Signed-off-by: Luca Barbato <lu_zero@gentoo.org> Signed-off-by: James Almer <jamrial@gmail.com>
-
John Rummell authored
Use avci->last_pkt_props to get the side data. Using |pkt| doesn't work when FF_API_MERGE_SD is set, as the compressed side data is expanded into |tmp|, leaving the original |pkt| unchanged. Signed-off-by: James Almer <jamrial@gmail.com>
-
James Darnley authored
-
James Darnley authored
-
James Darnley authored
-
James Darnley authored
Use named arguments for the functions so we can remove a define. The stride/linesize argument is now ptrdiff_t type so we no longer need to sign extend the register.
-
James Darnley authored
-
James Darnley authored
-
Diego Biurrun authored
(cherry picked from commit 2f792cb6)
-
wm4 authored
It is wrong/incorrect in two aspects: 1. The pixel format is not enough to guarantee that the resulting file will be any more compatible with media players. 2. Media players not supporting higher profiles are not necessarily outdated (in fact this is simply an arrogant statement that libavcodec can handle these particular features). You could add that there are plenty of other ways to produce widely incompatible files with ffmpeg, and these don't show any warnings. What we really want to do here is defaulting to codec profiles that have wide compatibility, such as main/high for h264. Also, if an encoder does not accept certain pixfmts, we should automatically convert them to a pixfmt the encoder can accept. But the existing message certainly is not appropriate. It also works for 2 specific encoders only. Extending it for other cases would result in a lot of special cases, so this is not the right place.
-
- 19 Jun, 2017 20 commits
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Anton Mitrofanov authored
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Anton Mitrofanov authored
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Anton Mitrofanov authored
Use the correct ctxIdxInc calculation for coded_block_flag. Keep old behavior for old versions of x264 for backward compatibility. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Kevin Mark authored
The input width and height is known at parse time so there's no reason ow/oh should not be usable when using 0 as the width or height expression. Previously in "scale=0:ow" ow would be set to "0" which works, conveniently, as "scale=0:0" is perfectly valid input but this breaks down when you do something like "scale=0:ow/4" which one could reasonably expect to work as well, but does not as ow is 0 not the real value. This change handles the 0 case for w/h immediately so the ow/oh variables work as expected. Consequently, the rest of the code does not need to handle 0 input. w/h will always be > 0 or < 0. The second explicit (int) cast ensures that ow/oh appear as integers as a user might expect when dealing with pixel dimensions. Signed-off-by: Kevin Mark <kmark937@gmail.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Kevin Mark authored
According to libavfilter/scale.c, if the width and height are both less than or equal to 0 then the input size is used for both dimensions. It does not need to be -1. -1:-1 is the same as 0:0 which is the same as -10:-42, etc. if (w < 0 && h < 0) eval_w = eval_h = 0; The documentation for the zscale filter has also been updated since the behavior is identical. Signed-off-by: Kevin Mark <kmark937@gmail.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Michael Niedermayer authored
Fixes: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself Fixes: 2291/clusterfuzz-testcase-minimized-5538453481586688 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: runtime error: shift exponent -8 is negative Fixes: 2286/clusterfuzz-testcase-minimized-5711764169687040 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
The new name more accuratly describes what the function does Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Nicolas George authored
-
Steven Liu authored
When the hlsenc at BYTERANGE mode, it should not show the warning message: "Duplicated segment filename detected:" Reported-by: Marco <marco@worldcast.com> Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
-
James Almer authored
About 2x faster than the c version.
-
James Almer authored
About 2x faster than the c version.
-