For Live SmoothStreaming, referential equality checking
isn't enough (it breaks once the manifest is updated).
Updated other instances too just for consistency.
The spurious transitions were caused by calling pushTrackSelection
in onRenderers after changing the renderer building state to BUILT
and before calling player.prepare. pushTrackSelection can cause the
ExoPlayer to generate state changes, since it can call setPlayWhenReady.
This change transitions the renderer building state later, so that
when this happens getPlaybackState correctly masks the state and
returns STATE_PREPARING.
Play movies has an Allocator that attempts to allocate a single
huge byte[] up front to minimize the risk of GC pauses. This abstraction
will be required to keep that when updating them to the new Exo.
VP8 can be decoded by MediaCodec (since very early versions of android). Now that we want WebmExtractor to be general purpose, adding VP8 makes sense as it is a common use case.
This CL adds support for WebM files which have Cues present at the end of the file (i.e.) after Clusters. The file referenced in the bug can now be played back using the demo app. It adds a new flag to WebmExtractor which should be set to true only when being used through ExtractorSampleSource. All others (e.g. DASH) should not set it.
Reference file: http://demos.webmproject.org/exoplayer/glass_vp9_vorbis_cues_at_end.webm
I've found myself doing this a couple of times during local
debugging. It's harmless to have it public, and seems pretty
useful for debugging inside of the mp4 package.
Using a file:// URL for loading an HLS stream (for testing) would fail due to
casting the connection to an HttpURLConnection in DefaultHttpDataSource.
This change makes UriDataSource an interface for objects that are DataSources
with URIs. That allows for reading manifests for HLS using just a UriDataSource
rather than an HttpDataSource (URLs in the playlist are relative to the data
source's URL so the getUri method is needed).
On retrying loading a chunk, the state of the extractor was reset due to a call
to seek(). Prevent this call by only calling init() if no bytes were loaded.
Also make the DefaultExtractorInput use the loading position not the original
stream position so that its getPosition() method returns offsets relative to
the start of the stream, which fixes a bug where the chunk index offsets would
be relative to the wrong position if there was a retry while loading the chunk.