The method openSocket in RtspMessageChannel does not actually open a socket.
The 'open' term refers more to opening the message channel.
#minor-release
PiperOrigin-RevId: 375908999
The callbacks received RTSP messages and RTSP sending errors are now invoked
directly from RtspMessageChannel's internal threads. It's up to the handler
implementation to decide which thread to handle the messages.
#minor-release
PiperOrigin-RevId: 375908282
Previously, RTSP interleaved binary data is posted onto the playback thread
for handling, the playback thread then adds the received data to a queue.
A loader thread will later dequeue the data and process it.
In this CL, the binary data is sent through a separate listener, on
RtspMessageChannel's RTSP receiving thread.
#minor-release
PiperOrigin-RevId: 375907609
Currently acquireSession() fails with an NPE from
checkNotNull(exoMediaDrm). A follow-up change will result in exoMediaDrm
sometimes being non-null while prepareCount==0 (and in this case we
still want acquireSession() to fail).
preacquireSession() doesn't currently fail in a way the caller can
observe - the same NPE is thrown, but asynchronously and it doesn't
propagate out of the background thread. Throwing directly seems
preferable since it's a clear bug to be trying to preacquire sessions
from an unprepared/released manager.
PiperOrigin-RevId: 375906450
Unlike Assertions, the introduced method cannot be disabled and throws
a ParserException instead. This method is meant to replace regular
assertions (which throw RuntimeExceptions) which check input in the
parsing code.
PiperOrigin-RevId: 375085160
We need to avoid reading and skipping into preload chunks as they
may need to be discarded. The current code iterates over all chunks,
but this can be simplified by just checking the last chunk knowing
that the preload chunk must always be the last one.
As a result, we avoid calling getFirstSampleIndex on all chunks. This
is a bug since the method is not allowed to be called for chunks
that have been spliced in. This still leaves the smaller issue of
potentially calling this method for spliced-in preload chunks, which
will be solved separately.
Issue: #8937
#minor-release
PiperOrigin-RevId: 375053638
Preload chunks may still need to be discarded. However, we don't
currently support discarding spliced-in chunks. Thus, we need to
avoid loadng a preload chunk that needs to be spliced-in.
Issue: #8937
#minor-release
PiperOrigin-RevId: 374851661
Colocate lines that refer to the same module, to reduce probability of
accidentally removing one line and not the other (which has happened
more than once :)).
PiperOrigin-RevId: 374847082
This media source wraps another source and publishes a Timeline with
ads. The created MediaPeriods for ad and content are mapped back to
the original stream to allow seamless playback.
PiperOrigin-RevId: 374836091
There is a newly added condition to help advancing between SSAI ads
and content in case the ad group position or ad duration changed. The
condition currently doesn't check directly whether it's a SSAI
transition but relies on indrect signals. Making this more direct
helps to understand the purpose and avoid unintentional bugs where
this condition would apply in other cases too.
In addition, we need to exclude TextRenderer from the check because
its read position doesn't correspond to the actual decode position
since the decoding happens in the renderer itself (b/181312195).
PiperOrigin-RevId: 374835985
We can instead just save this information in MediaPeriodInfo, similar
to how we store whether the MediaPeriod is last in the timeline etc.
PiperOrigin-RevId: 374835918
It only covers MediaSession - MediaController
(Does not consider cases that either a legacy session or a legacy controller is involved)
Add PlayerInfo#Builder to clean it up.
PiperOrigin-RevId: 374785779
Gradle warns against passing a relative path to `new File(String)`:
https://docs.gradle.org/current/userguide/working_with_files.html#sec:single_file_paths
This change fixes all usages of `exoplayerRoot` to pass it to Gradle's
`Project.file()` first, which returns an absolute `File`.
To reproduce the problem in Issue: #8927:
1. Checkout ExoPlayer git project, to e.g. `~/ExoPlayer/exoplayer-git`
2. Create a new Android Studio project in e.g. `~/AndroidStudioProjects/exoplayer-test`
3. Edit the new project's `settings.gradle` file as described in
https://github.com/google/ExoPlayer/blob/release-v2/README.md
using a relative path for `exoplayerRoot`:
```
gradle.ext.exoplayerRoot = '../../ExoPlayer/exoplayer-git'
```
4. In a shell:
```bash
$ cd ~/AndroidStudioProjects/exoplayer-test/app
$ ../gradlew build
```
(Step 4 is important, it seems running `./gradlew` from the project root
doesn't trigger the relative path problem)
This change fixes the problem, and also works with `exoplayerRoot` as a
`File` or `Path` object. `String`, `File` and `Path` all work with relative or
absolute paths:
```
gradle.ext.exoplayerRoot = '/home/ibaker/ExoPlayer/exoplayer-git'
gradle.ext.exoplayerRoot = '../../ExoPlayer/exoplayer-git'
gradle.ext.exoplayerRoot = new File('/home/ibaker/ExoPlayer/exoplayer-git')
gradle.ext.exoplayerRoot = new File('../../ExoPlayer/exoplayer-git')
gradle.ext.exoplayerRoot = Paths.get('/home/ibaker/ExoPlayer/exoplayer-git')
gradle.ext.exoplayerRoot = Paths.get('../../ExoPlayer/exoplayer-git')
```
Note: The Path versions above require importing `java.nio.file.Paths`
and changing the `apply from:` line in the project's settings.gradle
file to something like:
```
apply from: file(gradle.ext.exoplayerRoot.resolve('core_settings.gradle'))
```
It's assumed that a project wanting to pass a `Path` will make these
changes.
Issue: #8927
PiperOrigin-RevId: 374421627
Notes:
- The only functional change is that createForRemote now assings ERROR_CODE_REMOTE_ERROR.
- createForSource still uses ERROR_CODE_UNSPECIFIED, even though it expects an
IOException. The reason for not using ERROR_CODE_IO_UNSPECIFIED is that the reason for
the error might not be IO. For example, malformed media, or BehindLiveWindowException,
which have non-IO error codes. So using UNSPECIFIED saves a later change in category.
PiperOrigin-RevId: 374390407
When working with SSAI ads, we need to easily convert positions between
the underlying stream and the media model that exposes ad groups. To
simplify this, we can add util methods (that are testable on their own).
In addition, we need an easy way to build AdPlaybackStates for SSAI
inserted ads. The metadata is obtained out-of-band and usually has the
ad group start and end times in the underlying stream only. Hence, we
also add a util method to add a new ad group based on this information.
PiperOrigin-RevId: 374369360
