- 14 Feb, 2020 7 commits
-
-
Paul B Mahol authored
-
Lynne authored
There's just no reason not to when its so easy (albeit messy) and its also reducing the precision of all non-power-of-two transforms that use it.
-
Michael Niedermayer authored
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Rheinhardt authored
Fixes "passing argument 2 of ‘strtoul’ from incompatible pointer type [-Wincompatible-pointer-types]" ("expected ‘char ** restrict’ but argument is of type ‘const char **’") for GCC and "passing 'const char **' to parameter of type 'char **' discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]" for Clang. The cast itself is safe; it is only needed because strtoul itself is not const-correct. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
- 13 Feb, 2020 7 commits
-
-
James Almer authored
If i is greater than 0, it is a requirement of bitstream conformance that point_y_value[ i ] is greater than point_y_value[ i - 1 ]. If i is greater than 0, it is a requirement of bitstream conformance that point_cb_value[ i ] is greater than point_cb_value[ i - 1 ]. If i is greater than 0, it is a requirement of bitstream conformance that point_cr_value[ i ] is greater than point_cr_value[ i - 1 ]. Reviewed-by: Mark Thompson <sw@jkqxz.net> Signed-off-by: James Almer <jamrial@gmail.com>
-
Lynne authored
Saves 2 additions.
-
Lynne authored
It was renamed and no warning was given for undeffing a nonexisting one.
-
Lynne authored
Required minimal changes to the code so made sense to implement. FFT and MDCT tested, the output of both was properly rounded. Fun fact: the non-power-of-two fixed-point FFT and MDCT are the fastest ever non-power-of-two fixed-point FFT and MDCT written. This can replace the power of two integer MDCTs in aac and ac3 if the MIPS optimizations are ported across. Unfortunately the ac3 encoder uses a 16-bit fixed point forward transform, unlike the encoder which uses a 32bit inverse transform, so some modifications might be required there. The 3-point FFT is somewhat less accurate than it otherwise could be, having minor rounding errors with bigger transforms. However, this could be improved later, and the way its currently written is the way one would write assembly for it. Similar rounding errors can also be found throughout the power of two FFTs as well, though those are more difficult to correct. Despite this, the integer transforms are more than accurate enough.
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Andriy Gelman authored
FMO is not supported and fields related to FMO are not parsed, meaning that any fields which follow will be corrupt. Signed-off-by: James Almer <jamrial@gmail.com>
-
- 12 Feb, 2020 7 commits
-
-
Andreas Rheinhardt authored
For audio packets with dts != AV_NOPTS_VALUEs the dts was converted twice to the muxer's timebase during streamcopy, once as a normal packet and once specifically as an audio packet. This has been changed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: left shift of negative value -463 Fixes: 20542/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5688714435231744 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Compared to ad-hoc if(printed) ... code this allows the user to disable it by adjusting the log level Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 11 Feb, 2020 7 commits
-
-
Dale Curtis authored
When e2_pts == INT64_MIN and e1_pts >= 0 the calculation of e2_pts - e1_pts will overflow an int64_t. Signed-off-by: Dale Curtis <dalecurtis@chromium.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Wonkap Jang authored
In order for rate control to correctly allocate bitrate to each temporal layer, correct temporal layer id has to be set to each frame. This commit provides the ability to set correct temporal layer id for each frame. Signed-off-by: James Zern <jzern@google.com>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Martin Storsjö authored
Previously, it was always left in the automatic mode, if the option was set to the only special (negative) value. Now there's two separate special values for this option, -1 for automatic (metadata based) and -2 for explicitly disabled. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
It was disabled by default in 2dbd35b0 as it added delay, but now we compensate for the delay properly by offsetting timestamps. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
The delay is normally zero when the level limiter is disabled, but if enabled, there's a small delay. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 10 Feb, 2020 9 commits
-
-
Andreas Rheinhardt authored
The AVPacket destined for a demuxer's output has already been initialized before it reaches the demuxer. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Marton Balint <cus@passwd.hu>
-
Andreas Rheinhardt authored
Even in this scenario, the frame still contains references to data that won't be freed if the frame isn't unreferenced. And the AVFrame itself will leak, too. Fixes Coverity issue #1441422. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Rheinhardt authored
Since bae8844e the packet will always be unreferenced when a demuxer returns an error, so that a lot of calls to av_packet_unref() in lots of demuxers are now redundant and can be removed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Marton Balint <cus@passwd.hu>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Ting Fu authored
Tested using this command: /ffmpeg -pix_fmt yuv420p -s 1920*1080 -i ArashRawYuv420.yuv \ -vcodec rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null The fps increase from 389 to 640 on Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz Signed-off-by: Ting Fu <ting.fu@intel.com>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
- 09 Feb, 2020 3 commits
-
-
Andreas Rheinhardt authored
This is possible because the size of a scan header is always a multiple of a byte. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
They are spec-incompliant. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: signed integer overflow: -2147479324 + -32568 cannot be represented in type 'int' Fixes: 20103/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GREMLIN_DPCM_fuzzer-5667667579240448 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-