The asynchronous MediaCodec adapter queues input buffers in a
background thread. If a codec queueuing operation throws an exception,
the buffer enqueuer will store it as a pending exception and re-throw it
the next time the adapter will attempt to queue another input buffer.
The buffer enqueuer's flush() and shutdown() may throw an exception if
the pending error is set. This is subject to a race-condition in which
the pending error can be set while the adapter is flushing/shutting down
the enqueuer, e.g., if an input buffer is still being queued and the
codec throws an exception. As a result, the adapter cannot flush or
shutdown gracefully.
This change makes the buffer enqueuer to ignore any pending error
when flushing/shuttinf down so that the adapter can flush/release
gracefully even if a queueing error was detected.
PiperOrigin-RevId: 409113054
This method is helpful when iterating the list of track overrides
to figure out which type the override applies to.
Issue: google/ExoPlayer#9665
PiperOrigin-RevId: 409108977
We only had some documentation for a custom shuffle mode, but none
for generic repeat or shuffle modes.
#minor-release
Issue: google/ExoPlayer#9611
PiperOrigin-RevId: 409089623
The Javadoc of DefaultTrackSelector can be shortened as it's not the
right place to document detailed options of the Player track selection
parameters.
The documentation page about track selection is updated to the new
APIs and extended with most relevant options and information needed
to work with ExoPlayer's track selection API.
#minor-release
PiperOrigin-RevId: 409088989
MediaSource can be reused with other Player instances after they
have been released, so we need to set the PlayerId when preparing
the source. Access can mostly be handled by the implementation in
BaseMediaSource.
PiperOrigin-RevId: 408878824
HTTP header names are case-insensitive, but all the others in this file
are 'correctly' cased, so we might as well be consistent.
PiperOrigin-RevId: 408840566
Robolectric uses the JRE HttpURLConnection [1], while real Android
devices and emulators use OkHttp to implement HttpURLConnection. This
can lead to important differences in behaviour, so it's better to use
instrumentation tests when specific HTTP behaviour is important.
[1] https://github.com/robolectric/robolectric/issues/6769#issuecomment-943556156
PiperOrigin-RevId: 408840295
The setters in the Builder are already deprecated and using the
old getter is error-prone as they only return the overrides set
with the deprecated setters.
Issue: google/ExoPlayer#9665
PiperOrigin-RevId: 408817640
The `VideoSamplePipeline` handles all steps from decoding to
re-encoding that where previously in
`TransformerTranscodingVideoRenderer`. The renderer is now only
responsible for reading the format, reading input, passing it to the
pipeline and passing the pipeline's output to the muxer.
When no transformations are needed, decoding and re-encoding is
skipped using the `PassthroughPipeline`.
PiperOrigin-RevId: 408619407
We can rename the existing setIndex method to a more generic init
as this method is only called by EPII and implemented by BaseRenderer
anyway.
PiperOrigin-RevId: 408616055
When dropping the remainder, the decoder and encoder timestamps start diverging after a few buffers when no speed changes are supposed to occur. Tracking the remainder keeps them in sync.
PiperOrigin-RevId: 408341074
*** Original commit ***
Add link to annual media developer survey.
This will be removed after the survey has closed in ~1 month.
***
PiperOrigin-RevId: 408327757
The platform class is only available from API 31, so we need
a generic wrapper that can be used on all API levels. The wrapper
essentially provides an identifier for a player instance, so naming
it accordingly.
PiperOrigin-RevId: 408292802
And in a couple of related places.
This is for consistency with the rest of the codebase where
we exclusively use indices.
#minor-release
PiperOrigin-RevId: 408273372
The ExoPlayer.Builder constructor overloads are only needed for apps
trying to ensure certain classes are removed by R8/proguard, which isn't
relevant for the demo app.
PiperOrigin-RevId: 407819694
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
PiperOrigin-RevId: 407792330
And in a couple of related places.
This is for consistency with the rest of the codebase where
we exclusively use indices.
#minor-release
PiperOrigin-RevId: 408273372
The ExoPlayer.Builder constructor overloads are only needed for apps
trying to ensure certain classes are removed by R8/proguard, which isn't
relevant for the demo app.
PiperOrigin-RevId: 407819694
The comment "all should be same" is not correct, it is extremely likely they will be the same but not assured. In either case the seek position will work, it just may not land exactly on a sync point in every variant.
When operating the MediaCodec in asynchronous mode, after a
MediaCodec.flush(), we start MediaCodec in the callback thread,
which might trigger errors in some platforms. This change adds an
experimental flag to move the call to MediaCodec.start() back to the
playback thread.
PiperOrigin-RevId: 407801013
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
* Remove GlUtil.Program String[] constructor to unify and just use the
String constructor.
* Add getAttributeArrayLocationAndEnable() to simplify things a tiny bit.
* Increase usage of constant values.
PiperOrigin-RevId: 407570340
`TransformerAudioRenderer` reads input and passes `DecoderInputBuffer`s to the `AudioSamplePipeline`. The `AudioSamplePipeline` handles all steps from decoding to encoding. `TransformerAudioRenderer` receives `DecoderInputBuffer`s from the `AudioSamplePipeline` and passes their data to the muxer.
`AudioSamplePipeline` implements a new interface `SamplePipeline`. A pass-through pipeline will be added in a future cl.
PiperOrigin-RevId: 407555102
