Currently onTimelineChanged doesn't allow to distinguish easily between the
different reasons why it's being called. Especially, finding
out whether a new media source has been prepared or the current source
refreshed dynamically was impossible without tightly coupling the player
operations with the listener.
The new reasons provide this disdinction by either indicating a newly
initialized media source, a dynamic update to an existing timeline
or manifest, or a reset of the player (which usually results in an
empty timeline).
The original onTimelineChanged method without reason is kept in the
DefaultEventListener as deprecated to prevent the need to update all
existing listeners in one go.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176478701
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
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
* 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
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
This allows listeners to easily determine the source of the discontinuity.
Reasons can be period transitions, seeks, and internal reasons.
Listeners still using the deprecated ExoPlayer.EventListener interface were
updated to Player.EventListener.
GitHub: #3252
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168549612
This appears to be fixed in Oreo, but given how harmless
the workaround is we can probably just apply it on all
API levels to be sure.
Issue: #3160
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167709070
When creating PlaybackControlView inside SimpleExoPlayerView,
we want certain attributes to be passed through. This lets you
set control attributes on the SimpleExoPlayerView directly. We
don't want all attributes to be propagated though; only our own
custom ones.
Not sure if there's a cleaner way to do this. Pragmatically this
solution seems ... ok :)?
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167619801
1. Make LeanbackPlayerAdapter use a ControlDispatcher. This
allows apps to suppress control events in some circumstances,
and is in-line with our mobile controls.
2. Misc simplifications and cleanup to LeanbackPlayerAdapter.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166852816
This includes an option to show and hide the shuffle mode button. When
pressing the button, the shuffle mode of the player is toggled.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166455759
findViewById is now defined using generics, which allows
the types to be inferred.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166355555
This functionality is most likely needed by UI modules which currently need
to obtain the timeline, the current repeat and shuffle modes and are only then
able to query the next/previous window index using this information.
Adding these methods simplifies these cumbersome requests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166181202
This parameter is used by methods such as getNextWindowIndex
and getPreviousWindowIndex to determine the playback order.
Additionally, there are method to query the first and last
window index given the shuffle mode.
None of the timeline implementations nor the ExoPlayer
implementation supports shuffling so far.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166170229
These methods are only used in one place, and offer duplicate
functionality to checking getNext(Previous)WindowIndex == C.INDEX_UNSET.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165910258
There will be non-ExoPlayer players that can output text
and metadata, so the outputs should be standalone. There
may also be ExoPlayer instances that use non-standard
text and metadata renderers, for which this change also
makes sense.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165628420
We've seen more than one issue filed where a developer has
registered a video listener and been confused by the fact
their SimpleExoPlayerView no longer works properly. There
are also valid use cases for having multiple metadata/text
outputs.
Issue: #2933
Issue: #2800
Issue: #2286
Issue: #2240
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164839882
- Publish IMA extension
- Force IMA to use the correct version of the support library
- Add missing sr translations for repeat mode strings
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163705883
