SDK / exoplayer

1. Ignore edit list where the sequence doesn't contain a sync
   sample, rather than failing.
2. Make Mp4Extractor.readAtomPayload so it doesn't try and read
   the same payload twice if a failure occurs parsing it.
3. Make processAtomEnded so that it doesn't pop the moov if
   parsing it fails.

Issue: #3351

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

Recently added Java 8 features in the cronet extension and the linked native libs
require to enable Java 8 desugaring in gradle. Moreover, junit.assertThrows is not
available in our version and its usage has been replaced by the manual check.

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

The chunk size of real video data varies around the given average bitrate.
To account for this fact in the fake adaptive data set, the chunk size varies
randomly with a given standard deviation. The standard deviation used for the
BandwidthProfileSimulator is based on the chunk size variation measured on the
1 hour playlist of real media.

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

Using cookie validation from streamer, streamer can enforce that only clients who have the cookie are able to stream the video.

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

This change fixes various issues:
 - MobileHarness sometimes allocated devices with SDK < 16. As we have no tests running
   on these SDKs, a new dimension filter for the mobile_test target ensures that only
   devices with SDK >= 16 are selected. A similar filter for SDK version is also added
   to the ABR playback tests to ensure no old devices are selected.
 - DRM specific tests are skipped for Api < 18, but were not able to run because the
   DashTestRunner class tried to link to the MediaDrm constructor. Moved the
   constructor to a seperate Builder class to allow execution on Api levels 16 and 17.
 - DashWidevineOfflineTest also tried to access code for Api >= 18 without checking
   the current level.
 - Action implementations which are waiting for events did not ensure that they have a
   nextAction to wait for. This caused NullPointerExceptions when this next action was
   scheduled.
 - DefaultDrmSession always restored the offline keys when a new license was requested,
   even if the keys were already restored. These repeated slow calls to restoreKeys
   resulted in high numbers of dropped buffers.

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

and consume event without moving the focus.

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

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

Update the audio track selection logic in DefaultTrackSelector:

- When forcing lowest bitrate, use bitrate as tie-breaker when track scores are
the same, prefer the lower bitrate.
- Otherwise, use one of the following values as tie-breaker in order:
  - ChannelCount
  - SampleRate
  - BitRate
If the format being checked is within renderer's capabilities, select it if it
has higher tie-break value, else, select it if it has lower tie-break value.

If all tie-break values are the same, prefer the already selected track.

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

MediaCodecRenderer implementations require DrmSessionManager<FrameworkMediaCrypto>,
but it's currently not possible for an app to provide a custom implementation due
to FrameworkMediaCrypto having a package private constructor. This change exposes
public FrameworkMediaCrypto constructors, hence removing this restriction.

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

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

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

Calling HandlerThread.quit() or .quitSafely() doesn't immediately terminate
the thread. It just instructs the Looper not to accept any new messages and
to terminate at the next opportunity. Added a HandlerThread.join() everywhere
where the intention is to close and release all resources and to stop all
threads.

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

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

Issue: #3322

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

This change also replaces individual DownloadAction versions with a
single master version.

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

For initial DRM provisioning and key request, we allow the requests to be
retried (with increasing delay for each successive retry) before failing.

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

Android Studio refuses to build with the current beta4 version.

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

Controls are still hidden while playing ads, but if the app pauses the player,
controls will be shown. During ads, the player is not seekable.

When the player enters the background then returns to the foreground, the
content period may not be prepared, so also cache the content window duration.
This means that if the app reenters the foreground while an ad is paused the
time bar can be populated.

Issue: #3303

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

Now this counter includes input buffers too, which are dropped as part of
skipping to keyframes for catch up.

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

Some action schedules (especially those for real media with potentially
long initial buffering times) don't wait until the playback started
before executing the rest of the schedule.

Added waitForPlaybackStateChanged(STATE_READY) to all applicable action schedules.

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

This allows more deterministic action schedules, especially for real media
which may take an arbitrary amount of time to rebuffer after seeking.

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

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

If the current output buffer is very late and the playback position is in a
later group of pictures, drop all buffers to the keyframe preceding the
playback position.

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

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

imaPausedInAd could only be true when imaPlayingAd was true, so there are only
three possible states.

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

This is useful to determine when a seek request was processed by the player
and all playback state changes (mostly to BUFFERING) have been performed.

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

* Always assume a renderer is ready if it's read to the end of
  its current stream and there's a subsequent period already
  prepared. This prevents getting stuck when a non-clock renderer
  has a short stream.
* Switch to the standalone clock if the renderer providing the
  media clock has read to the end of its current stream, is no
  longer ready, and there's a subsequent period already prepared.
  This prevents getting stuck when a clock renderer has a short
  stream.
* Remove unnecessary clock synchronization logic (since it would
  need to be made more complicated as a result of this change).
* Don't update the playing period holder when playWhenReady is
  false. This avoids the position jumping to the start of the
  next period when seeking to the very end of the current period
  whilst paused (we still end up showing the first frame of video
  from the next period, but fixing that will have to wait).

Github: #1874

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

This works similar to the existing WaitForXXXX actions.

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

* If speed <= 0.1, update every second.
* If 0.1 < speed < 1, update approximately once per
  second in real time, aligned so that each second boundary
  in media time has a corresponding updatae.
* If speed == 1, keep existing behavior.
* If 1 < speed <= 5, update every second in media time
* If speed > 5, update every 200ms.

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

Run next action immediately without using the handler when the requested
delay is zero. This ensures that no other code can run between these two
actions to improve deterministic test behaviour.

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

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

This avoids spurious position reports following an underrun.

Github: #1874

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

In out libvpx extension, currently we always call vpxGetFrame and copy the data
from the native decoder to output frame. However, if the inputBuffer has
isDecoderOnly set, we can avoid populating the output buffer, but only setting
BUFFER_FLAG_DECODE_ONLY.

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

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

This change allows applications to provide custom AudioSinks, which could be
based on android.media.AudioTrack like AudioTrackAudioSink, or could be
completely custom.

The refactoring is mostly mechanical and shouldn't result in any functionality
changes.

Some android.media.AudioTrack-specific details have to appear in the AudioSink
interface so this change modifies the javadoc on the AudioTrack (now AudioSink)
to note that some methods will have no effect.

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

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

This allows simplified listener implementations as most listeners
will not listen to all possible notifications.

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

By default, if a codec is instantiated during an ongoing
playback, ExoPlayer will render the first frame that it
receives (so that there's "something other than black"
drawn to the surface). This frame is the key-frame before
the current playback position, and may be as much as 5
seconds behind the current position. ExoPlayer then drops
subsequent frames that are late until it's caught up to
the current position again.

For GTS tests that are counting dropped frames, this is
not desirable behavior, since it will cause spurious test
failures in cases where DummySurface is not supported.
This change overrides the default behavior so that the
player instead skips (rather than drops) frames until it's
caught up to the current playback position, and only then
renders the first frame.

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

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