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
This ensures we test the API level specific logic, in particular
around 5G-NSA detection.
Robolectric has a remaining bug that it doesn't support listening
to service state changes. Hence, we need to ignore some tests on
these API levels still until this is fixed.
PiperOrigin-RevId: 421505951
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
SampleQueues may be released in the context of a finally block
after an out of memory error. Allocating in that scenario can
throw yet a new OutOfMemoryError. By safely releasing SampleQueue
memory, we increase the possibility of handling the error
gracefully.
PiperOrigin-RevId: 420859022
The draw method was disabling vertex attrib arrays but not re-enabling them. Remove the call to disable the vertex attrib arrays so that then remain enabled after the program is created.
Manually verified by setting the surface type to spherical in the demo app and playing a spherical sample video.
Issue: google/ExoPlayer#9782
PiperOrigin-RevId: 420707503
* @Override is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs. @CryptoType is a TYPE_USE annotation, so should appear after modifiers and directly before the type.
PiperOrigin-RevId: 418811744
This more closely matches the pattern we have for all implementations
except DefaultMediaSourceFactory (e.g. ProgressiveMediaSource.Factory)
and other factory interfaces like (Http)DataSource.Factory.
PiperOrigin-RevId: 417826803
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
To support multi-period content we need to store AdPlaybackStates and
SharedMediaPeriod by the periodUid as a key. While after this no-op CL,
we still only support single-period content, storing these resources by
periodUid is the ground work for multi-period support being added in an
follow-up CL.
PiperOrigin-RevId: 416836445
Keep the old interface deprecated so any app code implementing it by
name (rather than with a lambda) will continue to work.
PiperOrigin-RevId: 416816566
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 ***
Rollback of 0aa23b08b1
*** Original commit ***
Add capability flags for hardware and decoder support
Issue: google/ExoPlayer#9565
***
***
PiperOrigin-RevId: 416285603
*** Original commit ***
Rollback of 27f905f571
*** Original commit ***
Don't sort decoders by format support in supportsFormat
This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.
This is n...
***
PiperOrigin-RevId: 416269130
*** Original commit ***
Don't sort decoders by format support in supportsFormat
This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.
This is necessary groundwork for a subsequent change that will
indicate in Capabilities whether the decoder that suppports the
format is the primary one as specifi
***
PiperOrigin-RevId: 416170612
This change adds a delegate class that loads and forwards calls
to a Spatializer with reflection, so that we can use the Spatializer
API before we update the compile SDK target to 32.
PiperOrigin-RevId: 416027289
*** 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
This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.
This is necessary groundwork for a subsequent change that will
indicate in Capabilities whether the decoder that suppports the
format is the primary one as specified by the MediaCodecSelector
(i.e., the one at index=0 in the lists that are now used).
Issue: google/ExoPlayer#9565
PiperOrigin-RevId: 414971986
Configure MediaCodec in API 32+ to always output 99 channels
so that we use the audio is spatialized, if the platform can apply
spatialization to it.
In a follow-up change, the output channel count will be set based on the
device's spatialization capabilities.
PiperOrigin-RevId: 414751543
`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
The existing code creates an imbalance between `inputBufferCount` and
`droppedBufferCount` by adding 'dropped source buffers' to
`droppedBufferCount` but not to `inputBufferCount`. This results in
assertion failures in `DashTestRunner`.
PiperOrigin-RevId: 414672175
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
When calling Android's Log class directly, there's a LongLogTag
lint check that detects tags over the 23 char limit, however it
cannot detect long log tags in ExoPlayer due to the way that we
log via our own Log class. This commit adds @Size annotations to
enforce the same rule.
PiperOrigin-RevId: 413976364
On the Sony Android TV device where this was originally reproducible on Android L, on Android N there is an E-AC3 decoder listed which handles the stream correctly. The workaround is harmless anyway but adding the API version restriction means it will be obvious it can be removed once we bump our min API to 24 or above in the future.
#minor-release
PiperOrigin-RevId: 413967443
Hardware audio decoders aren't really a thing, particularly on older
devices. SOC vendors do sometimes provide their own software decoders
though. Hence we update the approximation to assume that audio
decoders on older devices are software.
PiperOrigin-RevId: 413757859
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 allows to give TrackGroups an identifier. The underlying goal is
to provide a way to make otherwise identical TrackGroups
distinguishable.
Also set this id in all internal sources that may produce identical
TrackGroups in certain edge cases.
Issue: google/ExoPlayer#9718
PiperOrigin-RevId: 413430719
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
This is already called in GlUtil.Program().
Tested by confirming that the demo-gl target still runs as expected.
Refactoring change only. No intended functional changes.
PiperOrigin-RevId: 412308564
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
This allows to check if the media metrics service is available outside
the actual constructor and to fail gracefully if it is missing.
PiperOrigin-RevId: 412232425
This inheritance is really confusing because ExoPlayerImpl is not
a full Player interface implementation. It also claims to be an
ExoPlayer implementation in the Javadoc which isn't true in its
current state.
Removing the inheritance also allows to clean up some unused methods.
PiperOrigin-RevId: 411756963
