feat: teletext formatting

[tobbee]

This PR adds parsing of teletext styling, and rendering of the styling in output TTML and WebVTT subtitle tracks.

It is split into three commits, one for parsing teletext, one for TTML (stpp) generation and a third for WebVTT (wvtt) generation.

Beyond unit tests, I've used the sample https://drive.google.com/file/d/19ZYsoeUfH85gEilQkaAdLbPhC4CxhDEh/view?usp=sharing which has rather advanced subtitling with two separate rows at the same time, where one is left aligned and another is right aligned. This necessitates two parallel cues to be rendered. It also has some colored text.

This should solve #1335.

Commit 1: parse teletext styling and formatting

Extend the teletext parser to parse the teletext styling and formatting.
This includes translating rows into regions, calculating alignment
from start and stop position of the text, and extracting text and
background colors.

The colors are limited to full lines.
Both lines and regions are propagated in the TextSample structures.
This is because the number of lines may differ from different sources.
For teletext, there are 24 rows, but they are essentially always
used with double height, so the number of output lines is 12
from 0 to 11.
There are also corresponding regions are denoted "ttx_R",
where R is an integer row number. A renderer can use either
the line number or the region ID to render the text.

Commit 2: ttml generation for teletext to EBU-TT-D

Add support to render teletext input in EBU-TT-D (IMSC-1) format.
This includes appropriate regions ttx_0 to ttx_11 signalled
in the TextSamples, alignment and text and background colors.

The general TTML output has been changed to always include
metadata, layout, and styling nodes, even if they are empty.

EBU-TT-D is detected by the presence of "ttx_?" regions in the
samples. If detected, extra TTML elements will be added and
the EBU-TT-D linePadding used as well.

Appropriate styles for background and text colors are generated
depending on the color and backgroundColor attributes in the
text fragments.

Commit 3 fix: adapt WebVTT output to teletext TextSample.

Teletext input generates both a region with prefix ttx_
and a floating point line number (e.g. 9.5) in the
range 0 to 11.5 (due to input 0-23 as double lines).

The output is adopted to drop such regions
and convert the line number to an integer
since the standard only used floats for percent
values but not for plain line numbers.

[cosmin]

Please rebase as this will include integration tests in CI and hopefully fix the build failures on this PR on Windows and OS X.

[cosmin]

Looks like the existing TTML integration tests are failing. You can run the tests locally with python3 build/packager/packager_test.py. If the expectation files need to be updated due to improved behavior, you can run python3 build/packager/packager_test.py --test_update_golden_files and then verify that all the produced differences are expected.

[tobbee]

@cosmin Thanks for the note. I only made the unit tests work and missed the integration test.

I've now updated all the test TTML assets. The main difference is that the head element of all TTML
output now contains head, styling, and layout elements. In the test material these are empty,
but I don't think it is worth the effort to remove them if empty, since they are standard elements of TTML.

[cosmin]

@tobbee thank you, if all the CI jobs pass I'll go ahead and merge this

[cosmin]

The build is failing on Windows

D:\a\shaka-packager\shaka-packager\packager\media\formats\ttml\ttml_generator.cc(59,14): error C2220: the following warning is treated as an error [D:\a\shaka-packager\shaka-packager\build\packager\media\formats\ttml\ttml.vcxproj]
D:\a\shaka-packager\shaka-packager\packager\media\formats\ttml\ttml_generator.cc(59,14): warning C4305: 'initializing': truncation from 'double' to 'float' [D:\a\shaka-packager\shaka-packager\build\packager\media\formats\ttml\ttml.vcxproj]

[tobbee]

I talked to a real subtitle expert, and we should suppress the warning for bad data length, since it is stuffing that should be there if the TS stream is compliant with the DVB teletext spec. Apparently, the spec says that one cannot stuff on PES level, but must fill an integral number of TS packets with teletext PES data. I checked and all the payload bytes of this trailing chunk of 136 bytes are indeed stuffing 0xff in my test stream.

I'll update this PR.

[tobbee]

Turns out that the stuffing has a different data_unit_id, so by first checking that value before the length, we get rid of the warnings and only have an error if a teletext data unit has wrong length. I added another commit to fix that so this PR should now be fine for merging.