Package com.google.android.exoplayer2.trackselection

Class TrackSelector

  • Direct Known Subclasses:
    MappingTrackSelector
    @Deprecated
public abstract class TrackSelector
extends Object
    Deprecated.
    com.google.android.exoplayer2 is deprecated. Please migrate to androidx.media3 (which contains the same ExoPlayer code). See the migration guide for more details, including a script to help with the migration.
    The component of an ExoPlayer responsible for selecting tracks to be consumed by each of the player's Renderers. The DefaultTrackSelector implementation should be suitable for most use cases.

    Interactions with the player

    The following interactions occur between the player and its track selector during playback.
    • When the player is created it will initialize the track selector by calling init(InvalidationListener, BandwidthMeter).
    • When the player needs to make a track selection it will call selectTracks(RendererCapabilities[], TrackGroupArray, MediaPeriodId, Timeline). This typically occurs at the start of playback, when the player starts to buffer a new period of the media being played, and when the track selector invalidates its previous selections.
    • The player may perform a track selection well in advance of the selected tracks becoming active, where active is defined to mean that the renderers are actually consuming media corresponding to the selection that was made. For example when playing media containing multiple periods, the track selection for a period is made when the player starts to buffer that period. Hence if the player's buffering policy is to maintain a 30 second buffer, the selection will occur approximately 30 seconds in advance of it becoming active. In fact the selection may never become active, for example if the user seeks to some other period of the media during the 30 second gap. The player indicates to the track selector when a selection it has previously made becomes active by calling onSelectionActivated(Object).
    • If the track selector wishes to indicate to the player that selections it has previously made are invalid, it can do so by calling TrackSelector.InvalidationListener.onTrackSelectionsInvalidated() on the TrackSelector.InvalidationListener that was passed to init(InvalidationListener, BandwidthMeter). A track selector may wish to do this if its configuration has changed, for example if it now wishes to prefer audio tracks in a particular language. This will trigger the player to make new track selections. Note that the player will have to re-buffer in the case that the new track selection for the currently playing period differs from the one that was invalidated. Implementing subclasses can trigger invalidation by calling invalidate(), which will call TrackSelector.InvalidationListener.onTrackSelectionsInvalidated().
    • When the player is released, it will release the track selector by calling release().

    Renderer configuration

    The TrackSelectorResult returned by selectTracks(RendererCapabilities[], TrackGroupArray, MediaPeriodId, Timeline) contains not only TrackSelections for each renderer, but also RendererConfigurations defining configuration parameters that the renderers should apply when consuming the corresponding media. Whilst it may seem counter- intuitive for a track selector to also specify renderer configuration information, in practice the two are tightly bound together. It may only be possible to play a certain combination tracks if the renderers are configured in a particular way. Equally, it may only be possible to configure renderers in a particular way if certain tracks are selected. Hence it makes sense to determine the track selection and corresponding renderer configurations in a single step.

    Threading model

    All calls made by the player into the track selector are on the player's internal playback thread. The track selector may call TrackSelector.InvalidationListener.onTrackSelectionsInvalidated() from any thread.