SDK / exoplayer

PiperOrigin-RevId: 290041295

PiperOrigin-RevId: 290032841

This optimization allows a ChunkSampleStream to output track
formats as soon as they're parsed during an InitializationChunk
load, rather than waiting until after the InitializationChunk
load is completed.

In DASH VOD, a single InitializationChunk typically loads the
moov and sidx atoms in that order. Hence for long form content
where the sidx is a non-trivial size, this may result in the
track formats being output a non-negligible period of time
sooner than was previously the case. This allows downstream
renderers to start codec initialization sooner, potentially
decreasing startup latency.

For a single test stream on a fast & stable network, this
pretty consistently reduced elapsed time until both audio and
video codecs have been initialized from ~0.5s to ~0.3 seconds
on a Galaxy S8. For 5 test runs without and with these patches,
the eventTime logged by EventLogger for the second decoder
init were:

Without (secs): 0.47 0.47 0.45 0.48 0.46
With (secs)   : 0.32 0.33 0.34 0.31 0.40

PiperOrigin-RevId: 289845089

The current order of operations means that the Format is only passed
to the chunk's output after the DataSource has been opened. This
means that establishing the network connection and the downstream
renderers initializing their codecs are effectively serialized to
occur one after the other.

In the new order, the Format is passed to the chunk's output before
the DataSource has been opened. This allows the downstream renderers
to initialize their codecs in parallel with the network connection
being established, and hence latency at the start of playback is
reduced.

PiperOrigin-RevId: 289841854

Issue: #6870
PiperOrigin-RevId: 289658261

PiperOrigin-RevId: 289490708

Issue: #6798
PiperOrigin-RevId: 289424582

As discovered whilst investigating #6798, there are cases
where these methods are not correctly. They were added as
convenience methods that could be overridden by concrete
DownloadService implementations, but since they don't work
properly it's preferable to require application code to
listen to their DownloadManager directly instead.

Notes:

- The original proposal to fix #6798 stored the state change
events in memory until they could be delivered. This approach
is not ideal because the events still end up being delivered
later than they should be. We also want to fix the root cause
in a different way that does not require doing this.
- This change does not fix #6798. It's a preparatory step.

Issue: #6798
PiperOrigin-RevId: 289418555

This change makes it clear the SampleQueue doesn't outlive
the wrapping PlayerTrackEmsgHandler, and releases it from
PlayerTrackEmsgHandler.release().

This change is a no-op because calling release() is the
same as reset() in this case (the behavior only differs if
a non-dummy DrmSessionManager is being used).

PiperOrigin-RevId: 289416622

As a result, onMediaChunkLoadStarted gets invoked on the loading thread, and
init on the playback thread, matching the thread access comments.

Issue:#6321
PiperOrigin-RevId: 289167981

PiperOrigin-RevId: 289092332

PiperOrigin-RevId: 289091494

PiperOrigin-RevId: 289054937

Unfortunately devices such as the MI 8 do not provide an alternative
working decoder. Some Vivo devices do provide one though.

PiperOrigin-RevId: 288911897

PiperOrigin-RevId: 288860159

PiperOrigin-RevId: 288855515

PiperOrigin-RevId: 288772277

This improves readability by making clearer that reading no bytes from
the input in readFrames() is an expected case if the buffer is full.

PiperOrigin-RevId: 288711841

This doesn't work because the Chronometer text layout can only count in realtime.

Issue:#6816
PiperOrigin-RevId: 288711702

Issue: #6845
PiperOrigin-RevId: 288688716

PiperOrigin-RevId: 288667790

Issue: #4078
PiperOrigin-RevId: 288651166

PiperOrigin-RevId: 288468497

PiperOrigin-RevId: 288464154

PiperOrigin-RevId: 288304477

- Simulate IO exceptions in the test using FlacBinarySearchSeeker for
  seeking in FlacExtractorTests. This makes the test slower but covers
  more test cases.

PiperOrigin-RevId: 288285057

PiperOrigin-RevId: 288292488

PiperOrigin-RevId: 288280500

This typo was introduced in https://github.com/google/ExoPlayer/commit/ddb70d96ad99f07fe10f53a76ce3262fe625be70
when migrating a static method with parameter `durationUs` to an
instance method where the correct field to use was `blockDurationUs`
(but `durationUs` also exists).

The test that catches this was only added in https://github.com/google/ExoPlayer/commit/45013ece1e3fe054ff8960355a89559241eeb288 (and
therefore configured with the wrong expected output data).

issue:#6833
PiperOrigin-RevId: 288274197

PiperOrigin-RevId: 287973192

PiperOrigin-RevId: 287999703

Issue: #6552
PiperOrigin-RevId: 287964221

PiperOrigin-RevId: 287854701

Issue: #5789
PiperOrigin-RevId: 287828559

Issue: #6779
PiperOrigin-RevId: 287828273

Issue: #6266
PiperOrigin-RevId: 287821640

Issue: #6602
PiperOrigin-RevId: 287816831

It's unreliable for at least one IMA ADPCM file I've found.
Calculating the blockIndex to seek to using exact properties
also seems more robust.

Note this doesn't change anything for the existing PCM test,
since averageBytesPerSecond is set correctly. It does make
a difference for an upcoming IMA ADPCM test though.

PiperOrigin-RevId: 287814947

PiperOrigin-RevId: 287810018

Issue: #6733
PiperOrigin-RevId: 286621715