Now the listen timeout is hardcoded(10s).
How to test(30s timeout):
./ffprobe -listen_timeout 30 -protocol_whitelist rtp,udp,file -i test.sdp
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
then we can set the rtp read timeout instead of infinite timeout.
How to test(5s timeout):
./ffprobe -i rtp://192.168.1.67:1234?timeout=5000000
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
During operation, the user exits and interrupts,
causing pls->segment to be released,
resulting in a null pointer crash
Signed-off-by: bevis <javashu2012@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Fixes: Infinite loop
Fixes: 26445/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-5125558331244544
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>
The longest codes of any VLC codebooks are 18 bits long and the VLC
tables itself use 9 bits; therefore it is sufficient to read twice from
the table, yet this has been done thrice.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, quad VLCs are initialized with codes of type uint32_t,
pair VLCs with codes of type uint16_t. There were two separate loops in
the decoder's init function for each type of VLC. This commit unifies
this: The type of the codes are now passed in as void * and the actual
size of the codes is obtained from a table. This approach also allows to
use the smallest type for each VLC code table: some quad tables actually
fitted in uint16_t. This allows to remove about 7KB from the binary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It would lead to crashs lateron if they failed.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, there was no cleanup in case initializing the Theora VLC
tables failed, leading to memleaks. This commit gets rid of them by
setting the FF_CODEC_CAP_INIT_CLEANUP flag for all decoders in vp3.c;
this also allows to remove some (now redundant) cleanup code.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Prefer to error than to create a broken file. Closes ticket #5829.
Effectively disables remuxing adpcm_swf from flv -> wav.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Fixes: signed integer overflow: 2147483647 + 64 cannot be represented in type 'int'
Fixes: 26218/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CRI_fuzzer-5734075396259840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array write
Fixes: 26242/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CRI_fuzzer-5161495882891264
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
6f69f7a8bf introduced this and it was part
of a very large merging of refactoring. Current behaviour is what is
reflected by this indenting change, however my understanding of timing
is such that this correct behaviour.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: division by zero
Fixes: 26293/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_PSX_fuzzer-5176665237618688
Fixes: 26331/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_PSX_fuzzer-5632330364092416
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 536870912 + 1610612736 cannot be represented in type 'int'
Fixes: 26288/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-6194364759670784
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 553590816 - -2145378049 cannot be represented in type 'int'
Fixes: 26315/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5938755121446912
Fixes: 26340/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5644316208529408
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: OOM
Fixes: 26168/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NOTCHLC_fuzzer-6019839015256064
Equation is based on LZ4_COMPRESSBOUND from lz4.h
Suggested-by: Paul
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -1172299744 * 2 cannot be represented in type 'int'
Fixes: 26258/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5672758488596480
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 241173056 + 1953511200 cannot be represented in type 'int'
Fixes: 26086/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5068366420901888
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Commit a2b1dd0ce3 added support for
parsing annex B HEVC extradata to extract profile and level information.
Yet it only checks for there to be enough data left for the startcode
and the first byte of the NAL unit header and not for the full NAL unit
header; it simply presumes the second byte of the NAL unit header to be
present and skips it. Then the remaining size of the extradata is calculated
which ends up negative if the second byte of the NAL unit header is not
present. Yet when calling ff_nal_unit_extract_rbsp() it
will be converted to an uint32_t and end up as UINT32_MAX which
will cause mayhem.
This is solved by making sure that there is always enough remaining
extradata that could (pending 0x03 escapes) contain the data that we
are interested in.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 3458015007900000256 + 6425686373040000000 cannot be represented in type 'long'
Fixes: 26430/clusterfuzz-testcase-minimized-ffmpeg_dem_BRSTM_fuzzer-5761175004119040
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix ticket: 8636
When write keyframe and the keyframe is the frist packet of the segment,
then compute the size of the keyframe which have been write into segment
first packet. and set the start position of the segment, should not use
avio_tell(vs->out) to get the keyframe position, because it can be set
to 0 if close at above of the workflow, that maybe inaccurate, but the
start_pos can be used here, because start_pos is set after write
the previous packet.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
if the length of the root url is 0, unnecessary process the root_url
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
The target duration will be a negative value when there are
some b frames after prevous frame, the pts after current packet
is large than the pts of current packet, so the target duration
will compute as 0.040000 - 0.080000, then the value of the target
duration will be -0.040000. so hls muxer should check the pts after
current packet minus the pts of current packet, hls muxer can split
the stream as a segment if the target duration is neither negative nor
zero, hls muxer cannot split the stream as a segment if the
target duration is either negative or zero then get the next packet
until the target duration is not negative or zero.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Suggested-by: Zhili Zhao <quinkblack@foxmail.com>
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
