Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 16 Jul, 2021 8 commits
  3. 14 Jun, 2021 1 commit
  5. 11 Jun, 2021 1 commit
  7. 10 Jun, 2021 11 commits
  9. 07 Jun, 2021 2 commits
  11. 06 Jun, 2021 17 commits
    • Fix version number · 5c0bd14a
      olly committed
    • Fix texture transformation in gldemo · a83e4a7a 
      `SurfaceTexture` provides a transform matrix with each buffer. Previously
gldemo ignored this but it is important to apply it to have the video render
properly.

The transformation matrix from the surface texture includes flipping so this
change removes the hard-coded flipping from `a_texcoord`.

Issue: #8992

#minor-release

PiperOrigin-RevId: 377271389
      andrewlewis committed
    • Align README and helloworld documentation · 29bb552b 
      #minor-release

PiperOrigin-RevId: 377269770
      olly committed
    • Fallback to generate profile-level-id using H264 SPS if it's missing · 3cf28171 
      Related to: Issue: #9010

Profile-level-id (Format.codecs) can be generated from SPS if SDP does not
include it.

#minor-release

PiperOrigin-RevId: 377251211
      claincly committed
    • Allow RtspServer read a RTP dump file. · 027baa55 
      #minor-release

PiperOrigin-RevId: 377001305
      claincly committed
    • Keep secure MediaCodec instances when disabling the renderer · 2ab0e1dc 
      A renderer is disabled (without being reset) in two situations:
* When transitioning into a period that starts with a discontinuity
* When stopping the player with setForegroundMode(true)

Before this change the behaviour of `MediaCodecRenderer` when disabled
(but not reset) depended on whether the content being decoded had an
associated `DrmSession`:
* For content without an associated DRM session the MediaCodec instance
  was kept alive.
* For content with an associated DRM session, the MediaCodec instance
  was released. This was to prevent the DRM session from staying alive
  and continuing to make license refresh network requests while the
  player was stopped in 'foreground mode'.

This change removes the second bullet, and keeps MediaCodec instances
alive in both the secure and insecure case. This will result in the
DRM machinery making occasional license refresh network requests (at
a frequency defined by the license policy) while the player is stopped
and in 'foreground mode'. This network usage is considered to be a
'limited resource' as described by the `ExoPlayer#setForegroundMode`
javadoc.

This means that switches between secure content (or between secure and
clear content when `MediaItem.drmConfiguration.sessionForClearTypes`
indicates a secure decoder should be used for clear content) should
keep the same video decoder, thus avoiding the 'black flash' that occurs
on some devices when switching the surface away from a secure decoder.

Issue: #8842

#minor-release

PiperOrigin-RevId: 376825501
      ibaker committed
    • Ensure DefaultDrmSessions keep working if their manager is released · 037f24a0 
      This change introduces a third 'state' for `DefaultDrmSessionManager`:
It's been fully released (prepareCount == 0) but at least one of its
sessions is still active.

In this state new acquisitions are rejected (`(pre)acquireSession()`
calls will fail) but the machinery to support the existing sessions
(ExoMediaDrm and MediaDrmHandler) is kept until they're all released.

This change will allow us to remove the TODO in MediaCodecRenderer
that resolves Issue: #8842.

PiperOrigin-RevId: 376193952
      ibaker committed
    • Add a test for handling of DRM key refresh events · fd25d2f5 
      In a follow-up change I will add an additional test to ensure these
events continue to be correctly handled when DefaultDrmSessionManager
has prepareCount==0 but a non-null ExoMediaDrm instance.

PiperOrigin-RevId: 376190225
      ibaker committed
    • Fix incorrect re-use of non-secure DummySurface with secure decoder · 10e96c99 
      Issue: #8776
PiperOrigin-RevId: 376186877
      olly committed
    • Cleanup the MediaItem.Builder javadoc for 'conditional' setters · 5cec2a76 
      Many of the setters are ignored unless others are set - this change:
* Lists these conditions exhaustively.
* Uses more concise language to avoid overshadowing the main details
  of what the setter sets.
* Tweaks the language from 'is ignored' to 'shouldn't be called', to
  open up the future possibility of throwing an error if these are
  called without the 'required' setter also being present (see
  Issue: #8957).

#minor-release

PiperOrigin-RevId: 376162385
      ibaker committed
    • Fix docs on MediaItem.Builder#setDrmUuid · 6ec0044c 
      The docs on setLicenseUri say it's optional, and it has been since
https://github.com/google/ExoPlayer/commit/379cd8a04f0bf44a9422a08440223581b2657d74
(which should have changed this javadoc too)

#minor-release

PiperOrigin-RevId: 376139158
      ibaker committed
    • Support basic and digest authentication. · f2e476bd 
      Authentication sequence in RTSP:

- Server replies "Unauthorized" to our DESCRIBE request, and includes the
  necessary information (i.e. realm, digest nonce, etc) in WWW-Authenticate
  header

- After `RtspClient` receives the response, we

  - Parse the WWW-Authenticate header, stores the auth info. The info is saved
    for all further RTSP requests (that all need to carry authorization headers)
  - send the second DESCRIBE request with the Authorization header.

#minor-release

PiperOrigin-RevId: 376116302
      claincly committed
    • Fix StyledPlayerView detachment · 68eb7eb8 
      Issue: #8985
#minor-release
PiperOrigin-RevId: 375913914
      olly committed
    • Rename RtspMessageChannel.openSocket() to open(). · f49c1447 
      The method openSocket in RtspMessageChannel does not actually open a socket.
The 'open' term refers more to opening the message channel.

#minor-release

PiperOrigin-RevId: 375908999
      claincly committed
    • Remove the default RTSP message handling off playback thread. · b10f4363 
      The callbacks received RTSP messages and RTSP sending errors are now invoked
directly from RtspMessageChannel's internal threads. It's up to the handler
implementation to decide which thread to handle the messages.

#minor-release

PiperOrigin-RevId: 375908282
      claincly committed
    • Move RTP packet forwarding off playback thread. · 3e50a5a9 
      Previously, RTSP interleaved binary data is posted onto the playback thread
for handling, the playback thread then adds the received data to a queue.
A loader thread will later dequeue the data and process it.

In this CL, the binary data is sent through a separate listener, on
RtspMessageChannel's RTSP receiving thread.

#minor-release

PiperOrigin-RevId: 375907609
      claincly committed
    • Allow RtspHeaders to take multiple header values under the same name. · 088ad910 
      Some RTSP servers will offer multiple WWW-Authenticate options. We wanted to
be able to pick them up.

#minor-release

PiperOrigin-RevId: 375907276
      claincly committed