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
There's no need to extend this class. Factories for subclasses of
FakeMediaSource will need to re-implement createMediaSource, at which
point they basically need to re-implement the whole factory interface.
PiperOrigin-RevId: 417817499
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
Switch to using sentence-case naming convention but with one character prefixes for different types.
This is a no-op change.
PiperOrigin-RevId: 417791624
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
Move static factories into a separate class and make it implement an interface
that will let tests customize encoder/decoder creation.
PiperOrigin-RevId: 417610825
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
Transformer uses ExoPlayer for reading input. Apps using Transformer
do not need to know this. So, PlaybackExceptions are converted to
TransformationExceptions with the same message, cause and error code.
The corresponding IO error codes are copied from PlaybackException.
PiperOrigin-RevId: 416793741
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
This is a no-op because all the <resource> elements from these XML
files are effectively concatenated together during building.
PiperOrigin-RevId: 416326534
*** 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
The Robolectric implementation of HttpURLConnection forwards to the JRE
implementation [1], which behaves differently to the Android one
available on devices and emulators. For these tests to be a realistic
test of the HTTP stack used in real playbacks we can't use Robolectric.
Similar to df0e89c167
[1] https://github.com/robolectric/robolectric/issues/6769#issuecomment-943556156
PiperOrigin-RevId: 416013662
Opening the `DataSource` is one of the longer operations in the `Loader` sequence, as it requires a round trip to the origin server. This change allows all the potential `Loader` threads to perform this operation before one of them is forced to wait on shared TimestampAdjuster initialization.
Also, the initialization segment load will never produce media samples, so there is no need for it to wait for `TimestampAdjuster` initialization.
UnsupportedEglVersionException() is only used once, and seems a bit too
specific for Transformer. Also, it's possible for eglCreateContext to fail for
other reasons besides lack of support, so it wasn't always accurate when
thrown.
It is possible for devices not to support EGL version 2.0 though, per
https://source.android.com/devices/graphics/implement-opengl-es, which doesn't
specify the EGL version that must be supported.
PiperOrigin-RevId: 415489396
tl;dr:
In the previous transformer, the transcoding flow is
- If a the GL's input surface (from decoder) does not have data, wait 10ms
(DO_SOME_WORK)
- Else, make the decoder render **ONE** frame to the GL's input surface
- Wait at least 10ms, until the frame's texture is available
- Then process the texture
The process is quite slow, so in the new version, we do:
- If a the GL's input surface (from decoder) does not have data, wait 10ms
(DO_SOME_WORK) **same**
- Else, make the decoder render **as many frames** to the GL's input surface
- Process **as many** available textures in this DO_SOME_WORK cycle
PiperOrigin-RevId: 415474722
*** 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
The input rotation is used to rotate the video during decoding, the
video is rotated so that it is in landscape orientation before encoding
and a rotation is added to the output format where necessary so that
the output video has the same orientation as the input.
PiperOrigin-RevId: 415301328
