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

DefaultTrackSelector: Make it easy to enable text tracks with null language #2980

Closed
goffioul opened this issue Jun 21, 2017 · 8 comments
Closed

Comments

@goffioul
Copy link
Contributor

goffioul commented Jun 21, 2017

As far as I can see, DefaultTrackSelector allows to automatically select a text track based on the preferred language. But I don't think it's possible to have the same auto-selection mechanism for closed-captions track, as they don't have any associated language. Would that be a valid enhancement request?

My use case is when the user is switching between 2 TV channels, if closed-captions were enabled in the previous channel, it's very likely the user still wants them enabled in the new channel. Having that capability built into DefaultTrackSelector makes it easy to handle.

@ojw28
Copy link
Contributor

ojw28 commented Jun 21, 2017

If this is for playing TS streams (not encapsulated within HLS), then it looks like we do set the language from the descriptor tag here.

  • Are you using a recent enough version of ExoPlayer to be getting that code (2.3.0 and later, I think).
  • Are you overriding the caption formats using FLAG_OVERRIDE_CAPTION_DESCRIPTORS, in which case it's probably up to you to be specifying the language when you do the override?

@goffioul
Copy link
Contributor Author

I'm using 2.4.1. I'm not setting FLAG_OVERRIDE_CAPTION_DESCRIPTORS, but the broadcasts (live TV) I'm dealing with do not have the closed-captions descriptor.

@ojw28
Copy link
Contributor

ojw28 commented Jun 21, 2017

Got it, thanks. How does the subtitle get enabled in your code today? I suspect your only option currently is to enable it using setSelectionOverride. I'd also expect that override to continue applying when moving from one TV channel to another, because the tracks available to the text renderer probably look identical for all channels?

@goffioul
Copy link
Contributor Author

Indeed, I just found out that if I do not clear the override when switching channel, the override is still active on the new channel. Although that doesn't sound right, because the track layout could be different (especially in my test environment, where I have US and non-US channels).

However it appears I could probably emulate what I want by overriding DefaultTrackSelector.selectTextTrack. It would even be easier if formatHasLanguage was not static. In that case, I could create new parameters with something like 'withPreferredTextLanguage("cc1")', and then override formatHasLanguage to return true if language is "cc1" and the format has mimetype APPLICATION_CEA608 (Note: the string "cc1" is a pseudo-language I'm using in my app).

@goffioul
Copy link
Contributor Author

It would even be easier if formatHasLanguage was not static. In that case, I could create new parameters with something like 'withPreferredTextLanguage("cc1")', and then override formatHasLanguage to return true if language is "cc1" and the format has mimetype APPLICATION_CEA608

Actually, language normalization may interfere, so it's likely the above would not work.

@ojw28
Copy link
Contributor

ojw28 commented Jun 21, 2017

An override for a renderer is applied if the tracks available to that renderer match those for which the override set. In your case the text renderer probably sees a single closed caption track, with a format that's pretty much empty, and importantly, identical for all TV channels.

If you feel somewhat uneasy relying on this, then yes, I would too. If one of the channels happens to include a descriptor then the format for that channel will be different, so the tracks available to the text renderer will be different, so the override wont apply to that channel.

Extending DefaultTrackSelector and overriding selectTextTrack to do something like always select the first (and probably only) track if some preferred text language has been set is probably your best bet for current ExoPlayer releases.

I'm not sure what the best long term solution is. We could provide an option on DefaultTrackSelector to specify that a text track with no language should be enabled if available, and if no text track is available in the preferred language. Or something like that?

@goffioul
Copy link
Contributor Author

Thanks, for the time being, I'll probably go with extending DefaultTrackSelector.

For the long term, I'll leave that up to you, but the first thing that came to my mind was to allow also defining the preferred text track by mimetype (or a set of mimetypes) instead of language.

@ojw28 ojw28 changed the title Extend DefaultTrackSelector to prefer closed-captions track DefaultTrackSelector: Make it easy to enable text tracks with null language Jun 21, 2017
ojw28 pushed a commit that referenced this issue Nov 27, 2017
Also slightly improve language normalization/documentation.

For this CL, it is assumed that null and "und" languages are different
entities. Once we fully tackle language tag normalization, we can decide
whether to normalize the "undefined" language.

Issue:#2867
Issue:#2980

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177008509
@ojw28
Copy link
Contributor

ojw28 commented Nov 27, 2017

Support added in dev-v2.

@ojw28 ojw28 closed this as completed Nov 27, 2017
ojw28 pushed a commit that referenced this issue Dec 12, 2017
Also slightly improve language normalization/documentation.

For this CL, it is assumed that null and "und" languages are different
entities. Once we fully tackle language tag normalization, we can decide
whether to normalize the "undefined" language.

Issue:#2867
Issue:#2980

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177008509
@google google locked and limited conversation to collaborators Apr 10, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants