Most of those objects needs to be sent to MediaControler.
`TrackSelectior.Parameters` could have stayed Parcelable,
but it needs to be `Bundleable` as it inherit from
`TrackSelectionParameters` that is and needs to be
serializable anyway for the demo app.
As a result it has also been migrated to bundleable.
PiperOrigin-RevId: 391353293
This CL introduces two classes:
* CueEncoder - encodes list of Cue object into byte array.
* CueDecoder - decodes byte array into list of Cue objects.
This two classes are necessary in order to push Cues through SampleQueue. This classes are meant to be used by subtitle Extractor.
PiperOrigin-RevId: 388932088
The AnalyticsCollector releases listeners lazily so that listener
callbacks triggered on the application looper after
SimpleExoPlayer.release() are still handled. The change in ListenerSet
to post the onEvents callback on the front of the application looper
changed (correctly) how onEvents are propagated, however this made
the AnalyticsCollector deliver onEvents with out-of-order EventTimes.
This change fixes AnalyticsCollector to trigger onPlayerReleased() and
the matching onEvents() event in the correct order.
#minor-release
PiperOrigin-RevId: 388668739
Prior to this change, an initalized TimestampAdjuster that's then
reset with DO_NOT_OFFSET would incorrectly continue to apply the
offset.
Also add a test case for this issue, and for some other simple use
cases.
#minor-release
PiperOrigin-RevId: 388182645
The dokka javadoc generation tool complains when parameter names don't match between a method and its override. This change updates occurrences where there is currently a mismatch.
Notable renamings that might be controversial:
- `onPlaybackStateChanged(int state)` to `onPlaybackStateChanged(int playbackState)` affected a lot of lines but seems more consistent with other '-Changed' methods.
- `handleMessage(int messageType, Object payload)` to `handleMessage(int messageType, Object message)`
- `ExtractorInput` and `DataSource` inherit `DataReader` which had `read(byte[] target, ...`, while data sources normally called the first parameter `buffer`. I have standardized these all to use `buffer` even though it looks out of place in the `ExtractorInput` interface (which has more `read` methods with `target`).
PiperOrigin-RevId: 387290360
The inference is used when nesting DataSourceExceptions. It is removed because
nesting does not add additional value in surfacing the exceptions, and it is
better to assign an error code at the throw site (in the "leaf" or the bottom
most data source).
PiperOrigin-RevId: 386919118
In some DataSources, it is not easy to assign an error code at the throw site.
For example, CronetDataSource.readInternal() throws SocketTimeoutException
on L1033, and is caught at L754 as IOException and is thrown.
We need the logic to assign error code for the actual type of the error cause.
While we can certainly do in individual DataSources, IMO there's value in
making this logic generic at a higher level (like what is in this CL).
The catch and translation logic is borrowed from EPII:L646.
PiperOrigin-RevId: 385789629
The types (open/close/read) does not provide extra information about the thrown
playback exception, and they are not utilized at higher levels.
PiperOrigin-RevId: 384219870
The parameters staying in DefaultTrackSelector are considered
too ExoPlayer specific to be part of the `Player` interface.
Those are:
- exceedVideoConstraintsIfNecessary;
- allowVideoMixedMimeTypeAdaptiveness;
- allowVideoNonSeamlessAdaptiveness;
- exceedAudioConstraintsIfNecessary;
- allowAudioMixedMimeTypeAdaptiveness;
- allowAudioMixedSampleRateAdaptiveness;
- allowAudioMixedChannelCountAdaptiveness;
- disabledTextTrackSelectionFlags;
- exceedRendererCapabilitiesIfNecessary;
- tunnelingEnabled;
- allowMultipleAdaptiveSelections;
- rendererDisabledFlags
Track selection override will be migrated in a follow up cl.
To avoid breaking backward compatibility,
`DefaultTrackSelector.Parameters` extends
`TrackSelectionParameters` and
`DefaultTrackSelector.ParametersBuilder` extends `TrackSelectionParameters.Builder`.
The change are thus transparent for clients.
Test are incomplete for now, as this is a relatively big cl, I though
the reviewer could give a first pass will the tests are completed.
PiperOrigin-RevId: 383767021
The serialization scheme used here is custom, it doesn't need
to be compatible with emsg-v0 or emsg-v1 (since
97183ef558).
This means that C.TIME_UNSET will propagate correctly through the
serialization.
#minor-release
Issue: #9123
PiperOrigin-RevId: 382762873
- Use `PlaybackException.ErrorCode` IntDef for `DataSourceException` error code
- Deprecate `DataSourceException.POSITION_OUT_OF_RANGE`
- All other changes are related to replacing the deprecated constant and
constructor
PiperOrigin-RevId: 382683522
Currently when a HTTP POST request receives a 302, CronetDataSource will change the request method from POST to GET for the redirected request, and drop the post body. This aligns with the behaviours of many user agents, but our use case would like to keep the POST method and the post body.
org.chromium.net.UrlRequest.followRedirect also changes POST to GET for 302, so should be avoided here.
PiperOrigin-RevId: 381233011
This helps to remove old ad groups (e.g. those that fell out
of the live window) to keep the data size of AdPlaybackState small.
Also added this case to some existing unit tests to ensure it's
covered.
PiperOrigin-RevId: 376170653
This allows to decouple the data structure from the access. In
a future change, this allows to completely remove old ad groups
(e.g. for live streams where the number of groups would otherwise
grow forever).
Also move the time into the group itself for better encapsulation.
PiperOrigin-RevId: 376170408
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
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
This change adds an API in the ForwardingPlayer to disable commands.
This is affecting what Player.isCommandAvailable() returns as
well as what is being advertised from the
EventListener.onAvailableCommandsChanged() callback.
For the callback case, the ForwardingPlayer needs to intercept the
callback. It does so by wrapping registered EventListener and Listener
instances, which resulted in some boiler-plate code. In addition, there
is logic on the wrapped listeners to avoid triggering a queued callback
if all listeners have been removed in the meantime. This includes the
case where new listeners are added while callbacks scheduled for the
removed listeners are still pending.
PiperOrigin-RevId: 371139703
Move VideoSize in the common module and have the Player return it.
`Listener` and `AnalyticsListener` `onVideoSizeChanged` are updated
with the old method deprecated.
`VideoRendererEventListener.onVideoSizeChanged` was also migrated to
`VideoSize` but the old method is removed, not deprecated.
This is because:
- apps calling/listening to this method is a rare and niche use-case.
- it would introduce hard to diagnostic issues where if only the caller
or the callee is updated to use the new method, the event will be lost.
This doesn't occur with the other 2 listeners as the caller is always
in ExoPlayer library and was updated to call both the old and new methods.
VideoSize is used everywhere except in `Format` as this would lead to
too much refactoring and backward compatibility breakage for little gain.
#minor-release
PiperOrigin-RevId: 371087419
Rating class should be in the same module as MediaMetadata.
Tested:
$ ./gradlew --stacktrace :exo-library-common:tDUT
$ ./gradlew --stacktrace :media2-session:tDUT
$ ./gradlew --stacktrace :media2-session-vct-current:cAT
PiperOrigin-RevId: 370902917
We added a source that allows mixed placeholder and non-placeholder
periods, but have no way to denote that in the Timeline because the
placeholder flag only exists on Window level. This causes a bug if
the first item in a concatenation has a window-period offset and the
player can't detect whether it's still a placeholder or not.
Adding this flag to Period allows the player to detect this reliably.
In addition we need to make sure that re-resolving pending positions
only happens for the first placeholder period where the window-offset
can actually change. As all subsequent periods have to start at position
0, so they don't need to be re-resolved (and shouldn't).
PiperOrigin-RevId: 367171518
- Update the three `HttpDataSource` implementations to use the
Content-Range response header to determine when this is the
case. The Content-Range header is included when the status
code is 416. See [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/416).
- Update `ByteArrayDataSource` to conform to the requirement.
- Update `DataSourceContractTest` to enforce the requirement.
PiperOrigin-RevId: 363642114
Part of aligning HttpDataSource behavior will require adding
logic that's common across the DataSource implementations. This
change establishes a util class to house it, and moves a bit of
existing logic that's related and can be easily shared into it.
There is one small behavior change in this CL, which is that our
handling of Content-Range response headers can now parse the body
length if the "document size" part of the Content-Range is unknown,
for example "bytes 5-9/*". Previously the pattern we were matching
to required the "size" part to be set, for example "bytes 5-9/100",
despite the fact we don't need or use it.
PiperOrigin-RevId: 362396976
When we add DRM pre-acquire support to SampleQueue, we'll dispatch
twice the number of acquire and release events. This is slightly
confusing, since there's the same number of
DrmSessionManager#acquireSession() calls.
We can mitigate this by only dispatching each acquire and release
event to at most one EventDispatcher.
This also changes the events fired when playing a stream with both audio
and video encrypted with the same keys (even without pre-acquisition).
Before: The EventDispatcher would see 2 aquires, 1 key load and 2
release events.
After: The EventDispatcher will see 1 acquire, 1 key load and 1 release.
PiperOrigin-RevId: 358804502
It's for classes to clearly denote they support bundling and it gives
us a good place to document the best practice to implement fromBundle.
PiperOrigin-RevId: 355609942
This also moves DefaultHttpDataSource to common, which seems
sensible, else non-player components that need a DataSource
don't have any useful concrete implementations. We should
think about moving some of the other concrete implementations
to common as well.
PiperOrigin-RevId: 354738925
They only require common. This allows their use for non-playback networking
without requiring the user to depend on the whole of core. I will also make
the same change for Cronet, although this needs a little more work.
PiperOrigin-RevId: 353649388
Add a test to DataSourceContractTest that asserts the gzip flag is
either ignored or handled correctly.
Add a test resource to DefaultHttpDataSourceContracTest that enables
gzip compression on the 'server' and checks it's handled correctly by
the client.
PiperOrigin-RevId: 352574359
*** Original commit ***
Rollback of ff8c8645ab
*** Original commit ***
Merge #8401: Initialize Format.codecs from HEVC SPS NAL unit (#8393)
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8401
This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media so...
***
PiperOrigin-RevId: 351139861
Retrieve the capture frame rate and the SVC temporal layer count from
the smta box instead of the meta box because this is what Samsung do. It
is not guaranteed that the meta box will be present and will contain all
the necessary info in all slomo files.
PiperOrigin-RevId: 345639680
