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
A subsequent change will deprecate CronetEngineWrapper and move
all of the logic into a utility class for obtaining a suitable
CronetEngine.
This change also deprioritizes use of unknown cronet providers.
PiperOrigin-RevId: 381051164
The way CronetDataSource.Factory can internally fall back to another
factory is confusing and unnecessary. In the case the application cannot
instantiate a CronetEngine, it should directly use another factory.
This makes CronetDataSource more consistent with OkHttpDataSource. In
both cases, their factory constructors take the component that the
respective libraries advise should only be created once by the application,
which are CronetEngine and OkHttpClient respectively.
CronetEngineWrapper will be deprecated in a subsequent change.
PiperOrigin-RevId: 381016504
More information: go/checker-3130-lsc
Tested:
Some test failures are present, but the CL author has decided to mail the change anyway
PiperOrigin-RevId: 379622938
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
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
Release is a life cycle operation that should only be called when
the player is no longer needed. It's linked to the player lifecycle
and thus very different from prepare/stop.
As a result, it should not be in the same command.
Additionally it's not clear if remote players will ever need to call release,
as the player creator is best candidate to release it.
As a result the release operation doesn't have a use case for a command.
A release command can be added later if a need is identified.
PiperOrigin-RevId: 370649214
There is a bug when CronetDataSource opens an asset with a length
bigger that Integer.MAX_INT (2147483647 bytes, ~2GB). In read(),
`bytesRemaining` is cast to int, which overflows and evaluates to a
negative number, causing `bytesRead` to be negative too.
PiperOrigin-RevId: 370434368
Add method getAvailableCommands() in Player interface to return
the available commands. Method isCommandAvailable() moved to
BasePlayer since it can be implelented by calling
getAvailableCommands().
PiperOrigin-RevId: 370059328
* @Encoding is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations) (2 times)
* @Nullable is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations) (2 times)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 370048160
A subsequent change will make the UI module access
SphericalGLSurfaceView and VideoDecoderGLSurfaceView
using reflection, now we're at the point where we only
need to reflect the constructors.
PiperOrigin-RevId: 369630102
The original cl has been fixed by not implementing
VideoListener but Player.Listener in
StyledPlayerView.
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
PiperOrigin-RevId: 369417682
*** Original commit ***
Move VideoComponent in ExoPlayer
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
***
PiperOrigin-RevId: 369194309
VideoFrameMetadataListener and CameraMotionListener are still part
of the Player interface as a good way to break the UI dependency
on them has not yet been finalised.
PiperOrigin-RevId: 368863829
Other tests in this file already use `Executors.newSingleThreadExecutor` so do the same for the ones that currently use `mockExecutor`.
PiperOrigin-RevId: 368859470
Even when fixed to the US locale (and thus avoiding surprising behaviour
in e.g. Turkish locale with "i" and "I") there are unexpected behaviours
when upper and lower casing non-ASCII characters.
For example it's sometimes not symmetric, e.g.:
"ẞ".toLowerCase() -> "ß"
"ß".toUpperCase() -> "SS"
In all the ExoPlayer usages we are either dealing with known-ASCII
strings (e.g. MIME types) or comparing against ASCII constant strings
anyway, so it seems easier to just use Guava's ASCII-only class in these
cases.
This change also includes some null-twiddling, because
Util.toLowerInvariant() is null tolerant, while Ascii.toLowerCase() is
not. Most of the usages were already non-null, and it was easy enough to
change the remaining ones to be so by simple reordering of statements.
I'll make an equivalent change for Util.toUpperInvariant() next.
PiperOrigin-RevId: 368419813
This brings in another fix for `NullPointerExceptions` within `WebView` callbacks in the IMA SDK, related to companion ads.
Issue: #8447
#minor-release
PiperOrigin-RevId: 367591047
When playing TrueHD streams, it's possible that the first decoded
buffer is empty, and that the channel count and sample rate are
still unknown. To correct for this, defer determining the format
until a buffer that will actually be output from the decoder has
been obtained, and only then query the channel count and sample
rate.
Issue: #8616
#minor-release
PiperOrigin-RevId: 366246245
When playback transitions automatically, the timeline may have changed because the cast device learned about the duration of the next media item and includes this in the new media status that is sent to the CastPlayer. In such a case we need to make sure that we don't report a media item transition with reason PLAYLIST_CHANGED but for reason AUTO.
PiperOrigin-RevId: 366025323
The BasePlayer implementation of add/remove
Listener knows about Components.
As those are removed from the Player
interface, the implementation of those
methods needs to be moved down in Player
implementations.
This commit makes no functional change.
PiperOrigin-RevId: 364985291
Null was an alias for DEFAULT. Remove this for nullness
safety in the API.
The ExoPlayer implementation still checks for null and
replaces it by DEFAULT, so this is ABI compatible.
PiperOrigin-RevId: 364370017
- 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
`ImaAdsLoader` clears its `AdPlaybackState` when it's released but this could
cause `AdsMediaSource` to look up information in the ad playback state that is
no longer in bounds.
Issue: #8693
#minor-release
PiperOrigin-RevId: 362556286
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
- Avoid having two onPositionDiscontinuity events (seek and transition)
sent after a seek to another media item.
- Avoid triggering an onPositionDiscontinuity event after a timeline
change.
#minor-release
PiperOrigin-RevId: 361092914
Includes fixes for the HTTP implementations, which previously
broke this contract specifically in the case when a server
responds to a range request with a HTTP 200 response. To fix
this case, skipping to the requested position is moved from
read() to open(). As a side effect, this nicely simplifies
CronetDataSource!
PiperOrigin-RevId: 359737301
Latest LTS version is better than latest stable version because it will
be supported for longer.
#minor-release
Issue:#8581
PiperOrigin-RevId: 359467482
The concept of Renderers is not needed in the
Player interface. Move it to ExoPlayer.
This should not break most users as they use SimpleExoPlayer.
PiperOrigin-RevId: 359220977
- Ensure consistency between (Styled)PlayerControlView,
PlayerNotificationManager, TimelineQueueNavigator and
DefaultControlDispatcher.
- Handle the case where a live stream has ended when enabling previous
and next actions (window.isLive() is true and window.isDynamic is
false in that case)
#minor-release
PiperOrigin-RevId: 359063793
There are two different patterns we use at the moment:
1. Call both deprecated and non-deprecated method from call site with
no default method implementation body.
2. Use default method of non-deprecated method to call deprecated
method.
Pattern 1 is easier to reason about as it makes the calls more explicit,
so changing all usages of pattern 2 to pattern 1.
PiperOrigin-RevId: 358769803
`ImaAdsLoader` will preload the first ad of a subsequent media item, but the
preloaded ad might not actually play because the user could seek to a non-zero
position in that media item (which could trigger playback of a midroll, not the
preroll). In this case, playback would get stuck because the midroll ad
expected to play after the seek would never load, because the IMA SDK expected
the preroll to play first.
Fix this behavior by discarding the preloaded ad break. If there isn't a seek,
the transition to the next media item is still seamless.
#minor-release
PiperOrigin-RevId: 357682510
This type is different to the selection reason, which is
dynamic (i.e., corresponds to the individual selected track,
which can change during playback). The static type is
exposed via TrackSelection, where-as the selection reason
will be internal to the core (i.e., player) module.
PiperOrigin-RevId: 357578201
Previously it was safe to query the first period in the timeline, but
now we support using the ads loader in concatenations we need to use
the current period index instead.
#minor-release
PiperOrigin-RevId: 357578003
ControlDispatcher and DefaultControlDispatcher also need
to move to common for the UI module. As does PlaybackPreparer,
although that will be removed entirely in a future release.
PiperOrigin-RevId: 356467394
Also allow the player's prepared ad media period durations array to exceed the
length of the loaded ad URIs array, as it's possible for the player to buffer
an ad media period fully at the point where it's known that an ad is coming up
but its URI is still unknown.
#minor-release
PiperOrigin-RevId: 356249284
In both cases it's deliberate that all excluded constants should use
the default branch. Furthermore, there are quite a lot of excluded
constants missing, so it's probably better to suppress the warning
than to include them all.
#minor-release
PiperOrigin-RevId: 355426749
This resolves the following constraint resolution issue when running our release script:
> Cannot find a version of 'org.chromium.net:cronet-api' that satisfies the version constraints:
Dependency path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'com.google.android.gms:play-services-cronet:17.0.0' --> 'org.chromium.net:cronet-api:72.3626.96'
Constraint path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'org.chromium.net:cronet-api:{strictly 72.3626.96}' because of the following reason: debugRuntimeClasspath uses version 72.3626.96
Dependency path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'org.chromium.net:cronet-embedded:76.3809.111' --> 'org.chromium.net:cronet-common:76.3809.111' --> 'org.chromium.net:cronet-api:76.3809.111'
#minor-release
PiperOrigin-RevId: 355414968
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
This change fixes a bug in CronetDataSource when it makes a Range
request but the server does not support Range requests and returns the
entire resource. Before the fix, the CronetDataSource would read more
bytes than the intended range.
PiperOrigin-RevId: 353614477
We normally wouldn't do this kind of thing, given CronetDataSourceFactory is
deprecated, but it's needed to change the cronet --> core dependency to a
cronet --> common dependency.
PiperOrigin-RevId: 353609198
The IMA SDK currently notifies `CONTENT_RESUME_REQUESTED` then
`CONTENT_PAUSE_REQUESTED` quickly afterwards when playing an ad for an initial
seek. This triggered the logic to skip VPAID ads added for Issue: #7832,
causing the ad to be skipped.
This change reverts the fix for that issue and extends the ad preload timeout
logic to cover the case of an initial seek as well. Incompatible VPAID ads will
still be skipped but only after the preload delay (this seems fine given that
they are documented not to be supported, and we are just making the failure
mode less bad on a best-effort basis!).
Issue: #8428
Issue: #7832
PiperOrigin-RevId: 353011270
This is not necessary when following the README.md but it is required if
libopus is under a symlink (and won't do any harm if it's not symlinked).
PiperOrigin-RevId: 351985185
- Support setting the user-agent in CronetDataSource
- Support setting the default user-agent in CronetEngineWrapper
- Use the underlying network stack's default user-agent by
default. Many applications will configure the underlying
CronetEngine or OkHttpClient with a user-agent that they
expect to be used throughout their app, so always overriding
this with our own default, on reflection, is not the best
thing to do!
Issue: #8395
PiperOrigin-RevId: 350921963
if responseCode and responseMessage ara available always throws an InvalidResponseCodeException instead of HttpDataSourceException, so in onPlayerError method the http status code and message can be used to decide what will be the next step.
*** Original commit ***
DataSource.open() throws if already opened.
Update DataSource implementations to throw an error if open() is called
when the DataSource is already open.
***
PiperOrigin-RevId: 348783425
Previously the `AdTagLoader` only had one listener which meant that updates
that should affect all periods with matching identifiers in the timeline only
affected the last-attached one. Fix this by having `AdTagLoader` track all its
listeners.
Issue: #3750
PiperOrigin-RevId: 347571323
It is more realistic for each source to have its own listener and to share
`TimelineWindowDefinition`s between them.
Issue: #3750
PiperOrigin-RevId: 347398769
The `AudioProcessor` interface requires that no more input is queued after
queueing end of stream, but `DefaultAudioSink` did queue more input and the
implementation of `SonicAudioProcessor` actually relied on this to drain output
at the end of the stream.
Fix this behavior by getting `Sonic` output in `getOutput` and having
`DefaultAudioSink` only queue input to processors that are not draining.
Also add TODOs to clean up audio processor implementations where the code
handles interaction that doesn't conform to the interface.
PiperOrigin-RevId: 345406478
This ensures we have full test coverage for proguard configs now.
The only configs not covered by tests are:
- IMA and OkHttp which copy recommended configs from the respective
library. I couldn't reproduce failures by removing them (and thus
couldn't write a test that ensures they are correct).
- Some dontwarn lines that just suppress warnings.
In addition, this change fixes a couple of related issues:
- Moved AV1 proguard config to correct module.
- Removed mentioning of deprecated ExtractorMediaSource from README
- Suppressed warning from IMA code that prevent proguarding under
strict rules
- Fixed wrong proguard exclusion in VP9 module.
- Moved FLAC exclusion (DefaultExtractorsFactory) to correct module.
- Added AlertDialog suppression for de-jetified code.
- Removed unusued dependency from UI module that causes large APK
size increase.
#exofixit
#minor-release
PiperOrigin-RevId: 344427532
These tests appear not to need an activity, and removing it means we don't need
to switch away from the deprecated `ActivityTestRule`.
#exofixit
PiperOrigin-RevId: 344037927
Null check warning was reported by //java/com/google/android/apps/gsa/staticplugins/silk/silkcast:silkcast_nullness_checker
//third_party/java_src/android_libs/exoplayer/v2/extensions/media2/src/main:library_nullness_test
PiperOrigin-RevId: 343939763
*** Original commit ***
Suppress warnings in preparation for Checker Framework 3.7.1 upgrade.
LSC: go/checker-lsc
Tested:
TAP train for global presubmit queue
http://test/OCL:342788973:BASE:342817196:1605636478036:6c558c0c
***
PiperOrigin-RevId: 343895651
This callback allows listeners to know when all simultanous changes
have been handled and the values reported through callbacks are
again completely consistent with value obtained from Player
getter calls.
PiperOrigin-RevId: 343476639
In preparation for adding support for ads in playlists:
- Make releasing a no-op if the instance was already released
- Remove null checks on non-null `adDisplayContainer` and `adsLoader`
- Move initializing the ads manager into a private method as it will need to be
called from two places soon.
- Misc other cleanup.
Issue: #3750
PiperOrigin-RevId: 341021493
In a later change, the AdPlaybackState will include the playing adsId (set by
the AdsLoader) and the ads loader will use this to determine what ad
information is associated with the playing/next periods, to allow loading ads
in playlists.
Apps can continue to pass just a URI for an ad tag with their MediaItem, in
which case the associated playlist will request that ad tag just and the same
state will be used for all occurrences of the ad tag.
This change has breaking changes to the AdsLoader interface and removes
deprecated ways of passing the ad tag, as it's very likely to go into a major
release anyway and not needing to handle the deprecated cases simplifies
ImaAdsLoader.
Issue: #3750
PiperOrigin-RevId: 340438580
This test is not run in presubmit as it was too flaky, and is currently broken
due to assets moving.
Also migrate off ImaPlaybackTest off deprecated APIs.
#minor-release
PiperOrigin-RevId: 340405666
In a later change ImaAdsLoader will use multiple AdTagLoaders.
This change shouldn't have any substantial changes in behavior (it's almost
entirely moving code around). An exception is that ImaSdkSettings is configured
when making a request rather than at construction time.
Issue: #3750
PiperOrigin-RevId: 339891712
ImaAdsLoader notified onEnded whenever an ad finished playing, but when an ad
is skipped in an ad pod we'd receive a playAd call before the player
discontinuity for skipping to the next ad. Fix this behavior by checking that
IMA's playing ad matches the player's playing ad before notifying onEnded.
#minor-release
PiperOrigin-RevId: 339424910
We rolled back the previous <unknown commit> because some of the nullness checking fixes broke the exoplayer2 tests. We submit this CL into the TAP Global Presubmit train (https://test.corp.google.com/OCL:337620582:BASE:338201100:1603283151742:36afd5a5) and make sure that this CL wouldn't break any other tests on google3.
PiperOrigin-RevId: 338267548
ExoPlayerImpl and CastPlayer repeat the same logic. Moving the listener
and event handling to a common util class allows to reuse the same code
and add unit tests for this logic.
The change is a functional no-op.
PiperOrigin-RevId: 337812358
The ExoPlayer receiver app id is a thin wrapper around the default receiver, so
there are no reasons for users not to depend on it. By having ExoPlayer users
refer to the ExoPlayer app id we can collect usage metrics.
PiperOrigin-RevId: 337516767
The 'implementation' dependency causes problems when resolving
ListenableFuture in contexts that also include the
com.google.guava:listenablefuture:1.0 dependency.
Issue: #7905
Issue: #7997
Issue: #7993
PiperOrigin-RevId: 337093024
This will reduce the amount of boilerplate required to pass the configuration
values around (especially in a planned future change when logic is factored out
of ImaAdsLoader).
PiperOrigin-RevId: 337058355
This is in preparation for supporting playlists of ads media sources using
ImaAdsLoader.
Existing ways of passing ad tags should still function but are deprecated (and
won't be supported with playlists).
Issue: #3750
PiperOrigin-RevId: 335618364
On receiving a fetch error for an ad that would otherwise play based on an
initial/seek position, the pending content position wasn't cleared which meant
that position reporting was broken after a fetch error. Fix this by always
clearing the pending position (if there was a pending position that will have
triggered the fetch error).
Also deduplicate the code for handling empty ad groups (fetch errors)
and ad group load errors.
Issue: #7956
PiperOrigin-RevId: 334113131
Since gradle 4.0, CMake imported libraries are bundled in the APK, so
manually bundling them causes a duplication which breaks the build.
Issue: #7906
PiperOrigin-RevId: 332012375
This is useful because ImaAdsLoader.getAdsLoader() can now return null
(before ads have been requested), and it avoids the app needing to get
an AdsManager to attach its listener.
PiperOrigin-RevId: 330907051
- Use a setter, which is consistent with how other optional
components are passed.
- Remove nesting where a provider provides another provider.
Since AdSupportProvider then only provides one thing, it
can be renamed to AdsLoaderProvider, which more clearly
expresses what it provides.
PiperOrigin-RevId: 330396334
This brings SessionPlayerConnector in line with other
components that use a ControlDispatcher in the ExoPlayer
library, all of which have a setter.
PiperOrigin-RevId: 329665767
To play slow motion streams where the audio has been recorded at
slower speeds, it is necessary to be able to resample (rather than
time-stretch) the audio. This change undeprecates back the previously
deprecated PlaybackParameters class to allow apps to set pitch.
PiperOrigin-RevId: 328703116
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
