diff options
author | Andreas Rheinhardt <andreas.rheinhardt@outlook.com> | 2021-10-01 11:57:34 +0200 |
---|---|---|
committer | Andreas Rheinhardt <andreas.rheinhardt@outlook.com> | 2021-10-02 17:14:20 +0200 |
commit | 60e12318bb9372b3053703f2a3b849270b9d2fe5 (patch) | |
tree | 9e6f2b9cf240a11c6ba5075344af06e2598570bd /libavcodec/hapenc.c | |
parent | 03a0dbaff34222970960f0df9f92b818005ee03f (diff) | |
download | ffmpeg-60e12318bb9372b3053703f2a3b849270b9d2fe5.tar.gz |
avformat/sccdec: Don't use uninitialized data, fix crash, simplify logic
Up until now, the scc demuxer not only read the line that it intends
to process, but also the next line, in order to be able to calculate
the duration of the current line. This approach leads to unnecessary
complexity and also to bugs: For the last line, the timing of the
next subtitle is not only logically indeterminate, but also
uninitialized and the same applies to the duration of the last packet
derived from it.* Worse yet, in case of e.g. an empty file, it is not
only the duration that is uninitialized, but the whole timing as well
as the line buffer itself.** The latter is used in av_strtok(), which
could lead to crashes. Furthermore, the current code always outputs
at least one packet, even for empty files.
This commit fixes all of this: It stops using two lines at a time;
instead only the current line is dealt with and in case there is
a packet after that, the duration of the last packet is fixed up
after having already parsed it; consequently the duration of the
last packet is left in its default state (meaning "unknown/up until
the next subtitle"). If no further line could be read, processing
is stopped; in particular, no packet is output for an empty file.
*: Due to stack reuse it seems to be zero quite often; for the same
reason Valgrind does not report any errors for a normal input file.
**: While ff_subtitles_read_line() claims to always zero-terminate
the buffer like snprintf(), it doesn't do so if it didn't read anything.
And even if it did, it would not necessarily help here: The current
code jumps over 12 bytes that it deems to have read even when it
hasn't.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Diffstat (limited to 'libavcodec/hapenc.c')
0 files changed, 0 insertions, 0 deletions