This patch also fixes a -Wtautological-constant-out-of-range-compare
warning from Clang and a -Wtype-limits warning from GCC on systems
where size_t is 64bits and unsigned 32bits. The reason for this seems
to be that variable (whose value derives from sizeof() and can therefore
be known at compile-time) is used instead of using sizeof() directly in
the comparison.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reimar Döffinger [Sat, 16 Jan 2021 01:03:45 +0000 (02:03 +0100)]
lavc/aarch64: port HEVC SIMD idct NEON
Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth
available on aarch64.
For a UHD HDR (10 bit) sample video these were consuming the most time
and this optimization reduced overall decode time from 19.4s to 16.4s,
approximately 15% speedup.
Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts",
running on Apple M1.
Guo, Yejun [Mon, 8 Feb 2021 01:53:39 +0000 (09:53 +0800)]
dnn_interface.h: add enum DNNColorOrder
the data type and order together decide the color format, we could
not use AVPixelFormat directly because not all the possible formats
are covered by it.
Guo, Yejun [Sun, 7 Feb 2021 06:35:22 +0000 (14:35 +0800)]
dnn: add function type for model
So the backend knows the usage of model is for frame processing,
detect, classify, etc. Each function type has different behavior
in backend when handling the input/output data of the model.
Guo, Yejun [Mon, 8 Feb 2021 10:46:27 +0000 (18:46 +0800)]
dnn_backend_openvino.c: fix multi-thread issue for async execution
once we mark done for the task in function infer_completion_callback,
the task is possible to be release in function ff_dnn_get_async_result_ov
in another thread just after it, so we need to record request queue
first, instead of using task->ov_model->request_queue later.
Nicolas George [Mon, 30 Nov 2020 18:28:36 +0000 (19:28 +0100)]
lavfi/drawtext: ignore final LF of textfile.
A standard text file ends with a final LF.
Without this change, it is interpreted as an empty final line,
and visible with the box option.
The current behavior can be achieved by actually having
an empty line at the end of the file.
avformat/mxfenc: Discard audio until valid video has been received
Normally, video packets are muxed before audio packets for mxf (there is
a dedicated interleave function for this); furthermore the first (video)
packet triggers writing the actual header. Yet when the first video packet
fails the checks performed on it, it will be an audio packet that leads
to writing the header and codec_ul (a value set based upon
properties of the bitstream which necessitates actually inspecting
packets) may be wrong. Therefore this commit discards audio packets until
a valid video packet has been received.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
tests/fate-run.sh: Don't overlook errors from md5 tests
The md5 test up until now ignored errors from ffmpeg (the cli) and just
md5'ed whatever ffmpeg has output; while testing scenarios in which
ffmpeg fails has its merits, errors should not be overlooked by default;
doing so also reduces the effectiveness of sanitizers as errors from
them are ignored. This has happened with a memleak in the AV1 decoder.
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mxf_d10 muxer is very picky regarding the input it accepts:
The only video accepted is MPEG-2 with absolutely constant bitrate,
i.e. all packets need to have exactly the same size; and only a few
bitrates are accepted.
The sample file used did not abide by this: Writing the first packet
(a video packet) errors out and afterwards an audio packet from the
muxing queue has been written. That's all besides metadata (which this
test is about). The FFmpeg cli returned an error, but said error has
been ignored by the md5 test.
This commit changes the test to actually send a compliant stream to the
muxer, so that it does not error out; furthermore, the test is changed
to explicitly check the metadata instead of it only being implicitly
included in the md5 checksum. The compliant stream is created by our
encoder at runtime.
Finally, the test now also covers writing user-specified
product/company/version identification.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
mxf distinguishes codec profiles by different UIDs and therefore needs
to check that the input is actually compatible with mxf (i.e. if there
is a defined UID for it). If not, then sometimes the UID would be set to
NULL and writing the (video) packet would fail. Yet the following audio
packet would trigger writing the header (which has been postponed because
the UID is not known at the start) and if the UID is NULL, this can lead
to segfaults. This commit therefore stops setting the UID to NULL if the
input is incompatible with mxf (it has initially been set to a generic
value in mxf_write_header()).
Fixes #7993.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/frame_thread_encoder: Avoid allocations of AVFrames
Up until now, when using frame threaded encoding, an AVFrame would be
allocated for every frame to be encoded. These AVFrames would reach the
worker threads via a FIFO of tasks, a structure which contained the
AVFrame as well as an index into an array which gives the place where
the worker thread shall put the returned packet; in addition to that,
said structure also contained several unused fields.
This commit changes this: The AVFrames are now allocated during init in
the array that is up until now only used to return the packets. The
contents to be encoded are put into the AVFrame in the same array
element that is also used to return the packets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/frame_thread_encoder: Avoid allocations of AVPackets, fix deadlock
Up until now, when doing frame thread encoding, each worker thread
tried to allocate an AVPacket for every AVFrame to be encoded; said
packets would then be handed back to the main thread, where the content
of said packet is copied into the packet actually destined for output;
the temporary AVPacket is then freed.
Besides being wasteful this also has another problem: There is a risk of
deadlock, namely if no AVPacket can be allocated at all. The user
doesn't get an error at all in this case and the worker threads will
simply try to allocate a packet again and again. If the user has
supplied enough frames, the user's thread will block until a task has
been completed, which just doesn't happen if no packet can ever be
allocated.
This patch instead modifies the code to allocate the packets during
init; they are then reused again and again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/frame_thread_encoder: Fix segfault on allocation error
Fixes a segfault from av_fifo_size(NULL) that happens in
ff_frame_thread_encoder_free if the fifo couldn't be allocted;
furthermore the mutexes and conditions that are destroyed in
ff_frame_thread_encoder_free are not even initialized at this point,
so don't call said function.
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
tools/target_dec_fuzzer: Adjust threshold for MSA1
Fixes: Timeout (too long to wait -> 1ms) Fixes: 29048/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSA1_fuzzer-5733703473037312 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/rmdec: Check codec_length without overflow
Fixes: signed integer overflow: 2147483647 + 64 cannot be represented in type 'int' Fixes: 30333/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-5175286983426048 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/vp8: Move end check into MB loop in vp78_decode_mv_mb_modes()
Fixes: Timeout (long -> 5sec) Fixes: 30269/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP7_fuzzer-5430325004075008 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Peter Ross <pross@xvid.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It furthermore tests the demuxer's handling of chained SeekHeads,
level 1-elements after the Clusters and the muxer's capability of
writing huge TrackNumbers as well as expanding the Cues' length field
by one byte if necessary to fill the reserved space. It also tests
propagation of metadata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/utils: Add av_assert1 to preclude NULL + len, len != 0
Such a scenario is undefined behaviour and would also indicate a bug
in our code.
Suggested-by: James Almer <jamrial@gmail.com> Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is undefined behaviour in C, so use data = len ? data + len : data
instead of data += len. GCC optimizes the branch away in this case;
Clang unfortunately doesn't.
Fixes ticket #8592.
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avdevice/avdevice: Deprecate AVDevice Capabilities API
It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004,
yet since then none of the necessary create/free_device_capabilities
functions has been implemented, making this API completely useless.
Because of this one can already simplify
avdevice_capabilities_free/create and can already remove the function
pointers at the next major bump; given that the documentation explicitly
states that av_device_capabilities is not to be used by a user, it's
options can already be removed (save for the sentinel).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/fits: Check gcount and pcount being non negative
Fixes: signed integer overflow: 9223372036854775807 - -30069403896 cannot be represented in type 'long' Fixes: 30046/clusterfuzz-testcase-minimized-ffmpeg_dem_FITS_fuzzer-5807144773484544 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The choosen value is arbitrary. I am not sure if this is a good idea
but i dont immedeately see an alternative better way, it seems either
an arbitrary limit or OOM
Fixes: OOM Fixes: 27492/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6194970578649088 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
sfan5 [Fri, 12 Feb 2021 22:47:46 +0000 (23:47 +0100)]
avcodec/mediacodecdec: do not abort when H264/HEVC extradata extraction fails
Although rare, extradata can be present but empty and extraction will fail.
However Android also supports passing codec-specific data inline and
will likely play such a stream anyway. So there's no reason to abort
initialization before we know for sure.
avformat/electronicarts: Clear partial_packet on error
Fixes: Infinite loop Fixes: 30165/clusterfuzz-testcase-minimized-ffmpeg_dem_EA_fuzzer-6224642371092480 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/r3d: Check samples before computing duration
Fixes: signed integer overflow: -4611686024827895807 + -4611686016279904256 cannot be represented in type 'long' Fixes: 30161/clusterfuzz-testcase-minimized-ffmpeg_dem_R3D_fuzzer-5694406713802752 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/pnm_parser: Check av_image_get_buffer_size() for failure
Fixes: out of array access Fixes: 30135/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PBM_fuzzer-4997145650397184 Fixes: 30208/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-5605891665690624.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
projects / ffmpeg / log