SmoothStreaming

ExoPlayer supports SmoothStreaming with the FMP4 container format. Media streams must be demuxed, meaning that video, audio and text must be defined in distinct StreamIndex elements in the SmoothStreaming manifest. The contained audio and video sample formats must also be supported (see the sample formats section for details).

Feature Supported Comment
Containers    
FMP4 YES Demuxed streams only
Closed captions/subtitles    
TTML YES Embedded in FMP4
Content protection    
PlayReady SL2000 YES Android TV only

Creating a media source

To play a SmoothStreaming stream, create a SsMediaSource and prepare the player with it as usual.

// Create a data source factory.
DataSource.Factory dataSourceFactory =
    new DefaultHttpDataSourceFactory(Util.getUserAgent(context, "app-name"));
// Create a SmoothStreaming media source pointing to a manifest uri.
MediaSource mediaSource =
    new SsMediaSource.Factory(dataSourceFactory).createMediaSource(ssUri);
// Create a player instance.
SimpleExoPlayer player = new SimpleExoPlayer.Builder(context).build();
// Prepare the player with the media source.
player.prepare(mediaSource);

ExoPlayer will automatically adapt between streams defined in the manifest, taking into account both available bandwidth and device capabilities.

Accessing the manifest

You can retrieve the current manifest by calling Player.getCurrentManifest. For SmoothStreaming you should cast the returned object to SsManifest. The onTimelineChanged callback of Player.EventListener is also called whenever the manifest is loaded. This will happen once for a on-demand content, and possibly many times for live content. The code snippet below shows how an app can do something whenever the manifest is loaded.

player.addListener(
    new Player.EventListener() {
      @Override
      public void onTimelineChanged(
          Timeline timeline, @Player.TimelineChangeReason int reason) {
        Object manifest = player.getCurrentManifest();
        if (manifest != null) {
          SsManifest ssManifest = (SsManifest) manifest;
          // Do something with the manifest.
        }
      }
    });

Sideloading a manifest

For specifc use cases there is an alternative way to provide the manifest, by passing a SsManifest object to the constructor.

DataSource.Factory dataSourceFactory =
    new DefaultHttpDataSourceFactory(Util.getUserAgent(context, "app-name"));
// Create a smooth streaming media source with a smooth streaming  manifest.
MediaSource mediaSource =
    new SsMediaSource.Factory(dataSourceFactory).createMediaSource(ssManifest);
// Create a player instance which gets an adaptive track selector by default.
SimpleExoPlayer player = new SimpleExoPlayer.Builder(context).build();
// Prepare the player with the media source.
player.prepare(mediaSource);

Customizing SmoothStreaming playback

ExoPlayer provides multiple ways for you to tailor playback experience to your app’s needs. The following sections briefly document some of the customization options available when building a SsMediaSource. See the Customization page for more general customization options.

Customizing server interactions

Some apps may want to intercept HTTP requests and responses. You may want to inject custom request headers, read the server’s response headers, modify the requests’ URIs, etc. For example, your app may authenticate itself by injecting a token as a header when requesting the media segments.

The following example demonstrates how to implement these behaviors by injecting custom HttpDataSources into an SsMediaSource:

SsMediaSource ssMediaSource =
    new SsMediaSource.Factory(
            () -> {
              HttpDataSource dataSource = new DefaultHttpDataSource(userAgent);
              // Set a custom authentication request header.
              dataSource.setRequestProperty("Header", "Value");
              return dataSource;
            })
        .createMediaSource(ssUri);

In the code snippet above, the injected HttpDataSource includes the header "Header: Value" in every HTTP request triggered by ssMediaSource. This behavior is fixed for every interaction of ssMediaSource with an HTTP source.

For a more granular approach, you can inject just-in-time behavior using a ResolvingDataSource. The following code snippet shows how to inject request headers just before interacting with an HTTP source:

SsMediaSource ssMediaSource =
    new SsMediaSource.Factory(
        new ResolvingDataSource.Factory(
            new DefaultHttpDataSourceFactory(userAgent),
            // Provide just-in-time request headers.
            (DataSpec dataSpec) ->
                dataSpec.withRequestHeaders(getCustomHeaders(dataSpec.uri))))
        .createMediaSource(customSchemeUri);

You may also use a ResolvingDataSource to perform just-in-time modifications of the URI, as shown in the following snippet:

SsMediaSource ssMediaSource =
    new SsMediaSource.Factory(
        new ResolvingDataSource.Factory(
            new DefaultHttpDataSourceFactory(userAgent),
            // Provide just-in-time URI resolution logic.
            (DataSpec dataSpec) -> dataSpec.withUri(resolveUri(dataSpec.uri))))
        .createMediaSource(customSchemeUri);

Customizing error handling

Implementing a custom LoadErrorHandlingPolicy allows apps to customize the way ExoPlayer reacts to load errors. For example, an app may want fail fast instead of retrying many times, or may want to customize the back-off logic that controls how long the player waits between each retry. The following snippet shows how to implement custom back-off logic when creating a SsMediaSource:

SsMediaSource ssMediaSource =
    new SsMediaSource.Factory(dataSourceFactory)
        .setLoadErrorHandlingPolicy(
            new DefaultLoadErrorHandlingPolicy() {
              @Override
              public long getRetryDelayMsFor(...) {
                // Implement custom back-off logic here.
              }
            })
        .createMediaSource(ssUri);

You will find more information in our Medium post about error handling.

BehindLiveWindowException

In case a live stream with limited availability is played, the player may fall behind this live window if the player is paused or buffering for a long enough period of time. In this case a BehindLiveWindowException is thrown, which can be caught to resume the player at the live edge. The PlayerActivity of the demo app exemplifies this approach.

@Override
public void onPlayerError(ExoPlaybackException e) {
  if (isBehindLiveWindow(e)) {
    // Re-initialize player at the live edge.
  } else {
    // Handle other errors
  }
}

private static boolean isBehindLiveWindow(ExoPlaybackException e) {
  if (e.type != ExoPlaybackException.TYPE_SOURCE) {
    return false;
  }
  Throwable cause = e.getSourceException();
  while (cause != null) {
    if (cause instanceof BehindLiveWindowException) {
      return true;
    }
    cause = cause.getCause();
  }
  return false;
}