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]

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.