This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 9223372036854775807 - -1 cannot be represented in type 'long'
Fixes: 23167/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6425051741290496
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes a bunch of possible overread in avformat with the idiom p +=
strcspn(p, "\n") + 1 (strcspn() can focus on the trailing '\0' if no
'\n' is found, so the +1 leads to an overread).
Note on lavf/matroskaenc: no extra subtitles.o Makefile dependency is
added because only the header is required for ff_subtitles_next_line().
Note on lavf/mpsubdec: code gets slightly complex to avoid an infinite
loop in the probing since there is no more forced increment.
Skip the "\r" as normal text. Otherwise it will be the first character
of the string passed to sscanf(), which then fill fail to match the
timestamps.
Signed-off-by: Clément Bœsch <u@pkh.me>
