These two functions are always called after another; after all, what
ff_dolby_e_parse_init does is obviously part of parsing the frame header.
Also move the DolbyEHeaderInfo into DBEContext so that parsing the frame
header only needs one struct (both users used a DBEContext immediately
followed by a separate DolbyEHeaderInfo).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Parsers are not forced to use a ParseContext and the other stuff from
parser.h which is just designed to help parsers recombining frames. But
this parser does not do this at all, i.e. the ParseContext is unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: index 26981 out of bounds for type 'ASFStreamData [128]'
Fixes: 27334/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-6197611002068992
Alternatively the array could be increased in size or the cases not fitting be ignored
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: 9223372036854710272 - -541165944832 cannot be represented in type 'long'
Fixes: 27000/clusterfuzz-testcase-minimized-ffmpeg_dem_IVF_fuzzer-5643670608674816
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: -2147483648 - 4 cannot be represented in type 'int'
Fixes: 26907/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5746202330267648
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: 1111111111111111111 * 10 cannot be represented in type 'long'
Fixes: 26892/clusterfuzz-testcase-minimized-ffmpeg_dem_TEDCAPTIONS_fuzzer-5756045055754240
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Said table was unused in case libvorbis was disabled.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_init_ff_cos_tabs is only used for the floating point FFT and only
if hardcoded tables are disabled.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_fill_line_with_color and ff_draw_rectangle are unused since
19c8f2271423281c9b876b984076a6467c455904; ff_copy_rectangle
is unused since 53b7a3fe08.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Both motion vector tables have the same number of elements, hence one
can inline said number and remove the field containing the number of
elements from the structure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: -3468545475927866368 * 4 cannot be represented in type 'long'
Fixes: 28879/clusterfuzz-testcase-minimized-ffmpeg_dem_NUV_fuzzer-6303367307591680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The entry read is not used in subsequent computation, thus its
value is not important.
Fixes: out of array read
Fixes: 28578/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SIREN_fuzzer-6332019122503680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I've run into some bugs where I was downloading a bunch of data and began
seeing weird hiccups. For example, javascript promises to allow you to push
some very long lines of data, but the hiccups I saw was with data larger
than 2k in length (windows) pushed out of a child process stdout piped into
the stdin of the calling parent program.
Soo much for smooth promises, this was broken and would run into similar
problems on a linux PC with 32k line limits.
The solution was to break the data into smaller chunks than 2k - and then
these data hiccups disappeared (windows PC).
It would be expected to be similar for linux PCs (32k I think) and other
OSes with different sizes.
If the ANSI required minimum needs to be 509 chars or larger (assuming
509+<CR>+<LF>+<0>=512), then 509 was chosen as the shortest worst-case
scenario) in this patch.
Most small pictures will go output looking pretty much the same data out
until you get to about 84bytes (672 pixels wide), where lines out begin to
be split. For example a UW 4K will exceed a 2k readln and a UW 10K picture
approaches an 8k readln
The purpose for this patch is to ensure that data remains below the
readline limits (of 509 chars), so that programs (like javascript) can push
data in large chunks without breaking into hiccups because the data length
is too long to be pushed cleanly in one go.
Subject: [PATCH 3/3] avcodec/xbmenc: Allow for making UW images
Worst-case ANSI must allow for 509 chars, while Windows allows for 2048
and Linux for 32K line length. This allows an OS with a small readline
access limitation to fetch very wide images (created from ffmpeg).
Two minor memory improvements.
First bug reduces memory needed to about 6/7 the needed amount, which
allows you to host almost 7 pictures in the same memory needed for 6
Second is a recalculation of the total additional memory for headers etc.
size = avctx->height x (linesize * 6 + 1) + (31+32+38+4+1)
Subject: [PATCH 2/3] avcodec/xbmenc: xbm Lower memory use
Small 6/7th size memory reduction.
size = avctx->height x (linesize * 6 + 1) + (31+32+38+4+1)
Signed-off-by: Joe Da Silva <digital@joescat.com>
There is a minor bug in xbm encode which adds a trailing comma at the end
of data. This isn't a big problem, but it would be nicer to be more
technically true to an array of data (by not including the last comma).
This bug fixes the output from something like this (having 4 values):
static unsigned char image_bits[] = { 0x00, 0x11, 0x22, }
to C code that looks like this instead (having 3 values):
static unsigned char image_bits[] = { 0x00, 0x11, 0x22 }
which is the intended results.
Subject: [PATCH 1/3] avcodec/xbmenc: Do not add last comma into output array
xbm outputs c arrays of data.
Including a comma at the end means there is another value to be added.
This bug fix changes something like this:
static unsigned char image_bits[] = { 0x00, 0x11, 0x22, }
to C code like this:
static unsigned char image_bits[] = { 0x00, 0x11, 0x22 }
Signed-off-by: Joe Da Silva <digital@joescat.com>
Before 257a83b969, certain buffers were
zero-allocated in the init function and only reallocated lateron if they
turned out to be too small; now they are only allocated during init,
leading to use-of-uninitialized values lateron. The same could happen
before if the dimensions are big enough so that the buffers would be
reallocated, as the new part of the reallocated buffer would not be
zeroed (happened for 960x960). So always zero the buffers in the
function designed to init them.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The VLC for the macroblock address increment uses nine bits;
yet there is no code with this length: All codes are either shorter or
longer. So one can make the table smaller without changing the amount of
codes that need more than one round of parsing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This reverts commit 6ac0e78183.
The mpeg4video parser can reach code that presumes that a certain VLC
has been initialized; yet Libav did not ensure this and Libav bug #1012
[1] is about an ensuing crash.
Instead of fixing the root cause a simple check for whether said VLC
has already been initialized was added; said check is inherently racy.
The proper fix is of course to ensure that the VLC is initialized and
commit 7c76eaeca2 already ensured this,
so there was no need to merge 6ac0e78183
at all. This commit therefore reverts said commit.
[1]: https://bugzilla.libav.org/show_bug.cgi?id=1012
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
1b373b41d9 made it a bit harder to find
out that a call to avpriv_dv_produce_packet is dead when the DV demuxer
is disabled; too hard for GCC on -O0. So simplify the check a bit.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
