SDK / exoplayer

Rename FrameProcessor to VideoFrameProcessor, and GlEffectsFrameProcessor to
DefaultVideoFrameProcessor.

Most changes are semi-mechanical, semi-manual find-replace, preserving case:
* "FrameProc" -> "VideoFrameProc" (ex. FrameProcessor -> VideoFrameProcessor, and
   FrameProcessingException -> VideoFrameProcessingException)
* "GlEffectsVideoFrameProc" -> "DefaultVideoFrameProc"

PiperOrigin-RevId: 509887384

PiperOrigin-RevId: 509879029

PiperOrigin-RevId: 509808913

PiperOrigin-RevId: 509802784

Now that the GLEffectFrameProcessor handles external (video) and internal (image) input, components used only for external input needs should be moved to the ExternalTextureManager for code clarity

PiperOrigin-RevId: 509787494

PiperOrigin-RevId: 509785247

PiperOrigin-RevId: 509750806

* Moved the logic to SamplePipeline.
* Pass the requested values via Format.
* Moved exception throwing inside the methods.
* Build up the mimeTypesToCheck as a set - removing possible duplicate
checks.
* Simplified logic that calls the findSupportedMimeType method.
* Improved javadoc.

PiperOrigin-RevId: 509594062

PiperOrigin-RevId: 509546771

PiperOrigin-RevId: 509518734

#minor-release

PiperOrigin-RevId: 509501665

PiperOrigin-RevId: 509478455

PiperOrigin-RevId: 509473556

Because the ColorInfo constructor is deprecated.

PiperOrigin-RevId: 509468663

PiperOrigin-RevId: 509461955

It can be confusing how to use RgbMatrix for app devs not comfortable with image
manipulation, so add a helper class that simply translates rgb values the same
constant brightness value, to update the brightness values.

PiperOrigin-RevId: 509287229

For all end-to-end tests, we currently run on a generic API 26 and newer API 31 emulator. Due to some issues on API 31, update to use an API 33 emulator.

Also, update documentation to mention issues on different emulator versions.

PiperOrigin-RevId: 509242743

#minor-release

PiperOrigin-RevId: 509222489

This now matches EncoderUtil.getSupportedEncoders return type.

PiperOrigin-RevId: 509222078

#minor-release

PiperOrigin-RevId: 509218510

PiperOrigin-RevId: 509210836

In parsing Describe RTSP response messages, IllegalArgumentExceptions are thrown for invalid parameters and values. These exceptions were not caught and crashed the Playback thread. Now these exceptions will be caught and their errors forwarded to the proper error handling listeners.

#minor-release

Issue: google/ExoPlayer#10971
PiperOrigin-RevId: 509207881

FileUtil is only ever used in mh, and never in mh.analysis

PiperOrigin-RevId: 509206721

PiperOrigin-RevId: 509196594

#minor-release

PiperOrigin-RevId: 509189206

It may be confusing for 3P apps, for us to have separate error codes for (1) if
encoding HDR is not supported at all by the device, and (2) if encoding the
format, which happens to be HDR, is not supported by the device. Instead, we can
communicate this in the error message.

PiperOrigin-RevId: 509188666

Tests in `SilenceSkippingAudioProcessorTest` used half as many short integers as needed for channel values when generating alternating silence/noise input. Fix this by passing left and right channel input.

PiperOrigin-RevId: 509188074

PiperOrigin-RevId: 509165378

Following changes are included:
1. Added missing color information in HDR test case.
2. Corrected few namings in AudioBoxesTest.java.
3. Updated corresponding dump files.

PiperOrigin-RevId: 508745206

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