The docs on setLicenseUri say it's optional, and it has been since
379cd8a04f
(which should have changed this javadoc too)
#minor-release
PiperOrigin-RevId: 376139158
It only covers MediaSession - MediaController
(Does not consider cases that either a legacy session or a legacy controller is involved)
Add PlayerInfo#Builder to clean it up.
PiperOrigin-RevId: 374785779
Notes:
- The only functional change is that createForRemote now assings ERROR_CODE_REMOTE_ERROR.
- createForSource still uses ERROR_CODE_UNSPECIFIED, even though it expects an
IOException. The reason for not using ERROR_CODE_IO_UNSPECIFIED is that the reason for
the error might not be IO. For example, malformed media, or BehindLiveWindowException,
which have non-IO error codes. So using UNSPECIFIED saves a later change in category.
PiperOrigin-RevId: 374390407
When working with SSAI ads, we need to easily convert positions between
the underlying stream and the media model that exposes ad groups. To
simplify this, we can add util methods (that are testable on their own).
In addition, we need an easy way to build AdPlaybackStates for SSAI
inserted ads. The metadata is obtained out-of-band and usually has the
ad group start and end times in the underlying stream only. Hence, we
also add a util method to add a new ad group based on this information.
PiperOrigin-RevId: 374369360
MediaSession default command state contains all
commands.
To avoid having to update MediaSession when a command
is added, allow to create a Commands.Builder that
starts with all commands.
PiperOrigin-RevId: 374183484
Make ForwardingPlayer implement Player and not extend BasePlayer so that
ForwardingPlayer forwards each Player method directly to the wrapped
Player instance.
PiperOrigin-RevId: 374161084
There are two main changes that need to be made:
1. Whenever we determine the next ad to play, we need to select a
server-side inserted ad even if it has been played already (because
it's part of the stream).
2. When the Timeline is updated in the player, we need to avoid changes
that would unnecessarily reset the renderers. Whenever a Timeline
change replaces content with a server-side inserted ad at the same
position we can just keep the existing MediaPeriod and also if the
duration of the current MediaPeriod is reduced but it is followed by
a MediaPeriod in the same SSAI stream, we can don't need to reset
the renderers as we keep playing the same stream.
PiperOrigin-RevId: 373745031
Content after ad groups currently always resumes at the ad break position (unless
overridden by a seek or similar). In some cases, media inserting ads wants to
specify an offset after the ad group at which playback should resume. A common
example is a live stream that inserts an ad and then wants to continue streaming
at the current live edge.
Support this use case by allowing ad groups to specify a content resume offset
and making sure that the content start position after the ad group uses this offset.
PiperOrigin-RevId: 373393807
The player already supports changing durations of periods and ads.
The only thing not yet supported is a change in ad break positions
which changes the duration of clipped content ending in an ad break.
Adding support for this requires updating the end position in
MediaPeriodInfo and changing the clip end position of the respective
ClippingMediaPeriod.
Issue: #5067
PiperOrigin-RevId: 373139724
First intention to support parsing MPEG-H 3D Audio in ExoPlayer is to
take advantage of parsing capability from MediaParser API in AOSP.
Just with this change ExoPlayer does't support decoding MPEG-H 3D Audio
but can support decoding either by adding decoder with an extension or
by using Android OS which has decoder capability with MediaCodec API.
