SDK / exoplayer

There are multiple issues with HlsSampleSource's use of
LoadControl that become apparent when you attempt to use
the same LoadControl for loads by another source.

* In the "limbo" state HlsSampleSource doesn't start any
  new loads, but doesn't update the LoadControl to tell
  it that it doesn't want to load anything either. This
  can prevent another source from starting the loads that
  it needs to make to complete preparation, causing
  playback to become stuck.
* The LoadControl isn't updated properly when the EOS is
  reached. This can cause playback to become stuck near
  the end of the media.
* If HlsSampleSource is released from being in the "limbo"
  state, it doesn't unregister itself with the control.

Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111942009

Given we need to do this in HlsPlaylistParser in the normal
case (i.e. not MEDIA_TAG), we may as well just be consistent
and do it everywhere.

Issue: #151
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111941335

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111839055

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111833857

Currently only supports a single offset to the full media timeline
(indicated by a duration of 0). This is most often used to fix the
non-zero starting presentation timestamp introduced when B-frames
are present.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111816916

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111746825

Fixes Issue #1047
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111708934

This is equivalent to DashTrackSelector and SmoothStreamingTrackSelector.
This is a step toward allowing HlsChunkSource to expose multiple tracks,
which is a requirement for supporting WebVtt.

This change also enables WebVtt extractor instantiation.

Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111698833

This allows the same adjusters to be used by multiple
HlsChunkSource instances. This is necessary because
WebVTT chunks will be loaded by a second chunk source
to the one loading audio/video. In both cases the same
timestamp adjustments will need to be applied.

Each source may transition from one discontinuity sequence
to the next at a slightly different time, so it's necessary
to maintain a separate adjuster for each sequence.

An adjuster can only be initialized correctly using audio/video
and not WebVTT, because the start time in a WebVTT file in
HLS doesn't necessarily correspond to the chunk start time,
which means the timestamp offset calculated by the adjuster
could end up being incorrect. Hence sources providing WebVTT
chunks will set isMasterSource to false. Lovely, right :(?

Issue: #151
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111693126

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111689012

This gives DefaultSmoothStreamingTrackSelector feature parity
with DefaultDashTrackSelector. Note that the code duplication
across these classes will go away eventually, when we rework
track selection as described in Github Issue #1121.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111688784

This is a no-op change for clarity only. maxWidth/maxHeight
don't mean anything for AAC/MP3, so it makes sense to pass
MediaFormat.NO_VALUE in all cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111619832

Moved the behaviors related to Cue's to the WebvttCueParser class.
This way, the parsing methods will be more easily accessible to
other classes, such as the MP4Webvtt parser. This class also has
some methods that require state to avoid repetitive avoidable
allocations. The method visibility is subject to changes in
further CLs.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111616824

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111613354

Issue: #1090
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111607802

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111515406

Targeting to all API level 19 devices using the OMX.SEC.avc.dec
decoder is probably the right thing to do. It shouldn't have
negative implications if we apply the workaround on devices that
don't really need it, except to slow down seeking slightly due
to decoder re-allocation. Given we're talking about JB, I think
the priority should be to "make sure it works".

Issue: #951
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111514406

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111507159

We normally expect each frame to come in its own PES packet,
but it seems that this is not always the case. This change
uses the frame rate in the stream to increment the frame
timestamp in the case of multiple frames contained within
a single PES.

Note that since we don't expect 100s of frames in a single
PES, or anything close to that really, the rounding errors
that may accumulate due to use of a frame duration should be
fine.

Issue: #1112
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111499052

Issue: #1102
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111497855

Issue: #862
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111403855

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111402555

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111394118

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111348701

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111326567

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111326567

Issue: #1111
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111326378

Issue: #1078
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111325745

This is in preparation for removing BufferingInput,
and using peeking instead.

Also add tests for peeking with allowEndOfInput and
resetPeekPosition.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111318236

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111315463

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111310622

This CL adds a class responsible for managing the lifecycle
of a single Choreographer to be shared among all
VideoFrameReleaseTimeHelper instances.

Issue: #1066
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110839824

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110768506

This CL is prepares the ground for refactoring the Webvtt parser,
so as to use the common parsing algorithms in both parsers. In order
to do this, the Webvtt Parser will be refactored. As a side note, many
more test cases will be added once the new subtitle features are
implemented. Some useful test cases have also been left for a following
CL, to allow an easy code review.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110466914

Seems (marginally) nicer than making one up :). I didn't
realize there was a method that didn't require a framerate
to be passed!
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110456874

Improve identification of (E)AC3 content in MPEGTS and tweak EAC3 parsing