style_active doesn't do anything any more: It is already assured
that style_active is one when one reaches the end of a style.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The checks for whether a style should be opened/closed at the current
character position are as follows: A variable entry contained the index
of the currently active or potentially next active style. If the current
character position coincided with the start of style[entry], the style
was activated; this was followed by a check whether the current
character position coincided with the end of style[entry]; if so, the
style was deactivated and entry incremented. Afterwards the char was
processed.
The order of the checks leads to problems in case the endChar of style A
coincides with the startChar of the next style (say B): Style B was never
opened. When we are at said common position, the currently active style
is A and so the start pos check does not succeed; but the end pos check
does and it closes the currently active style A and increments entry.
At the next iteration of the loop, the current character position is
bigger than the start position of style B (which is style[entry]) and
therefore the style is not activated.
The solution is of course to first check for whether a style needs to be
closed (and increment entry if it does) before checking whether the next
style needs to be opened.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They would either lead to unnecessary ASS tags being emitted (namely
tags that are reset immediately thereafter) or would lead to problems
when parsing: e.g. if a zero-length style immediately follows another
style, the current code will end the preceding style and set the
zero-length style as the next potentially active style, but it is only
tested for activation when the next character is parsed at which point
the current offset is already greater than both the starting as well
as the end offset of the empty style. It will therefore neither be
opened nor closed and all subsequent styles will be ignored.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the 3GPP Timed Text decoder used av_dynarray_add()
for a list of style entries. Said entries are individually allocated
and owned by the pointers in the dynamic array and are therefore
unsuitable for av_dynarray_add() which simply frees the array,
but not the entries on error. In this case the intended new entry
also leaks because it has been forgotten to free it.
This commit fixes this. It is now allocated in one go and not
reallocated multiple times (and it won't be overallocated any more).
After all, the final number of elements (pending errors) is already
known in advance.
Furthermore, the style entries are now the entries of the new array,
i.e. they are no longer allocated separately. This also removes one
level of indirection.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Every font entry occupies at least three bytes, so checking early
whether there is that much data available is a low-effort way to exclude
invalid extradata. Doing so leads to an overall simplification.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the 3GPP Timed Text decoder used av_dynarray_add()
for a list of font entries, a structure which contains an allocated
string. The font entries are owned by the pointers in the dynamic array
and are therefore unsuitable for av_dynarray_add() which simply frees
the array, but not the font entries and of course not the strings. The
latter all leak if reallocating the dynamic array fails.
This commit fixes this. It stops reallocating the array altogether:
After all, the final number of elements (pending errors) is already
known in advance.
Furthermore, the font entries are now the entries of the new array,
i.e. the font entries are no longer allocated separately. This also
removes one level of indirection.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If allocating fonts fails when reading the header, all fonts are freed,
yet the counter of fonts is not reset and no error is returned; when
subtitles are decoded lateron, the inexistent list of fonts is searched
for the matching font for this particular entry which of course leads to
a segfault.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Alternatively the POC could be changed to 64bit. the large values seem to be within what is allowed.
Fixes: signed integer overflow: 2147483646 + 2 cannot be represented in type 'int'
Fixes: 26076/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5711127201447936
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is more than 10 times the size of the largest i found. And also alot more
than our encoder could handle (our encoder is limited to max 31)
Without any limit megabyte+ sized blocks can be reallocated millions of times.
Sadly the SCTE-20 spec does not seem to contain any hard limit directly, so this limit here
is arbitrary
Fixes: Timeout (25sec -> 152ms)
Fixes: 25714/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG2VIDEO_fuzzer-5713633336885248
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The ASUS V2 format is designed for a little-endian bitstream reader, yet
our encoder used an ordinary big-endian bitstream writer to write it;
the bits of every byte were swapped at the end and some data (namely the
numbers not in static tables) had to be bitreversed before writing it at
all, so that it would be reversed twice.
This commit stops doing so; instead, a little-endian bitstream writer is
used. This also necessitated to switch certain static tables, which
required trivial modifications to the decoder (that uses the same
tables).
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now the ASV2 decoder used an ordinary big-endian bitreader to
read data actually destined for a little-endian bitreader; this is done
by reversing the whole input packet bitwise, using the big-endian
bigreader and reversing (and shifting) the result again. This commit
stops this and instead uses a little-endian bitreader directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: off by 1 error
Fixes: index 5 out of bounds for type 'COOKSubpacket [5]'
Fixes: 25772/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_COOK_fuzzer-5762459498184704.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes fate-binsub-movtextenc on PPC64
Currently tags are written in reverse order on BE arches. This is fixed
by using MKBETAG() and AV_RB32() to be arch agnostics.
Also s->font_count is of type int. On BE arches with 32bit int,
count = AV_RB16(&s->font_count) will read two most significant bytes
instead of the least significant bytes. This is fixed by assigning
s->font_count to count first.
The final change is modifying the type of len. On BE arches
the most significant byte of the int was written instead of the least
significant byte.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
The MV checks did not consider the width and height of the block, also they
had some off by 1 errors. This resulted in undefined behavior and crashes.
This commit instead errors out on these
Fixes: out of array read
Fixes: 26080/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5758146355920896
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
