ExoPlayer

public interface ExoPlayer extends Player

An extensible media player that plays MediaSources. Instances can be obtained from .

Player components

ExoPlayer is designed to make few assumptions about (and hence impose few restrictions on) the type of the media being played, how and where it is stored, and how it is rendered. Rather than implementing the loading and rendering of media directly, ExoPlayer implementations delegate this work to components that are injected when a player is created or when it's prepared for playback. Components common to all ExoPlayer implementations are:

• MediaSources that define the media to be played, load the media, and from which the loaded media can be read. MediaSources are created from MediaItems by the MediaSource.Factory injected into the player Builder, or can be added directly by methods like setMediaSource. The library provides a DefaultMediaSourceFactory for progressive media files, DASH, SmoothStreaming and HLS, which also includes functionality for side-loading subtitle files and clipping media.
• Renderers that render individual components of the media. The library provides default implementations for common media types (MediaCodecVideoRenderer, MediaCodecAudioRenderer, TextRenderer and MetadataRenderer). A Renderer consumes media from the MediaSource being played. Renderers are injected when the player is created. The number of renderers and their respective track types can be obtained by calling getRendererCount and getRendererType.
• A TrackSelector that selects tracks provided by the MediaSource to be consumed by each of the available Renderers. The library provides a default implementation (DefaultTrackSelector) suitable for most use cases. A TrackSelector is injected when the player is created.
• A LoadControl that controls when the MediaSource buffers more media, and how much media is buffered. The library provides a default implementation () suitable for most use cases. A LoadControl is injected when the player is created.

An ExoPlayer can be built using the default components provided by the library, but may also be built using custom implementations if non-standard behaviors are required. For example a custom LoadControl could be injected to change the player's buffering strategy, or a custom Renderer could be injected to add support for a video codec not supported natively by Android.

The concept of injecting components that implement pieces of player functionality is present throughout the library. The default component implementations listed above delegate work to further injected components. This allows many sub-components to be individually replaced with custom implementations. For example the default MediaSource implementations require one or more DataSource factories to be injected via their constructors. By providing a custom factory it's possible to load data from a non-standard source, or through a different network stack.

Threading model

The figure below shows ExoPlayer's threading model.

• ExoPlayer instances must be accessed from a single application thread unless indicated otherwise. For the vast majority of cases this should be the application's main thread. Using the application's main thread is also a requirement when using ExoPlayer's UI components or the IMA extension. The thread on which an ExoPlayer instance must be accessed can be explicitly specified by passing a Looper when creating the player. If no Looper is specified, then the Looper of the thread that the player is created on is used, or if that thread does not have a Looper, the Looper of the application's main thread is used. In all cases the Looper of the thread from which the player must be accessed can be queried using getApplicationLooper.
• Registered listeners are called on the thread associated with getApplicationLooper. Note that this means registered listeners are called on the same thread which must be used to access the player.
• An internal playback thread is responsible for playback. Injected player components such as Renderers, MediaSources, TrackSelectors and LoadControls are called by the player on this thread.
• When the application performs an operation on the player, for example a seek, a message is delivered to the internal playback thread via a message queue. The internal playback thread consumes messages from the queue and performs the corresponding operations. Similarly, when a playback event occurs on the internal playback thread, a message is delivered to the application thread via a second message queue. The application thread consumes messages from the queue, updating the application visible state and calling corresponding listener methods.
• Injected player components may use additional background threads. For example a MediaSource may use background threads to load data. These are implementation specific.

Summary