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 Closed Caption special characters are printed twice #6133

Closed
kvillnv opened this issue Jul 4, 2019 · 2 comments
Closed

CEA608 Closed Caption special characters are printed twice #6133

kvillnv opened this issue Jul 4, 2019 · 2 comments
Assignees
Labels

Comments

@kvillnv
Copy link

kvillnv commented Jul 4, 2019

[REQUIRED] Content description

Exoplayer has trouble with special characters in embeded CEA608 text track with Dash stream or .ts file.
Tested with exoplayer-demo with all default parameters.
Issue: Characters contained into exoplayer's CEA608Decoder.SPECIAL_CHARACTER_SET are printed in double
We are playing french content and observed the issue on all the Special characters we could test: "à", "â", "è", "ê", "î", "ô", "û"
FYI: Characters such as "é" and "ù" are not affected. I noticed they are not in SPECIAL_CHARACTER_SET array.

Example: "Allons voir où il nous mène." is printed "Allons voir où il nous mèène."

  • I have played the same .ts video file in Kodi and other players, the subtitles are correct
  • I have extracted the subtitles from the .ts video file and they are correctly written (no duplicated letters)
  • Our packager also provides CMAF content to our iOS app which is correct as well

I was unable to create the same issue in any other player than Exoplayer.

[REQUIRED] Link to test content

To demonstrate the problem, I am sending by email a link where you can download:

  • A .ts sample with embedded CEA608 closed caption.
  • The extracted subtitles in .txt file, where you can see there is no typo.

[REQUIRED] Version of ExoPlayer being used

2.10.2 (bug was already here in previous versions)

[REQUIRED] Device(s) and version(s) of Android being used

Android N , O and P. Any device.

[REQUIRED] A full bug report captured from the device

No bug report

@tonihei
Copy link
Collaborator

tonihei commented Jul 5, 2019

Ça alors, c'est pas croyable :)

We'll provide a fix for that. The special control character gets repeated, but we don't check for repeated characters after handling it. So it's basically just a wrong execution order.

@kvillnv
Copy link
Author

kvillnv commented Jul 5, 2019

Merci!

ojw28 pushed a commit that referenced this issue Jul 8, 2019
We currently handle most the control code logic after handling special
characters. This includes filtering out repeated control codes and checking
for the correct channel. As the special character sets are control codes as well,
these checks should happen before parsing the characters.

Issue:#6133
PiperOrigin-RevId: 256993672
@ojw28 ojw28 closed this as completed Jul 8, 2019
ojw28 pushed a commit that referenced this issue Jul 9, 2019
We currently handle most the control code logic after handling special
characters. This includes filtering out repeated control codes and checking
for the correct channel. As the special character sets are control codes as well,
these checks should happen before parsing the characters.

Issue:#6133
PiperOrigin-RevId: 256993672
@google google locked and limited conversation to collaborators Oct 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants