Commit 8038cb11da4e4f803e88f4476d9e49348bb3ca19 introduces various closed caption bugs

[Clayton Smith <argilo@…>]

Following commit 8038cb11da4e4f803e88f4476d9e49348bb3ca19 I retested CEA-708 (ATSC) captions using the following test video:

​http://ncamftp.wgbh.org/DTV/CEA%20test%20material/Iteration_1/

The commit has introduced various problems:

• When new captions appear, bits and pieces of the old captions are visible around the edges. This can be seen in many places throughout the test video.
• Sometimes the bottom line of captions gets cut off. See for example 01:03:21 and 01:03:26 (as displayed by the clock in the test video). In general the captions seem to be too low, always extending beyond the bottom of the red box in the test video. Maybe this has something to do with the font change mentioned in the commit message.
• Sometimes the last letter of captions gets cut off slightly. See for example 01:01:03 in the test video, where the final double quote gets cut off because the box is not wide enough.
• There is now blank space between each line of captions, which looks ugly compared to before. Either the lines need to be closer together, or the black background needs to be taller.

[Jim Stichnoth]

Clayton, thanks for the deep testing of this.

As background, the goal was to refactor cc608, cc708, and text subs into a common framework that supports all formatting controls and tries to give a consistent look across the subtitle types. For consistency, cc608 was used as the basis since it doesn't offer much flexibility in layout. The original cc608 code included gaps between lines, and that has been carried into cc708 and text as well.

I haven't been able to reproduce issues 1 and 3. What is your setting for OSDSubFont, and what is your playback resolution? (Mine are FreeMono?, and 1280x720 and 1366x768.)

Issue 2 is the result of improper CEA-708 encoding. In this sample, the text is anchored relative to the top of the screen, so the first caption row should appear at a specific point, but there are no guarantees on subsequent rows. You should see a similar effect in the old code if you change OSDCC708TextZoom.

Issue 4 I plan to leave as it is for now, with future plans to make line spacing and other attributes customizable by the theme and/or the user.

[Clayton Smith <argilo@…>]

My OSDSubFont was set to FreeSans? (which I'm guessing is the default, since this was a relatively recent clean install). I changed it to FreeMono?, and that got rid of issue 2 (but not the others). My screen resolution is 1680x1050.

I'll dig through CEA-708 to see what it says with respect to issue 2. Even if it technically allows captions to go off the screen, it would probably be good to have some safeguard to stop that from happening, since captions that can't be seen aren't terribly useful. :-)

[Clayton Smith <argilo@…>]

The following section seems to be what is intended to keep captions on the screen. My guess would be that the 1/15 rule is violated when FreeSans? is used.

"9.13 DTVCC Section 8.5.1 - Pen Size At a minimum, decoders must support the STANDARD pen size, with the implementation of the LARGE and SMALL pen sizes being optional.

The STANDARD pen size should be implemented such that the height of the tallest character in any implemented font is no taller than 1/15 of the height of the safe-title area, and the width of the widest character is no wider than 1/32 of the width of the safe-title area for 4:3 displays and 1/42 of the safe-title area width for 16:9 displays.

The LARGE pen size should be implemented such that the width of the widest character in any implemented font is no wider than 1/32 of the safe-title area for 16:9 displays. This recommendation allows for captions to grow to a LARGE pen size without having to reformat the caption since no caption will have more than 32 characters per row (see Section 8.4.6)."

[Jim Stichnoth]

We appear to be within the spec for text height with the standard pen size. In both the old code and the new code, the font height is set to 1/20 of the safe area height. In the new code, additional spacing is added between lines such that the distance from the top of one line to the top of the next line is 1/17 of the safe area height. (Note that 17 is chosen to match the number of rows in the non-teletext CEA-608 spec.) This is all assuming OSDCC708TextZoom is set to 100.

On top of this, there is a 4% slop added to deal with what looks like a Qt text size calculation bug, plus possible cumulative truncation/rounding error, but I would be very surprised if this reduced 17 lines down to less than the spec's minimum 15.

[Github]

Subtitles: Improve the vertical layout of CEA-708 captions.

The problem is that we were expecting the bounding box height of caption text to be equal to the font pixel size, which is generally untrue and can in fact be very different. As a result, CEA-708 captions could have too much extra space between the lines. Now, we target line spacing based on the desired pixel size, taking care not to let lines overlap.

Refs #10333

Branch: master Changeset: f7b7f61cb43a2022cb5faed608561bdd5fd64ae3

[Github]

Subtitles: Try to ensure CEA-708 subtitles stay within the safe area.

In a perfect storm of fonts with large heights relative to pixel size, anchor points close to the bottom/right, and/or large values of OSDCC708TextZoom, the text may end up falling outside the safe area. Try to shift it back in if this happens.

Refs #10333

Branch: master Changeset: 148314b2961f0db6eba5524d1ddee95f4b2767e2

[Jim Stichnoth]

Many thanks to Clayton for a multitude of tests, screenshots, and logs while chasing down these issues.

Issues 1 and 2 are fixed by keeping all caption text and background fully within the safe area (148314b2961f0db6eba5524d1ddee95f4b2767e2 and efcfee33fc77d1e9acbaf54c2fe44b5fc28bf0a5). This may also have involved bugs in older nvidia drivers.

Issue 4 is improved by tightening vertical spacing to meet expectations (f7b7f61cb43a2022cb5faed608561bdd5fd64ae3).

Issue 3 appears to be a font problem. The "SM" special character displayed in the FreeMono? font at timecode 01:01:01 (as displayed by the clock in the test video) is wider than the rest of the (monospaced) characters, and QFontMetrics may be calculating the width too small, leading to clipping. This doesn't happen on my system, so it is probably an issue with some versions of FreeMono?.ttf.

Please open a new ticket for issue 3 if it becomes more widespread.