r2.14.1 #9045
Merged
r2.14.1 #9045
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PiperOrigin-RevId: 373142159
PiperOrigin-RevId: 374161340
#minor-release PiperOrigin-RevId: 373410795
#minor-release PiperOrigin-RevId: 374235979
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
#minor-release PiperOrigin-RevId: 374433331
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
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 PiperOrigin-RevId: 375053638
PiperOrigin-RevId: 375054051
Its absence seems to have caused #8969. #minor-release PiperOrigin-RevId: 375058222
#minor-release PiperOrigin-RevId: 375097412
#minor-release PiperOrigin-RevId: 375435339
PiperOrigin-RevId: 375436117
Without this the Cue isn't deeply immutable, which can be a bit surprising. PiperOrigin-RevId: 375477571
PiperOrigin-RevId: 375484765
#minor-release PiperOrigin-RevId: 375674759
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
Some RTSP servers will offer multiple WWW-Authenticate options. We wanted to be able to pick them up. #minor-release PiperOrigin-RevId: 375907276
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
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
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
Issue: #8985 #minor-release PiperOrigin-RevId: 375913914
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
The docs on setLicenseUri say it's optional, and it has been since 379cd8a (which should have changed this javadoc too) #minor-release PiperOrigin-RevId: 376139158
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
Issue: #8776 PiperOrigin-RevId: 376186877
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 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
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
#minor-release PiperOrigin-RevId: 377001305
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
#minor-release PiperOrigin-RevId: 377269770
`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
PiperOrigin-RevId: 373343326
Also added test cases covering this. PiperOrigin-RevId: 374218514
Related to Issue: #8941. RTSP message body's format is not regulated by the RTSP spec, meaning it can use either CRLF or LF as its line terminator. The old code assumes every line ends with CRLF (RTSP message and the message body); the new code will rely on the Content-Length information to receive the bytes for the message body. #minor-release PiperOrigin-RevId: 377475565
#minor-release PiperOrigin-RevId: 377476603
The old version's retry logic will not work if using authentication. Specifically, we use the same authentication parameters from the previous session, and the RTSP server will reject such parameter. In this fix, we reset the authentication info on retry. Further, we retry the last request on receiving a 401 Unauthorized, rather than sending out another DESCRIBE request. #minor-release PiperOrigin-RevId: 377539711
The current code does not catch the IAE thrown when building a MediaDescription or SessionDescription. This CL catches the IAE and propagates it as a ParserException. Issue: #9014. PiperOrigin-RevId: 377544439
The size of rtspLoaderWrappers must match the number of tracks exposed by the RTSP session (a track is exposed if its media description entry appears in DESCRIBE's SDP response). When retrying with TCP, the old code will start loading all exposed RTSP tracks, regardless of whether they are selected. The fixed code will only start loading selected tracks. #minor-release PiperOrigin-RevId: 377931030
RtspMediaSource uses the timeline update paradigm from ProgressiveMediaPeriod. PiperOrigin-RevId: 378150758
PiperOrigin-RevId: 377106891
PiperOrigin-RevId: 378665771
#minor-release PiperOrigin-RevId: 373351014
#minor-release PiperOrigin-RevId: 378844770
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.