Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 30 Nov, 2020 2 commits
  3. 23 Nov, 2020 15 commits
    • Fix ProgressiveDownloader retry logic · 3a8524d0 
      RunnableFutureTask is not reusable. Trying to reuse it meant that a
failure in one doWork() call would cause subsequent download() calls
to (a) not block until the runnable has finished executing (does not
apply when using a direct executor), and (b) throw the same failure
as thrown from the first doWork() call.

This could cause #8078 if the initial failure occurred before the
content length was resolved. Retries are not blocked on their work
completing due to (a), and the download would be marked as failed due
to (b). The work itself could then resolve the content length, which
causes the stack trace in this issue.

Issue: #8078
PiperOrigin-RevId: 343498252
      olly committed
    • Re-download failed download in demo app · f39c40ab 
      The demo app has two states for downloads, as per DownloadTracker.isDownloaded.
It's either "downloaded or downloading" (isDownloaded returns true, and the UI
shows a blue tick) or it's "not downloaded or failed (isDownloaded returns
false, and the UI does not show a blue tick).

toggleDownload is out of sync in that it treates "failed" as belonging to the
first state rather than the second. This means tapping on the grey tick in the
UI in this case appears to be a no-op (tapping it again will make something
happen).

This change aligns things by making toggleDownload re-download in the case a
previous download failed. In the future we could consider having three states,
so failed downloads could be disambiguated properly. Unclear whether it's a
good complexity/benefit trade-off for the demo app though!

#minor-release

PiperOrigin-RevId: 343464364
      olly committed
    • Fix bug in SampleQueue.discardTo for duplicate timestamps. · 10164d74 
      When a stream has duplicate timestamps we currently discard to
the last sample with the specified discardTo timestamp, but
it should be the first one to adhere to the method doc and the
intended usage.

#minor-release

PiperOrigin-RevId: 343458870
      tonihei committed
    • Allow to remove all playlist items · 6edf52b2 
      PiperOrigin-RevId: 343437513
      sungsoo committed
    • Refactor ComponentListener of PlayerWrapper · 3f2eb9d7 
      PiperOrigin-RevId: 343432873
      sungsoo committed
    • Minimal fix for playback freezes when enabling tracks #8203 · 305ec3b4 
      Background:

1. When the player has multiple audio renderers, by default they share a
   single AudioSink.
2. When any new renderer is enabled, all disabled renderers are reset
   prior to the new renderer being enabled. This is to give them a chance
   to free up resources in case the renderer being enabled needs them. These
   reset calls are expected to be no-ops for renderers that have never been
   enabled.

The issue:

The problematic case arises when there are two audio renderers and a third
renderer (e.g., text) is being enabled. In this case, the disabled audio
renderer's reset call ends up resetting the AudioSink that's shared with the
enabled audio renderer. The enabled audio renderer is then unable to make
progress, causing playback to freeze.

This is a minimal fix that directly prevents the mentioned issue. There are
multiple follow-ups that would probably make sense:

1. Having ExoPlayerImplInternal track which renderers need to be reset, and
   only resetting those renderers rather than all that are disabled. This
   seems like a good thing to do regardless, rather than relying on those
   calls being no-ops.
2. If we want to continue sharing AudioSink, we need to formalize this much
   better and make sure we have good test coverage. Messages like
   MSG_SET_VOLUME are also delivered to the AudioSink multiple times via
   each of the renderers, which works currently because DefaultAudioSink
   no-ops all but the first call in each case. This is pretty fragile though!

Issue: #8203
PiperOrigin-RevId: 343296081
      olly committed
    • Finish PlayerActivity if cleartext not permitted · 4a26a59f 
      This is inline with other show-toast-on-error cases in this method, and avoids
leaving the user on a completely black screen.

Note that the maybeRequestReadExternalStoragePermission is an exception because
it's not actually an error case.

#minor-release

PiperOrigin-RevId: 343264869
      olly committed
    • Fix fastforward and rewind color tinting and text alignment · 3509f507 
      Issue: #7898
PiperOrigin-RevId: 343251455
      olly committed
    • Fix HLS format derivation in traditional preparation · 78d65818 
      ExoPlayer's traditional HLS preparation works by loading a chunk from each track
group, and then tries to use the sample information plus the master playlist
information to generate the preparation's resulting TrackGroups.

There are 3 possible scenarios:
- Supported case: Each variant has a single codec string per track type. We can
  assign each track the codec string which matches the loaded sample's type.
- Supported case: Each variant has more than one codec string, but each track
  group has a single track. This is the case when different languages use
  different codecs. In this case, we can assign whichever codec matches the
  loaded sample's mime type.
- Unsupported case: Each variant has more than one codec string, and track
  groups contain more than one track. We are not able to safely map tracks to
  codec strings because that would require loading a chunk from each track
  (which would considerably delay preparation).

Broken in:
https://github.com/google/ExoPlayer/commit/4783c329cc545da4269a9401a4975a41e75f2f43

PiperOrigin-RevId: 343072201
      aquilescanta committed
    • Update Styled Player settings dialogs to respect RTL. · bb8a2de3 
      PiperOrigin-RevId: 342672124
      olly committed
    • Fix CronetDataSource handling of 200 response for range request · 1f498677 
      Issue: #8090
#minor-release
PiperOrigin-RevId: 342638922
      olly committed
    • Discard buffer synchronously after seek before cancelling a load. · 5698eadc 
      This ensures the buffer is not full when the `DefaultLoadControl` determines
whether we should continue loading and thus prevents a false warning about
not having enough memory left.

PiperOrigin-RevId: 342616623
      tonihei committed
    • Increase touch target height of timebar in StyledPlayerControlView · 82969c82 
      This change also introduces gravity attribute to DefaultTimeBar.

PiperOrigin-RevId: 342573167
      insun committed
    • Fix 2.12.1 release note · bf131ec0 
      PiperOrigin-RevId: 342512836
      olly committed
    • Pass drm_key_request_properties in offline DRM downloads · d5f5d311 
      Pass the drm_key_request_properties specified in the json list
when donwloading thee offline Widevide license in the demo app.

PiperOrigin-RevId: 342243441
      christosts committed
  5. 19 Nov, 2020 9 commits
  7. 18 Nov, 2020 13 commits
  9. 23 Oct, 2020 1 commit