Fixes: out of array access
Fixes: 15381/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5668057826983936
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>
Fixes: 15372/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5708881759567872
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>
Before this commit, the Matroska muxer would read a block when required
to do so, parse the block, create and return the necessary AVPackets and
yet keep the blocks (in a dynamically allocated list), although they
aren't used at all any more. This has been changed. There is no list any
more and the block is immediately discarded after parsing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Every new element of an EbmlList is zeroed initially in
ebml_parse_elem, so that in particular a SimpleBlock's duration is
initialized to zero. Therefore it is unnecessary to initialize this
field again (for SimpleBlocks) in matroska_parse_cluster_incremental.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By default, the data_offset member of the AVFormatInternal of the
AVFormatContext associated with the MatroskaDemuxContext has not been
initialized explicitly by any Matroska-specific function, so that it was
initialized by default to the offset at the end of matroska_read_header,
i.e. usually to the offset of the length field of the first encountered
cluster. This meant that in case that the Matroska-specific seek-code
fails because there are no index entries for the target track a seek to
data_offset would be performed and ordinary parsing would start from
there which is nonsense: The length field would be treated as EBML ID and
(if the length field is not longer than four bytes (EBML numbers that
long are rejected as invalid EBML IDs)) whatever comes next would be
treated as its EBML size although it simply isn't.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The earlier code relied on the length of clusters always being coded on
eight bytes as was the behaviour of libavformat's Matroska muxer until
recently. But given that our own Matroska muxer now (and mkvmerge from
time immemorial) creates files that don't conform to this assumption,
it is high time to get rid of this assumption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When the new incremental parser was introduced, the old parser was
kept, because the new parser was unable to handle the way SSA packets
are put into Matroska. But since 2014 (since c7d8dbad) this is no
longer needed, so that the old parser can be completely removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This commit replaces copying attached pictures by using references to
the already existing buffers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When multiple variant streams are specified by var_stream_map option,
implementation assumes that each elementary stream is assigned only once
to any variant. But this is not checked. This patch makes this checking.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Reviewed-by: Steven Liu<lq@onvideo.cn>
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes: 15118/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5740230004441088
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: 44444442 * 100 cannot be represented in type 'int'
Fixes: 15117/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5164660531134464
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes: 15123/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5738039235575808
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit uses smaller types for some static const arrays to reduce
their size in case the entries can be represented in the smaller type.
The biggest savings came from inv_map_table in vp9.c.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
avformat/movenc still relies on AVCodecContext time_base to mux tmcd
tracks and segment muxer did not copy that field to inner streams
leading to SIGFPE in the child muxer instance.
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Currently %v is substituted by its variant index value (0, 1, 2
etc.). In some use cases it would be handy to specify names for variants
instead of numerical indexes. This patch makes it possible to use names
instead of default indexes. In var_stream_map option each or some of the
variant streams may use an optional name attributum (e.g.
-var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is
specified for a variant, then this name value will be used as
substitution value of %v instead of the default index value.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@onvideo.cn>
Hi All,
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Most of %v handlng is done in format_name function. Currently
in this function the result buffer is the same as the
input pattern buffer, so you must allocate it before calling format_name
function. It also means, that it is silently assumed that the result
string will NOT be
longer that the pattern string. It is true most of the time, because %v
may appear only once in the pattern string and number of variant streams
is less than 100 in practical cases. But theoretically it will fail if
specified number of variant streams is greater than 100 (i.e. longer
than 2 digits).
This patch fixes this behaviour by altering format_name function to
allocate the
result buffer and return it to the caller.
Please, review this patch.
best,
Bela
>From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001
From: Bela Bodecs <bodecsb@vivanet.hu>
Date: Mon, 17 Jun 2019 14:31:36 +0200
Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Most of %v handlng is done in format_name function. Currently
in this function the result buffer is the same as the input pattern
buffer, so you must allocate it before calling format_name function. It
also means, that it is silently assumed that the result string will NOT
be longer that the pattern string. It is true most of the time, because
%v may appear only once in the pattern string and number of variant
streams is less than 100 in practical cases. But theoretically it will
fail if specified number of variant streams is greater than 100. This
patch fixes this behaviour by altering format_name function to allocate
the result buffer and return it to the caller.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Redundant condition: '!A || B' is equivalent to '!A || (A && B)' but
more clearly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
FF_DECODE_ERROR_CONCEALMENT_ACTIVE is set when the decoded frame has error(s) but the returned value from
avcodec_receive_frame is zero i.e. concealed errors
Signed-off-by: Amir Pauker <amir@livelyvideo.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Direct leak of 536 byte(s) in 1 object(s)
Fixes: 15266/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-5629530426834944
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>
Fixes: left shift of negative value -14614752
Fixes: 15174/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5670543606415360
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>
Fixes: out of array read
Fixes: 14563/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5646451545210880
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 read
Fixes: 14563/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5646451545210880
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: 904444 * 3600 cannot be represented in type 'int'
Fixes: 15113/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5764083346833408
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: 84026453 * 28 cannot be represented in type 'int'
Fixes: 15111/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5675630072430592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>