SDK / exoplayer

Tested:
  $ ./gradlew :media-test-session-current:cAT
  $ blaze test test_session_current/src/androidTest:test_with_current_support_app
  The tests run but seem flaky, not related to this change.
PiperOrigin-RevId: 373677924

This is mainly so that developers can try out RTSP with
the main demo app without having to change the build.gradle
file.

The change also aligns what media can be played across the
different demo apps.

#minor-release

PiperOrigin-RevId: 373591974

#minor-release

PiperOrigin-RevId: 373550935

#minor-release

PiperOrigin-RevId: 373543587

PiperOrigin-RevId: 373542819

This helps both player the logic and clients like UI or analytics to
detect SSAI ads.

PiperOrigin-RevId: 373540754

In order to deliver Cue objects between different processes
(e.g. in Player#getCurrentCues), this CL makes it Bundleable.

PiperOrigin-RevId: 373524501

In Android 12 mutability flags have to be set on PendingIntents. If they are not, and the app targets Android 12, then the app will be crashed by the system.

PiperOrigin-RevId: 373427591

It's no longer used.

PiperOrigin-RevId: 373426109

#minor-release

PiperOrigin-RevId: 373410795

#minor-release

PiperOrigin-RevId: 373402932

Content after ad groups currently always resumes at the ad break position (unless
overridden by a seek or similar).  In some cases, media inserting ads wants to
specify an offset after the ad group at which playback should resume. A common
example is a live stream that inserts an ad and then wants to continue streaming
at the current live edge.

Support this use case by allowing ad groups to specify a content resume offset
and making sure that the content start position after the ad group uses this offset.

PiperOrigin-RevId: 373393807

#minor-release

PiperOrigin-RevId: 373351935

#minor-release

PiperOrigin-RevId: 373351014

PiperOrigin-RevId: 373343326

#minor-release

PiperOrigin-RevId: 373336127

NAT will block off incoming UDP connection because the router has no knowledge
of the necessary port mapping (the mapping is never set up because UDP is
connectionless).

The end result is, the UDP socket to receive RTP data will timeout. After the
`SocketTimeoutException` is caught, the following takes place to try streaming
with TCP (or, RTP over RTSP).

- `RtspClient` sends TEARDOWN to tear down the current session.
- `RtspClient` re-connect to the RTSP server.
- `RtspMediaPeriod` cancels all loading `RtpDataLoadables` (that are using UDP)
- `RtspMediaPeriod` constructs new `RtpDataLoadables` that use
    `TransferRtpDataChannel`, and starts loading.
- Once the `RtpDataLoadables` are up and running, we are ready to receive.
  `RtspClient` sends the SETUP requests.

- The rest of the flow is unchanged.

#minor-release

PiperOrigin-RevId: 373310774

It helps to change allowed commands from session.

PiperOrigin-RevId: 373302990

It's convenient for testing.

PiperOrigin-RevId: 373280130

PiperOrigin-RevId: 373222158

PiperOrigin-RevId: 373180764

#minor-release

PiperOrigin-RevId: 373175041

#minor-release

PiperOrigin-RevId: 373173075

PiperOrigin-RevId: 373172693

PiperOrigin-RevId: 373170792

Instead just forward the existing exception.

PiperOrigin-RevId: 373145328

PiperOrigin-RevId: 373144415

PiperOrigin-RevId: 373142159

The player already supports changing durations of periods and ads.
The only thing not yet supported is a change in ad break positions
which changes the duration of clipped content ending in an ad break.

Adding support for this requires updating the end position in
MediaPeriodInfo and changing the clip end position of the respective
ClippingMediaPeriod.

Issue: #5067
PiperOrigin-RevId: 373139724

PiperOrigin-RevId: 373128118

PiperOrigin-RevId: 373126944

PiperOrigin-RevId: 373026239

RTSP interleaving enables RTP packets to be sent using RTSP's TCP connection.
The interleaving RTSP messages contain binary data only and always start with a
'$'. Normal RTSP messages contain line breaks (CRLFs) that indicate complete
lines.

#minor-release

PiperOrigin-RevId: 372990181

PiperOrigin-RevId: 372981744

#minor-release

PiperOrigin-RevId: 372981022

#minor-release

PiperOrigin-RevId: 372980349

PiperOrigin-RevId: 372942778

The method to handle Timeline updates currently uses
 isAd() || isPlaceholder()
to trigger two things:
 1. Using the existing requested content position as the content
    position.
 2. Re-resolving the content position from window to period in case
    it changed since the last update.

The condition is correct for case (1) because ads must use the content
position (and not the position in the ad) and a placeholder period must
keep using the requested content position as well until the media
information is no longer a placeholder.

However, case (2) only needs to be done if the content position is
C.TIME_UNSET (to start at the default position) OR if the period is
still a placeholder and we want to re-resolve the position.

The case where re-resolution shouldn't be done is for ads with a non-
placeholder period and a concrete content position. This likely only
affects ads in live stream where the content position is currently
moving with the live stream instead of staying where it is.

PiperOrigin-RevId: 372929439

#minor-release

PiperOrigin-RevId: 372925409

#minor-release

PiperOrigin-RevId: 372919342