SDK / exoplayer

Issue: androidx/media#192
PiperOrigin-RevId: 508649684

GLEffectsFrameProcessor, MatrixShaderProgram and FinalMatrixShaderProgramWrapper are currently setup to handle the input frames coming from an external input (i.e. a video decoder). Image input is loaded into Bitmap objects at the start of the pipeline, so they are not produced externally. The changes provide a way for the frame processing pipeline to handle this "internal" (i.e. non-external) input.

PiperOrigin-RevId: 508645244

The AsynchronousMediaCodecAdapter's queuing thread stores any exceptions
raised by MediaCodec and re-throws them on the next call to
queueInputBuffer()/queueSecureInputBuffer(). However, if MediaCodec
raises and error while queueing, it goes into a failed state and does
not announce available input buffers. If there is no input available
input buffer, the MediaCodecRenderer will never call
queueInputBuffer()/queueSecureInputBuffer(), hence playback is stalled.

This change surfaces the queueing error through the adapter's dequeueing
methods.

PiperOrigin-RevId: 508637346

`TrackSelectorResult.rendererConfigurations` can contain null elements:
> A null entry indicates the corresponding renderer should be disabled.

This wasn't caught by the nullness checker because `ExoPlayerImpl` is
currently excluded from analysis.

#minor-release

Issue: google/ExoPlayer#10977
PiperOrigin-RevId: 508619169

PiperOrigin-RevId: 508602059

The existing implementation depends on an internal library (Mp4Slicer) to assert the output. We have removed the dependency on internal library and used golden data to compare the output.

PiperOrigin-RevId: 508401527

PiperOrigin-RevId: 508323432

This simplifies usage of 64-bit sequence numbers.

PiperOrigin-RevId: 508107588

- For single-asset, the behavior stays the same. Transcode if and only
  if it's necessary,
- For constrained multi-asset, always transcode, except if the setter to
  transmux is set. This is to avoid failing if a MediaItem that doesn't
  require transcoding is followed by a MediaItem that does require
  transcoding.

PiperOrigin-RevId: 508097798

Previously, Robolectric's instrumentation updated all constructors to be
public. This caused two main types of problems:

1) When non-public constructors were made public and added to the Android API,
Robolectric allowed tests to incorrectly use the constructors on older SDK
levels (where they were non-public). This most commonly occurs for
AccessibiltyEvent and AccessibilityNodeInfo.

2) When reflection was used to instantiate classes that were instrumented by
Robolectric, all constructors were accessible.

Fix issues across Google3 Robolectric tests that were affected by this issue.
A forthcoming change will fix the instrumentation in Robolectric to prevent
this type of issue from occurring.

Tested:
    TAP --sample ran all affected tests and none failed
    http://test/OCL:507861075:BASE:507805409:1675803313108:f2128fa4
PiperOrigin-RevId: 508087822

PiperOrigin-RevId: 508062795

PiperOrigin-RevId: 508053559

PiperOrigin-RevId: 508031337

If a renderer error happens while processing readahead data for the
next item in the playlist, we currently throw the error immediately
and only set the item id in the error details. This makes it harder
to associate the error to the right item. For example, the user
facing UI is likely not updated to show the failing item when the
error is reported.

This can be improved slighly by force setting the position to the
failing item. The playback still fails immediately, but this can't
be avoided because the renderer itself went into an error state.

PiperOrigin-RevId: 507808635

PiperOrigin-RevId: 507784608

This will also allow us to skip transcodes in the future for other effects, like
cropping, color effects, etc.

PiperOrigin-RevId: 507765618

Also replace some usages of deprecated Transformer listeners with the new
ones.

PiperOrigin-RevId: 507743860

The AudioTrackPositionTracker needs to correct positions by
the speed set on the AudioTrack itself whenever it makes
estimations based on real-time (=the real-time playout
duration is not equal to the media duration played).

This happens for the main playback path already, but not for
the mode in which the position is estimated from the playback
head position and also not in the phase after the track has
been stopped. Both cases are not very noticeable during
normal playback, but become relevant when playing in offload
mode.

PiperOrigin-RevId: 507736408

Checked there's no other occurrence.

PiperOrigin-RevId: 507534909

Also, replace instances of "texture processor" to "shader program", with capitalization retained.

PiperOrigin-RevId: 507515655

PiperOrigin-RevId: 507515587

In MediaCodecUtil, use Format.colorInfo, besides the codec string,
to accurately map to a 10bit HEVC profile.

PiperOrigin-RevId: 507500071

PiperOrigin-RevId: 507461550

This is a refactoring to separate and simplify the logic
of VOD and live streams when handling IMA ad events. An
additional listener will be required for DASH live stream
in a follow-up CL.

PiperOrigin-RevId: 507435741

Also update some Javadoc in Transformer

PiperOrigin-RevId: 507395956

PiperOrigin-RevId: 506965394

It doesn't actually make sense for them to be placed in the Transformer, because the error's root causes are actually only in codecs. Also, a few codec errors were
repeated, so deduplicate these instances

PiperOrigin-RevId: 506937695

Based on [this conversation thread](https://chat.google.com/room/AAAA--f88ao/76Rem_cRCK8), I've opted to update the existing FrameProcessor.create() rather than deprecate it, as it is unlikely to be in use by apps outside google3.

PiperOrigin-RevId: 506920930

More info in: https://developer.android.com/about/versions/13/behavior-changes-13#granular-media-permissions

PiperOrigin-RevId: 506908079

This is more flexible for apps and more consitent with the Player API.

PiperOrigin-RevId: 506901645

PiperOrigin-RevId: 506900817

PiperOrigin-RevId: 506898392

* Overload added `(cause, errorCode, isVideo, isDecoder, details)`,
where `details` is a string of values to be added to the error message
of the `TransformationException`.
* Overload with `MediaFormat` and `mediaCodecName` moved to
`DefaultCodec`, because all usages of that overload were from
`DefaultCodec`, and this allows a simplified API because of internally
stored values.
* `mediaCodecName` removed from overload that takes a `Format`.
* Reordered `createForCodec` parameters.

PiperOrigin-RevId: 506895268

PiperOrigin-RevId: 506890459

PiperOrigin-RevId: 506886903

In encoding small and odd-numbered resolutions, like `316x61` ([this image](https://upload.wikimedia.org/wikipedia/commons/6/65/100winners.png)), the current fallback logic prefers a software encoder to hardware ones. The assumption was, the encoder factory applies the encoder size alignment and changes the resolution to `316x60` for SW encoders and `316x64` for HW ones. SW encoders is selected because the supported resolution 60 is closer to requested 61, than the hardware supported 64.

This change changes the default encoder selection process to only expose hardware encoders if there is any.

PiperOrigin-RevId: 506879983

With multi-asset, the sample pipelines can process more than one
MediaItem. The renaming makes it clear that the format passed to the
SamplePipeline constructors is the one corresponding to the first
MediaItem. Indeed, the first format is the one used to configure the
SamplePipelines.

PiperOrigin-RevId: 506879260

This avoids affecting ExoPlayer metrics with non-typical usage.

PiperOrigin-RevId: 506878231

PiperOrigin-RevId: 506874799

PiperOrigin-RevId: 506868341