- 23 Sep, 2021 4 commits
-
-
These give some documentation-as-code for a clearkey integration with ExoPlayer. #exofixit PiperOrigin-RevId: 398017708
ibaker committed -
The MIME type is currently required to select a SubtitleDecoder implementation in the TextRenderer. Future changes might remove this requirement, so we pre-emptively mark the field as @Nullable. The change in SingleSampleMediaSource ensures the track still maps to the TextRenderer, otherwise it shows up as unmapped. Passing null MIME type to MediaItem.Subtitle constructor now results in this from EventLogger: TextRenderer [ Group:0, adaptive_supported=N/A [ [ ] Track:0, id=null, mimeType=text/x-unknown, language=en, supported=NO_UNSUPPORTED_TYPE ] ] PiperOrigin-RevId: 398010809ibaker committed -
Both license and provisioning requests could be considered 'DRM requests', and these headers are only sent on license requests, so rename them to reflect that. The old field remains deprecated for backwards compatibility. PiperOrigin-RevId: 397980021
ibaker committed -
This change only calls setters if we need to override the existing value (or more specifically, set a value that's absent). PiperOrigin-RevId: 397979904
ibaker committed
-
- 22 Sep, 2021 2 commits
-
-
Christos Tsilopoulos committed
-
r2.15.1
christosts committed
-
- 21 Sep, 2021 7 commits
-
-
#minor-release PiperOrigin-RevId: 397976212
christosts committed -
#minor-release PiperOrigin-RevId: 397976212
christosts committed -
The type is already UUID so there's no need to duplicate that info in the field name, and 'scheme' is a widely used term throughout both ExoPlayer and android.os.MediaDrm documentation. The old field remains deprecated for backwards compatibility. The MediaItem.DrmConfiguration.Builder#setUuid method is renamed directly (without deprecation) because it's not yet part of a released ExoPlayer version. PiperOrigin-RevId: 397961553
ibaker committed -
This takes advantage of the new MediaItem.LiveConfiguration.Builder This change will always allocate a new LiveConfiguration.Builder and LiveConfiguration, but preserves the behaviour of keeping the same MediaItem instance if no values have changed. PiperOrigin-RevId: 397961427
ibaker committed -
This isn't needed since the whole library's min API is already 16 PiperOrigin-RevId: 397939444
ibaker committed -
PiperOrigin-RevId: 397772916
ibaker committed -
PiperOrigin-RevId: 397758146
christosts committed
-
- 20 Sep, 2021 9 commits
-
-
#minor-release PiperOrigin-RevId: 397758146
christosts committed -
PiperOrigin-RevId: 397753634
andrewlewis committed -
PiperOrigin-RevId: 397748657
ibaker committed -
PiperOrigin-RevId: 397718885
ibaker committed -
Issue: #9429 #minor-release PiperOrigin-RevId: 397717740
kimvde committed -
PiperOrigin-RevId: 397717018
andrewlewis committed -
PiperOrigin-RevId: 397707790
tonihei committed -
PiperOrigin-RevId: 397697019
ibaker committed -
These fields can't be used if `drm_uuid` isn't set. Make that case throw an exception, so it's obvious to a developer what's wrong. Most of the fields 'obviously' need `drm_uuid` to be set, but it's not obvious for `drm_session_for_clear_content` (because it might be reasonable to assume it's possible to play clear content without specifying a UUID). This tripped me up in https://github.com/google/ExoPlayer/issues/8842#issuecomment-833659808. PiperOrigin-RevId: 397328556
ibaker committed
-
- 17 Sep, 2021 12 commits
-
-
PiperOrigin-RevId: 397319051
kimvde committed -
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 -
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: 397285756ibaker committed -
Issue: #9437 #minor-release PiperOrigin-RevId: 397273931
olly committed -
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 -
PiperOrigin-RevId: 397290953
ibaker committed -
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: 397285756ibaker committed -
PiperOrigin-RevId: 397280475
bachinger committed -
Issue: #9437 #minor-release PiperOrigin-RevId: 397273931
olly committed -
The deprecated `Player.addListener(EventListener)` is moved out of Player into its subclasses (CastPlayer and ExoPlayer). This is unlikely to break users because: - the method has been deprecated in the last major version - the method is still present in the major implementations If an users is affected, they can either: - use ExoPlayer instead of Player - (recommended) switch to Player.Listener. Additionally update the threading guarantees that did not reflect the current implementation. PiperOrigin-RevId: 397272144
krocard committed -
This will allow to disable video/audio... through the player interface. PiperOrigin-RevId: 397183548
krocard committed -
* Avoid ActivityManager log spam by only calling startForeground once, and subsequently updating the notification via NotificationManager. * Tweak demo app service to make it a tiny bit easier to swap the Scheduler. PiperOrigin-RevId: 397179398
olly committed
-
- 16 Sep, 2021 6 commits
-
-
The second getScheduler() call violates the documentation of the class, which states that getScheduler() is not called if foregroundNotificationId if FOREGROUND_NOTIFICATION_ID_NONE. Presumably implementing subclasses would return null, in which case this didn't do any harm, but we should make sure the implementation behaves as documented regardless. PiperOrigin-RevId: 397167603
olly committed -
#minor-release PiperOrigin-RevId: 397164973
christosts committed -
PiperOrigin-RevId: 397156268
bachinger committed -
PiperOrigin-RevId: 397141742
bachinger committed -
PiperOrigin-RevId: 397138908
olly committed -
Issue: #9428 PiperOrigin-RevId: 397064086
claincly committed
-