- 17 Oct, 2020 14 commits
-
-
PiperOrigin-RevId: 333051018
andrewlewis committed -
We have a workaround for uneven sample stream durarions in playlists that assumes a renderer allows playback if it's reading ahead or waiting for the next stream. https://github.com/google/ExoPlayer/commit/652c2f9c188bf9d9d6e323ff5333e5026454a082 changed this logic to no longer require to wait until the next stream is prepared due to a change in how we advance media periods in the queue. However, the code falsely still requires the next stream to exist (even if it's not prepared). This can cause a stuck buffering state when the difference in the duration of the streams is more than what we buffer ahead because we never create the next stream in such a case. Note: DefaultMediaClock.shouldUseStandaloneClock has roughly the same logic and also doesn't require the next stream to be present. Also fix a test that seemed to rely on this stuck buffering case to test stuck buffering detection. Changed the test to not read the end of stream to ensure it runs into the desired stuck buffering case. Issue:#7943 PiperOrigin-RevId: 333050285
tonihei committed -
PiperOrigin-RevId: 333031399
ibaker committed -
https://github.com/google/ExoPlayer/commit/f2c51560c21bdd757c30678223345fa8f59fb82b
PiperOrigin-RevId: 333031301
tonihei committed -
PiperOrigin-RevId: 333029935
tonihei committed -
PiperOrigin-RevId: 333023580
olly committed -
We're not using regex so there's no need to use replaceAll() PiperOrigin-RevId: 332865724
ibaker committed -
Without this patch, playback would be frozen indefinitely until the user manually pauses and unpauses it. This has the side effect of disabling offload until the next stop due to the workaround of disabling offload when it encounters a failure. As an audio server crash is considered very infrequent, especially in stable conditions like an audio only playback, it is unlikely that disabling offload is an issue. PiperOrigin-RevId: 332857094
krocard committed -
PiperOrigin-RevId: 332814223
Oliver Woodman committed -
PiperOrigin-RevId: 332254072
kimvde committed -
I didn't copy-paste the whole of https://github.com/google/guava/wiki/UsingProGuardWithGuava because this line seems relevant based on our current usage. Lots of that file seems to relate to classes that are strongly discouraged on Android: https://github.com/google/guava/wiki/Android#specifics I've only added this to the `common` module, since everyone that uses ExoPlayer must depend on that. This avoids duplicating this line into every module that has a Guava dependency. Also remove some other warning suppressions that are defined in both `core` and `common`. Issue: #7904 PiperOrigin-RevId: 332203086
ibaker committed -
PiperOrigin-RevId: 332014290
olly committed -
Issue: #7866 PiperOrigin-RevId: 330736774
kimvde committed -
PiperOrigin-RevId: 331591005
olly committed
-
- 21 Sep, 2020 2 commits
- 16 Sep, 2020 8 commits
-
-
PiperOrigin-RevId: 332015471
olly committed -
PiperOrigin-RevId: 332012857
aquilescanta committed -
Since gradle 4.0, CMake imported libraries are bundled in the APK, so manually bundling them causes a duplication which breaks the build. Issue: #7906 PiperOrigin-RevId: 332012375
aquilescanta committed -
PiperOrigin-RevId: 331955966
christosts committed -
Issue: #7906 PiperOrigin-RevId: 331775990
olly committed -
Issue: #7902 PiperOrigin-RevId: 331771187
olly committed -
This test is intended to check that DefaultLoadControl will cause playback to fail as "stuck buffering" rather than OOM-ing, in the case that its target buffer size is reached and playback still hasn't started. Unfortunately, the target buffer size is ~130MB, and when running on some setups an OOM actually ends up happening before this much memory is allocated. This change makes the target buffer size much smaller to avoid the problem. PiperOrigin-RevId: 331748208
olly committed -
PiperOrigin-RevId: 331539036
christosts committed
-
- 12 Sep, 2020 5 commits
-
-
PiperOrigin-RevId: 331354102
olly committed -
r2.12.0
Oliver Woodman committed -
Oliver Woodman committed
-
Oliver Woodman committed
-
There's no option to enable them. This is probably a copy/paste error from DefaultHttpDataSourceFactory. PiperOrigin-RevId: 331334263
olly committed
-
- 11 Sep, 2020 11 commits
-
-
PiperOrigin-RevId: 331211708
bachinger committed -
PiperOrigin-RevId: 331162350
olly committed -
PiperOrigin-RevId: 331155539
bachinger committed -
Issue: #7889 PiperOrigin-RevId: 331149688
andrewlewis committed -
PiperOrigin-RevId: 331148067
olly committed -
Setting to 2x BATCH_SIZE_BYTES PiperOrigin-RevId: 331124129
olly committed -
Throwing Error forces a test to catch Throwable (e.g. DashWidevineOfflineTest#widevineOfflineReleasedV22), which will also catch AssertionError meaning the fail() call at the end of the try block won't work. The DashWidevineOfflineTest have been broken since https://github.com/google/ExoPlayer/commit/91185500a1242b99b86b18bc9f3449d3dac1fa01 PiperOrigin-RevId: 331120894
ibaker committed -
PiperOrigin-RevId: 331027732
olly committed -
PiperOrigin-RevId: 331025924
bachinger committed -
This may remove available memory from other tests running in the same process. Instead, create the huge buffer when needed so it can be GCed immediately. PiperOrigin-RevId: 330960844
tonihei committed -
Not releasing the player means the playback thread keeps running and also keeps its entire allocated playback buffer. PiperOrigin-RevId: 330958821
tonihei committed
-