Add preferred mime type(s) to DefaultTrackSelector parameters

I’d like to implement a customized TrackSelector. My situations are

1. I don’t want to change any code of ExoPlayer core library so that I’ll not modify DefaultTrackSelector directly;
2. I know I can do some kinds of customization via setParameter API.

trackSelector.setParameters( trackSelector .buildUponParameters() .setMaxVideoSizeSd() .setPreferredAudioLanguage("deu"));

But Current APIs can’t satisfy my requirement. For example, I’d like to always set higher priority for Dolby Digital plus track than AAC audio track. It seems that current interface can’t support it.

According to ExoPlayer official documentation (https://exoplayer.dev/customization.html),

TrackSelector – Implementing a custom TrackSelector allows an app developer to change the way in which tracks exposed by a MediaSource are selected for consumption by each of the available Renderers.

My first feeling is I need to copy all files under “library\core\src\main\java\com\google\android\exoplayer2\trackselection” folder into my application layer and then do some modification. Do you have any suggestion for this? Is there a better solution?

Thank you very much in advance.

[ybai001]

I hope your team can help to implement it since it will be more quickly to be merged. Thanks a lot in advance.

[tonihei]

I’m not sure which proposal is better: setPreferredMimeType(String mimeType) or setPreferredMimeTypes(String[] mimeTypes) For example, prefering “eac3”, “eac3-joc”, “ac-4” over “aac” while “eac3”, “eac3-joc” and “ac-4” have same “MIME type based” priority (so that channel count/sample rate/… will decide the final priority of eac3/eac3-joc/ac-4) . That is to say, the parameter is a string[]. Proposal 1 is easier while proposal 2 is more general. Both proposals can satisfy our current customer requirement so that you may decide it from platform perspective

In a similar case for languages we have two methods setPreferredAudioLanguage(String) and setPreferredAudioLanguages(String...), which both end up in an ImmutableList<String> in the Parameters object (with one or many elements). I think we can just do the same here. I’ll mark as an enhancement for now. Are you thinking about providing a PR yourself or shall we implement this?