CEA-608 with multiple tracks

[emveepee]

I have been able to force CEA608 subtitles on mpegts streams and it is working as expected, but I have not found a way to force anything but the first CC. In the US there is often a Spanish stream and VLC is reporting these on CC-3 but I have tried setAccessibilityChannel(3) but there no subtitles, forcing "sp" etc without success.

CCExtractor finds them with field 2 caption one which should be 3.

Is there any working example dealing with multiple set of captions?

[emveepee]

I have been using the code with the debugger and it turns out the data is there when I force it but it isn't being displayed correctly. It seems there is a conflict with the xds handling also on field 2, so this is more an issue then question.

I can get it almost working by not ignoring the xds data with

  if (!isCaptionValid  && isInCaptionService ) {

here https://github.com/google/ExoPlayer/blob/release-v2/library/extractor/src/main/java/com/google/android/exoplayer2/text/cea/Cea608Decoder.java#L500

[emveepee]

I found another issue in the code on the test for the control byte

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

Line 876 in ab4d37f

return (cc1 & 0xF7) == 0x14;

doesn't meet spec. On field 2 the control byte is 0x15

[tonihei]

Thanks for investigating this. As you noted, the different accessibility channels should be supported, but it sounds like there might be bug. Can you share the stream you are using with us? Otherwise it's hard to reproduce and to fix. You can also send a link to dev.exoplayer@gmail.com with "Issue #10666" in the subject if you don't want to post here.

[emveepee]

@tonihei I sent the link. This file has CC's in field 1 and field2 also with xds data. Here is the spec

When closed captioning is used on line 21, field 2, it shall conform to all of the applicable specifications
and recommended practices as defined for field 1 services with the following differences:

a) The non-printing character of the miscellaneous control-character pairs that fall in the range of 0x14,
0x20 to 0x14, 0x2F in field 1, shall be replaced with 0x15, 0x20 to 0x15, 0x2F when used in field 2.

b) The non-printing character of the miscellaneous control-character pairs that fall in the range of 0x1C,
0x20 to 0x1C, 0x2F in field 1, shall be replaced with 0x1D, 0x20 to 0x1D, 0x2F when used in field 2.

c) When any of the control codes from 0x01 to 0x0F is used to begin a control-character pair it indicates
the beginning of XDS Data. This XDS data should be considered part of a different data channel and
can be used to interrupt the captioning data according to the FCC rules for other data channels

[icbaker]

Thanks for the test media and all the pointers - I've looked into this and think I've found two different issues:

1. As you pointed out, we're too strict in isServiceSwitchCommand(). I've fixed this by relaxing the check a little by ANDing with 0xF6 instead of 0xF7 so it works for both 0x14 and 0x15. You can see this is already done in isMiscCode above.

2. Some of the packets in the file you provided seem to have invalid parity. The code currently measures the 'invalidity' of a packet in two ways:

   • The validity bit in the packet header
   • The parity check of the cc1 and cc2 bytes

   In both cases it assumes that an 'invalid' packet should clear all existing subtitle data. This causing the subtitles of your spanish track to be cleared before they were shown. There's a comment in the code which says The encoder has flipped the validity bit to indicate captions are being turned off. Based on that wording I experimentally changed it so the clearing only happens based on the header bit (which is the only one the encoder should be setting). If a packet fails parity then it's skipped, but previous data is not cleared.

These changes together result in the subtitles in your file being shown.

I think (1) is uncontroversial and I'll send it for internal review shortly.

(2) (the parity change) is a bigger deal. Reading through the discussion on #5086 (where this clear-on-invalid-parity logic was first added), it looks like it was queried at the time but was needed for sarnoff compliance. I need to have more of a think about this. It's possible that we can keep the general check, but re-order the statements slightly - I need to dig into exactly what packet(s) in your stream were failing the parity check.