SDK / exoplayer

Adds a modified version of sample.mp4 to the list, which has no audio.

PiperOrigin-RevId: 492993918

PiperOrigin-RevId: 492579961

These have the same value (`-1`), and basically the same meaning (offset
in an array/list/file/byte stream/etc), but 'position' is an overloaded
term in a media playback library, and there's a risk people assume that
methods like `Player.getCurrentPosition()` may return
`C.POSITION_UNSET`, when in fact unset media times (whether duration or
position) are always represented by `C.TIME_UNSET` which is a) a `long`
(not `int`) and b) a different underlying value. (aside:
`getCurrentPosition()` never returns an unset value, but it's a good
example of the ambiguity of the word 'position' between 'byte offset'
and 'media timestamp'.)

PiperOrigin-RevId: 492493102

The callback is currently triggered on the ExoPlayer playback thread
instead of the app thread that added the listener.

PiperOrigin-RevId: 492474405

This inconsistency was exposed by an upcoming change to deprecate
`POSITION_UNSET` in favour of `INDEX_UNSET` because position is an
ambiguous term between 'byte offset' and 'media position', as shown
here.

PiperOrigin-RevId: 492470241

Discovered while investigating Issue: google/ExoPlayer#10823

Example stack trace with the previous code (I added the index value for
debugging):

```
playerFailed [eventTime=44.07, mediaPos=44.01, window=0, period=0, errorCode=ERROR_CODE_FAILED_RUNTIME_CHECK
  androidx.media3.exoplayer.ExoPlaybackException: Unexpected runtime error
      at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:635)
      at android.os.Handler.dispatchMessage(Handler.java:102)
      at android.os.Looper.loopOnce(Looper.java:202)
      at android.os.Looper.loop(Looper.java:291)
      at android.os.HandlerThread.run(HandlerThread.java:67)
  Caused by: java.lang.IllegalArgumentException: index=-1
      at androidx.media3.common.util.Assertions.checkArgument(Assertions.java:55)
      at androidx.media3.extractor.text.webvtt.WebvttSubtitle.getEventTime(WebvttSubtitle.java:62)
      at androidx.media3.extractor.text.SubtitleOutputBuffer.getEventTime(SubtitleOutputBuffer.java:56)
      at androidx.media3.exoplayer.text.TextRenderer.getCurrentEventTimeUs(TextRenderer.java:435)
      at androidx.media3.exoplayer.text.TextRenderer.render(TextRenderer.java:268)
      at androidx.media3.exoplayer.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:1008)
      at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:509)
      at android.os.Handler.dispatchMessage(Handler.java:102)
      at android.os.Looper.loopOnce(Looper.java:202)
      at android.os.Looper.loop(Looper.java:291)
      at android.os.HandlerThread.run(HandlerThread.java:67)
]
```

#minor-release

PiperOrigin-RevId: 492464180

PiperOrigin-RevId: 492443147

This is necessary to move video decoding to the AssetLoader. Otherwise,
if the decoder max pending frame count is reached, the AssetLoader will
stop queuing frames to the pipeline, and process data will not be called
anymore.

PiperOrigin-RevId: 492392621

PiperOrigin-RevId: 492195931

In some cases we split a test method, and in other cases we just add
line breaks to make the separation between arrange/act/assert more
clear.

PiperOrigin-RevId: 492182769

PiperOrigin-RevId: 492164739

PiperOrigin-RevId: 492160193

PiperOrigin-RevId: 492154544

Add required import for
androidx.window.java.layout.WindowInfoTrackerCallbackAdapter

PiperOrigin-RevId: 492131661

This adds the forwarding logic for most setters in SimpleExoPlayer
in the same style as the existing logic for setPlayWhenReady.

This change doesn't implement the setters for modifying media items,
seeking and releasing yet as they require additional handling that
goes beyond the repeated implementation pattern in this change.

PiperOrigin-RevId: 492124399

This helps to denote what type of content or folder the metadata
describes.

PiperOrigin-RevId: 492123690

PiperOrigin-RevId: 492023573

PiperOrigin-RevId: 492003800

Also, use the mediaCodecName passed into the constructor to get the
maxPendingFrameCount.

PiperOrigin-RevId: 491985044

PiperOrigin-RevId: 491963883

EncoderUtil using a static list to cache encoders means it's not possible to
use a different set of encoders for different tests when running all
robolectric tests together.

PiperOrigin-RevId: 491959350

PiperOrigin-RevId: 491933937

This better matches the terminology we use elsewhere in the Player
interface, where items inside the playlist are referred to as
"media item" and only the entire list is called "playlist".

PiperOrigin-RevId: 491882849

Implements milestone 1.1 of the [overlays implementation plan](https://docs.google.com/document/d/1EcP2GN8k8N74hHZyD0KTqm9oQo5-W1dZMqIVyqVGtlo/edit#bookmark=id.76uzcie1dg9d)

PiperOrigin-RevId: 491696361

Bypass Z Fold 4 HDR10 tone-mapping bug by limiting the max frame count to 12.

This passed with a value of 14, and failed with a value of 15, but I figured I'd use 12 just to be safe.

PiperOrigin-RevId: 491684058

Follow-up CLs will use this duration for silent audio.

PiperOrigin-RevId: 491670359

PiperOrigin-RevId: 491660842

Use the bitrate of the audio format (when available) in
DefaultAudioSink.AudioTrackBufferSizeProvider.getBufferSizeInBytes() to
calculate accurate buffer sizes for direct (passthrough) playbacks.

#minor-release

PiperOrigin-RevId: 491628530

PiperOrigin-RevId: 491623586

To support OPUS offload, we need to provide a few configuration values
that are currently not set due to the lack of devices supporting
OPUS offload.

PiperOrigin-RevId: 491613716

Main change:

- Removed `Codec.EncoderFactory.createForVideoEncoding`'s argument of a list
of allowed MIME types
- Moved the check for whether a video MIME type is supported to VTSP

PiperOrigin-RevId: 491611799

The fix for b/171657375 (internal) has been shipped with 21.1.0 already (see https://developers.google.com/cast/docs/release-notes#august-8,-2022).

PiperOrigin-RevId: 491583727

PiperOrigin-RevId: 491377695

PiperOrigin-RevId: 491336828

The list of charsets is already hard-coded, and using `Charset` types
ensures they will all be present at run-time, hence we will never
encounter an 'unsupported' charset.

PiperOrigin-RevId: 491324466

This should fix how color matrix transforms look when applied on HDR colors

PiperOrigin-RevId: 491323228

This thread just starts the player and handles the player callbacks for
now. Sample pipelines are still run on the playback thread.

PiperOrigin-RevId: 491299671

It's clearer if each test method follows the Arrange/Act/Assert pattern

PiperOrigin-RevId: 491299379

PiperOrigin-RevId: 491289028

FakeClock keeps an internal list of messages to be executed to
ensure deterministic serialization. The next message from the list
is triggered by a separate helper message sent to the real Handler.
However, if the target HandlerThread is no longer alive (e.g. when
it quit itself during the message execution), this helper
message is never executed and the entire message execution chain
is stuck forever.

This can be solved by checking the return values of Hander.post or
Handler.sendMessage, which are false if the message won't be
delivered. If the messages are not delivered, we can unblock the
chain by marking the message as complete and triggering the next
one.

PiperOrigin-RevId: 491275031