Change in behavior of selection override in 2.16.0
See original GitHub issueFollow up on #9649. (@tonihei)
I applied eb678a7d6de0658856cb77087c2247f7ec52f683 on top of r2.16.0 but I still have issues working with selection overrides. The same code which works on 2.15.1 doesn’t work on 2.16.0. (Is there possibly more to this issue?)
for (int rendererIndex = 0; rendererIndex < mappedTrackInfo.getRendererCount(); rendererIndex++) {
if (mappedTrackInfo.getRendererType(rendererIndex) == C.TRACK_TYPE_TEXT) {
final TrackGroupArray trackGroups = mappedTrackInfo.getTrackGroups(rendererIndex);
final DefaultTrackSelector.SelectionOverride selectionOverride =
trackSelector.getParameters().getSelectionOverride(rendererIndex, trackGroups);
DefaultTrackSelector.Parameters parameters = trackSelector.getParameters();
if (parameters.getRendererDisabled(rendererIndex)) {
Log.d("Test", "Disabled");
} else if (selectionOverride == null) {
Log.d("Test", "No selection override");
} else {
Log.d("Test", "Index=" + selectionOverride.groupIndex);
}
}
}
On 2.15.1, I can use this to detect subtitle index. (Testing with the same video file as in the linked issue)
On 2.16.0, the selection override is always null.
I noticed that methods like DefaultTrackSelector.ParametersBuilder.setSelectionOverride()
etc. are deprecated but nothing from the code above(getSelectionOverride
). (I would still expect the code to work the same though).
- ExoPlayer version number: 2.16.0
- Android version: Android 10
- Android device: OnePlus 7
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Log4j – Changes - Apache Logging Services
Provide support for overriding the Tomcat Log class in Tomcat 8.5+. Fixes LOG4J2-2025. rgoers. Update, Updated dependencies. - com.fasterxml.
Read more >Cannot select any other than 1st audio/subtitle track ... - GitHub
When I select any audio or subtitle track (in StyledPlayerView), other than the ... Change in behavior of selection override in 2.16.0 #9665....
Read more >DOS vulnerability in log4j < 2.16.0 - Bloomreach
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. ... Log4j 2.15.0 ...
Read more >Log4J2 Vulnerability and Spring Boot
To check that the override as been applied run ./mvnw dependency:list | grep log4j and check that the version is 2.17. 1.
Read more >Mockito 2.16.0 API - Javadoc.io
In the lifecycle of a library, breaking changes are necessary to roll out a set of brand new features that alter the existing...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think this is the only way to make sure, yes. We have a private method
TrackSelectionOverride.getTrackType
which returns the track type, seems we could make this public.I believe this is working as intended, although I can see how it might not be obvious why.
ExoPlayer 2.16.0 introduced new track selection APIs in the
Player
interface. In particular,TrackSelectionParameters
allows to set track overrides. The “old” way of usingDefaultTrackSelector
still works, but has a different set of (now deprecated) selection overrides, which work in a slightly different way. Your code snippet above checks the old overrides, butStyledPlayerView
started setting the new overrides, that’s why you can’t see them anymore.In any case, the selection overrides are the input to the track selection algorithm, not the output that tells you which tracks are actually selected. So to check which text track is selected, you should not query the configuration parameters, but the actually selected tracks:
There are still two things to fix here:
trackSelector.getParameters().getSelectionOverride
should be deprecated in line with all the setters so that it would have been clear to you that this code is not up to date.