Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 17 Aug, 2021 7 commits
  3. 13 Aug, 2021 2 commits
  5. 12 Aug, 2021 6 commits
  7. 11 Aug, 2021 10 commits
  9. 10 Aug, 2021 8 commits
  11. 09 Aug, 2021 7 commits
    • Move DeviceInfo into root package · 700ec939 
      PiperOrigin-RevId: 389681733
      olly committed
    • Deprecate final non-nested Factory classes in upstream · 7e8ba031 
      PiperOrigin-RevId: 389661768
      olly committed
    • Remove DeviceListener · e2ffb5e1 
      PiperOrigin-RevId: 389640670
      olly committed
    • Remove IntArrayQueue from public API · 5dc8eeb4 
      PiperOrigin-RevId: 389622428
      olly committed
    • Remove @DoNotInstrument from test classes · db1fe804 
      This isn't needed now we've updated to Robolectric 4.6

Follow-up to https://github.com/google/ExoPlayer/commit/0df0df9aeece386b7421afde160e9009457512ab

PiperOrigin-RevId: 389616471
      ibaker committed
    • Move `requiresSecureDecoder` logic into `ExoMediaDrm` · 849c3074 
      The result is plumbed back to `MediaCodecRenderer` via a new
`DrmSession#requiresSecureDecoder` method.

This allows us to use the `MediaDrm#requiresSecureDecoder` method added
in Android 12:
https://developer.android.com/reference/android/media/MediaDrm#requiresSecureDecoder(java.lang.String)

This change also removes
`FrameworkMediaCrypto#forceAllowInsecureDecoderComponents`, replacing it
with equivalent logic in `FrameworkMediaDrm#requiresSecureDecoder`.

PiperOrigin-RevId: 389616038
      ibaker committed
    • Add ability to disable Surface.setFrameRate calls · 0097a79c 
      Adding a CHANGE_FRAME_RATE_STRATEGY_ALWAYS strategy is
omitted from this commit, since adding it is more complicated
than just plumbing it through and leaving everything else
unchanged. Specifically, VideoFrameReleaseTimeHelper would
need updating to behave differently when such a strategy is
enabled. It currently calls setFrameRate in cases such as
pausing, seeking and re-buffering, on the assumption that
changes to the underlying display refresh rate will only be
made if they can be done seamlessly. For a mode in which
this will not be the case, it makes more sense to stick to
the content frame-rate when these events occur. It may also
make sense to only use explicit content frame-rate values,
and not those inferred from individual frame timestamps.
Finally, for adaptive content containing a mix of frame-rates,
it makes sense to use the maximal frame-rate across all
variants, and to avoid calling setFrameRate on switches from
one variant to another.

Applications that know the frame-rate of their content can
set ExoPlayer's strategy to CHANGE_FRAME_RATE_STRATEGY_OFF and
then use setFrameRate directly on the output surface. Note that
this is likely to be a better option for apps than anything we
could implement in ExoPlayer, because the application layer
most likely knows the frame-rate of the content earlier than
ExoPlayer does (e.g., to perform the disruptive mode switch
at the same time as an activity transition).

Adding CHANGE_FRAME_RATE_STRATEGY_ALWAYS will be deferred
until there's clear demand for it. In the meantime, we'll
recommend the alternative approach above.

PiperOrigin-RevId: 389610965
      olly committed