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
Even after this change, it's unclear to me why we need so many
assets for these tests. Just doing a minimal pass for now though!
PiperOrigin-RevId: 326613941
Being specific, this includes following changes
- Remove PlaylistManager and TimelinePlaylistManager
and use Player's playlist API directly.
- Replace ConcatenatingMediaSource uses with
ExoPlayer MediaItem.
- Replace PlaybackPreparer uses with Player#prepare()
- Add MediaItemConverter for developers to customize
converting AndroidX MediaItems to ExoPlayer MediaItems
and vice-versa.
- Add DefaultMediaItemConverter for providing default
implementation of both MediaItemConverter
and MediaSourceFactory.
Note that removing PlaylistManager loses the ability
to suppress individual playlist API. But decided to remove
for simpler API set. The feature can be added back later
via explicit request.
PiperOrigin-RevId: 326463492
This is the workaround for b/159147455.
The issue will be fixed in media2-session 1.1.0-stable, but we'd
better to have workaround until it's ready.
PiperOrigin-RevId: 325434543
It seems generally useful to have access to the decoder in
getOutputFormat. We're currently working around lack of access
by using member variables in the concrete audio extension
renderers. In the case of the Ffmpeg extension, holding a
reference to the decoder is preventing it from being garbage
collected when the decoder is released by the base class.
PiperOrigin-RevId: 324799670
The working of libOpus is different from ffmpeg. With ffmpeg, the decoder can
be configured to output floating point PCM. While in libOpus, floating samples
are acquired by calling a different function. This is the reason the new JNI
functions and the logic in OpusDecoder/LibopusAudioRenderer is added to
support float output.
PiperOrigin-RevId: 324661603
This callback was not notified before, which could theoretically lead to ad
loading timing out. In practice it doesn't currently happen because the timeout
appears to start when the ad cue point is reached, not when loadAd is called.
We notify onLoaded when the ad media period is prepared (for HTML5 the
recommendation is to notify on the HTMLMediaElement 'canplay' event, which this
roughly corresponds to).
PiperOrigin-RevId: 324568407
This allows us to enforce the limit because the array can only be
reassigned through reset(byte[]) or reset(byte[], int) (which update
the limit)
PiperOrigin-RevId: 323339960
This removes Supplier, Function and Predicate. Consumer is kept because
Guava doesn't have an equivalent (Java 8 does, but we can't use that
yet).
#exofixit
PiperOrigin-RevId: 323324392
Suggested during the review of 437d1b6e9a
This keeps the Runnable -> Callable<Boolean> conversion encapsulated
inside SessionPlayerConnector which makes it clearer why it's needed.
PiperOrigin-RevId: 321553744
