Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 28 Sep, 2021 1 commit
    • Check direct playback capabilities for automotive devices · 732fc3ef 
      For Automotive devices, surround encodings can be supported via
the passthrough path. Therefore, include automotive in the allowed
device types in the isDirectPlaybackSupported checks. The automotive
system feature is checked, rather then UI_MODE_TYPE_CAR, because
the UI_MODE_TYPE_CAR can be force enabled via
android.app.UiModeManager.enableCarMode(), whereas FEATURE_AUTOMOTIVE
cannot be forced.
      Dean Wheatley committed
  3. 23 Sep, 2021 12 commits
  5. 22 Sep, 2021 2 commits
  7. 21 Sep, 2021 7 commits
  9. 20 Sep, 2021 9 commits
  11. 17 Sep, 2021 9 commits
    • Make README structure match the desired androidx structure · 0f0e11aa 
      PiperOrigin-RevId: 397319051
      kimvde committed
    • Support RFC4566 SDP attribute. · fd6a6ec8 
      Issue: #9430

The current supported SDP (RFC2327) spec only allows for alpha-numeric
characters in the attribute-field. RFC4566 (section 9, token type) allowed
extra characters, and this CL adds the support.

PiperOrigin-RevId: 397301173
      claincly committed
    • Improve AdtsExtractor#sniff when trying different sync word offsets · 5f3953d3 
      The previous implementation did the following (after skipping any ID3
headers at the start of the stream):
1. Skip forward byte-by-byte looking for a sync word (0xFFF)
2. Assume this indicates the start of an ADTS frame and read the size
  a) If frameSize <= 6 immediately return false
3. Skip forward by frameSize and expect to find another ADTS sync word
   (with no further scanning).
   b) If we find one, great! Loop from step 2.
   a) If we don't find one then assume the **last** sync word we found
      wasn't actually one, so loop from step 1 starting one extra byte
      into the stream. This means we're looking for a sync word we would
      have skipped over in step 3.

The asymmetry here comes from the different handling of frameSize <= 6
(immediately return false) and frameSize being 'wrong because it doesn't
lead to another sync word' (scan the file again from the beginning for
alternative sync words).

With this change both these cases are handled symmetrically (always scan
for alternative sync words). Step 2a) becomes the same as 3b): Loop back
to the beginning of the stream with an incremented offset and scan for
another sync word.

#minor-release

PiperOrigin-RevId: 397285756
      ibaker committed
    • Fix documention for specifying a custom exolist.json · 8d01d66a 
      Issue: #9437
#minor-release
PiperOrigin-RevId: 397273931
      olly committed
    • Don't call `MediaItem.Builder#setKeySetId` without setting the DRM UUID · 04943db7 
      This is known to silently drop the value. This setter is now deprecated
in favour of `MediaItem.Builder#setDrmConfiguration(MediaItem.DrmConfiguration)`,
which requires a UUID in order to construct the `DrmConfiguration`
instance.

Issue: #9378 tracks correctly propagating the DRM info out of
`DownloadRequest#toMediaItem`.
PiperOrigin-RevId: 397291013
      ibaker committed
    • Use the new MediaItem.Builder#setDrmConfiguration method · 13827186 
      PiperOrigin-RevId: 397290953
      ibaker committed
    • Improve AdtsExtractor#sniff when trying different sync word offsets · 73aece63 
      The previous implementation did the following (after skipping any ID3
headers at the start of the stream):
1. Skip forward byte-by-byte looking for a sync word (0xFFF)
2. Assume this indicates the start of an ADTS frame and read the size
  a) If frameSize <= 6 immediately return false
3. Skip forward by frameSize and expect to find another ADTS sync word
   (with no further scanning).
   b) If we find one, great! Loop from step 2.
   a) If we don't find one then assume the **last** sync word we found
      wasn't actually one, so loop from step 1 starting one extra byte
      into the stream. This means we're looking for a sync word we would
      have skipped over in step 3.

The asymmetry here comes from the different handling of frameSize <= 6
(immediately return false) and frameSize being 'wrong because it doesn't
lead to another sync word' (scan the file again from the beginning for
alternative sync words).

With this change both these cases are handled symmetrically (always scan
for alternative sync words). Step 2a) becomes the same as 3b): Loop back
to the beginning of the stream with an incremented offset and scan for
another sync word.

#minor-release

PiperOrigin-RevId: 397285756
      ibaker committed
    • Remove obsolete imports · 6f728a43 
      PiperOrigin-RevId: 397280475
      bachinger committed
    • Fix documention for specifying a custom exolist.json · 985e73de 
      Issue: #9437
#minor-release
PiperOrigin-RevId: 397273931
      olly committed