Fixes: left shift of 243 by 24 places cannot be represented in type 'int'
Fixes: 22716/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOVTEXT_fuzzer-5704263425851392
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d7a2311a2c5be1e861c3df618d295e7eced8e84b)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Font sizes are relative to the subtitle frame dimensions. If the
expected frame dimensions are not known, the font sizes will most
likely be incorrect.
Signed-off-by: Philip Langdale <philipl@overt.org>
Style flags were only being turned on. If the default was on and style
record turned off, style flag remained on.
Signed-off-by: Philip Langdale <philipl@overt.org>
It's not necessary to walk the style record list twice per subtitle
character. style records are in order and do not overlap.
Signed-off-by: Philip Langdale <philipl@overt.org>
Limits based on 3GPP TS 26.245 V14.0.0
Fixes: Timeout
Fixes: 6377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOVTEXT_fuzzer-5175929115508736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Subtitles which contained styled UTF-8 subtitles (i.e. not just 7 bit
ASCII characters) were not handled correctly. The spec mandates that
styling start/end ranges are in "characters". It's not quite clear what
a "character" is supposed to be, but maybe they mean unicode codepoints.
FFmpeg's decoder treated the style ranges as byte idexes, which could
lead to UTF-8 sequences being broken, and the common code dropping the
whole subtitle line.
Change this and count the codepoint instead. This also means that even
if this is somehow wrong, the decoder won't break UTF-8 sequences
anymore. The sample which led me to investigate this now appears to work
correctly.
The value of wrap_flag in the Text Wrap Box specifies if the text is to
be wrapped or not. Uses 'end of line wrap' amongst the wrap styles
supported by ASS if the text is to be wrapped, i.e; fill as much text
in a line as possible, then break to next line.
The 3GPP spec has no provision for smart wrapping.
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
As suggested, posting the combined patch with the fate changes.
The patch sets the default style in ASS from the default style
information present in the movtext header.
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
The commit broke sub-movtext and sub-subripenc
fate output differs between mips ad x86 so updating fate ref is not
possible
This reverts commit d670848d4c.
Add support for fontsize in style records. The patch uses reset to
directly change back to default style instead of using closing tags,
since we are not handling the default styles right now.
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
Previous version reviewed-by: Philip Langdale <philipl@overt.org>
Previous version reviewed-by: Carl Eugen Hoyos <cehoyos@ag.or.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The logic here was off. If the packet size is exactly two, then
it's a well-formed empty subtitle, used to mark the end of the
duration of the previous subtitle.
Signed-off-by: Philip Langdale <philipl@overt.org>
