We currently always reset everything if playingPeriod != readingPeriod.
However, this is only needed when the pausing is actually required, i.e.,
if the feature is enabled and we are in the last period of the window.
PiperOrigin-RevId: 328141242
Currently the audio renderer can become ready before the AudioTrack
actually has enough data to play something, which means that the
player may transition to the ready state before audio starts
playing. This makes the player's current state transition not very
useful for detecting when audio actually starts playing.
This change adds a new event to notify apps when the audio position
is increasing after a pause or seek/flush/reset event, and includes
an estimate of the system time at which audio playout started.
Issue: #7577
PiperOrigin-RevId: 327810040
Before this CL, SessionPlayerConnector getters had returned
UNKNOWN_TIME in idle state. It was because
SessionPlayerConnector had followed AndroidX media2
MediaPlayer's behavior, which was the baseline code of the
SessionPlayerConnector.
With this CL, SessionPlayerConnector getters directly return
underlying Player's value, rather than considering calls
in IDLE state as an exception and fallbacks to the default
UNKNOWN_TIME.
PiperOrigin-RevId: 327420940
ExoPlayer is now the trusted source of playlist and can be
used by other components without breaking
SessionPlayerConnector's cached playlist.
PiperOrigin-RevId: 327266929
Playlist can now be obtained directly from Timeline windows
in any state. So make ExoPlayer as the trusted source of
playlist, instead of SessionPlayerConnector.
PlayerWrapper still need to keep the list of media items.
It's used to detect whether the Timeline change is caused by
changes in media items or not, and only notify
SessionPlayer.PlayerCallback#onPlaylistChanged() only when
the playlist is really changed.
PiperOrigin-RevId: 327231820
MediaSession requires prepared Looper in 1.0.3-stable release,
which is the latest stable release for now.
The requirement would be removed in 1.1.0-stable, but workaround
is needed meanwhile.
PiperOrigin-RevId: 327220042
This allows us to more easily create different dumps derived from the
same assets.
This moves media/source files from `assets/` to `assets/media/` and
dump files from `assets/` to `assets/extractordumps/` and
`assets/audiosinkdumps/` as appropriate. I intend to add
`assets/playbackdumps/` in a future CL.
PiperOrigin-RevId: 326986283
- Applications should generally use DefaultMediaSourceFactory,
or their own custom implementation if they need one. Having the
media2 extension implement its own version directly doesn't seem
that useful.
- Remove support for CallbackMediaItem. This type of MediaItem
doesn't go cross-process, and it seems like there would never
be a use case where an app would need to generate one locally.
If an app needs to provide data from a custom source, it should
hook into ExoPlayer's way of doing this (i.e., use a UriMediaItem
with a custom scheme, and inject a custom DataSource that can
handle this scheme).
PiperOrigin-RevId: 326914465
- Use ExoPlayer DataSource instrumentation to intercept reads
- Use ExoPlayer Resource URIs
- Use ExoPlayer DefaultMediaSourceFactory
PiperOrigin-RevId: 326912324
PlayerWrapper throws Exception if getters is called in the
STATE_IDLE. In that case, log may print 50+ lines of stack
traces. It's verbose and can be considered as serious issue.
This CL include folloing changes
- Change to use ExoPlayer's log class
- Adjust log level, because it would be consumed by caller
- Leave log when the debug flag is turned on.
Another CL will remove exceptions between PlayerWrapper and
and SessionPlayerConnector, not to use Exception for ordinary
control flow as the Effective Java suggests.
PiperOrigin-RevId: 326614559
