* Add `setOutputStreamOffsetUs(long)` method in `AudioSink`.
* Add private methods `setOutputStreamOffsetUs(long)` method in `MediaCodecRenderer` and `DecoderAudioRenderer`.
* Add protected method `onOutputStreamOffsetUs(long)` method in `MediaCodecRenderer`, in which:
  * `MediaCodecRenderer` itself will be no-op for this method.
  * `MediaCodecAudioRenderer` will propagate this value to its `audioSink`.
* Add logics in `DecoderAudioRenderer` to calculate `outputStreamOffsetUs`.

PiperOrigin-RevId: 479265429
(cherry picked from commit 4c73241)

This mode is supported by using `C.TIME_UNSET` (which is a negative value). The
new logic decouples the value of `C.TIME_UNSET` and the frame dropping
behaviour.

PiperOrigin-RevId: 479368880
(cherry picked from commit ccab9fb)

PiperOrigin-RevId: 479569806
(cherry picked from commit 7c68b8d)

Also, update tests to allow AnyOf error codes, and no longer check exception messages, which caused quite a bit of churn.

PiperOrigin-RevId: 479570861
(cherry picked from commit faa796d)

PiperOrigin-RevId: 479579252
(cherry picked from commit a6b9772)

Currently, a frame is dropped if it's requested release time is in the past.
This mode was added to support previewing. However, in normal ExoPlayer
playback, slightly late frames (<30ms late) are also rendered. On MediaCodec
side, this means calling `releaseOutputBuffer` with a release time in the
past.

PiperOrigin-RevId: 479615291
(cherry picked from commit 2188685)

If the sample type is Dolby Vision and the display does not support Dolby Vision, then the capabilities DecoderSupport flag is set to DECODER_SUPPORT_FALLBACK_MIMETYPE. This denotes that the renderer will use a decoder for a fallback mimetype if possible. This alters track selection as tracks with DecoderSupport DECODER_SUPPORT_PRIMARY are preferred.

UnitTests included
-DefaultTrackSelector test that checks track selection reordering with DECODER_SUPPORT_FALLBACK_MIMETYPE
-MediaCodecVideoRenderer test that checks setting of DecoderSupport flag based on Display's Dolby Vision support

Issue: google#8944
PiperOrigin-RevId: 480040876
(cherry picked from commit a366590)

We currently use the literal -1 (=NO_VALUE) when adding up the
total. Tracks without known bitrate can be ignored in the
calculation, but we should use an explicit value of 0.

#minor-release

Issue: google#10664
PiperOrigin-RevId: 480048126
(cherry picked from commit af19e0e)

PiperOrigin-RevId: 480349627
(cherry picked from commit 225d0dc)

Before, slider values were read as `floor()`'ed `longValue()`s, so that trimming to
intervals less than one second would be interpreted as a request for a zero-
duration trim.

Also, rename `radiusRange` references here to `trimRange`, since this is not a
radius range.

PiperOrigin-RevId: 480401556
(cherry picked from commit 6c59f9e)

Player controls are somewhat distracting when showing the difference between the
input and output video, as they obscure and darken the video players.

PiperOrigin-RevId: 480597804
(cherry picked from commit 91a61ce)

Most demo videos aren't very long, and the default demo video is only 10 seconds.

Shorten the maximum trim duration to 10 seconds, to demonstrate transformer functionality more easily, and allow this to be used more easily when trimming short sections of a longer video (ex. to make test clips)

PiperOrigin-RevId: 480602037
(cherry picked from commit 3142a21)

When debugging and fixing Issue: google#10666 I wanted to write a regression
test, but needed to add a test first... This is just a small bit of
coverage to start with. It checks the field/channel filtering works
correctly, but doesn't check any styling info. It also doesn't test
'pop on' subtitles (i.e. when the subtitle isn't shown until a 'end of
subtitle' signal is received).

PiperOrigin-RevId: 480644568
(cherry picked from commit 6052212)

- This method is redundant with getSupportedSampleMimeTypes().
- This is to prepare the Muxer class to become public.

PiperOrigin-RevId: 480840902
(cherry picked from commit 8962f5a)

PiperOrigin-RevId: 480847967
(cherry picked from commit 446c994)

Adds root extras and metadata extras to MockMediaLibraryService and MockMediaBrowserCompatService and completed test cases for asserting
interoperability with a media1 or Media3 browser.

PiperOrigin-RevId: 480854842
(cherry picked from commit f95406e)

We already have logic to end all session except the current one if the
current one doesn't have a MediaPeriodId yet. This is assuming that this
only happens after a seek on the app side where the player doesn't have
detailled knowledge about the MediaPeriodIds yet.

Currently this logic isn't triggered if the window we are coming from
doesn't have its MediaPeriodId either as we run into another check that
keeps sessions around until we have a valid windowSequenceNumber.

Swapping both conditions fixes this case without breaking any of the
other known transition scenarios.

Issue: androidx/media#180
PiperOrigin-RevId: 480866465
(cherry picked from commit 6070d91)

This means the null checker can be more sure that these fields don't
get reassigned between a null-check and a usage.

PiperOrigin-RevId: 481142004
(cherry picked from commit 248ee46)

PiperOrigin-RevId: 481143798
(cherry picked from commit 026699b)

PiperOrigin-RevId: 481150758
(cherry picked from commit 871a5e6)

PiperOrigin-RevId: 481215581
(cherry picked from commit 6cdaf2c)

PiperOrigin-RevId: 481605567
(cherry picked from commit fd315da)

PiperOrigin-RevId: 481606248
(cherry picked from commit 325e973)

- The naming DefaultMuxer is more consistent with the rest of
Transformer codebase (e.g. DefaultEncoderFactory).
- By hiding the implementation details of DefaultMuxer, the transition
to in-app Muxer will be seamless for apps using DefaultMuxer.
- The current plan is that DefaultMuxer will become the in-app muxer.

PiperOrigin-RevId: 481838790
(cherry picked from commit b4d7f06)

In exoplayer2 this affects StyledPlayer(Control)View

#minor-release

PiperOrigin-RevId: 481878940
(cherry picked from commit a5583c0)

#cleanup

PiperOrigin-RevId: 481882181
(cherry picked from commit b6bd358)

This is to prepare Muxer to become public

PiperOrigin-RevId: 481893842
(cherry picked from commit bd9181e)

(Also, make some public methods private)

PiperOrigin-RevId: 481912071
(cherry picked from commit a404fde)

Currently, repeating the same item (via seekNext/Previous) implicitly
results in a seek to the default position of the current item, which
looks exactly the same as a direct seek. As a result, we don't send
onMediaItemTransition as we would for every other seekNext/Previous
call.

This can be fixed by explicitly marking the repeat case in the internal
BasePlayer/ExoPlayerImpl methods, so that the callback can be triggered.

Issue: google#10667
PiperOrigin-RevId: 481951788
(cherry picked from commit 76ce0cc)

Before, they used `width` and `height`, which was inconsistent with other pixel tests, and less descriptive.

Refactoring change only. No functional change intended.

PiperOrigin-RevId: 481970243
(cherry picked from commit 620d8c9)

#minor-release
Issue: androidx/media#245
PiperOrigin-RevId: 510456793
(cherry picked from commit a231ff4)

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
(cherry picked from commit 829b49d)

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
(cherry picked from commit cbb6878)

Issue: google#10992

#minor-release

PiperOrigin-RevId: 510988140
(cherry picked from commit 57a638a)

The current logic uses manual array operations to keep track of pending
changes. Modernize this code by using an ArrayDeque and a data class.
This also allows to extend the output stream information in the future.

This also fixes a bug where a position reset accidentally assigns a pending
stream offset instead of keeping the current one.

PiperOrigin-RevId: 511787571
(cherry picked from commit 4e0babd)

PiperOrigin-RevId: 512002735
(cherry picked from commit 1ef70cd)

Protected system broadcasts should not specify the export flag.
Marking them as NOT_EXPORTED breaks sticky broadcasts in some
cases.

Issue: google#10970

#minor-release

PiperOrigin-RevId: 512020154
(cherry picked from commit 34b9824)

This test became flaky after google@cbb6878 because some of the
unrealistic frame times ended up on the same release time.

Using realistic numbers avoids the flakiness.

PiperOrigin-RevId: 512566469
(cherry picked from commit 13700e0)

The output info for a new stream is marked pending until the last
sample of the previous stream has been processed. However, this fails
if the previous stream has already been fully processed. We need to
detect this case explicitly to avoid signalling the output change one
sample too late.

#minor-release

PiperOrigin-RevId: 512572854
(cherry picked from commit 39935d7)

Some devices were reported to have wrong PerformancePoint sets
that cause 60 fps to be marked as unsupported even though they
are supported.

Issue: google#10898

#minor-release

PiperOrigin-RevId: 512580395
(cherry picked from commit 04f0cc9)

MediaCodecRenderer currently has two independent paths to trigger
events at stream changes:
 1. Detection of the last output buffer of the old stream to trigger
    onProcessedStreamChange and setting the new output stream offset.
 2. Detection of the first input buffer of the new stream to trigger
    onOutputFormatChanged.
Both events are identical for most media. However, there are two
problematic cases:
  A. (1) happens after (2). This may happen if the declared media
     duration is shorter than the actual last sample timestamp.
  B. (2) is too late and there are output samples between (1) and (2).
     This can happen if the new media outputs samples with a timestamp
     less than the first input timestamp.

This can be made more robust by:
 - Keeping a separate formatQueue for each stream to avoid case A.
 - Force outputting the first format after a stream change to
   avoid case B.

Issue: google#8594

#minor-release

PiperOrigin-RevId: 512586838
(cherry picked from commit a02c8d8)

Playback parameter signalling can be quite complex because
 (a) the renderer clock often has a delay before it realizes
     that it doesn't support a previously set speed and
 (b) the speed set on media clock sometimes intentionally
     differs from the one surfaced to the user, e.g. during
     live speed adjustment or when overriding ad playback
     speed to 1.0f.

This change fixes two problems related to this signalling:
 1. When resetting the media clock speed at a period transition,
    we don't currently tell the renderers that this happened.
 2. When a delayed speed change update from the media clock is
    pending and the renderer for this media clock is disabled
    before the change can be handled, the pending update becomes
    stale but it still applied later and overrides any other valid
    speed set in the meantime.

Both edge cases are also covered by extended or new player tests.

Issue: google#10882

PiperOrigin-RevId: 512658918
(cherry picked from commit d363977)

Once the value returned from AudioTimestampPoller advances, we
only need getPlaybackHeadPosition to sample sync params and
verify the returned timestamp. Both of these happen less often
and we can avoid calling getPlaybackHeadPosition if we don't
actually need it.

PiperOrigin-RevId: 512882170
(cherry picked from commit 4cf7d3c)

#minor-release

PiperOrigin-RevId: 512890813
(cherry picked from commit 13a86b3)

#minor-release

PiperOrigin-RevId: 512897269
(cherry picked from commit 48047cf)

These are not supported by Dackka

#minor-release

PiperOrigin-RevId: 513176533
(cherry picked from commit ef5a1ce)

…or_entire_file

PiperOrigin-RevId: 513213229
(cherry picked from commit d2ba290)

Add some additional information which methods to override
for available commands.

#minor-release

PiperOrigin-RevId: 513251805
(cherry picked from commit a64a9e6)

PiperOrigin-RevId: 513482096
(cherry picked from commit b634005)

#minor-release

PiperOrigin-RevId: 513488487
(cherry picked from commit 3b16231)

PiperOrigin-RevId: 513516267
(cherry picked from commit 658b503)

#minor-release

PiperOrigin-RevId: 513533248
(cherry picked from commit af6807d)

#minor-release

PiperOrigin-RevId: 513555559
(cherry picked from commit 4f68f89)

r2.18.4