CEA-608 caption goes out of safe area (bleeds out of screen) in Roll-up mode

[sneelavara]

Issue description

Summary 

CEA-608 caption goes out of safe area (bleeds out of screen) in Roll-up mode

Root Cause

On certain Live TV channels the Caption from Live TV program bleeds out of the entire screen.  This happens in Roll-Up mode and when the caption start at the left top with row number less than or equals to 2.

The Cea608Decoder.java line number 890

ExoPlayer/library/core/src/main/java/com/google/android/exoplayer2/text/cea/Cea608Decoder.java

Line 890 in 6bfdf8f

if (captionMode == CC_MODE_ROLL_UP || row > (BASE_ROW / 2)) {

has this logic -

if (captionMode == CC_MODE_ROLL_UP || row > (BASE_ROW / 2)) {
  lineAnchor = Cue.ANCHOR_TYPE_END;
  line = row - BASE_ROW;
  // Two line adjustments. The first is because line indices from the bottom of the window
  // start from -1 rather than 0. The second is a blank row to act as the safe area.
  line -= 2;
} else {
  lineAnchor = Cue.ANCHOR_TYPE_START;
  // Line indices from the top of the window start from 0, but we want a blank row to act as
  // the safe area. As a result no adjustment is necessary.
  line = row;
}

Roll-up caption with row number on top portion of the screen are also pulled up by two lines because of this code. When the row number is less than 2, the Roll-up caption is drawn on the top of the screen. I think this violates the safe area restriction. The effect of this is the caption from the first row is cut off.

Changing the if condition at line 890 to -

if (row > (BASE_ROW / 2)

i.e. excluding Roll-up caption mode check, fixes the caption bleeding issue. Line 890 seem to be modified as part of commit (e86bfd6).

Could you please explain why the Roll-up captions are always pulled up by 2 lines? What could be the side effect of not checking for Roll-up mode at line number 890?

Reproduction steps

Using the sample HLS stream, play to the stream. Observe the caption when it’s on top left screen.

Link to test content

Content is broadcast from cable, so link was sent to exoplayer dev email

A full bug report captured from the device

N/A

Version of ExoPlayer being used

2.11.4 

Device(s) and version(s) of Android being used

Tested and reproduced on Arris and Amino AndroidTV devices running Android Pie.  Reproduction is 100%.

[icbaker]

That if block is trying to deal with lines it thinks should be in the bottom half of the screen. I agree roll-up cues shouldn't be assumed to be in the bottom half of the screen though - I've sent a change that removes captionMode == CC_MODE_ROLL_UP from the condition.

[sneelavara]

Thank you very much @icbaker. That would greatly help us addressing the regulatory defect.

[icbaker]

This is now fixed on dev-v2.

[zsmatyas]

We implemented this a long time ago, so please forgive me if my recollection is incorrect.

@sneelavara Could you also provide the last few instructions leading to the issue? You should not have more than 2 lines rolling if you are not at least in the second row.

  if (captionMode == CC_MODE_ROLL_UP || row > (BASE_ROW / 2)) {

Has the Roll-up mode checked separately, as roll up captions always grow upwards, their location is based on the last line of the Roll-up captions so they need to use ANCHOR_TYPE_END.

In exoPlayer, as I recall, the lines on the screen are numbered as:

---

1
2
3
4
...
-4
-3
-2
-1

Row -1 should not be used (unless there are other adjustments for the safe area), and the second adjustment seems to be needed for:

https://github.com/google/ExoPlayer/blob/release-v2/library/ui/src/main/java/com/google/android/exoplayer2/ui/SubtitlePainter.java#L385

seems to add one to the index to calculate the position from the next row.

[icbaker]

Ah thanks for the clarification @zsmatyas, I didn't realise this bit:

Has the Roll-up mode checked separately, as roll up captions always grow upwards, their location is based on the last line of the Roll-up captions so they need to use ANCHOR_TYPE_END.

Your numbering of lines is semi-correct, but it's important to also consider that both of those numbering schemes extend past each other (positive numbers are just offset from the top of the screen, negative numbers from the bottom):

0    -7
1    -6
2    -5
3    -4
4    -3
5    -2
6    -1

Relying on negative line offsets (from the bottom) to position something near the top of the screen is risky - because you don't know how many lines will "fit" on the screen, so it's easy to overshoot (or end up with captions in the middle of the screen). It all depends on the font size the subtitles end being rendered in (which is, in general, user-configurable (though I guess you can disable that in your own apps)).

I think we should special-case CC_MODE_ROLL_UP in the 'top half of the screen' if-block to count the number of lines that have been rolled up (instead of using ANCHOR_TYPE_END). I'll experiment with that change tomorrow.

[zsmatyas]

Could we make sure that the content we want to fix is according to the standard? Are the indices / values correct and rendered with the expected font sizes? What is the base row and how many rows are rolling?

---

As there are small adjustments for the exact positioning at many layers of the caption decoding / rendering, I do not think it is currently easy to use the top anchor, for example, having 3 lines of rolling captions, then switch to 2 lines by keeping the bottom 2 rows and keep them perfectly at the previous location of them.
This might be already complicated because of the font sizes affecting positioning. So in case we render the 2-4 lines based on a single anchor and it needs to change the row-count dynamically, we might need to rely on ANCHOR_TYPE_END to avoid moving the captions around.

Also note:
The default font sizes of exoplayer used to not match to CEA608 standard. Can you render 15 rows inside the safe area?