Not enabling text tracks with same language by default

[yberg]

FAQ

• I have read the FAQ and checked for duplicate open issues

If the question is related to FairPlay, have you read the tutorial?

Not applicable

What version of Shaka Player are you using?

5.1.0

What browser and OS are you using?

Chrome, MacOS

Please ask your question

When I start a stream that has Swedish audio, I don't want to enable Swedish captions by default. In version 4.x the preferredTextLanguage property let me pick a text language that would only be applied if it didn't match the audio language:

Name	Description
preferredTextLanguage	... If a matching text track is found, and the selected audio and text tracks have different languages, the text track will be shown. ...

v4.15.10 PlayerConfiguration docs

I want to achieve the same thing with the new preferredAudio and preferredText config, but the player always enables the text track even if it doesn't match my .TextPreference.

Stream

Audio tracks

[
  { label: "Swedish", language: "sv", primary: true, roles: ["main"], ... },
  { label: "Swedish (AD)", language: "sv", primary: true, roles: ["commentary"], ... }
]

Text tracks

[
  { label: "Swedish (CC)", language: "sv", primary: false, roles: ["caption"], ... }
]

Configuration

{
  preferredAudio: [
    { language: 'sv', channelCount: 6 },
    { language: 'sv', channelCount: 2 },
    { language: 'en', channelCount: 6 },
    { language: 'en', channelCount: 2 },
  ],
  preferredText: [
    { language: 'sv', role: 'main' }
  ],
}

I would expect this configuration to not enable any subtitles since there is no match ("main" != "caption"), but as long as the language matches it seems to get picked. With preferredText: [], no subtitles are enabled by default as expected.

I can see this in the logs No exact match for the text role could be found., shouldn't an empty list be returned there if there are no role matches?

Is this achievable without manually calling this.player.selectTextTrack(null) when the player is ready?

[avelad]

@matvp91 can you review it? Thanks!

[matvp91]

@yberg can you provide a test stream?

[yberg]

@matvp91 Sure!

https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd

Extra config:

{
  "preferredText": [
    {
      "language": "en",
      "role": "some-other-role"
    }
  ]
}

I would expect that to have no default text track set.

[matvp91]

We select an arbitrary role if any is available.

shaka-player/lib/util/stream_utils.js

Lines 1927 to 1938 in ef83be2

	// Either there was no role preference, or it could not be satisfied.
	// Choose an arbitrary role, if there are any, and filter out any other
	// roles. This ensures we never adapt between roles.
	const allRoles = chosen.map((stream) => {
	return stream.roles;
	}).reduce((a, b) => a.concat(b), []);
	if (!allRoles.length) {
	return chosen;
	}
	return shaka.util.StreamUtils.filterStreamsByRole_(chosen, allRoles[0]);

This code stems from 2017, but I suspect we can simplify this a fair bit. I agree that if you specify a role and it is unmatched, we should not fallback to "any other role".

@avelad & @KimKyuHoi, with all of the changes in preferences lately, does it make sense to remove the defaulting?

[avelad]

I think so! Simplify it please!

[matvp91]

Most of our internal code is still based on currentTextLanguage_, currentTextRole_ and currentTextForced_ which predates #9542.

The logic has always been that the role preference is a soft selection, meaning that if a role is not matched, the user would still want to see an active text track matching the preferred role as closely as possible. I think that's a fair assumption to make.

However, with the move to preferredText and the other track type preferences, we can be more flexible about initial track selection and treat each of the same preference as a strict AND match. It's also less confusing for end users.

For now, I think it's fair to return no preference if none is strictly matching a role (what @yberg proposed) but we'll have to think about reworking the logic I mentioned above. We'd no longer be able to treat preferences before we get the streams in, as we don't know what the current state would be upfront.

I'll file a PR this week for the simple change and think about how we can restructure this internally.