SDK / exoplayer

I'm not really a fan of micro-optimizations, but given this method
scans through every H264 frame in the HLS case, it seems worthwhile.
The trick here is to examine the first 7 bits of the third byte
first. If they're not all 0s, then we know that we haven't found a
NAL unit, and also that we wont find one at the next two positions.
This allows the loop to increment 3 bytes at a time.

Speedup is around 60% on Art according to some ad-hoc benchmarking.

There's no code change here at all, except for how TsExtractor's
getLargestSampleTimestamp method works.

1. AdtsReader would previously copy all data through an intermediate
adtsBuffer. This change eliminates the additional copy step, and
instead copies directly into Sample objects.

2. PesReader would previously accumulate a whole packet by copying
multiple TS packets into an intermediate buffer. This change
eliminates this copy step. After the change, TS packet buffers
are propagated directly to PesPayloadReaders, which are required
to handle partial payload data correctly. The copy steps in the
extractor are simplified from:

DataSource->Ts_BitArray->Pes_BitArray->Sample->SampleHolder

To:

DataSource->Ts_BitArray->Sample->SampleHolder

Issue: #278

- TsExtractor is now based on ParsableByteArray rather than BitArray.
  This makes is much clearer that, for the most part, data is byte
  aligned. It will allow us to optimize TsExtractor without worrying
  about arbitrary bit offsets.
- BitArray is renamed ParsableBitArray for consistency, and is now
  exclusively for bit-stream level reading.
- There are some temporary methods in ParsableByteArray that should be
  cleared up once the optimizations are in place.

Issue: #278

This is the start of a sequence of changes to fix the ref'd
github issue. Currently TsExtractor involves multiple memory
copy steps:

DataSource->Ts_BitArray->Pes_BitArray->Sample->SampleHolder

This is inefficient, but more importantly, the copy into
Sample is problematic, because Samples are of dynamically
varying size. The way we end up expanding Sample objects to
be large enough to hold the data being written means that we
end up gradually expanding all Sample objects in the pool
(which wastes memory), and that we generate a lot of GC churn,
particularly when switching to a higher quality which can
trigger all Sample objects to expand.

The fix will be to reduce the copy steps to:

DataSource->TsPacket->SampleHolder

We will track Pes and Sample data with lists of pointers into
TsPackets, rather than actually copying the data. We will
recycle these pointers.

The following steps are approximately how the refactor will
progress:

1. Start reducing use of BitArray. It's going to be way too
complicated to track bit-granularity offsets into multiple packets,
and allow reading across packet boundaries. In practice reads
from Ts packets are all byte aligned except for small sections,
so we'll move over to using ParsableByteArray instead, so we
only need to track byte offsets.

2. Move TsExtractor to use ParsableByteArray except for small
sections where we really need bit-granularity offsets.

3. Do the actual optimization.

Issue: #278

- Also make text renderers respect the decodeOnly flag.
- Also fix AC3 passthrough to always allocate direct buffers.

- Remove simple variant. Maintaining both simple + full is
  unnecessary effort.
- Remove need to specify content id in Sample definition,
  except where it's actually required (for DRM requests in
  the Widevine GTS samples)

Also add parseMp4vFromParent and return the track's duration in parseTrak.

This is in preparation for adding a non-fragmented MP4 extractor.

If the timesource track renderer ends, but other track renderers
haven't finished, the player would get stuck in a pending state.
This change enables automatic switching to the media clock in the
case that the timesource renderer has ended, which allows other
renderers to continue to play.

Add a utility for converting named atom types to integers.

Add atom types for non-fragmented MP4 parsing.

Issue: #268

These may occur in VOD streams where a representation's data
is small enough not to require segmentation or an index. For
example subtitle files.

Issue: #268

SampleExtractor will initially only be implemented by FrameworkSampleExtractor
which delegates to a MediaExtractor, but eventually it will also be implemented
by additional extractors.

The sample extractor can be used as a source of samples via DefaultSampleSource.

Issue: #268

This may be painful in terms of applications having to change their
imports. Sorry about that.

Merge dev-hls -> dev

dev -> dev-hls

Also added clamping to getSegmentNum in one case where
it was not already implemented, and defined this behavior
property in the getSegmentNum javadoc.

Issue: #262

This makes the calculation correct for the case where periodDurationMs
does not divide exactly into durationMs.

Fixed wrong calculation of last segment number when using segment templa...

Fixed wrong calculation of last segment number when using segment template without segment timeline.

dev -> dev-hls

Without this, the byte is cast as follows (in bits) if the top
byte is set:

10000010 -> 1000000000000000000000000000010

This works because we then always shift at least one bit left,
and only look at the bottom 8 bits of the result. It's confusing
though. It's clearer if the cast to int gives just adds zeros to
the front, like:

10000010 -> 0000000000000000000000010000010

Fix a signed right shift issue in BitArray.readUnsignedByte()

Make BitArray.readUnsignedByte() a bit more clear by using int value instead of byte to prevent unnecessary convert from int to byte.