Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 26 Jun, 2020 13 commits
  3. 23 Jun, 2020 20 commits
  5. 17 Jun, 2020 7 commits
    • Bump version to 2.11.6 · 92fd3bc2 
      PiperOrigin-RevId: 316949571
      olly committed
    • Rollback of https://github.com/google/ExoPlayer/commit/b6f5a263f725089c026bb8416ade555f4f16a2bc · ffa4ad0e 
      *** 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
    • Remove unused previousExtractor from HlsExtractorFactory · a5bc91f0 
      PiperOrigin-RevId: 316902430
      aquilescanta committed
    • Remove overloaded set method · 733e71b4 
      PiperOrigin-RevId: 316900193
      bachinger committed
    • Rollforward of commit 5612ac50. · b6f5a263 
      *** 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
    • Workaround unexpected discard of preloaded ad · ed0778d0 
      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
    • Remove some ad playback state change requirements · 2546be51 
      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