Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 14 Dec, 2021 5 commits
  3. 13 Dec, 2021 4 commits
  5. 10 Dec, 2021 17 commits
  7. 08 Dec, 2021 5 commits
    • Add a builder to `DefaultAudioSink` · 97206b9c 
      `DefaultAudioSink` already has 3 telescoping
constructors and an other one would be have been
needed to add a buffer size tuning option.

PiperOrigin-RevId: 414703366
      krocard committed
    • Fix how drop-to-keyframe events are recorded in `DecoderCounters` · 0f48dfc9 
      The existing code creates an imbalance between `inputBufferCount` and
`droppedBufferCount` by adding 'dropped source buffers' to
`droppedBufferCount` but not to `inputBufferCount`. This results in
assertion failures in `DashTestRunner`.

PiperOrigin-RevId: 414672175
      ibaker committed
    • Migrate usages of Timeline#getPeriodPosition to getPeriodPositionUs · 5c2f6186 
      #minor-release

PiperOrigin-RevId: 414671861
      ibaker committed
    • Retry creating a MediaCodec instance in MediaCodecRenderer · 07352a45 
      It's been observed that some devices fail when releasing a secure codec
attached to a surface and immediately trying to create a new codec
(secure or insecure) attached to the same surface. This change catches
all exceptions thrown during codec creation, sleeps for a short time,
and then retries the codec creation. This is observed to fix the problem
(we believe this is because it allows enough time for some background
part of the previous codec release operation to complete).

This change should have no effect on the control flow when codec
creation succeeds first time. It will introduce a slight delay when
creating the preferred codec fails (while we sleep and retry), which
will either delay propagating a permanent error or attempting to
initialize a fallback decoder. We can't avoid the extra delay to
instantiating the fallback decoder because we can't know whether we
expect the second attempt to create the preferred decoder to succeed or
fail. The benefit to always retrying the preferred decoder creation
(fixing playback failures) outweighs the unfortunate additional delay
to instantiating fallback decoders.

Issue: google/ExoPlayer#8696
#minor-release
PiperOrigin-RevId: 414671743
      ibaker committed
    • GL: Document ambiguous parameter names in comments. · fcdb96f0 
      Also, made a few other refactoring changes for clarity. No functional changes
intended.

PiperOrigin-RevId: 414487729
      huangdarwin committed
  9. 07 Dec, 2021 6 commits
  11. 06 Dec, 2021 3 commits
    • Fix condition for when to use the FrameEditor. · 18442b7f 
      outputHeight is the actual output height while
transformation.outputHeight could be Format.NO_VALUE
causing the FrameEditor to be used more often than
necessary in the old version.

PiperOrigin-RevId: 414304251
      hschlueter committed
    • Shorten log tags to 23 char limit · 4af06100 
      When calling Android's Log class directly, there's a LongLogTag
lint check that detects tags over the 23 char limit, however it
cannot detect long log tags in ExoPlayer due to the way that we
log via our own Log class. This commit adds @Size annotations to
enforce the same rule.

PiperOrigin-RevId: 413976364
      olly committed
    • Apply MTK E-AC3 workaround before API 24 · ee911015 
      On the Sony Android TV device where this was originally reproducible on Android L, on Android N there is an E-AC3 decoder listed which handles the stream correctly. The workaround is harmless anyway but adding the API version restriction means it will be obvious it can be removed once we bump our min API to 24 or above in the future.

#minor-release

PiperOrigin-RevId: 413967443
      andrewlewis committed