SDK / exoplayer

- Add silent audio when the output contains an audio track but the
  current MediaItem doesn't have any audio.
- Add an audio track when generateSilentAudio is set to true.

PiperOrigin-RevId: 511005887

Test cases for following boxes are added:
1. stsc
2. co64
3. stss

PiperOrigin-RevId: 511002841

Previously, this was limited to API 29. Expand this to all API versions.

Also, update the test to:
(1) skip based on SDR format input instead of HDR format input
(2) Check the exception message in order to disambiguate between the decoder tone
mapping error, and general video format support error.

PiperOrigin-RevId: 511002218

PiperOrigin-RevId: 511000498

Issue: google/ExoPlayer#10992

#minor-release

PiperOrigin-RevId: 510988140

Following changes are included:
1. Move test file into third_party/.../muxer/...
2. Rewrite tests for stts box and stsz box to use dump file infra instead of Mp4Slicer.
3. Remove existing test cases related to stts box which are kind of duplicate as it tries to cover the scenarios which are already covered by "DurationsVuForStts" related test cases.

PiperOrigin-RevId: 510977119

Unstuck the muxer if the next timestamp in the track with the minimum
timestamp is larger than this minimum timestamp plus
MAX_TRACK_WRITE_AHEAD_US.

PiperOrigin-RevId: 510977088

Using these annotations/checkers should hopefully make it marginally harder to use the wrong input values in the API.

PiperOrigin-RevId: 510966941

When rendering frames at a rate higher than the screen refresh rate,
e.g. playing at 8x, the player is releasing multiple frames at the same
release time (nanos) which are then dropped by the platform. The output
buffers are available later and as a result MediaCodec cannot keep up
decoding fast enough.

This change skips releasing multiple video frames on the same vsync
period and proactivelly drops the frame. The frame is counted as skipped
rather than dropped to differentiate with frames dropped due to slow
decoding.

PiperOrigin-RevId: 510964976

This call may cause performance overhead in some situations,
for example if the AudioTrack needs to query an offload DSP
for the current position. We don't need to check this multiple
times per doSomeWork iteration as the value is unlikely to
change in any meaningful way.

PiperOrigin-RevId: 510957116

Before, if the upstream AssetLoader provides HDR to the VideoSamplePipeline when
HDR_MODE_EXPERIMENTAL_FORCE_INTERPRET_HDR_AS_SDR is requested, the
VideoSamplePipeline would attempt to tell the AssetLoader to output SDR, which
could be accomplished via MediaCodec tone-mapping in the AssetLoader.

However, this makes an assumption of the AssetLoader implementation, and
AssetLoaders may not all implement support for decoder tone-mapping. Remove javadoc
attempting to explain how AssetLoaders (ex. custom ones) could behave.

PiperOrigin-RevId: 510956820

This method uses sampleRate, channelCount and pcmEncoding, so passing
AudioFormat is easier.

This will lead into a future change that builds the
encoderInputAudioFormat from encoder.getConfigurationFormat()

PiperOrigin-RevId: 510956177

Rename:
* MatrixShaderProgram to DefaultShaderProgram, and
* FinalMatrixShaderProgramWrapper to FinalShaderProgramWrapper.
PiperOrigin-RevId: 510498547

Rename ScaleToFitTransformation to ScaleAndRotateTransformation.

This better represents the operations that can be accomplished using this
effect. The name was originally named ScaleToFit* because it's not obvious how
to scale to fit using OpenGL, and this effect handled the scaling to fit in a way that no other MatrixTransformations did.

However, it's hard to discover how to rotate when skimming names of effects, so
it's probably more useful to convey that this effect rotates, than that it
scales to fit.

PiperOrigin-RevId: 510480078

Format.toString unfortunately doesn't log colorInfo, and as Format holds a very
large set of values, it's unclear that it should. ColorInfo is useful for codec
exceptions though, so log this in ExportException.createForCodec.

PiperOrigin-RevId: 510475520

resolving comments from https://github.com/google/ExoPlayer/commit/8aa1638fe46c02d12f59a9768422a8787e09e97c.

PiperOrigin-RevId: 510457401

#minor-release
Issue: androidx/media#245
PiperOrigin-RevId: 510456793

PiperOrigin-RevId: 510441777

PiperOrigin-RevId: 510437262

PiperOrigin-RevId: 510433206

Only the version need to be updated. No changes in class or package mappings since the last release.

PiperOrigin-RevId: 510385733

Also rename to forceAudioTrack

PiperOrigin-RevId: 510394620

Only the version need to be updated. No changes in class or package mappings since the last release.

PiperOrigin-RevId: 510385733

PiperOrigin-RevId: 510384933

PiperOrigin-RevId: 510377977

Adds a new option to the preset file list to show an image for 5secs at 30fps. Also adds an ImageView to show the input image

PiperOrigin-RevId: 510372035

Following changes are included:
1. Move BoxesTest.java into muxer module.
2. Change test code to use dump file infra.

BoxesTest.java does not cover all the boxes implemented in Boxes.java so created a WI to track it b/269471752

PiperOrigin-RevId: 510219645

Otherwise, a lack of HDR decoding support will result in the tests checking output files for HDR output, like HdrEditingTest.transform_noRequestedTranscode_hdr10File_transformsOrThrows, failing.

PiperOrigin-RevId: 510213020

This space was added by mistake in a prior CL of mine.

PiperOrigin-RevId: 510157363

PiperOrigin-RevId: 510155318

This allows us to fix usage of HDR_MODE_EXPERIMENTAL_FORCE_INTERPRET_HDR_AS_SDR.

Before, this was checked in the VideoSamplePipeline, which no longer decides on the decoder configuration input format.

PiperOrigin-RevId: 510142097

PiperOrigin-RevId: 510118760

It's unlikely anyone will try to use Transformer on watches.

PiperOrigin-RevId: 510115645

PiperOrigin-RevId: 510100709

Some of the test methods in `TransformationTest` don't check
capabilities. Add a check just scoped to decoding (not checking
encoding, but the default encoder factory may fall back).

PiperOrigin-RevId: 510088562

PiperOrigin-RevId: 510087543

PiperOrigin-RevId: 510077348

PiperOrigin-RevId: 510062674

Previously, any constructors instrumented by Robolectric were made public. This
caused two types of issues:

1) If Android classes had non-public constructors which 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, which did not match what
happened when running on an Android test.

Update the instrumentation in Robolectric to prevent making all public
constructors.

PiperOrigin-RevId: 510049123