Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 24 Jan, 2020 20 commits
  3. 17 Jan, 2020 7 commits
  5. 16 Jan, 2020 13 commits
    • HLS: Fix slow seeking into long MP3 segments · 2859a340 
      Issue: #6155
PiperOrigin-RevId: 290117324
      olly committed
    • FlacExtractor: handle case where last frame < MAX_FRAME_HEADER_SIZE · db750125 
      PiperOrigin-RevId: 290079840
      kimvde committed
    • Tunneling timestamp use Message instead of Runnable · a99ab622 
      This avoids allocating a Runnable.

PiperOrigin-RevId: 290079660
      krocard committed
    • Start service in foreground if allowed · cb8391a5 
      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 · 775a17c4 
      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 · 51f2723b 
      - 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 · 1ec05199 
      PiperOrigin-RevId: 290041295
      Oliver Woodman committed
    • Reorder renderer changes at period transitions · 2e7978a0 
      Currently the following sequence of events happens at automatic period transitions:
1. Update queue (=release old playing period)
2. Disable unused renderers
3. Enable newly needed renderers

This order requires difficult to follow workarounds in AnalyticsCollector for all
events related to step 2 (disable renderers). The current media period has already
been advanced so can't be used. The current workaround saves the last known playing
media period that was published as part of a PlaybackInfo update in ExoPlayerImpl.
This works in most cases, but is inherently wrong because the published state in
ExoPlayerImpl may be completely unrelated to the updates happening on the playback
thread (e.g. if many other operations are pending).

Simplify and fix this problem by changing the order of the events above:
1. Disable unused renderers.
2. Update queue
3. Enable newly needed renderers.
This way the current playing media period can be used for both renderer disable
and renderer enable events, thus it's correct in all cases and the workaround
in AnalyticsCollector can be removed.

PiperOrigin-RevId: 290037225
      tonihei committed
    • Fix setting maskingPeriodIndex in ExoPlayerImpl · 8d2fd383 
      Whenever we set the maskingWindowIndex, we also need to set the masking period index
and the masking position. Otherwise it may cause exception when the period index
is used together with the masking timeline.

PiperOrigin-RevId: 290036973
      tonihei committed
    • Merge pull request #6678 from phhusson:feature/enable-multi-metadata-tracks · 17d13433 
      PiperOrigin-RevId: 290032841
      Oliver Woodman committed
    • Fix demo app NPE when selecting unsupported samples. · cf7b908e 
      PiperOrigin-RevId: 290027772
      tonihei committed
    • Add non-null by default to source.chunk · 090aed3a 
      PiperOrigin-RevId: 289859343
      olly committed
    • DASH: Output Format before InitializationChunk load completes · 4a5d788f 
      This optimization allows a ChunkSampleStream to output track
formats as soon as they're parsed during an InitializationChunk
load, rather than waiting until after the InitializationChunk
load is completed.

In DASH VOD, a single InitializationChunk typically loads the
moov and sidx atoms in that order. Hence for long form content
where the sidx is a non-trivial size, this may result in the
track formats being output a non-negligible period of time
sooner than was previously the case. This allows downstream
renderers to start codec initialization sooner, potentially
decreasing startup latency.

For a single test stream on a fast & stable network, this
pretty consistently reduced elapsed time until both audio and
video codecs have been initialized from ~0.5s to ~0.3 seconds
on a Galaxy S8. For 5 test runs without and with these patches,
the eventTime logged by EventLogger for the second decoder
init were:

Without (secs): 0.47 0.47 0.45 0.48 0.46
With (secs)   : 0.32 0.33 0.34 0.31 0.40

PiperOrigin-RevId: 289845089
      olly committed