aboutsummaryrefslogtreecommitdiffstats
path: root/tests/ref/fate/hapenc-hap-none
diff options
context:
space:
mode:
authorAndreas Rheinhardt <andreas.rheinhardt@outlook.com>2021-10-01 11:57:34 +0200
committerAndreas Rheinhardt <andreas.rheinhardt@outlook.com>2021-10-02 17:14:20 +0200
commit60e12318bb9372b3053703f2a3b849270b9d2fe5 (patch)
tree9e6f2b9cf240a11c6ba5075344af06e2598570bd /tests/ref/fate/hapenc-hap-none
parent03a0dbaff34222970960f0df9f92b818005ee03f (diff)
downloadffmpeg-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 'tests/ref/fate/hapenc-hap-none')
0 files changed, 0 insertions, 0 deletions