Previously, we produced output with either \r\n or mixed line endings.
This was undesirable unto itself, but also made working with patches affecting
FATE output particularly challenging, especially via the mailing list.
Everything that consumes the SSA/ASS format is line-ending-agnostic,
so \n is selected to simplify git/ML usage in FATE.
Extra \r characters at the end of a packet are dropped. These are always
ignored by the renderer anyway.
The Encoding field (and the \fe tag) allows to limit font selection to
only those fonts declaring support for the specified codepage in their
OS/2's table "Code Page Character Range" field.
Particularly, Encoding=0 means only font's declaring support for "ANSI",
or rather "Latin (Western European)", are allowed to be selected.
Specifying Encoding=1 allows all fonts to be considered.
We do not want to limit font selection, so specify Encoding=1.
NB: at the time of writing libass only partially supports this field,
thus hiding the issue in any libass-based renderer. A VSFilter-based
DirectShow filter or XySubFilter will reveal the issue when a font not
declaring support for latin characters is specified in a style.
Colour values used in ASS files without a "YCbCr Matrix" header set to
"None" are subject to colour mangling, due to how ASS was historically
conceived. A more in-depth description can be found in the documetation
inside libass' public ass_types.h header. The important part is, if this
header is not set to "None", the final output colours can deviate from
the literal value specified in the file. When converting from non-ASS
formats we do not want any colour shift to happen, so let's set the
appropiate header.
NB: ffmpeg's subtitle filter, does not follow libass' documentation
regarding colour mangling, thus hiding the bug. Anything based on
VSFilter, XySubFilter or e.g. mpv do and might show the issue.
(Of course native ASS subs, which _do_ rely on colour mangling won't
work properly with the subtitle filter, but this can be fixed another
time)
When a JACOsub subtitle has two timestamps, they represent its start and
end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the
duration is the difference between the two, not the sum of the two.
The subtitle end times in the FATE test for this were wrong as a result;
fix them too. (This test is based on JACOsub's demo.txt, and the end
time computed for the last line using @ now matches what the comments
there say it should be.)
Also tested in practice using MPV, a LaserDisc, and some authentic 1993
JACOsub files.
Signed-off-by: Adam Sampson <ats@offog.org>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids the following libass warning when using the subtitles
filter: "Neither PlayResX nor PlayResY defined. Assuming 384x288"
Subtitles tests change because the output is ASS and the PlayRes[XY]
ends up in the output.
