CEA-608 caption covers entire screen in Roll-up mode

[sneelavara]

Issue description

Summary

CEA-608 caption covers entire screen in Roll-up mode

Root Cause

On certain Live TV channels the Caption from Live TV program covers the entire screen. This happens in Roll-Up mode and mostly during commercial breaks.

As per spec CEA-608-E the Roll-up style
Precede each new row of text with these three codes:

1. RU2 or RU3 or RU4 (to set roll-up style and depth)
2. CR (to roll the display up one row)
3. PAC (to set the indent and base row)
   The above sequence is seen during normal working. But when the problem happens the CR (Carriage Return) code is not seen.

Working case - has CR (0x14, 0x2D) in between RU2 (ox14, 0x25) and PAC (0x13, 0x70). Please see the caption byte pairs capture -

2020-05-05 16:05:42.197 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: cc1 54 cc2 00
2020-05-05 16:05:42.296 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: cc1 20 cc2 00
2020-05-05 16:05:42.339 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: **cc1 14 cc2 25**
2020-05-05 16:05:42.372 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: **cc1 14 cc2 2D**
2020-05-05 16:05:42.400 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: **cc1 13 cc2 70**
2020-05-05 16:05:42.431 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: cc1 54 cc2 4F
2020-05-05 16:05:42.471 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: cc1 4D cc2 4F

When caption starts filling the screen the CR is not seen

2020-05-05 16:05:49.076 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: cc1 52 cc2 41
2020-05-05 16:05:49.108 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: cc1 4D cc2 20
2020-05-05 16:05:49.139 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: **cc1 14 cc2 25**
2020-05-05 16:05:49.178 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: **cc1 13 cc2 70**
2020-05-05 16:05:49.210 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: cc1 42 cc2 41
2020-05-05 16:05:49.240 15402-15465/com.tivo.exoplayer.demo D/Cea608Decoder: decode: cc1 43 cc2 4B

The Cea608Decoder.java does handle the PAC in Cea608Decoder.handlePreambleAddressCode() by setting the base row and indent. The base row (row 13 for the stream we tested) and indent is 0 are set correctly. But the problem is, it continues to accumulate the caption bytes in currentCueBuilder.captionStringBuilder. The captionStringBuilder seem to be reset when CR (0x14, 0x2D) code is received. But when there is no CR code, the caption bytes are continuously appended to captionStringBuilder. In the stream we used to reproduce, the length of captionStringBuilder grows up to 3858 bytes. This whole 3858 bytes are rendered on screen as a second row in Roll-up2 case making the caption visible on entire screen.

I did not see a convincing statement to justify the stream. But CEA-608 section B.9 seem to tell “when a PAC addresses a cell in the midst of a displyable characters already received, destroy the character to the left of the cursor”. Could that be implemented in Cea608Decoder.handlePreambleAddressCode() ?

I tested this stream on VLC media player and Safari. Both players are working around by just drawing only one row. i.e. the row 2 in this case does not grow to fill the entire screen.

Proposed Solution

The work around we tried is to set the length of captionStringBuilder to 0 in Cea608Decoder.handlePreambleAddressCode() if there is no CR seen. That seem to address this problem.

Please suggest if there are better way to handle this ?

Reproduction steps

Using the sample HLS stream, play to the first commercial break 40 seconds into the stream. Observe the caption "Backto the ABC…” starts growing to cover the entire 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]

Thanks for the report - I can reproduce with the provided media.

I'll take a deeper look next week.

[icbaker]

If I understand correctly this problem occurs because the media you're using is not spec-compliant (i.e. it's missing the CR code that must precede each row).

Doing anything on based on section B.9 of the CEA-608 spec seems wrong - the sentence you highlighted seems to refer to behaviour of the TC1 decoder which the introduction states was last sold in mid-1985 and support for its behaviour can likely be phased out during 1994 and 1995.

It seems the reason ExoPlayer ends up filling the screen in this case is because we auto-wrap the subtitles. If we didn't auto-wrap then then it would only ever be two lines. I grabbed the subtitle text when it's almost filling the screen (rendering 6 lines on my device) and it only has one \n:

IN THE MEANTIME WE'LL SEND YOU \nBACK TO THE ABC PROGRAM O THE ABC PROGRAM BACK TO THE ABC PROGRAM BACK TO THE ABC PROGRAM BACK TO THE ABC PROGRAM BACK TO THE ABC PROGRAM BA

Would you be happy with ExoPlayer's behaviour if we didn't auto-wrap?

It's likely we can't turn off auto-wrapping in all cases, but we might be able to add a property like Cue.autoWrap that the CEA608 decoder can set to false and which is then respected in SubtitleView.

[sneelavara]

Thank you @icbaker for the inputs. I don't have a strong evidence to declare this stream as off spec. I couldn't find any reference which says the CR is mandatory. Other players (like Safari and VLC media player) are handling this situation gracefully by not filling the entire screen.

Would you be happy with ExoPlayer's behaviour if we didn't auto-wrap?
Yes, that would be much better compare to current behavior. Very much appreciate if that can be implemented.
Thanks.

[icbaker]

After some discussion with the team we decided to solve this slightly differently: Update Cea608Decoder to ignore lines longer than 32 chars (since the spec only allows 32 columns).

This is now pushed to dev-v2, it fixes the issue with the provided media.

[sneelavara]

Thank you @icbaker