Transformer's minimum API level is 21, where-as the
full library is still targeting 16. Hence we should
no longer include the transformer module in the
full library dependency.
#minor-release
PiperOrigin-RevId: 426958045
This is a breaking change if the annotation itself is in use in Kotlin
code. It's judged that the IntDefs in this commit are unlikely to be
referred to often in Kotlin code. This is because they're either:
- Related to esoteric parts of the library, or
- In a common part of the library but only returned from methods (and
never passed to callback methods).
A follow-up change will fix the positions of existing usages to match
this new config.
#minor-release
PiperOrigin-RevId: 426410237
This is not backwards compatible if the @SelectionReason annotation is
used in Kotlin code, but before this change there aren't many library
surfaces that return a value annotated with @SelectionReason, so it
seems relatively unlikely that it is in use in any/many apps.
A follow-up change will fix the positions of existing usages to match
this new config.
#minor-release
PiperOrigin-RevId: 426409877
The listener will automatically forward diagnostics info to the
Android platform. ExoPlayer.Builder gets a new setter that allows
to disable this feature if required.
#minor-release
PiperOrigin-RevId: 426099872
Some phone with limited memory can't allocate bigger
shared memory buffers.
This might or might not be related to Binder's 1M
transaction limit.
Tested on Pixel 4 by setting the minimum buffer size to
1h.
https://github.com/google/ExoPlayer/issues/9712
#minor-release
PiperOrigin-RevId: 425324536
Enforcing the correct thread usage has been enabled since 2.13.0.
Opting-out of this enforement is dangerous as it can hide very hard
to debug bugs.
PiperOrigin-RevId: 424815808
If muxerWrapper.release() was throwing an exception, the progress state
was not updated and getProgress could throw an exception.
#minor-release
PiperOrigin-RevId: 424696783
When the decoder output buffer was partially read, a call to
Codec.getOutputBuffer() was returning the same buffer, but with the
position reset to 0. The reason was that, in
Codec.maybeDequeueAndSetOutputBuffer(), mediaCodec.getOutputBuffer()
was called with the same buffer index (L350 in old rev), even though
there was already a buffer available (outputBufferIndex >=0). This
change avoids calling mediaCodec.getOutputBuffer() if the previous
buffer has not been released.
#minor-release
PiperOrigin-RevId: 424612197
Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.
The new class is easily configurable and highly tested.
Manual test was used to catch any regression.
https://github.com/google/ExoPlayer/issues/8891
PiperOrigin-RevId: 424602011
Ad playback shouldn't be affected by manual speed adjustments set
by the user. This change enforces unit speed for ad playback.
Issue: google/ExoPlayer#9018
PiperOrigin-RevId: 424546258
Issue: google/ExoPlayer#9775
We got a few issues for this on GH already. Some RTSP servers do not provide
track timing in PLAY responses, or the timings are invalid.
Missing timing means the RTSP stream is not seekable. Added method to
1. Update the timeline that seek is not possible
2. Report read discontinuity so that playback can start from the beginning.
PiperOrigin-RevId: 423281439
This change adds more standard metadata fields to Cast metadata including the artwork URL that makes the cast device show the artwork in the Cast route dialog (https://screenshot.googleplex.com/uj4n4Jqd7it9bob) and the Cast device.
This change also discriminates between media with an audio MIME type and others. For audio MIME type the Cast metadata is set to MEDIA_TYPE_MUSIC_TRACK which changes the layout and shows artwork and additional audio meta data to be displayed (https://screenshot.googleplex.com/ASy3KDcsTdJDM2T).
Issue: google/ExoPlayer#9663
PiperOrigin-RevId: 422589957
Adaptive video and audio selections will be limited to formats with
the same level of DecoderSupport and HardwareAccelatationSupport, unless
specifically allowed by new flags.
If different levels of decoder support are available, prefer primary
over fallback decoders and hardware-accelerated over software decoders
(in this order). For video, also prefer more efficient codecs, if both
are supported by hardware-accelerated primary decoders.
Issue: google/ExoPlayer#4835
Issue: google/ExoPlayer#9565
PiperOrigin-RevId: 422345048
This change moves the video track selection to the generic
selection method introcuced for audio and text. This ensures
we can apply the same criteria for fixed and adaptive video
track selections. Implicitly, this reorders the preferences
for adaptive tracks to give non-quality preferences (like
preferred MIME type or preferred role flags) a higher priority
than number of tracks in the selection.
Issue: google/ExoPlayer#9519
PiperOrigin-RevId: 422310902
Live speed adjustment is used for all live playback at the moment,
but has no user visible effect if the media is not played with low
latency. To avoid unnecessary adjustment during playback without
benefit, this change restricts the live speed adjustment to cases
where either the user requested a speed value in the MediaItem or the
media specifically defined a low-latency stream.
Issue: google/ExoPlayer#9329
PiperOrigin-RevId: 421514283
The media codec renderers have fallback logic in getDecoderInfos
to assume that E-AC3 decoders can handle the 2D version of E-AC3-JOC and
that H264/H265 decoders can handle some base layer of Dolby Vision
content. Both fallbacks are useful if there is no decoder for the
enhanced Dolby formats.
Both fallbacks are not applied during track selection at the moment
because the separate MediaCodecInfo.isCodecSupported method verifies
that the mime type corresponding to format.codecs is the same as the
decoder mime type (which isn't true for the fallback case).
To fix the fallback logic, we can just completely remove this additional
check because it's not needed in the context of this method that is only
called after we already established that the decoder can handle the
format.sampleMimeType.
In addition, we need to map the Dolby Vision profiles to the equivalent
H264/H265 profile to make the codec profile comparison sensible again.
PiperOrigin-RevId: 420959104
This method has been deprecated since 2.12.0 ([commit](d1bbd3507a)).
Also remove
DashMediaSource.Factory#setLivePresentationDelayMs(long, boolean), this
method has been deprecated since 2.13.0 ([commit](41b58d503a)).
PiperOrigin-RevId: 420719877
The `main` role distinguishes a track from an `alternate`, but unlike
`SELECTION_FLAG_DEFAULT` it doesn't imply the track should be selected
unless user preferences state otherwise. e.g. in the case of a text
track, the player shouldn't enable subtitle rendering just because a
`main` text track is present in the manifest.
The `main`/`alternate` distinction is still available through
`Format.roleFlags` and the `ROLE_FLAG_MAIN` and `ROLE_FLAG_ALTERNATE`
values.
This behaviour was originally [added in 2.2.0](7f967f3057),
however at the time the `C.RoleFlags` IntDef did not exist. The IntDef
was [added in 2.10.0](a86a9137be).
PiperOrigin-RevId: 418937747
Before this change we checked whether the playback state and playWhenReady have changed when the state from the cast device arrived. If we detected such a change we called the listener callback `onIsPlayingChanged`. However, in the case when `setPlayWhenReady(boolean)` is called on 'CastPlayer', we mask the change in `playWhenReady`, then send the play/pause request to the cast device and when the state from the cast device arrives we never detect a change because we have already masked `playWhenReady`.
This change now moves the check for `isPlaying` to the same place where the state and playWhenReady is updated, so we call the `onIsPlayingChanged` callback in either case, when masking or when a changed state from the server arrives.
Issue: google/ExoPlayer#9792
PiperOrigin-RevId: 418483509
There is an open Gradle bug that dependencies with AARs are not marked
as such in the created POM files (https://github.com/gradle/gradle/issues/3170).
This causes issues building ExoPlayer with Maven POMs only.
(Issue: google/ExoPlayer#8353).
This change adds the workaround suggested on the Gradle bug until
the bug is fixed. As we have a mixture of JAR and AAR dependencies,
we need to maintain a lookup table to know which dependencies have AARs.
The current code throws when a new dependency is added and it's not
classified.
#minor-release
PiperOrigin-RevId: 417797407
Some have been deprecated since 2.13.0
([commit](5b9fa7d7d9)):
* `setDrmSessionManager(DrmSessionManager)`
* `setDrmHttpDataSourceFactory(HttpDataSource.Factory)`
* `setDrmUserAgent(String)`
And the rest have been deprecated since 2.12.0
([commit](d1bbd3507a)):
* `setStreamKeys(List<String>)`
* `createMediaSource(Uri)`
PiperOrigin-RevId: 417622794
We check the fraction of the available duration we have already
buffered for live streams to see if we can increase the quality.
This fraction compares against the overall available media duration
at the time of the track selection, which by definition can't include
one of the availabe chunks (as this is the one we want to load next).
That means, for example, that for a reasonable live offset of 3 segments
we can at most reach a fraction of 0.66, which is less than our default
threshold of 0.75, meaning we can never switch up.
By subtracting one chunk duration from the available duration, we make
this comparison fair again and allow all live streams (regardless of
live offset) to reach up to 100% buffered data (which is above our
default value of 75%), so that they can increase the quality.
Issue: google/ExoPlayer#9784
PiperOrigin-RevId: 416791033
Before the introduction of the MediaCodecAdapter, users could get
access directly to the MediaCodec instance from
MediaCodecRenderer.getCodec() and then retrieve the codec metrics.
This change exposes MediaCodec.getMetrics() on the MediaCodecAdapter.
Issue: google/ExoPlayer#9766
#minor-release
PiperOrigin-RevId: 416343023
*** Original commit ***
Make audio track min buffer size configurable.
Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.
The new class is easily configurable and highly tested.
Manual test was used to catch any regression.
https://github.com/google/ExoPlayer/issues/8891
***
PiperOrigin-RevId: 415469179
Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.
The new class is easily configurable and highly tested.
Manual test was used to catch any regression.
https://github.com/google/ExoPlayer/issues/8891
PiperOrigin-RevId: 415268938
The color set via textAppearance is overridden by any non-null
textColor set directly on the style. We always want the specific
properties the textAppearance specifies, so set them directly to
prevent them from being overridden.
#minor-release
Issue: google/ExoPlayer#9765
PiperOrigin-RevId: 414967143
`DefaultAudioSink` already has 3 telescoping
constructors and an other one would be have been
needed to add a buffer size tuning option.
PiperOrigin-RevId: 414703366
It's been observed that some devices fail when releasing a secure codec
attached to a surface and immediately trying to create a new codec
(secure or insecure) attached to the same surface. This change catches
all exceptions thrown during codec creation, sleeps for a short time,
and then retries the codec creation. This is observed to fix the problem
(we believe this is because it allows enough time for some background
part of the previous codec release operation to complete).
This change should have no effect on the control flow when codec
creation succeeds first time. It will introduce a slight delay when
creating the preferred codec fails (while we sleep and retry), which
will either delay propagating a permanent error or attempting to
initialize a fallback decoder. We can't avoid the extra delay to
instantiating the fallback decoder because we can't know whether we
expect the second attempt to create the preferred decoder to succeed or
fail. The benefit to always retrying the preferred decoder creation
(fixing playback failures) outweighs the unfortunate additional delay
to instantiating fallback decoders.
Issue: google/ExoPlayer#8696
#minor-release
PiperOrigin-RevId: 414671743
Using chunkless preparation greatly improves start up time if the master
playlist declares CODECS for the renditions. Hence, we turn this on
by default as it benefits most well-defined HLS master playlists.
The only known reason why developers may want to turn this feature off is
when the renditions contain muxed closed-caption tracks that are not
declared in the master playlist. So this change also updates the documentation
and RELEASENOTES to point out this caveat.
PiperOrigin-RevId: 413950036
Allowing duplicate groups caused some other code working with the
array to use reference equality comparison. This is error-prone,
easily forgotten (e.g. when using the TrackGroups in a map) and
causes bugs when TrackGroups are serialized to disk or to another
process.
All TrackGroups created by ExoPlayer are already unique and custom
code creating TrackGroupArrays with identical groups can easily
distringuish them by adding an id to each group.
Issue: google/ExoPlayer#9718
PiperOrigin-RevId: 413617005
This will remove the need to implement compat code handling very old API
versions where some symbols are not available, and it reduces the burden of
dealing with media framework issues around concurrent codec usage that are
worse on older API versions. Top apps that we've surveyed as potential users
for transformer library features are using API 21 or later.
PiperOrigin-RevId: 413341540
Currently we prefer technical preferences set in the Parameters over
content preferences implied by the media. It proably makes more
sense in the opposite order to avoid the situation where a
non-default track (e.g. commentary) is selected just because it
better matches some technical criteria.
Also add comments explaining the track selection logic stages.
PiperOrigin-RevId: 412840962
And also tweak existing role flag logic to strictly prefer perfect
matches over partial matches.
Caveat: Video role flags only supported for fixed track selections
(same issue as Issue: google/ExoPlayer#9519).
Issue: google/ExoPlayer#9402
PiperOrigin-RevId: 412292835
After removing the deprecated call to player.stop(/* reset= */ true) and instead using two calls to the player, overridding stop in a ForwardingPlayer does not help to avoid clearing the player. To remove the deprecation we need an option so that users who want not to clear the player have a way to do so.
PiperOrigin-RevId: 411518090
The player will not play ads in final states (played, skipped, error)
again. To allow ads loader customizations to play ads again, we can
add a method that resets the state back to available or unavailable
(depending on whether we have the URI for the ad).
Issue: google/ExoPlayer#9615
PiperOrigin-RevId: 411042842
Currently, DrmSessionManager takes player specific values (= the
playback looper) through (pre)acquireSession calls and requires
the caller to pass in the same values every time.
Instead, we can configure the DrmSessionManager for playback with
a player once before it's being used. We can't simply extend the
prepare() method as prepare may be called before the player is
created to prewarm the DrmSessionManager.
The new method also takes a PlayerId which is bound to the lifetime
of the player similar to the playback looper.
To avoid breakage of custom MediaSources with DRM, we can keep the
old the SampleQueue.createWithDrm method as deprecated.
PiperOrigin-RevId: 410998240
Populate ICY headers into MediaMetadata so that they can
propagate to the app via AnalyticsListener#onMediaMetadataChanged().
This change copies IcyHeaders.name into MediaMetadata.description
and IcyHeaders.genre into MediaMetadata.genre.
Note: MediaItem.metadata maintain their precedence and overwrite any
ICY headers parsed.
Issue: google/ExoPlayer#9677
#minor-release
PiperOrigin-RevId: 410495676
We already parse essential and supplemental properties from the
Representation, but don't add them to our Representation class so that
they can be accessed by users.
Issue: google/ExoPlayer#9579
PiperOrigin-RevId: 409961990
When we have multiple overrides for TrackGroups associated with
one renderer, we need to look at all of them to find the non-empty
one. Empty ones should only be used to remove previously selected
tracks for this group and otherwise be ignored.
Currently this is broken because the first override (no matter if
it's empty or not) is used as the final selection for this renderer.
Issue: google/ExoPlayer#9649
#minor-release
PiperOrigin-RevId: 407792330
Add protected method DefaultRenderersFactory.getCodecAdapter(), so that
subclasses of DefaultRenderersFactory that override
buildVideoRenderers() or buildAudioRenderers() can access the
DefaultRenderersFactory codec adapter factory and pass it to
MediaCodecRenderer instances they may create.
#minor-release
PiperOrigin-RevId: 407345431
Where this introduced an inconsistency (e.g. assigning to something
called `windowIndex`), I generally renamed the transitive closure of
identifiers to maintain consistency (meaning this change is quite
large). The exception is code that interacts with Timeline and Window
directly, where sometimes I kept the 'window' nomenclature.
#minor-release
PiperOrigin-RevId: 407040052
Test file produced with:
$ MP4Box -add "sample.mp4#video:colr=nclc,1,1,1" -new sample_18byte_nclx_colr.mp4
And then manually changing the `nclc` bytes to `nclx`.
This produces an 18-byte `colr` box with type `nclx`. The bitstream of
this file does not contain HDR content, so the file itself is invalid
for playback with a real decoder, but adding the box is enough to test
the extractor change in this commit.
(aside: MP4Box will let you pass `nclx`, but it requires 4 parameters, i.e. it
requires the full_range_flag to be set, resulting in a valid 19-byte colr box)
#minor-release
Issue: #9332
PiperOrigin-RevId: 405842520
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
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 possibilities to set a ControlDispatcher have been removed in
<unknown commit> so that the ControlDispatcher is always a
DefaultControlDispatcher.
PiperOrigin-RevId: 403327092
*** Original commit ***
Rollback of 8ed6c9fcf5
*** Original commit ***
Fix capitalization of language in track selector
Issue: #9452
***
***
PiperOrigin-RevId: 400942287
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
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
- 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
Issue: #9430
The current supported SDP (RFC2327) spec only allows for alpha-numeric
characters in the attribute-field. RFC4566 (section 9, token type) allowed
extra characters, and this CL adds the support.
PiperOrigin-RevId: 397301173
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
This was originally reported on #9390. There was a bug that when HLS
loads failed, the player would endlessly retry and never fail with a
player error.
This change fixes a bug in HlsSampleStreamWrapper.onPlaylistError()
which would return true for a playlist whose load encountered an error
but could not be excluded, whereas the method should return false.
Issue: #9390
#minor-release
PiperOrigin-RevId: 397045802
*** 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 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
Instead of selecting the base URL initially or when a load error occurs, it is now selected when a chunk or initialization chunk is created. The selected base URL is then assigned to `RepresentationHolder.lastUsedBaseUrl` that is excluded in case of a load error. For a next chunk another base URL will be selected by using the `BaseUrlExclusionList`.
#minor-release #exo-fixit
PiperOrigin-RevId: 395721221
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
I think this has been broken since 617267bfcf (which was trying to fix
the same problem).
This change initializes `rootDir` to always be the current project (i.e. ExoPlayer)
directory. From the [Gradle docs](https://docs.gradle.org/current/userguide/working_with_files.html#sec:single_file_paths):
> What happens in the case of multi-project builds? The file() method
> will always turn relative paths into paths that are relative to the
> current project directory, which may be a child project.
We can also then remove exoplayerRoot completely and simplify the local
dependency instructions.
* #minor-release
* #exofixit
* Issue: #9403
PiperOrigin-RevId: 395478121
Some server will send partial URIs in the RTP-Info header, while the RTSP spec
requires absolute URLs.
Issue: #9346
#exofixit
PiperOrigin-RevId: 395452741
- Fix focus when pausing and resuming
- Prevent repeated readout of the playback position when paused
#exofixit
#minor-release
Issue #9111
PiperOrigin-RevId: 395301765
The current detection logic checks that the two byte terminator starts
at an even position in the ID3 data, where-as it should check that it
starts at an even position relative to the start of the string.
#minor-release
#exofixit
Issue: #9087
PiperOrigin-RevId: 395274934
StyledPlayerControlView was checking whether the player is an ExoPlayer
instance to set the track selector. This means that, if apps were
wrapping an ExoPlayer in a ForwardingPlayer (to replace a
ControlDispatcher for example), the track selector wasn't set anymore.
#minor-release
PiperOrigin-RevId: 391776305
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
Issue: #9254
#minor-release
We used to allow only alphanumerical characters in session id. The spec also
allows "$", "-", "_", ".", "+" (RFC2326 Sections 3.4 and 15.1).
PiperOrigin-RevId: 388873742
For audio-only playlists, when formats are communicated to the app with
AnalyticsListener.onDownstreamFormatChanged(), the passed MediaLoadData
do not indicate this is an audio track and therefore the
PlaybackStatsListener cannot derive audio format-related information.
This change sets the main SampleStreamWrappers track type to AUDIO, if
the master playlist contains only audio variants.
Issue: #9175
#minor-release
PiperOrigin-RevId: 388676060
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
Using all lower case RTSP headers is perfectly valid, as the spec mandates case
insensitively. However, some RTSP servers do not implement the RTSP spec
closely and does not recognize the lower case headers. This change aims
at using the header names as defined in the RTSP spec to maximize compatibility.
Issue: #9182
PiperOrigin-RevId: 386224566
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
* Add release note for `RtspMediaSource.Factory.setTimeoutMs()`
* Remove mention of what we don't support (any such list is necessarily non-exhaustive)
* Remove markdown quote character ('>')
PiperOrigin-RevId: 385143574
This values won't be configurable from the UI anymore once the
DefaultControlDispatcher is removed.
They can be configured in the Player or by using a ForwardingPlayer.
PiperOrigin-RevId: 385113498
Issue: #9183
RFC2326 Section C.1.1 specifies that the URI to identify a track can be either
absolute (like rtsp://example.com/path) or relative (like "path"). Currently
we don't handle absolute URI, and this CL is to add the support.
Note though, we don't currently use the Content-Base or Content-Location
headers for the session URI.
PiperOrigin-RevId: 384649818
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
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
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
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
Until now, we have stuck with the 3.12 long-term branch so as
to keep support for older API levels. However, this means that
the version we're using is 2.5 years old at this point. The
3.12 branch will stop receiving critical updates in December
2021.
Since use of the OkHttp extension is optional anyway, it seems
preferable to move to a modern version of OkHttp at this point.
PiperOrigin-RevId: 381465269
No-op change that adds the @FallbackType IntDef and changes the signature of getBlacklistDurationMsFor(LoadErrorInfo) to getExclusionDurationMsFor(@FallbackType, LoadErrorInfo).
PiperOrigin-RevId: 381075496
The problem occurs when the primary media playlist URL switches
from one whose latest snapshot has not yet got the ended tag, to
one whose latest snapshot already has the ended tag. In this case:
- We trigger a redundant load of the ended playlist.
- When the redundant load completes,
MediaPlaylistBundle.processLoadedPlaylist detects that the
playlist is unchanged from the one it already has, and so
doesn't call onPlaylistUpdated.
- PrimaryPlaylistListener.onPrimaryPlaylistRefreshed is never
called with the new primary. Hence the externally visible primary
is still the one that hasn't ended. HlsMediaSource therefore thinks
the event hasn't ended, which in turn prevents the player from
transitioning to the ended state.
This commit detects when the new primary already has the ended tag.
In this case, we call onPrimaryPlaylistRefreshed directly and remove
the unnecessary playlist load.
Issue: #9067
#minor-release
PiperOrigin-RevId: 380680532
The glitches were introduced in:
https://github.com/google/ExoPlayer/commit/6c31e34528
The problem is that Listener.onEvents is called in a later looper iteration
than the listener methods that were previously used. This created a gap on
the main thread between the UI component dispatching a seek operation to the
player, and onEvents being called to update the progress bar's position.
At the start of this gap the progress bar is rendering the new position,
but its position member variable is still set to the old position. If the
progress bar is re-drawn by another message on the main thread within the
gap, it will briefly show the old position until onEvents is called.
There are multiple possible fixes to this, and the best one is probably to
modify ListenerSet to remove the gap. That's high risk though, so for now we
fix the flicker by always updating the progress immediately after the seek
is dispatched, in addition to when onEvents is called.
Issue: #9049
#minor-release
PiperOrigin-RevId: 380678388
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
Note that this removes a workaround for malformed content, in which the
track_ID is set incorrectly. It's unclear there was sufficient reason to
implement that workaround, and so it's preferable to remove it, rather
than implementing the concept of unrecognized tracks, which would be
needed to keep it and to also fix this issue.
Issue: #9056
#minor-release
PiperOrigin-RevId: 379506261
`SurfaceTexture` provides a transform matrix with each buffer. Previously
gldemo ignored this but it is important to apply it to have the video render
properly.
The transformation matrix from the surface texture includes flipping so this
change removes the hard-coded flipping from `a_texcoord`.
Issue: #8992
#minor-release
PiperOrigin-RevId: 377271389
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
Many of the setters are ignored unless others are set - this change:
* Lists these conditions exhaustively.
* Uses more concise language to avoid overshadowing the main details
of what the setter sets.
* Tweaks the language from 'is ignored' to 'shouldn't be called', to
open up the future possibility of throwing an error if these are
called without the 'required' setter also being present (see
Issue: #8957).
#minor-release
PiperOrigin-RevId: 376162385
Authentication sequence in RTSP:
- Server replies "Unauthorized" to our DESCRIBE request, and includes the
necessary information (i.e. realm, digest nonce, etc) in WWW-Authenticate
header
- After `RtspClient` receives the response, we
- Parse the WWW-Authenticate header, stores the auth info. The info is saved
for all further RTSP requests (that all need to carry authorization headers)
- send the second DESCRIBE request with the Authorization header.
#minor-release
PiperOrigin-RevId: 376116302
We need to avoid reading and skipping into preload chunks as they
may need to be discarded. The current code iterates over all chunks,
but this can be simplified by just checking the last chunk knowing
that the preload chunk must always be the last one.
As a result, we avoid calling getFirstSampleIndex on all chunks. This
is a bug since the method is not allowed to be called for chunks
that have been spliced in. This still leaves the smaller issue of
potentially calling this method for spliced-in preload chunks, which
will be solved separately.
Issue: #8937
#minor-release
PiperOrigin-RevId: 375053638
Gradle warns against passing a relative path to `new File(String)`:
https://docs.gradle.org/current/userguide/working_with_files.html#sec:single_file_paths
This change fixes all usages of `exoplayerRoot` to pass it to Gradle's
`Project.file()` first, which returns an absolute `File`.
To reproduce the problem in Issue: #8927:
1. Checkout ExoPlayer git project, to e.g. `~/ExoPlayer/exoplayer-git`
2. Create a new Android Studio project in e.g. `~/AndroidStudioProjects/exoplayer-test`
3. Edit the new project's `settings.gradle` file as described in
https://github.com/google/ExoPlayer/blob/release-v2/README.md
using a relative path for `exoplayerRoot`:
```
gradle.ext.exoplayerRoot = '../../ExoPlayer/exoplayer-git'
```
4. In a shell:
```bash
$ cd ~/AndroidStudioProjects/exoplayer-test/app
$ ../gradlew build
```
(Step 4 is important, it seems running `./gradlew` from the project root
doesn't trigger the relative path problem)
This change fixes the problem, and also works with `exoplayerRoot` as a
`File` or `Path` object. `String`, `File` and `Path` all work with relative or
absolute paths:
```
gradle.ext.exoplayerRoot = '/home/ibaker/ExoPlayer/exoplayer-git'
gradle.ext.exoplayerRoot = '../../ExoPlayer/exoplayer-git'
gradle.ext.exoplayerRoot = new File('/home/ibaker/ExoPlayer/exoplayer-git')
gradle.ext.exoplayerRoot = new File('../../ExoPlayer/exoplayer-git')
gradle.ext.exoplayerRoot = Paths.get('/home/ibaker/ExoPlayer/exoplayer-git')
gradle.ext.exoplayerRoot = Paths.get('../../ExoPlayer/exoplayer-git')
```
Note: The Path versions above require importing `java.nio.file.Paths`
and changing the `apply from:` line in the project's settings.gradle
file to something like:
```
apply from: file(gradle.ext.exoplayerRoot.resolve('core_settings.gradle'))
```
It's assumed that a project wanting to pass a `Path` will make these
changes.
Issue: #8927
PiperOrigin-RevId: 374421627
In Android 12 mutability flags have to be set on PendingIntents. If they are not, and the app targets Android 12, then the app will be crashed by the system.
PiperOrigin-RevId: 373427591
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
All `add*Listener` and `add*Output` methods are
deprecated in favor of `addListener`.
As for the class themselves `VideoListener` and
`AudioListener` are not used internaly by ExoPlayer,
`VideoRendererEventListener`
and `AudioRendererEventListener` are use in their
place.
As a result `VideoListener` and `AudioListener`
can be deprecated in favor `Listener`.
On the other hand `TextOutput` and `MedataOutput`
are used both in the player interface and internally in
renderers.
This means that those class can't be deprecated.
There usage in the public interface are indirectly
deprecated as their is no way to use them without
using the deprecated `add*Output`.
Thus it's not an issue that the class themselves are
not deprecated.
#minor-release
PiperOrigin-RevId: 371318268
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8858
Fix bug in text alignment inheritance where child does not correctly inherit ancestor's setting
@icbaker
Merge 70eb4bceb73b3f07e2f8d545b4fa7961189ac52a into 45616f916b
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/ExoPlayer/pull/8877 from dlafayet:multirowalign-cue d942b50a40525fea5d11b35a33d3bbc512550960
PiperOrigin-RevId: 371306966
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
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
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 protected visibility causes problems in Kotlin (Issue: #8830) and
also prevents a subclass of AdaptiveTrackSelection.Factory that isn't
nested inside a subclass of AdaptiveTrackSelection (in both Java and
Kotlin).
#minor-release
PiperOrigin-RevId: 369468841
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
This change moves the responsibility of creating, configuring and starting the MediaCodec from the MediaCodecRender to the MediaCodecAdapter.Factory.
This move allows ExoPlayer's client to decide how and when codecs are created and/or reused.
To allow the move, this CL replaces MediaCodecRenderer.ConfigureCodec with MediaCodecRenderer.getCodecConfiguration
PiperOrigin-RevId: 369273887
*** 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 properties of SphericalGLSurfaceView (e.g., setDefaultStereoMode)
are not plumbed through the PlayerView components, and it doesn't scale
to plumb through all properties of all of the SurfaceView types.
Applications can instead do:
```
((SphericalGLSurfaceView) playerView.getVideoSurfaceView())
.setUseSensorRotation(useSensorRotation);
```
PiperOrigin-RevId: 368196537
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
- Take centerControls padding into account to prevent switching to
minimal mode too soon
- Disable clipping to padding to avoid the edges of controls from
being clipped as the view gets smaller
Issue: #8763
PiperOrigin-RevId: 366966298
This ensures BUFFER_FLAG_DECODE_ONLY is set on samples that are
before the playback start position, in the case that the queue
is created after the start position is set.
#minor-release
PiperOrigin-RevId: 366249188
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
