SDK / exoplayer

PiperOrigin-RevId: 371102614

Before, Looper.myLooper().getThread() could throw an NPE if the current
thread didn't have any looper.

#minor-release

PiperOrigin-RevId: 371097485

Move VideoSize in the common module and have the Player return it.

`Listener` and `AnalyticsListener` `onVideoSizeChanged` are updated
with the old method deprecated.

`VideoRendererEventListener.onVideoSizeChanged` was also migrated to
`VideoSize` but the old method is removed, not deprecated.
This is because:
 - apps calling/listening to this method is a rare and niche use-case.
 - it would introduce hard to diagnostic issues where if only the caller
   or the callee is updated to use the new method, the event will be lost.
   This doesn't occur with the other 2 listeners as the caller is always
   in ExoPlayer library and was updated to call both the old and new methods.

VideoSize is used everywhere except in `Format` as this would lead to
too much refactoring and backward compatibility breakage for little gain.

#minor-release

PiperOrigin-RevId: 371087419

PiperOrigin-RevId: 371068549

Rating class should be in the same module as MediaMetadata.

Tested:
  $ ./gradlew --stacktrace :exo-library-common:tDUT
  $ ./gradlew --stacktrace :media2-session:tDUT
  $ ./gradlew --stacktrace :media2-session-vct-current:cAT
PiperOrigin-RevId: 370902917

PiperOrigin-RevId: 370902227

PiperOrigin-RevId: 370897451

#minor-release

PiperOrigin-RevId: 370881618

Session pre-fetching caused this ordering assertion to no longer be
always true. It should have been removed in
https://github.com/google/ExoPlayer/commit/795ddfee40cba83eba8e9f39da01fba2f1f8775c

#minor-release

PiperOrigin-RevId: 370880530

PiperOrigin-RevId: 370875532

PiperOrigin-RevId: 370740311

PiperOrigin-RevId: 370739641

Add the onMediaMetadataChanged event to onEvents.

PiperOrigin-RevId: 370738521

Deferred the addition of error codes to ease the review process.

PiperOrigin-RevId: 370687238

#minor-release

PiperOrigin-RevId: 370673852

1. Clarify intention of getAdGroupIndexForPositionUs and
   getAdGroupIndexAfterPositionUs. Both methods are used for very
   specific but different purposes and encode the logic of which
   ads should be played at which time, so it's helpful to clarify
   this in the documentation as well.
2. Change one usage getAdGroupIndexForPositionUs to use the already
   existing nextAdGroupIndex. This is also more in line with the
   intended usage as clarified in step 1.
3. Update MediaPeriodQueueTest for updateQueuedPeriods to only
   look for duration changes in future periods, not in the
   current one, because that's not handled MediaPeriodQueue for ads
   and the test is just passing by chance now. Also remove wrong
   advancePlaying() calls that are already implicitly included in
   the preceding enqueueNext() call.
4. Fix a minor bug where post-roll ads are not checked whether they
   are played already before using them as the next ad group. Also
   added a test covering this case.

#minor-release

PiperOrigin-RevId: 370664131

Some RTSP servers do not include the RANGE attribute for live contents.

#minor-release

PiperOrigin-RevId: 370662587

Previously loadingFinished will never be set to true because it started in
false, and we are and'ing it with `canceled`.

#minor-release

PiperOrigin-RevId: 370662456

PiperOrigin-RevId: 370660058

Allow ExoPlayer to open URIs starting with rtsp://

PiperOrigin-RevId: 370653248

The ForwardingPlayer implements the Player interface and forwards all
operations to another Player instance. Apps will be able to override
methods of ForwardinPlayer in order to modify and/or suppress specific
Player funcionalities.

This commit introduces the ForwardingPlayer which simply forwards all
Player operations to another Player instance. In follow-up changes,
the ForwardingPlayer will be extended so that it eventually reaches the
feature-set offered by ControlDispatcher.

PiperOrigin-RevId: 370653167

Release is a life cycle operation that should only be called when
the player is no longer needed. It's linked to the player lifecycle
and thus very different from prepare/stop.
As a result, it should not be in the same command.

Additionally it's not clear if remote players will ever need to call release,
as the player creator is best candidate to release it.

As a result the release operation doesn't have a use case for a command.
A release command can be added later if a need is identified.

PiperOrigin-RevId: 370649214

We remove other source related listeners if a MediaSource is
removed from the playlist or the player/source is released.
This isn't currently done for the DRM listener.

#minor-release

PiperOrigin-RevId: 370482571

The DebugMediaCodecVideoRenderer expects the MediaCodec to return an
output format change after the MediaCodecRenderer detects an input
format change, but the DebugMediaCodecVideoRenderer resets its state
after flushing MediaCodec. This does not cover the following case: an
input format change is detected when queueing sample with timestamp X
and before the respective output buffer is dequeued, the player seeks
back to X. After seeking back to X, the MCR does not trigger an input
format change for X again, and MediaCodec (correctly) returns an output
format change before dequeueing output X.

This commit is changing DebugMediaCodecVideoRenderer to keep expecting
an output format change after a flush, is one a format pending output.
Such an an edge-case is addressed already in MediaCodecRenderer.

PiperOrigin-RevId: 370482506

PiperOrigin-RevId: 370474795

MediaCodecRenderer is calling its protected methods
resetCodecStateForRelease() and resetCodecStateForFlush() from its
constructor. Classess that override the methods (eg.
DebugMediaCodecVideoRenderer) need to checks if the methods
are called from the superclass constructor thus their members are not
initialized yet.

With this change, the MCR constructor does not call the two
methods and sets the respective state directly on its fields.

PiperOrigin-RevId: 370445978

PiperOrigin-RevId: 370439509

There is a bug when CronetDataSource opens an asset with a length
bigger that Integer.MAX_INT  (2147483647 bytes, ~2GB). In read(),
`bytesRemaining` is cast to int, which overflows and evaluates to a
negative number, causing `bytesRead` to be negative too.

PiperOrigin-RevId: 370434368

After refactoring MediaCodecRenderer's configureCodec() to
getMediaCodecConfiguration(), there was some state initialization left
in DebugMediaCodecVideoRenderer's configureCodec(). This is now moved
inside DebugMediaCodecVideoRenderer.onCodecInitialized().

PiperOrigin-RevId: 370430193

Remove references to deprecated methods. I didn't replace the DRM info
with references to non-deprecated methods because I'm not sure it
belongs at class level. The methods themselves are already documented
in detail.

PiperOrigin-RevId: 370421087

This will help app developers identify which thread is being used and
which is expected.

PiperOrigin-RevId: 370409697

PiperOrigin-RevId: 370407108

* @Nullable is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
  (see go/java-style#s4.8.5-annotations)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

PiperOrigin-RevId: 370377751

Add method getAvailableCommands() in Player interface to return
the available commands. Method isCommandAvailable() moved to
BasePlayer since it can be implelented by calling
getAvailableCommands().

PiperOrigin-RevId: 370059328

* @Encoding is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
  (see go/java-style#s4.8.5-annotations) (2 times)
* @Nullable is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
  (see go/java-style#s4.8.5-annotations) (2 times)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

PiperOrigin-RevId: 370048160

PiperOrigin-RevId: 369934240