Initialize default components lazily in ExoPlayer.Builder to avoid
redundant component instantiations, useful in cases where apps
overwrite default components with ExoPlayer.Builder setters.
The fields in ExoPlayer.Builder are wrapped in a Supplier (rather than
just making then nullable and initializing them in
ExoPlayer.Builder.build()) so that we maintain the proguarding
properties of this class. The exception is
ExoPlayer.Builder.AnalyticsCollector which became nullable and is
initialized in ExoPlayer.Builder.build() in order to use any Clock
that has been set separately with ExoPlayer.Builder.setClock().
#minor-release
PiperOrigin-RevId: 406345976
Only deprecated references remain.
Usages of the deprecated methods will be migrated in a follow-up change.
#minor-release
PiperOrigin-RevId: 405927141
Also add a setRenderersFactory() method, so that all constructor-provided
components can also be passed via setters.
This comment already appears on the constructor that takes all
components, but it applies to these ones as well.
PiperOrigin-RevId: 405917343
Our package-info.java files are annotated with @NonNullApi which results
in everything being non-null by default, so this annotation is never
needed.
#minor-release
PiperOrigin-RevId: 405864737
This has a few benefits:
* Aligns the Builder constructors with the setters
(setRenderersFactory is missing, but can be easily added in a
follow-up change).
* Allows DefaultMediaSourceFactory to be stripped by R8 and
makes the shrinking dev guide for the cases of providing a custom
MediaSourceFactory or directly instantiating MediaSource instances
less weird too.
#minor-release
PiperOrigin-RevId: 405632981
The static and dynamic metadata now build up in a list, such that when
the MediaMetadata is built, they are applied in an event order. This
means that newer/fresher values will overwrite older ones. The MediaItem
values are then applied at the end, as they take priority over any other.
#minor-release
PiperOrigin-RevId: 405383177
The current API exposes an `ImmutableMap` of
`TrackGroup` -> `TrackSelectionOverride`.
This has several disadvantages:
- A difficult to use API for mutation
(`ImmutableMap.Builder` doesn't support key removal).
- There is no track selection specific methods,
how the generic map API mapps to the selection override is not complex
but to obvious for a casual reader.
- The internal data type is exposed, making internal refactor difficult.
This was done to have the API ready as quick as possible.
When transitioning the clients to the map API in <unknown commit>,
it became clear that the map API was too verbose and not mapping
to the clients needs, so utility methods
were added to make operations clearer and more concise.
Nevertheless, having to use utility method to use easily and correctly
an API is not the sign of a good API.
This cl refactors the track selection API for several improvements:
- Add a type `TrackSelectionParameters` that encapsulate the internal
data structure (map currently).
- For iteration, expose as a list.
- Add a `Builder` for easy mutable operations.
- Add track selection specific methods to avoid having utilities functions.
- Those operations are the same as `DefaultTrackSelector.Parameters`
for easier migration. (`setOverride` was renamed to `addOverride`)
- Move `TrackSelection` classes outside of `TrackSelectionParameters`
as their own top level classes.
The migration of the client code is straightforward as most of it
were already using the previously mentioned utility functions
that are now native methods.
The full migration has not been done yet, and is pending on this cl approval.
PiperOrigin-RevId: 405362719
* @Reason is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations)
* Curly braces should be used for inline Javadoc tags: {@code ...}
(see http://go/bugpattern/InvalidInlineTag)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* 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/media/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: 404769260
Issue: #9392 reports occasional IllegalStateExceptions from release()
in crashlytics,`with no way to reproduce locally. It seems likely there
is a bug somewhere in DRM handling, and ideally we would find that and
fix it.
However we haven't been able to find the problem, and in the meantime
these exceptions cause the entire app to crash. Although this is
arguably useful from a debugging perspective, it's obviously a poor
experience for developers and users, since all we're actually trying to
do is release the session, so maybe we shouldn't strictly care that it's
already released?
This change replaces the exception with an error log, which might be a
useful debugging hint if we see other DRM unexpected behaviour due to
references to released sessions being held for too long.
PiperOrigin-RevId: 403942546
The new forcedSessionTrackTypes field was introduced in
<unknown commit>.
These usages are migrated in a follow-up change to add confidence that
the deprecated field continued to work correctly.
PiperOrigin-RevId: 403342893
Common houses DataSource as an interface for reading data,
but most of the concrete implementations are in ExoPlayer.
This means that in practice, if an app wants to use a module
that reads using DataSource (e.g. extractor), they may be
forced to depend on ExoPlayer as well to get a concrete
implementation (e.g. FileDataSource). This change moves the
DataSource implementations into common to resolve this.
PiperOrigin-RevId: 403222081
An upcoming change will modify ExoPlayer.Builder#build() to return
ExoPlayer, so any places that explicitly need a SimpleExoPlayer
instance should be using SimpleExoPlayer.Builder.
PiperOrigin-RevId: 403028312
Update the UI module, the demos and most other users
to make use of the new player TracksInfo and track
selection override APIs.
PiperOrigin-RevId: 402817857
Enable subtitle output in the PlaybackOutput and disable the text
renderer in the MkvPlaybackTest. Add WebvttPlaybackTest to test the
output of side-loaded WebVTT subtitles.
PiperOrigin-RevId: 402526588
*** Original commit ***
Migrate callers of ExoPlayer.Builder#build() to buildExoPlayer()
An upcoming change will update build() to return Player.
PiperOrigin-RevId: 401468532
In a future change it will be updated to return ExoPlayer
We no longer need separate methods to build Player and ExoPlayer, so
buildExoPlayer will be removed shortly.
PiperOrigin-RevId: 401441016
TracksInfo is very similar to
`MappingTrackSelector.MappedTracksInfo` with some
fields removed to simplify the Player API,
notably it doesn't expose the renderer concept.
A significant difference is the addition of a `selected` boolean
field which avoids having a separate `getCurrentTrackSelection`
API.
This cl is a part of the bigger track selection change,
splitted for ease of review.
In particular, the MediaSession implementation and UI usage
have been slitted in child cls.
Find all cls with the tag:
#player-track-selection
PiperOrigin-RevId: 400937124
This change makes asynchronous queueing non-experimental, it enables the
feature by default on devices with API level >= 31 (Android 12+) and
exposes APIs for apps to either fully opt-in or opt-out from the
feature.
The choice to use or not asynchronous queueing is moved out of
MediaCodecRenderer to a new MediaCodecAdapter factory, the
DefaultMediaCodecAdapterFactory. This is because, at the moment,
if an app passes a custom adapter factory to a MediaCodecRenderer and
then enables asynchronous queueing on it, the custom
adapter factory is not used but this is not visible to the user.
The default behavior of DefaultMediaCodecAdapterFactory is to create
asynchronous MediaCodec adapters for devices with API level >= 31
(Android 12+), and synchronous MediaCodec adapters on devices with older
API versions.
DefaultMediaCodecAdapterFactory exposes methods to force enable or force
disable the use of asynchronous adapters so that applications can enable
asynchronous queueing on devices with API versions before 31 (but not
before 23), or fully disable the feature. For applications that build
MediaCodecRenderers directly, they will need to create a
DefaultMediaCodecAdapterFactory and pass it to the renderer constructor.
For applications that rely on the DefaultRenderersFactory, additional
methods have been added on the DefaultRenderersFactory to control
enabling/disabling asynchronous queueing.
Issue: #6348
PiperOrigin-RevId: 400733506
Removes subtitle allow-list by using SubtitleDecoderFactory.DEFAULT.
When the format is unsupported, the extractor registers one track and
sends the format with the Format#sampleMimeType set to TEXT_UNKNOWN and
Format#codecs field set to the actual subtitle MIME type.
The TextRenderer will recognize this MIME Type as not supported which is
gonna be visible in the event log.
PiperOrigin-RevId: 400679058
It calls through to a deprecated method, which is unusual for a
convenience method, and the deprecated method has various
implementations. This allows for a smoother removal of stop(boolean)
and removes an obstacle for the ExoPlayer-SimpleExoPlayer merge.
Adds missing @Deprecated tags to some Players.
PiperOrigin-RevId: 400213422
Usages of the (already deprecated) Subtitle constructors were not
migrated, as it would require migrating to the Builder which is a more
involved change.
PiperOrigin-RevId: 400153139
If callers need an ExoPlayer instance they should use buildExoPlayer().
Also remove the @InlineMe annotation now these methods are no longer
equivalent.
PiperOrigin-RevId: 400143239
This moves `SelectionOverride` from `DefaultTrackSelector`
to `TrackSelectionParameters`.
It is then use to allow track selection override per
track selection array.
Note that contrary to
`DefaultTrackSelector.Parameters.selectionOverride`, the renderer
concept is not exposed.
This cl is a part of the bigger track selection change,
splitted for ease of review.
Find all cls with the tag:
#player-track-selection
PiperOrigin-RevId: 399933612
There are two very similar tests checking for release events,
one running with Robolectric and one instrumentation test.
The instrumentation test only adds the interaction with the player
to release it while the renderers are active. This same interaction
can be added to the Robolectric test as well.
This arguably improves the realism of the Robolectric test too
as we listen for real player events instead of simulating the same
events.
PiperOrigin-RevId: 399694869
Before releasing r2.15.0, we had a regression that crashed
PlaybackStatsListener. A change in the AnalyticsCollector made
it to send an additional AnalyticsListener.onEvents() callback after
calling Player.release() and AnalyticsListener.onEvents() appeared
to arrive with event times that were not monotonically increasing.
The AnalyticsListener.onEvents() callback that contained
AnalyticsListener.EVENT_PLAYER_RELEASED was called with a timestamp that
was smaller than event times of previously AnalyticsListener.onEvents()
calls.
A first fix changed the order of events being forwarded to
AnalyticsListener. Upon calling Player.release(), the AnalyticsCollector
would call AnalyticsListener.onPlayerReleased() and its associated
AnalyticsListener.onEvents() on the same stack call. This fix maintained
that event times are monotonically increasing, but made
AnalyticsListener.onPlayerReleased() be called earlier.
This change:
- Further changes AnalyticsCollector to ensure that
AnalyticsListener.onPlayerReleased() and its related
AnalyticsListener.onEvents() are the last callbacks to be called,
and the associated timestamp is bigger than previously reported
event times.
- Adds an instrumentation test to guard against the regression.
PiperOrigin-RevId: 399437724
The fix for Issue: #8776 was to release and null-out dummySurface if
it doesn't match the security level of the decoder. But it's possible
that this.surface is already set to this.dummySurface, in which case we
must also null out this.surface otherwise we will later try and re-use
the old, released DummySurface instance.
This logic already exists in MCVR#onReset, so I pulled it into a
releaseDummySurface() helper function.
Issue: #9476
#minor-release
PiperOrigin-RevId: 399420476
For Automotive devices, surround encodings can be supported via
the passthrough path. Therefore, include automotive in the allowed
device types in the isDirectPlaybackSupported checks. The automotive
system feature is checked, rather then UI_MODE_TYPE_CAR, because
the UI_MODE_TYPE_CAR can be force enabled via
android.app.UiModeManager.enableCarMode(), whereas FEATURE_AUTOMOTIVE
cannot be forced.
- If DownloadService is configured to run as a foreground service,
it will remain started and in the foreground when downloads are
waiting for requirements to be met, with a suitable "waiting for
XYZ" message in the notification. This is necessary because new
foreground service restrictions in Android 12 prevent to service
from being restarted from the background.
- Cases where requirements are not supported by the Scheduler will
be handled in the same way, even on earlier versions of Android.
So will cases where a Scheduler is not provided.
- The Scheduler will still be used on earlier versions of Android
where possible.
Note: We could technically continue to use the old behavior on
Android 12 in cases where the containing application still has a
targetSdkVersion corresponding to Android 11 or earlier. However,
in practice, there seems to be little value in doing this.
PiperOrigin-RevId: 398720114
The MIME type is currently required to select a SubtitleDecoder
implementation in the TextRenderer. Future changes might remove this
requirement, so we pre-emptively mark the field as @Nullable.
The change in SingleSampleMediaSource ensures the track still maps to
the TextRenderer, otherwise it shows up as unmapped. Passing null MIME
type to MediaItem.Subtitle constructor now results in this from
EventLogger:
TextRenderer [
Group:0, adaptive_supported=N/A [
[ ] Track:0, id=null, mimeType=text/x-unknown, language=en, supported=NO_UNSUPPORTED_TYPE
]
]
PiperOrigin-RevId: 398010809
Both license and provisioning requests could be considered 'DRM
requests', and these headers are only sent on license requests, so
rename them to reflect that.
The old field remains deprecated for backwards compatibility.
PiperOrigin-RevId: 397980021
The type is already UUID so there's no need to duplicate that info in
the field name, and 'scheme' is a widely used term throughout both
ExoPlayer and android.os.MediaDrm documentation.
The old field remains deprecated for backwards compatibility.
The MediaItem.DrmConfiguration.Builder#setUuid method is renamed
directly (without deprecation) because it's not yet part of a released
ExoPlayer version.
PiperOrigin-RevId: 397961553
This takes advantage of the new MediaItem.LiveConfiguration.Builder
This change will always allocate a new LiveConfiguration.Builder and
LiveConfiguration, but preserves the behaviour of keeping the same
MediaItem instance if no values have changed.
PiperOrigin-RevId: 397961427
This is known to silently drop the value. This setter is now deprecated
in favour of `MediaItem.Builder#setDrmConfiguration(MediaItem.DrmConfiguration)`,
which requires a UUID in order to construct the `DrmConfiguration`
instance.
Issue: #9378 tracks correctly propagating the DRM info out of
`DownloadRequest#toMediaItem`.
PiperOrigin-RevId: 397291013
The deprecated `Player.addListener(EventListener)`
is moved out of Player into its subclasses
(CastPlayer and ExoPlayer).
This is unlikely to break users because:
- the method has been deprecated in the last major version
- the method is still present in the major implementations
If an users is affected, they can either:
- use ExoPlayer instead of Player
- (recommended) switch to Player.Listener.
Additionally update the threading guarantees that did not
reflect the current implementation.
PiperOrigin-RevId: 397272144
* Avoid ActivityManager log spam by only calling startForeground once,
and subsequently updating the notification via NotificationManager.
* Tweak demo app service to make it a tiny bit easier to swap the Scheduler.
PiperOrigin-RevId: 397179398
The second getScheduler() call violates the documentation of
the class, which states that getScheduler() is not called if
foregroundNotificationId if FOREGROUND_NOTIFICATION_ID_NONE.
Presumably implementing subclasses would return null, in which
case this didn't do any harm, but we should make sure the
implementation behaves as documented regardless.
PiperOrigin-RevId: 397167603
*** Original commit ***
Ensure MediaSourceFactory instances can be re-used
This fixes DefaultDrmSessionManager so it can be used by a new Player
instance (by nulling out its reference to the playback thread, which is
unique per-Player instance). This only works if the
DefaultDrmSessionManager is 'fully released' before being used by the
second Player instance, meaning that the reference count of the manager
and all its sessions is zero.
#exofixit
Issue: #9099
***
PiperOrigin-RevId: 396861138
Previously the released preacquired sessions would start their keepalive
timeout, and so no additional resources would be freed in time for the
manager to retry the session acquisition.
This change adds an additional purge of keepalive sessions *after* the
preacquired sessions are released, which fixes the problem.
#exofixit
#minor-release
PiperOrigin-RevId: 396613352
This is was reported in #9257 where the PlaybackStatsListener may try to
access an emtpy ArrayList.
Issue: #9257
#minor-release
#exofixit
PiperOrigin-RevId: 396329373
This is a candidate fix for #8906. As mentioned in that issue,
negative positions within windows might be (kind of) valid in
live streaming scenarios, where the window starts at some
non-zero position within the period. However, negative positions
within periods are definitely not valid. Neither are positions
that exceed the period duration.
There was already logic in ExoPlayerImplInternal to prevent a
resolved seek position from exceeding the period duration. This
fix adds the equivalent constraint for the start of the period.
It also moves the application of the constraints into Timeline.
This has the advantage that the constraints are applied as part
of state masking in ExoPlayerImpl.seekTo, removing any UI flicker
where the invalid seek position is temporarily visible.
Issue: #8906
PiperOrigin-RevId: 395917413
The new name is consistent with the corresponding parameters to `onVolumeChanged`, `setDeviceVolume` and `onDeviceVolumeChanged`.
PiperOrigin-RevId: 395705288
This fixes DefaultDrmSessionManager so it can be used by a new Player
instance (by nulling out its reference to the playback thread, which is
unique per-Player instance). This only works if the
DefaultDrmSessionManager is 'fully released' before being used by the
second Player instance, meaning that the reference count of the manager
and all its sessions is zero.
#exofixit
#minor-release
Issue: #9099
PiperOrigin-RevId: 395490506
The C2 MP3 decoder produces an extra output buffer when draining after
end-of-stream is queued. This output buffer has a later timestamp than the last
queued input buffer so we need to calculate its timestamp to detect a stream
change in the correct position.
Before this CL we used the original input buffer timestamp as the largest
queued timestamp, which caused the stream change to be detected at the correct
position because the original input buffer timestamp was slightly larger than
the actual last output buffer timestamp. After this change we use exact
calculated timestamp as the largest queued timestamp. I manually verified
gapless continues to work on a device using the C2 MP3 decoder by comparing
output of the MP3 gapless and MP3 gapless stripped playlists in the demo app,
and that the last buffer timestamp now matches.
#exofixit
PiperOrigin-RevId: 395428928
C should only hold constants.
Also resolve the TODO in getErrorCodeForMediaDrmErrorCode(), and
annotate the deprecated methods with Error Prone's @InlineMe to
facilitate automated refactoring of callers.
PiperOrigin-RevId: 395244855
This CL contains integration of the ExoplayerCuesDecoder and the
SubtitleExtractor with the player. The SubtitleExtractor is integrated
inside the DefaultMediaSourceFactory. The flag was added to the
state of the DefaultMediaSourceFactory to let user decide between the
ProgressiveMediaSource and the SingleSampleMediaSource as a source for
subtitles. Choosing the ProgressiveMediaSource will cause data to flow
through the SubtitleExtractor and eventually the ExoplayerCuesDecoder.
PiperOrigin-RevId: 394500305
Empty buffer with flag C.BUFFER_FLAG_END_OF_STREAM is send at the end
of the stream. Handling that flag properly is necessary to make the
ExoplayerCuesDecoder work properly with components like TextRenderer.
PiperOrigin-RevId: 394472642
In the old version, the transcoder uses decoder.isEnded() alone as the criteria
to stop the encoding/muxing process. It's rectified to:
- On decoder ending, signal the encoder of EOS after writing all decoded frames to it.
- On encoder ending, write end track to muxer.
PiperOrigin-RevId: 393322114
Make this behaviour optional, so it can be disabled for
AnalyticsCollectorTest where we don't use
FakeExoMediaDrm.LicenseServer.
PiperOrigin-RevId: 393133721
This cl doesn't implement completely the API for
`ExoPlayerImpl` as
`onTrackSelectionParametersChanged` is not called.
The follow up cl adds `TrackSelectionParameters` in PlaybackInfo
to correctly propagate the change event and mask it.
Additionally `TrackSelectionParameters` is serialized as a Parcelable
for now. It is transitioned to bundleable in a follow up cl.
PiperOrigin-RevId: 392899918
- Android 12 will not allow our download service to be
restarted from the background when conditions that
allow downloads to continue are met. As an interim
(and possibly permanent) solution, we'll keep the
service in the foreground if there are unfinished
downloads that would continue if conditions were met.
- Keeping the service in the foreground requires a
foreground notification. Hence we need to be able to
generate a meaningful notification for this state.
PiperOrigin-RevId: 391969986
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
The prototype is built upon Transformer and took many references from
TransformerAudioRenderer.
Please take a look and we can discuss more details.
PiperOrigin-RevId: 390192487
The result is plumbed back to `MediaCodecRenderer` via a new
`DrmSession#requiresSecureDecoder` method.
This allows us to use the `MediaDrm#requiresSecureDecoder` method added
in Android 12:
https://developer.android.com/reference/android/media/MediaDrm#requiresSecureDecoder(java.lang.String)
This change also removes
`FrameworkMediaCrypto#forceAllowInsecureDecoderComponents`, replacing it
with equivalent logic in `FrameworkMediaDrm#requiresSecureDecoder`.
PiperOrigin-RevId: 389616038
Adding a CHANGE_FRAME_RATE_STRATEGY_ALWAYS strategy is
omitted from this commit, since adding it is more complicated
than just plumbing it through and leaving everything else
unchanged. Specifically, VideoFrameReleaseTimeHelper would
need updating to behave differently when such a strategy is
enabled. It currently calls setFrameRate in cases such as
pausing, seeking and re-buffering, on the assumption that
changes to the underlying display refresh rate will only be
made if they can be done seamlessly. For a mode in which
this will not be the case, it makes more sense to stick to
the content frame-rate when these events occur. It may also
make sense to only use explicit content frame-rate values,
and not those inferred from individual frame timestamps.
Finally, for adaptive content containing a mix of frame-rates,
it makes sense to use the maximal frame-rate across all
variants, and to avoid calling setFrameRate on switches from
one variant to another.
Applications that know the frame-rate of their content can
set ExoPlayer's strategy to CHANGE_FRAME_RATE_STRATEGY_OFF and
then use setFrameRate directly on the output surface. Note that
this is likely to be a better option for apps than anything we
could implement in ExoPlayer, because the application layer
most likely knows the frame-rate of the content earlier than
ExoPlayer does (e.g., to perform the disruptive mode switch
at the same time as an activity transition).
Adding CHANGE_FRAME_RATE_STRATEGY_ALWAYS will be deferred
until there's clear demand for it. In the meantime, we'll
recommend the alternative approach above.
PiperOrigin-RevId: 389610965
This CL moves SubtitleDecoder and all its dependencies
to common in order to enable using it in extractor
module while implementing SubtitleExtractor.
PiperOrigin-RevId: 388979021
This change removes ERROR_CODE_IO_NETWORK_UNAVAILABLE,
ERROR_CODE_IO_NETWORK_CONNECTION_CLOSED, and ERROR_CODE_IO_DNS_FAILED
in favor of keeping only ERROR_CODE_IO_NETWORK_CONNECTION_FAILED.
PiperOrigin-RevId: 388715972
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
This change aligns all the names for classes that are 'holders of static
methods' to be `ApiNN`. Classes that hold state are named meaningfully
based on that state.
PiperOrigin-RevId: 388641064
This CL addresses the github issue [#8946](https://github.com/google/ExoPlayer/issues/8964). That issue requests support for `font-size` CSS property in WebVTT subtitle format. This CL:
* Adds support for `font-size` property by extending capabilities of WebVTT `CssParser`. Implementation of `font-size` property value parsing is based on the one in `TtmlDecoder`.
* Adds unit test along with test file containing WebVTT subtitles with all currently supported `font-size` units.
#minor-release
PiperOrigin-RevId: 388423859
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.
PiperOrigin-RevId: 387367509
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 reason this was not an IO error code is that before other
IOExceptions were classified, this catch would grab non-IO error
codes, like ParserException. Now that we are getting closer to
the final state, we can assume IOExceptions are ok to classify
as IO error codes (unlike, for example, ParserExceptions or
DrmSessionExceptions).
PiperOrigin-RevId: 386496752
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
Before this fix, if DefaultDrmSessionManager.release() was called while
there was at least one 'external' session reference still active (i.e.
session.referenceCount > 1) then the manager will release it's reference
immediately but when the session's reference count subsequently drops to
1 (due to external references being released) the manager will schedule
a task to release its internal reference *again*.
This change fixes the problem by only scheduling the timed release if
the manager is unreleased. This ensures that the internal references
are only released once.
Issue: #9193
#minor-release
PiperOrigin-RevId: 385580741
* Constructors and methods with the same name should appear sequentially with no other code in between, even when modifiers such as static or private differ between the methods. Please re-order or re-name methods.
(see http://go/bugpattern/UngroupedOverloads)
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/media/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: 384877648
Also rename hasPrevious/Next to hasPrevious/NextWindow for consistency.
This makes it clearer what the difference between
seekToPrevious/NextWindow and seekToPrevious/Next is.
PiperOrigin-RevId: 384643373
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
In order to avoid doing the classification in ExoPlayerImplInternal. Note:
This only makes the constructor change. The error code assignment will
happen in an immediately following CL.
PiperOrigin-RevId: 383397729
MediaItem.mediaId used to default to the content URI, but this changed:
cc26a92e07
Before the mediaId change linked above, a playlist of different content
all with the same ad URI would play the ads for every item. After the
change the ad would only play once (because mediaId == "" for every
item, so they're all the same). This change restores roughly the
original behaviour by always considering both mediaId and the content
URI.
#minor-release
Issue: #9106
PiperOrigin-RevId: 382763618
Without this annotation it seems that `SimpleExoPlayer` effectively
'un-deprecates' the method, specifically:
* A usage of these methods isn't flagged by Android Studio if the
declared type is `SimpleExoPlayer` (up-casting to e.g.
`ExoPlayer.VideoComponent` results in the warning showing up).
* The `SimpleExoPlayer` javadoc doesn't mention this method is
deprecated:
https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/SimpleExoPlayer.html#addVideoListener(com.google.android.exoplayer2.video.VideoListener)
* The Metalava API output for `SimpleExoPlayer` doesn't show these
methods as deprecated.
PiperOrigin-RevId: 382756174
- 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
A no-op change that changes the signature of the onChunkLoadError method of the ChunkSource. Implementors can get the exclusion duration directly from the LoadErrorHndlingPolicy instead of receiving it as an argument of the callback.
PiperOrigin-RevId: 381102935
No-op change that adds the @FallbackType IntDef and changes the signature of getBlacklistDurationMsFor(LoadErrorInfo) to getExclusionDurationMsFor(@FallbackType, LoadErrorInfo).
PiperOrigin-RevId: 381075496
The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.
PiperOrigin-RevId: 380792251
This change parses the entire BaseURL element including DVB extension attributes, stores it in an instance of new BaseUrl class and puts it in a list of base URLs of the resulting Representation. The base url handling itself is still the same, which means that only the first base url is taken into account, just as before this change.
PiperOrigin-RevId: 380609495
Also change to explicitly track the provisioning session, which makes
the code easier to reason about than always using the zero'th element
of the list.
PiperOrigin-RevId: 380181453
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
As of [JDK-8247957](https://bugs.openjdk.java.net/browse/JDK-8247957), doclint
no longer supports html4.
Tested:
Some test failures are present, but the CL author has decided to mail the change anyway
PiperOrigin-RevId: 378819179
After refactoring MediaCodecAdapter.Factory to create configured and
started MediaCodecAdapters in a single operation, the
AsynchronousMediaCodecAdapter does not need to have separate methods to
configure and start, so they are merged. The CONFIGURED state is
removed.
PiperOrigin-RevId: 377519117
Add the `needsReconfiguration` API on the `MediaCodecAdapter` interface so that `MediaCodecRenderer` can reconfigure the `MediaCodec` in case a `MediaCodecAdapter` needs to be reconfigured immediately after being obtained from the `MediaCodecAdapter.Factory`.
PiperOrigin-RevId: 376944334
A renderer is disabled (without being reset) in two situations:
* When transitioning into a period that starts with a discontinuity
* When stopping the player with setForegroundMode(true)
Before this change the behaviour of `MediaCodecRenderer` when disabled
(but not reset) depended on whether the content being decoded had an
associated `DrmSession`:
* For content without an associated DRM session the MediaCodec instance
was kept alive.
* For content with an associated DRM session, the MediaCodec instance
was released. This was to prevent the DRM session from staying alive
and continuing to make license refresh network requests while the
player was stopped in 'foreground mode'.
This change removes the second bullet, and keeps MediaCodec instances
alive in both the secure and insecure case. This will result in the
DRM machinery making occasional license refresh network requests (at
a frequency defined by the license policy) while the player is stopped
and in 'foreground mode'. This network usage is considered to be a
'limited resource' as described by the `ExoPlayer#setForegroundMode`
javadoc.
This means that switches between secure content (or between secure and
clear content when `MediaItem.drmConfiguration.sessionForClearTypes`
indicates a secure decoder should be used for clear content) should
keep the same video decoder, thus avoiding the 'black flash' that occurs
on some devices when switching the surface away from a secure decoder.
Issue: #8842
#minor-release
PiperOrigin-RevId: 376825501
This change introduces a third 'state' for `DefaultDrmSessionManager`:
It's been fully released (prepareCount == 0) but at least one of its
sessions is still active.
In this state new acquisitions are rejected (`(pre)acquireSession()`
calls will fail) but the machinery to support the existing sessions
(ExoMediaDrm and MediaDrmHandler) is kept until they're all released.
This change will allow us to remove the TODO in MediaCodecRenderer
that resolves Issue: #8842.
PiperOrigin-RevId: 376193952
