- 23 Jun, 2020 19 commits
-
-
PiperOrigin-RevId: 317672619
samrobinson committed -
The compat dependency is no longer maintained and we need to keep it at its old version. PiperOrigin-RevId: 317658349
tonihei committed -
PiperOrigin-RevId: 317637058
ibaker committed -
PiperOrigin-RevId: 317636681
ibaker committed -
The IMA SDK now preloads postrolls which is great as we no longer need to rely on detecting buffering at the end of the stream to trigger playing postrolls. Add in the required logic to detect the period transition to playing the postroll. Issue: #7518 PiperOrigin-RevId: 317610682
andrewlewis committed -
PiperOrigin-RevId: 317609986
olly committed -
We currently get float ad cue points from IMA, but store these as longs in microseconds. The cast from double to long would take the floor of the value, which could lead to stored ad cue points being off-by-one. Use Math.round to avoid this. ImaAdsLoader also has code to map a double AdPodInfo position (which should match a cue point) onto the corresponding ad group index by searching the long ad cue points. Match the calculation used where we map float cue points, including narrowing the position to a float first to avoid regressions if IMA SDK behavior changes to represent positions in more than float precision later, and also remove the requirement that the ad positions match exactly as a defensive measure. PiperOrigin-RevId: 317607017
andrewlewis committed -
PiperOrigin-RevId: 317604812
andrewlewis committed -
They currently fall back to the main Looper if the current thread doesn't have a Looper. All the changed Handlers are guaranteed to be created on a thread with a Looper (mostly the ExoPlayer playback Looper) and thus can make this stricter assumption. This makes it easier to reason about the code as there are no ambiguities as to which thread the Handler is running on. PiperOrigin-RevId: 317334503
tonihei committed -
https://github.com/google/ExoPlayer/commit/63ae4cc54bc58303faf15a0dc97017792b0de6f2
*** Original commit *** Rollback of https://github.com/google/ExoPlayer/commit/6ae472243f16d1f075328a779f3d4b46e180b76d *** Original commit *** PiperOrigin-RevId: 317331407
tonihei committed -
PiperOrigin-RevId: 317322247
aquilescanta committed -
The setForeground mode method blocks in the same way as release and should use the same timeout if configured. In case the method runs into the timeout, a player error is reported. PiperOrigin-RevId: 317283808
tonihei committed -
https://github.com/google/ExoPlayer/commit/6ae472243f16d1f075328a779f3d4b46e180b76d
*** Original commit *** Rename Util methods to clarify which Looper is used. The method name didn't clarify that either the main or current Looper is used. *** PiperOrigin-RevId: 317283606
olly committed -
The method name didn't clarify that either the main or current Looper is used. PiperOrigin-RevId: 317276561
tonihei committed -
- It seems conceptually simpler for DefaultExtractorsFactory - It seems unlikely we'll need to diverge the two. In the case of workaround flags we can just have them be no-ops in the version that doesn't need them. PiperOrigin-RevId: 317151955
olly committed -
PiperOrigin-RevId: 317148010
olly committed -
The details are available on the public fields, which are referenced with @see PiperOrigin-RevId: 317092269
ibaker committed -
Looks like this change was introduced in <unknown commit> onKeysRemoved is currently not triggered in DefaultDrmSessionManager as far as I can tell. It seems like it should be called from here. PiperOrigin-RevId: 317072794
ibaker committed -
It seems more natural given we always end up instantiating a Matroska extractor, not one that's specific to the WebM subset of Matroska. There's also no reason not to support Matroska MIME types in DASH. PiperOrigin-RevId: 316975451
olly committed
-
- 17 Jun, 2020 21 commits
-
-
PiperOrigin-RevId: 316949571
olly committed -
https://github.com/google/ExoPlayer/commit/b6f5a263f725089c026bb8416ade555f4f16a2bc
*** Original commit *** Rollforward of commit 5612ac50. *** Reason for rollforward *** Rollforward after making sure the handler is created from the playback thread and not from an app thread. *** Original change description *** Rollback of https://github.com/google/ExoPlayer/commit/e1beb1d1946bb8ca94f62578aee8cbadd97b6e2b *** Original commit *** Expose experimental offload scheduling Add a new scheduling mode that stops ExoPlayer main loop when the audio offload buffer is full and resume it... *** PiperOrigin-RevId: 316914147
olly committed -
PiperOrigin-RevId: 316902430
aquilescanta committed -
PiperOrigin-RevId: 316900193
bachinger committed -
*** Reason for rollforward *** Rollforward after making sure the handler is created from the playback thread and not from an app thread. *** Original change description *** Rollback of https://github.com/google/ExoPlayer/commit/e1beb1d1946bb8ca94f62578aee8cbadd97b6e2b *** Original commit *** Expose experimental offload scheduling Add a new scheduling mode that stops ExoPlayer main loop when the audio offload buffer is full and resume it when it has been partially played. This mode needs to be enabled and dissabled manually by the app for now. #exo-offload *** *** PiperOrigin-RevId: 316898804
krocard committed -
After an ad pod coming up has preloaded, if the user seeks before it plays we get pauseAd/stopAd called for that ad pod. Also, the ad will not load again. Work around this unexpected behavior by handling pauseAd/stopAd and discarding the ad. In future, it's likely that the IMA SDK will stop calling those methods, and will loadAd again for the preloaded ad that was unexpectedly discarded. This change should be compatible with that, because the ad won't be discarded any more due to not calling stopAd. Issue: #7492 PiperOrigin-RevId: 316873699
andrewlewis committed -
Ads can appear due to asynchronous ad tag requests completing after earlier ads in a pod have loaded, so remove the requirement that the ad count can't change. The MediaPeriodQueue should handling discarding buffered content if an ad appears before already buffered content, so I think this case is actually handled correctly by the core player already. Also remove the requirement that an ad URI can't change. This is a defensive measure for now, but it's likely that a later fix in the IMA SDK for an issue where loadAd is not called after preloading then seeking before a preloaded ad plays will result in loadAd being called more than once, and I think it's possible that the second call to loadAd may have a different URI. Because the ad URI should only change after an intermediate seek to another MediaPeriod, there shouldn't be any problems with buffered data not getting discarded. Issue: #7477 PiperOrigin-RevId: 316871371
andrewlewis committed -
The test was trying to synchronize a background decoding thread by waiting for pending decode calls. However, the background thread needs to fully queue the newly available output buffer before we can stop waiting to ensure it's actually fully predictable. So we change the pending wait to wait until the input buffer is cleared, which only happens after the decoder is definitely done with it. Also properly clean-up decoder (including shutting down the background thread). PiperOrigin-RevId: 316870659
tonihei committed -
The release() method was added in the recent IMA API changes for preloading and now 'collides' with the ExoPlayer AdsLoader release method. This led to all ads completing being treated as a call to completely release the ads loader, which meant that the ad playback state was not updated on resuming after all ads had completed, which in turn led to playback getting stuck buffering on returning from the background after all ads played. Move the IMA callbacks into an inner class to avoid this. Issue: #7508 PiperOrigin-RevId: 316834561
andrewlewis committed -
constructor to note that the builder does NOT infer the http method from the existence of the post body. PiperOrigin-RevId: 316765677
olly committed -
- Leaving the TODO, since there are still MIME types we're unsure about. - Removing AAC because xHE-AAC does not have this property. We may re-add it with an additional profile check to exclude xHE-AAC in the future. PiperOrigin-RevId: 316715147
olly committed -
We haven't seen it used anywhere in practice. It's a niche feature not supported by any other extractors, and is one of the very few things stopping us from simplifying MediaSource implementations to not set the decodeOnly sample flag. This is a simplification that we want to make, since the current mechanism doesn't work properly for cases where a downstream decoder adjusts the buffer presentation timestamps so that they're different on the output side than on the input side. PiperOrigin-RevId: 316712302
olly committed -
To be the abstraction to use for integrating with MediaParser. PiperOrigin-RevId: 316710421
aquilescanta committed -
This flag isn't needed anymore because the waiting for keys happens on the source side and the source just returns NOTHING_READ under the same conditions. PiperOrigin-RevId: 316704214
tonihei committed -
We started using this method from other tests unrelated to TestExoPlayer, so the method is better placed inside a generic Util class. PiperOrigin-RevId: 316675067
tonihei committed -
PiperOrigin-RevId: 316650017
bachinger committed -
This change adds MediaSource.getMediaItem and deprecates MediaSource.getTag. For backwards compatibility, the tag is made available through the Window with `mediaItem.playbackProperties.tag` as well as in the deprecated `tag` attribute. PiperOrigin-RevId: 316539752
bachinger committed -
We're then able to use this same helper class from tests, to avoid running into spurious failures caused by long microseconds being round-tripped through float seconds. PiperOrigin-RevId: 316435084
ibaker committed -
Using the default offset as a magic constant makes tests hard to understand. Improve that by looking up the value from the timeline or setting it explicitly in multiple places, so the relationship becomes clear. PiperOrigin-RevId: 316421977
tonihei committed -
PiperOrigin-RevId: 316172860
aquilescanta committed -
The correct order of initializing the MediaCodec should be (as per documentation https://developer.android.com/reference/android/media/MediaCodec#initialization) "create -> setCallback -> configure -> start" but the MediaCodecRenderer currently does "create -> configure -> setCallback -> start" MediaCodec implementations did not complain about this so far, but the wrong sequence does not work with the MediaCodec in block mode (new mode in Android R) and also the ShadowMediaCodec won't operate in asynchronous mode otherwise. To initialize the MediaCodec in the correct order, this commit adds configure() in the MediaCodecAdapter so the MediaCodecRenderer can do: adapter.configure(); // sets the callback and then configures the codec adapter.start(); // starts the codec PiperOrigin-RevId: 316127680
christosts committed
-