When a passthrough AudioTrack is replaced (due to seeking) the new one behaves
as if it is still emptying data from the old one, with its playback position
advancing until it runs out of data.
Data written while the 'old' AudioTrack was emptying would be discarded, so
avoid writing to the new AudioTrack while the old one is still emptying.
Also avoid using AudioTrack.getTimestamp with passthrough tracks, as this causes
the playback position to jump to a position that breaks audio/video
synchronization.
This also fixes a technical mistake where HlsChunkSource is fed
seekPositionUs=-1 when obtaining the first chunk. This is wrong,
but the usage of this variable within HlsChunkSource enforces that
the seek must stay within bounds, so we get away with it.
Issue: #385
1. prepare() needs to load a TsChunk to actually prepare the source.
2. Source is prepared, but no tracks are enabled (this is why it's
an edge case - no-one is likely to be doing this!).
3. The TsChunk load completes.
We should not load additional chunks in this case.
For Live SmoothStreaming, referential equality checking
isn't enough (it breaks once the manifest is updated).
Updated other instances too just for consistency.
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.
