Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CEA608: Handling XDS and TEXT modes #5807

Merged
merged 2 commits into from
May 2, 2019
Merged

CEA608: Handling XDS and TEXT modes #5807

merged 2 commits into from
May 2, 2019

Conversation

zsmatyas
Copy link
Contributor

[Problem]
There are 3 services / modes transported on line 21:

  • Captioning
  • TEXT (generally not program related)
  • XDS (eXtended Data Services)

Bytes belonging to the unsupported modes are interleaved with the
bytes of the captioning mode.
See Chapter 7, Chapter 8.5 and Chapter 8.6 of the CEA608 Standard for
more details.

[Solution]
Drop all bytes belonging to unsupported modes.

[Test]

  • All streams containing only captioning services should not be influenced
  • Test all 4 CEA 608 channels with live over-the-air content and
    using all available TEXT and XDS streams.

[Links]
https://www.law.cornell.edu/cfr/text/47/79.101
https://en.wikipedia.org/wiki/EIA-608#Channels

[Problem]
There are 3 services / modes transported on line 21:
- Captioning
- TEXT (generally not program related)
- XDS (eXtended Data Services)

Bytes belonging to the unsupported modes are interleaved with the
bytes of the captioning mode.
See Chapter 7, Chapter 8.5 and Chapter 8.6 of the CEA608 Standard for
more details.

[Solution]
Drop all bytes belonging to unsupported modes.

[Test]
- All streams containing only captioning services should not be influenced
- Test all 4 CEA 608 channels with live over-the-air content and
using all available TEXT and XDS streams.
@zsmatyas zsmatyas changed the title Handling XDS and TEXT modes CEA608: Handling XDS and TEXT modes Apr 26, 2019
@@ -306,6 +330,38 @@ protected Subtitle createSubtitle() {
return new CeaSubtitle(cues);
}

private boolean isCodeForUnsupportedMode(byte cc1, byte cc2) {
// Control codes from 0x01 to 0x0F indicate the beginning of XDS Data
if (0x01 <= cc1 && cc1 <= 0x0F) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Section 8.5 C of the CEA608 Standard:

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 Text data according to the FCC rules for other data channels.

}

switch (cc2) {
case CTRL_END_OF_CAPTION:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See C.16 of the CEA608 standard.

EDM or ENM command does not instruct the decoder to treat subsequent data as caption data
...
There are six caption-specific commands which do terminate a Text Mode data stream: EOC, RCL, RDC, RU2, RU3, and RU4.

Copy link
Collaborator

@tonihei tonihei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good in general. Just some code structure comments.

}

// 2 commands switch to TEXT mode.
if (((cc1 & 0xF7) == 0x14) // first byte must be 0x14 or 0x1C based on channel
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you move (cc1 & 0xF7) == 0x14 to a private static method isModeSwitchCommand(cc1) for readability? And use the same method on L349 below. Then you only need to add the explaining comment once.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could not come up with a better name, but the suggested function signature could be misleading. Usually both bytes are needed to figure out what the command is doing, and there could be a long range of values this function returns true, although there is no mode switch expected.

@@ -363,6 +419,16 @@ protected void decode(SubtitleInputBuffer inputBuffer) {
continue;
}

if (isCodeForUnsupportedMode(ccData1, ccData2)) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm not mistaken, it seems that this code can move to handleCrtl? That is probably a better place to handle these transitions as it's part of "control code handling" in general.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think so. We need stop processing all data (characters included) in case we are not in CAPTION mode. Moving this down would add the characters of the TEXT and XDS modes to the buffers of our processing of CAPTION mode.

@tonihei tonihei self-assigned this Apr 29, 2019
@zsmatyas
Copy link
Contributor Author

Added the suggested improvements as a new commit, now the comments given to the first commit might point to locations that might be "Outdated"

Copy link
Collaborator

@tonihei tonihei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be able to merge now. I'll do some further formatting changes on our side, but otherwise looks good.

@ojw28 ojw28 merged commit 3e14ce1 into google:dev-v2 May 2, 2019
ojw28 added a commit that referenced this pull request May 2, 2019
PiperOrigin-RevId: 246132620
@zsmatyas zsmatyas deleted the dev-v2 branch May 2, 2019 22:28
@google google locked and limited conversation to collaborators Sep 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants