SDK / exoplayer

- There's definitely potential for more code sharing in these
classes, but deferring for now.
- Also made no-scheme default to file://, and allowed smoothstreaming
URLs to be specified with or without the /Manifest suffix.

Before preparation, and when seeking, Mp3Extractor did not handle retrying:
- synchronizedHeader was set before the header was known to be valid, which
  means that after seeing one valid frame header and then failing to read, the
  synchronization would be treated as complete.
- The input buffer would keep data loaded during synchronization but on the next
  call to synchronize when retrying it was not returned to the mark position to
  re-parse the data.

This change fixes these issues.

- Make HlsPlaylistParser treat non-positive dimensions as unknown.
- Make HlsPlaylistParser parse floating point resolutions, because
  technically that's how they're spec'd.
- Make VideoFormatSelectorUtil treat non-position dimensions as unknown.

Issue: #461

1. Make DefaultUriDataSource robust against exceptions through from close().
2. Make AssetDataSource handle file:///android_asset/ URIs.

When I moved the id3Reader instantiation out of the while
loop (below where it is now) it was no longer guarded by
the streamTypes.get(streamType) deduping check. This brings
back an equivalent check.

When a XING header is present but not usable (due to missing fields), CBR
seeking can be used instead. It relies on the bitrate. The bitrate from the
unusable XING header is not correct, which leads to incorrect seeking.

Also fix VBRI seeking by setting the correct offset on the frame to parse. Few
people seem to use that format, but I have found two very short truncated
samples which were falling back to the CBR case before but are using VBRI with
this change.

support content uri (e.q. content://xxx)

Support setting properties on MediaDrm

Gradle plugin 1.2.3

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

Issue: #400

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.