Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 30 Mar, 2020 1 commit
  3. 18 Feb, 2020 6 commits
  5. 13 Feb, 2020 7 commits
  7. 03 Feb, 2020 2 commits
  9. 01 Feb, 2020 6 commits
  11. 27 Jan, 2020 6 commits
  13. 17 Jan, 2020 12 commits
    • Release notes: Move download segment merging out of 2.11.2 · ce1ec1d5 
      PiperOrigin-RevId: 290276507
      olly committed
    • Tidy up DownloadService restart. Final change for #6798. · b137cfbd 
      - Add additional Listener methods to DownloadManager, to inform of
  changes to whether the downloads are paused or waiting for requirements.

- Only schedule the Scheduler if we really are waiting for requirements.

- Only restart the service if we're no longer waiting for requirements,
  and if there are queued downloads that will now be restarted.
  Previously the service would be restarted whenever the requirements
  were met, regardless of whether there was any work to do.

- Restart service if it might be stopping, as well as if it's already
  stopped. Also restart service if there's a download state change to a
  state for which the service should be started, if.

Issue: #6798
PiperOrigin-RevId: 290270547
      olly committed
    • 2.11.2 release notes and version bump · 0a2373c3 
      PiperOrigin-RevId: 290269098
      olly committed
    • Do not hold a codec in OnFrameRenderedListener · 49349f0f 
      Doing so prevent Codec which is a big object with
JNI to be garbage collected.

As the codec can not be hold in the listener, there
is no way to call release, as it must be called on
the same codec.
As a result the release method is also removed.
The downside is that at runtime some callbacks may be
dropped but it should be a short transitive state.

This also simplifies lifecycle of the listener as
the client does not have to know if release needs
to be called or not.

An alternative would have been to hold a weak ref,
but I deemed it too complicated for the
runtime gain.

PiperOrigin-RevId: 290231659
      krocard committed
    • Fix build · ea471163
      Oliver Woodman committed
    • HLS: Fix slow seeking into long MP3 segments · f146bad4 
      Issue: #6155
PiperOrigin-RevId: 290117324
      olly committed
    • FlacExtractor: handle case where last frame < MAX_FRAME_HEADER_SIZE · 0456b638 
      PiperOrigin-RevId: 290079840
      kimvde committed
    • Tunneling timestamp use Message instead of Runnable · e202560d 
      This avoids allocating a Runnable.

PiperOrigin-RevId: 290079660
      krocard committed
    • Start service in foreground if allowed · 0ac22d34 
      This fixes an issue where a DownloadService implementation
that allows foreground but doesn't provide a scheduler would
not be restarted in the case that it was still in memory but
classed as idle by the platform.

It also speeds up service restart in the case that a
scheduler is provided.

Issue: #6798
PiperOrigin-RevId: 290068960
      olly committed
    • Split SampleQueue.advanceTo for advance & seek use cases · f35cb8ae 
      This method has two use cases:

1. Seeking. Calls are immediately preceded by a call to rewind(), and
   the returned value isn't important unless it's ADVANCED_FAILED (i.e.
   the caller is only interested in success and failure).
2. Advancing. The return value is important unless it's ADVANCED_FAILED,
   in which case the caller wants to treat it as 0.

This change creates separate methods for each use case. The new seekTo
methods automatically rewind and return a boolean. The updated advanceTo
method returns 0 directly in cases where ADVANCED_FAILED was returned.
Arguments that were always hard-coded to true by callers have also been
removed.

This change is a step toward one possible solution for #6155. How we'll
solve that issue is still up for discussion, but this change seems like
one we should make regardless!

Issue: #6155
PiperOrigin-RevId: 290053743
      olly committed
    • Fix DownloadService resumption · dfa4d55f 
      - DownloadManagerHelper now passes all downloads to the
  DownloadService when the service is attached (and once
  the downloads are known). The service then starts the
  foreground notification updater if necessary. This fixes
  the ref'd issue.
- Don't call getScheduler() if the service is background
  only. This was already documented to be the case on the
  DownloadService constructor.
- If the service is started in the foreground on SDK level
  26 and higher, satisfy the condition to move the service
  to the foreground in onStartCommand rather than in stop().
  It's much more obviously correct, and should produce the
  same end result.

Issue: #6798
PiperOrigin-RevId: 290050024
      olly committed
    • Merge pull request #6603 from TiVo:fix-tunneling-stuck-release · c269ffe1 
      PiperOrigin-RevId: 290041295
      Oliver Woodman committed