- 17 Jun, 2020 15 commits
-
-
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
-
- 12 Jun, 2020 5 commits
-
-
PiperOrigin-RevId: 316119460
olly committed -
This is useful for debugging both in tests and via logging. PiperOrigin-RevId: 316102968
andrewlewis committed -
Some but not all VideoAdPlayer callbacks from the IMA SDK included defensive handling of unexpected cases. Add the remaining ones. Issue: #7492 PiperOrigin-RevId: 316082651
andrewlewis committed -
PiperOrigin-RevId: 316079131
andrewlewis committed -
PiperOrigin-RevId: 316071392
andrewlewis committed
-
- 11 Jun, 2020 20 commits
-
-
PiperOrigin-RevId: 315995776
Oliver Woodman committed -
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: 315948869
andrewlewis committed -
https://github.com/google/ExoPlayer/commit/2aac0717d728df5511ebac5855467e83cd2d4aa0
*** Original commit *** Propagate format in supportsOutput It is needed to know if gapless is needed, as gapless offload might not be supported. *** PiperOrigin-RevId: 315947888
andrewlewis committed -
https://github.com/google/ExoPlayer/commit/962e08d3be3b47166d1628cd1951e115c5cc00be
*** Original commit *** Add Offload gapless support Confirmed to work on a Pixel 4 after enabling the feature: `setprop vendor.audio.offload.gapless.enabled true` *** PiperOrigin-RevId: 315946947
andrewlewis committed -
Issue: #5978 PiperOrigin-RevId: 315941765
olly committed -
The test uses two items with period-in-window offsets and a non-zero default start position. The test also prepares the first item lazily so that the start position (and thus the renderer offsets) need to change. This is arguably the most complicated setup that needs to be tested. PiperOrigin-RevId: 315903958
tonihei committed -
Confirmed to work on a Pixel 4 after enabling the feature: `setprop vendor.audio.offload.gapless.enabled true` PiperOrigin-RevId: 315889054
krocard committed -
The order of source info refresh and onPrepared was accidentally changed by https://github.com/google/ExoPlayer/commit/ed88f4f1dd7addc9932094113f560287ea7d344e. This changes it back to the correct order and adds a test PiperOrigin-RevId: 315885164
tonihei committed -
It is needed to know if gapless is needed, as gapless offload might not be supported. PiperOrigin-RevId: 315877127
krocard committed -
Rename the DedicatedThreadAsyncMediaCodecAdapter to AsynchronousMediaCodecAdapter as it is the only asynchronous adapter implementation left after the clean-up. PiperOrigin-RevId: 315873431
christosts committed -
PiperOrigin-RevId: 315867160
andrewlewis committed -
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: 315860373
krocard committed -
This seems to match DecoderVideoRenderer more closely: https://github.com/google/ExoPlayer/blob/b1e56304a1fda8075fc637074927c0886f49fdf1/library/core/src/main/java/com/google/android/exoplayer2/video/DecoderVideoRenderer.java#L300 Although MediaCodecRenderer does it in onReset() and then calls that from onDisable(): https://github.com/google/ExoPlayer/blob/b1e56304a1fda8075fc637074927c0886f49fdf1/library/core/src/main/java/com/google/android/exoplayer2/mediacodec/MediaCodecRenderer.java#L754 PiperOrigin-RevId: 315859212
ibaker committed -
PiperOrigin-RevId: 315857270
kimvde committed -
PiperOrigin-RevId: 315794031
Oliver Woodman committed -
PiperOrigin-RevId: 315720712
aquilescanta committed -
Delete the AsynchronousMediaCodecAdapter, the MultiLockAsyncMediaCodecAdapter and their tests. PiperOrigin-RevId: 315694296
christosts committed -
The option to cancel ongoing loads as part of the queue size evalation was added recently. This split out the decision to a new method so that a TrackSelection implementation can independently cancel loads and discard upstream data. It also clarifies that evaluateQueueSize will only be called if there is no ongoing load. Issue: #2848 PiperOrigin-RevId: 315659735
tonihei committed -
This flag was always set even if the load was canceled and not completed. PiperOrigin-RevId: 315659262
tonihei committed -
If the previous chunk didn't finish loading, we need to find the appropriate next chunk based on the current loading position (or the previous chunk's start time if not independent). PiperOrigin-RevId: 315658435
tonihei committed
-