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
`SurfaceTexture` provides a transform matrix with each buffer. Previously
gldemo ignored this but it is important to apply it to have the video render
properly.
The transformation matrix from the surface texture includes flipping so this
change removes the hard-coded flipping from `a_texcoord`.
Issue: #8992
#minor-release
PiperOrigin-RevId: 377271389
Use of mavenCentral() is now the default when making a new project
in Android Studio. Furthermore, Android Studio displays warnings
when jcenter() is used.
PiperOrigin-RevId: 377268744
Related to: Issue: #9010
Profile-level-id (Format.codecs) can be generated from SPS if SDP does not
include it.
#minor-release
PiperOrigin-RevId: 377251211
Add the `needsReconfiguration` API on the `MediaCodecAdapter` interface so that `MediaCodecRenderer` can reconfigure the `MediaCodec` in case a `MediaCodecAdapter` needs to be reconfigured immediately after being obtained from the `MediaCodecAdapter.Factory`.
PiperOrigin-RevId: 376944334
A renderer is disabled (without being reset) in two situations:
* When transitioning into a period that starts with a discontinuity
* When stopping the player with setForegroundMode(true)
Before this change the behaviour of `MediaCodecRenderer` when disabled
(but not reset) depended on whether the content being decoded had an
associated `DrmSession`:
* For content without an associated DRM session the MediaCodec instance
was kept alive.
* For content with an associated DRM session, the MediaCodec instance
was released. This was to prevent the DRM session from staying alive
and continuing to make license refresh network requests while the
player was stopped in 'foreground mode'.
This change removes the second bullet, and keeps MediaCodec instances
alive in both the secure and insecure case. This will result in the
DRM machinery making occasional license refresh network requests (at
a frequency defined by the license policy) while the player is stopped
and in 'foreground mode'. This network usage is considered to be a
'limited resource' as described by the `ExoPlayer#setForegroundMode`
javadoc.
This means that switches between secure content (or between secure and
clear content when `MediaItem.drmConfiguration.sessionForClearTypes`
indicates a secure decoder should be used for clear content) should
keep the same video decoder, thus avoiding the 'black flash' that occurs
on some devices when switching the surface away from a secure decoder.
Issue: #8842
#minor-release
PiperOrigin-RevId: 376825501
This change introduces a third 'state' for `DefaultDrmSessionManager`:
It's been fully released (prepareCount == 0) but at least one of its
sessions is still active.
In this state new acquisitions are rejected (`(pre)acquireSession()`
calls will fail) but the machinery to support the existing sessions
(ExoMediaDrm and MediaDrmHandler) is kept until they're all released.
This change will allow us to remove the TODO in MediaCodecRenderer
that resolves Issue: #8842.
PiperOrigin-RevId: 376193952
In a follow-up change I will add an additional test to ensure these
events continue to be correctly handled when DefaultDrmSessionManager
has prepareCount==0 but a non-null ExoMediaDrm instance.
PiperOrigin-RevId: 376190225
This helps to remove old ad groups (e.g. those that fell out
of the live window) to keep the data size of AdPlaybackState small.
Also added this case to some existing unit tests to ensure it's
covered.
PiperOrigin-RevId: 376170653
This allows to decouple the data structure from the access. In
a future change, this allows to completely remove old ad groups
(e.g. for live streams where the number of groups would otherwise
grow forever).
Also move the time into the group itself for better encapsulation.
PiperOrigin-RevId: 376170408
Many of the setters are ignored unless others are set - this change:
* Lists these conditions exhaustively.
* Uses more concise language to avoid overshadowing the main details
of what the setter sets.
* Tweaks the language from 'is ignored' to 'shouldn't be called', to
open up the future possibility of throwing an error if these are
called without the 'required' setter also being present (see
Issue: #8957).
#minor-release
PiperOrigin-RevId: 376162385
The docs on setLicenseUri say it's optional, and it has been since
379cd8a04f
(which should have changed this javadoc too)
#minor-release
PiperOrigin-RevId: 376139158
Authentication sequence in RTSP:
- Server replies "Unauthorized" to our DESCRIBE request, and includes the
necessary information (i.e. realm, digest nonce, etc) in WWW-Authenticate
header
- After `RtspClient` receives the response, we
- Parse the WWW-Authenticate header, stores the auth info. The info is saved
for all further RTSP requests (that all need to carry authorization headers)
- send the second DESCRIBE request with the Authorization header.
#minor-release
PiperOrigin-RevId: 376116302
