Suggested by zhilizhao, vlc project has solved the compatibility by
the same way, so I borrowed the comments from vlc project.
Fixes ticket #9449
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Zhao Zhili added a ttl upper bound in commit 9daac85da8,
but the check for ttl in url is missing still.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Add command 'delays' to the adelay filter.
This command accepts same values as the option with one difference, to apply
delay to all channels prefix 'all:' to the argument.
Signed-off-by: David Lacko <deiwo101@gmail.com>
It is sane, but UB. It could happen in case of allocation errors
in vc2_encode_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using Range allows for getting the full file size from the
Content-Range header in the response, even if the server sends
back the response using chunked Transfer-Encoding, which does not
allow using Content-Length.
When Transfer-Encoding:chunked is used, the client must ignore a
Content-Length header, if present. However, it should not ignore a
Content-Range header, which also includes the full size of the
entity.
As the potential failure of the av_mallocz(), the 's->alpha_context'
could be NULL and be dereferenced later.
Therefore, it should be better to check it and deal with it if fails
in order to prevent memory leak, same as the av_frame_alloc() in
ff_vp56_init().
Fixes: 39a3894ad5 ("lavc/vp6: Implement "slice" threading for VP6A decode")
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
bca30570d2 added a user option to set max_packet_size replacing
a hardcoded value. This had a side-effect of leaving the field
set to 0 when packet demuxing is carried out from another demuxer
using avpriv functions, which could lead to demux failure.
Hardcoded max_packet_size inside avpriv_mpegts_parse_open to
2048000 to avoid this. Value chosen to be 10x that of default value
to accommodate large payloads.
Use ff_thread_release_buffer() instead of av_frame_unref(),
as the former handles the case of non-thread-safe callbacks
properly. (This is possible now that ff_thread_release_buffer()
no longer requires a ThreadFrame.)
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The majority of frame-threaded decoders (mainly the intra-only)
need exactly one part of ThreadFrame: The AVFrame. They don't
need the owners nor the progress, yet they had to use it because
ff_thread_(get|release)_buffer() requires it.
This commit changes this and makes these functions work with ordinary
AVFrames; the decoders that need the extra fields for progress
use ff_thread_(get|release)_ext_buffer() which work exactly
as ff_thread_(get|release)_buffer() used to do.
This also avoids some unnecessary allocations of progress AVBuffers,
namely for H.264 and HEVC film grain frames: These frames are not
used for synchronization and therefore don't need a ThreadFrame.
Also move the ThreadFrame structure as well as ff_thread_ref_frame()
to threadframe.h, the header for frame-threaded decoders with
inter-frame dependencies.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These will be used by the codecs that need allocated progress
and is in preparation for no longer using ThreadFrame by the codecs
that don't.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for further commits that will stop
using ThreadFrame for frame-threaded codecs that don't use
ff_thread_(await|report)_progress(); the API for those codecs
having inter-frame depdendencies will live in threadframe.h.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Several of our decoders support both frame- as well as slice-threading;
in case of the latter avctx->internal->thread_ctx points to
a SliceThreadContext, not to a frame-thread PerThreadContext.
So only treat avctx->internal->thread_ctx as the latter after
having checked that frame-threading is active.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 9223372036854775748 + 60 cannot be represented in type 'long'
Fixes: 44417/clusterfuzz-testcase-minimized-ffmpeg_dem_HLS_fuzzer-5802443881971712
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 32768 by 16 places cannot be represented in type 'int'
Fixes: Timeout
Fixes: 44219/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMVJPEG_fuzzer-4679455379947520
Fixes: 44088/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMVJPEG_fuzzer-4885976600674304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Division by 0
Fixes: 44035/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4826721386364928
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: pointer index expression with base 0x000000000000 overflowed to 0xffffffffffffffff
Fixes: 44012/clusterfuzz-testcase-minimized-ffmpeg_dem_HLS_fuzzer-5670607746891776
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
