- 15 May, 2020 5 commits
-
-
Marton Balint authored
This reverts commit 339593ca. Fixes null pointer dereference. Signed-off-by: Marton Balint <cus@passwd.hu>
-
Marton Balint authored
This reverts commit d88e1c98. Fixes null pointer dereference. Signed-off-by: Marton Balint <cus@passwd.hu>
-
Josh de Kock authored
This tests the hscale 8bpp to 14/18bpp functions with different filter sizes. Signed-off-by: Josh de Kock <josh@itanimul.li>
-
Martin Storsjö authored
This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0). Signed-off-by: Josh de Kock <josh@itanimul.li>
-
Josh de Kock authored
The NEON hscale function only supports X8 filter sizes and should only be selected when these are being used. At the moment filterAlign is set to 8 but in the future when extra NEON assembly for specific sizes is added they will need to have checks here too. The immediate usecase for this change is making the hscale checkasm test easier and without NEON specific edge-cases (x86 already has these guards). Signed-off-by: Josh de Kock <josh@itanimul.li>
-
- 14 May, 2020 15 commits
-
-
Zachariah Brown authored
The h264_nvenc and hevc_nvenc encoders aren't respecting the framerate in the codec context. Instead it was using the timebase which in our use-case was 1/1000 so the encoder was behaving as if we wanted 1000fps. This resulted in poor encoding results due to an extremely low bitrate. Both the amf and qsv encoders already contain similar logic to first check the framerate before falling back to the timebase. Signed-off-by: Zachariah Brown <zachariah@renewedvision.com> Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
-
James Almer authored
It's not meant for audio or subtitles, or for encoders of any kind. Reviewed-by: mypopy@gmail.com <mypopy@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
Lynne authored
-
Limin Wang authored
have tested on linux x86_32/64, mingw32/64 arm & mips qemu Tested-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
./ffmpeg -loglevel debug -i ../fate-suite/svq3/Vertical400kbit.sorenson3.mov -vf minterpolate=fps=60:mi_mode=blend -an -f null - [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 1600 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 4120 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 5780 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 6700 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 8140 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 9740 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 14060 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 15680 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 18480 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 20020 [Parsed_minterpolate_0 @ 0x7fe7f3e193c0] scene changed, input pts 21740 The results are consistent with tests/ref/fate/filter-metadata-scenedetect For the master, it'll detect more than 20 scene change for the same source. Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Andriy Gelman authored
ts->{tsid,onid} stores the values of ts->{transport_stream_id,original_network_id} Reviewed-by: Marton Balint <cus@passwd.hu> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
Andriy Gelman authored
A temporary heap array currently stores pids from all streams. It is used to make sure there are no duplicated pids. However, this array is not needed because the pids from past streams are stored in the MpegTSWriteStream structs. Reviewed-by: Marton Balint <cus@passwd.hu> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
Limin Wang authored
Tested on x86-32/64, mingw32/64, arm & mips qemu Tested-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
lance.lmwang@gmail.com authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
- 13 May, 2020 7 commits
-
-
Jan Ekström authored
Until now, we would have only attempted to utilize already decrypted data if it was enough to fill the size of buffer requested, that could very well be up to 32 kilobytes. With keep-alive connections this would just lead to recv blocking until rw_timeout had been reached, as the connection would not be officially closed after each transfer. This would also lead to a loop, as such timed out I/O request would just be attempted again. By just returning the available decrypted data, keep-alive based connectivity such as HLS playback is fixed with schannel.
-
Jan Ekström authored
The dec_buf seems to be properly managed between read calls, and we have no logic to decrypt before attempting socket I/O. Thus - until now - such data would not be decrypted in case of connections such as HTTP keep-alive, as the recv call would always get executed first, block until rw_timeout, and then get retried by retry_transfer_wrapper. Thus - if data is received - decrypt all of it right away. This way it is available for the following requests in case they can be satisfied with it.
-
Martin Storsjö authored
Use this in vf_spp.c, where the get_pixels operation is done on unaligned source addresses. Hook up the x86 (mmx and sse) versions of get_pixels to this function pointer, as those implementations seem to support unaligned use. This fixes fate-filter-spp on armv7. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Michael Niedermayer authored
The reference (thp.txt) uses floats so wrap around would seem incorrect. Fixes: signed integer overflow: 1073741824 + 1073741824 cannot be represented in type 'int' Fixes: 20658/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_THP_fuzzer-5646302555930624 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Linjie Fu authored
Set DEPRECATED flag to option cabac, replace with coder. The priority logic is: 1. s->coder; then 2. avctx->coder_type; then 3. s->cabac. Change the default option to -1 and allow the default cabac to be determined by profile. Add FF_API_OPENH264_CABAC macro for cabac to remove this option after LIBAVCODEC_VERSION_MAJOR = 59. Reviewed-by: Martin Storsjö <martin@martin.st> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
-
Linjie Fu authored
And determine the profile with following priority: 1. s->profile; then 2. avctx->profile; then 3. s->cabac; then 4. a default profile. This seems more natural in case user somehow sets both avctx->profile and s->profile. Reviewed-by: Martin Storsjö <martin@martin.st> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
-
Linjie Fu authored
Support the profiles "constrained_baseline" and "high" for libopenh264 version >= 1.8, support "constrained_baseline" and "main" for earlier version. If option not supported with current version, convert to constrained baseline with a warning for users. Reviewed-by: Martin Storsjö <martin@martin.st> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
-
- 12 May, 2020 13 commits
-
-
Lynne authored
Both API and CLI users can enable any extension they'd like using the options.
-
Lynne authored
Only warn instead. API users can find out which extensions were unavailable by using the enabled_inst_extensions and enabled_dev_extensions fields. This eliminates having to trial-and-error to find which extensions were missing.
-
Lynne authored
Due to our AVHWDevice infrastructure, where API users are offered a way to derive contexts rather than always create new one, our filterchains, being supported by a single hardware device context, can grow to considerable size. Hence, in such situations, using the maximum amount of queues the device offers can be benefitial to eliminating bottlenecks where queue submissions on the same family have to wait for the previous one to finish.
-
Lynne authored
-
Michael Niedermayer authored
Fixes: out of array access Fixes: 20659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RALF_fuzzer-5739471895265280 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: Out of array access Fixes: 20659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5658548592967680 Fixes: 20659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5723561177382912 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: out of array read Fixes: 20659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CDTOONS_fuzzer-5754518731227136 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>
-
Michael Niedermayer authored
This was suggested in https://github.com/google/oss-fuzz/issues/3787 to reduce the grouping errors by oss-fuzz Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Steven Liu authored
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
-
Steven Liu authored
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
-
Steven Liu authored
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
-
Anton Khirnov authored
-
Anton Khirnov authored
-