SDK / exoplayer

PiperOrigin-RevId: 300727785

This prevents OOM errors for high bitrate streams that attempt to fill
the buffer regardless of the memory usage.

Also change the max buffer sizes to ensure this is a no-op for video
streams < 20Mbps and audio streams < 260kbps.

Issue:#6647
Issue:#7006
PiperOrigin-RevId: 300720299

Issue: #6761
PiperOrigin-RevId: 300715682

After this change users of ExoPlayerImpl and SimpleExoPlayer can use the media item base playlist API which converts the media item to a media source.

It adds the media item based methods to the ExoPlayer instead of the Player interface. This avoids a big change in the CastPlayer which requires migrating the cast extension to the MediaItem of the core module (follow up CLs).

PiperOrigin-RevId: 300575567

PiperOrigin-RevId: 300554337

This CL removes the prefixes to the tests added after https://github.com/google/ExoPlayer/commit/a6d0caaa3c95746beb4e82c1005c06cbb14b6f6c.

This CL is generated by following command
$ find -name '*Test.java' | xargs -I{} sed -i 's/^\ \ public\ void\ test\([A-Z]\)\(.*\)$/  public void \L\1\E\2/' {}

PiperOrigin-RevId: 300547504

Related to issue:#6765

PiperOrigin-RevId: 300539527

This is one step toward following the google3's test naming convention.
See go/java-testing/getting_started#basic-test-template for details
why prefix test isn't necessary.

This CL is generated by following command
$ find -name '*Test.java' | xargs -I{} sed -i 's/^\ \ public\ void\ test\([A-Z]\)\(.*\)$/  public void \L\1\E\2/' {}

PiperOrigin-RevId: 300537212

This is one step toward following the google3's test naming convention.
See go/java-testing/getting_started#basic-test-template for details
why prefix test isn't necessary.

This CL is generated by following command
$ find -name '*Test.java' | xargs -I{} sed -i 's/^\ \ public\ void\ test\([A-Z]\)\(.*\)$/  public void \L\1\E\2/' {}

PiperOrigin-RevId: 300530329

This avoids duplicate events being dispatched to object foo if
addListener(foo) is called more than once.

Part of issue:#6765

PiperOrigin-RevId: 300529733

We currently have the following logic to update renderers during
period transitions:
 1. Wait for the currently reading period to finish reading all its
    streams.
 	a. Advance reading period.
	b. Set all streams that can't be replaced to final.
	c. If streams can be replaced, replace them now.
 2. Wait until playback position reaches the transition point
 	a. Disable all unneeded renderers (or those that need
           re-enabling).
	b. Advance playing period.
	c. Enable all new renderers (i.e. all except the ones where
           we replaced streams directly in step 1c.

This logic causes delays because steps 2a and 2c can easily happen
before 2b. Doing this allows a smooth transition for cases where
renderers change or where they need to be re-enabled.

The new order after this change is:
 1. Wait for currently reading period to finish reading.
	a. Advance reading period.
	b. Set all streams that can't be replaced to final.
 2. Update reading renderers iteratively.
	a. If streams can be replaced, replace them asap.
	b. If renderes need to be disabled, do so as soon as the
	   respective renderer ended.
	c. Once step b is fully finished, enable or re-enable all new
           renderers.
 3. Wait unril playback position reaches the transition point AND
    all tasks in step 2 are done (i.e. all renderers are set up for the
    playing period).
        a. Advance playing period.

As a nice side effect, decoder enabled and disabled events are now
always reported for the reading period, which is more consistent with
other renderer callbacks.

PiperOrigin-RevId: 300526983

This means DataSource.read now may throw InterruptedException.

PiperOrigin-RevId: 300523430

PiperOrigin-RevId: 300519989

PiperOrigin-RevId: 300513930

This list was meant to simplify some usages where we only want to
make operations on enabled renderers. However, keeping this list
up-to-date is slightly error-prone (because renderers aren't added
and removed from this list next to the corresponding enable and disable
calls) and it makes it hard to do more fine-grained changes that only
enable or disabled a single renderer at a time.

PiperOrigin-RevId: 300513788

Also adds tests covering the internal implementation.

Issue:#5660
PiperOrigin-RevId: 300513548

Removes usage of PlaybackParameters where it seems to be trivial.

PiperOrigin-RevId: 300435199

After this change MediaClocks and ExoPlayerImplInternal don't depend on the deprecated PlaybackParameter anymore but only know about playbackSpeed.

PiperOrigin-RevId: 300428791

This change deprecates the PlaybackParameters and remove the skipSilenceField from the PlaybackParameters. This implies that enabling and disabling skipping silences needs to be done on the Player.AudioComponent after this change.

After submission of the change, all Player API changes are done which are required to bring playbackSpeed and skipSilenceEnabled in the converged Player API state.

PiperOrigin-RevId: 300420843

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/949bbcfb2e98c5cb76ebb35d68fc9f0da4706f16

*** Original commit ***

Add masking for playWhenReady.

Masking is needed as soon as updates to a value can happen both in EPI
and EPII. PlayWhenReady is currently not masked because all updates
happen in EPI only. As soon as we allow pausing at certain times
(e.g. end of a stream), playWhenReady c...

***

PiperOrigin-RevId: 300330307

PiperOrigin-RevId: 300330109

PiperOrigin-RevId: 300313753

*** Original commit ***

Add masking for playWhenReady.

Masking is needed as soon as updates to a value can happen both in EPI
and EPII. PlayWhenReady is currently not masked because all updates
happen in EPI only. As soon as we allow pausing at certain times
(e.g. end of a stream), playWhenReady changes may be triggered by EPII
as well and that's why we need masking.

To know when the value actually changed, we also need to update the
internal state to include whether playback is supppressed.

***

PiperOrigin-RevId: 300303307

Masking is needed as soon as updates to a value can happen both in EPI
and EPII. PlayWhenReady is currently not masked because all updates
happen in EPI only. As soon as we allow pausing at certain times
(e.g. end of a stream), playWhenReady changes may be triggered by EPII
as well and that's why we need masking.

To know when the value actually changed, we also need to update the
internal state to include whether playback is supppressed.

PiperOrigin-RevId: 300284613

PiperOrigin-RevId: 300249371

Exceeding the period duration may mean that that playback transitions
to another item even if the player is currently paused.

PiperOrigin-RevId: 300133655

There is no need for that, updating them is often forgotten and
takes up too much line space. Replace by a single TAG per test class.

PiperOrigin-RevId: 300113072

PiperOrigin-RevId: 300067561

PiperOrigin-RevId: 300067502

This change uses mime types in a functionally equivalent way to how we used the extension hint so far.

Using a mimeType instead of the extension has some advantages. Most importantly mimeTypes are used by the cast SDK with which we want to achieve interoperability in the cast extension.

Using a mimeType instead of the extension hint further appears to be a bit more clear (which might be opinionated). Further mime types are a well known and widely used concept to identify file type on the internet and it provides asterix based generalizations (audio/*, */*) which could express the media type OTHER that ExoPlayer is using internally (no usage of asterix required so far though).

PiperOrigin-RevId: 300058945

PiperOrigin-RevId: 299943596

Requested by https://github.com/google/ExoPlayer/issues/7058.
Additionally move one of the common option in COMMON_OPTIONS.

PiperOrigin-RevId: 299862479

Disabling reference counting allows some checks to be removed.

This is a no-op.

PiperOrigin-RevId: 299829600

handlePrepare/Stop/SetPlayReady can be merged together as they all
handle changes to the desires state of the player.

Also, simplify parts of the control flow by not mixing code that
determines if audio focus needs to be handled with code that actually
acquires or abandons the focus.

PiperOrigin-RevId: 299824857

PiperOrigin-RevId: 299819656

Without this option it's impossible to merge periods covering
different timestamps (at least not without playback issues).

Issue:issue:#6103
PiperOrigin-RevId: 299817540

PiperOrigin-RevId: 299361095

PiperOrigin-RevId: 299357049

Issue: #6975
PiperOrigin-RevId: 299328798

Pre-work for issue:#6765

PiperOrigin-RevId: 299322086