Fixes: signed integer overflow: 1 - -9223372036854775808 cannot be represented in type 'long'
Fixes: 23490/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5133490093031424

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: NNicolas George <george@nsup.org>
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

The already parsed subtitles (contained in an FFDemuxSubtitlesQueue)
would leak if an error happened upon reading a subsequent subtitle
or when allocating extradata.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Up until now, the microdvd demuxer uses av_strdup() to allocate the
extradata from a string; its length is set to strlen() + 1, i.e.
including the \0 at the end. Upon remuxing, the muxer would simply copy
the extradata at the beginning, including the \0.

This commit changes this by not adding the \0 to the size of the
extradata; the muxer now delimits extradata by inserting a \n. This
required to change the subtitles-microdvd-remux FATE-test.

Furthermore, the extradata is now allocated with zeroed padding.

The microdvd decoder is not affected by this, as it didn't use the size
of the extradata at all, but treated it as a C-string.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: NPaul B Mahol <onemda@gmail.com>
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Lauri Kasanen
Reviewed-by: Tomas Härdin

MicroDVD has a "hack" for specifying the video framerate the subtitle
was authored against. The demuxer reads this hint correctly, but didn't
skip it correctly.

This was not noticed, because the exported packet has its duration set
to 0, making it invisible (depending on the API user's rendering logic).
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NJames Almer <jamrial@gmail.com>
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

MicroDVD files are normally frame-based (i.e. there are no absolute
timestamps), but can have an optional frame rate header. If this
header is missing, the timestamps depend on the frame rate of the
video they were created for.

The demuxer will use a fallback frame rate if it's missing from the
header. Currently, applications using libavformat can't know whether
the time base is based on the fallback value, or if a frame rate
header was present.

This commit introduces a subfps AVOption for MicroDVD, and the
demuxer sets it if and only if a frame rate header was present.
Signed-off-by: NClément Bœsch <u@pkh.me>

The BOM is already skipped in the probe function, but not the header
read function. This could cause the header to be misparsed, such as
not interpreting the FPS line.

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.

This flag is not necessary.

Current MicroDVD AVPackets contain timing information and trailing line
breaks. The data is now only composed of the markup data. Doing this
consistently between text subtitles decoders allows to use different
codec for various formats. For instance, MicroDVD markup is sometimes
found in some VPlayer files. Also, generally speaking, the subtitles
text decoders have no use of these timings (and they must not use them
since it would break any user timing adjustment).

Technically, this is a major ABI break. In practice, a mismatching
lavf/lavc will now error out for MicroDVD decoding. Supporting both
formats requires unnecessary complex and fragile code.

FATE needs update because line breaks in the ASS file were "\n" (because
that's what is used in the original file). ASS format expect "\r\n" line
breaks; this commit fixes this issue. Also note that this "\r\n"
trailing need to be moved at some point from the decoders to the ASS
muxer.

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Example:

{3350}{}this subtitle...
{3390}{}...continues up to...
{4000}{4500}this one.
{4600}{}and now...
{4800}{}...to the end of the presentation

Signed-off-by: NAurelien Jacobs <aurel@gnuage.org>