- 19 Feb, 2021 2 commits
- 12 Feb, 2021 12 commits
-
-
#minor-release PiperOrigin-RevId: 357273184
olly committed -
PiperOrigin-RevId: 357219132
olly committed -
The previous logic was changed under the assumption that the first box inside a meta box was not always an hdlr box, but this is not true. #minor-release PiperOrigin-RevId: 357200713
kimvde committed -
PiperOrigin-RevId: 357190780
christosts committed -
#minor-release PiperOrigin-RevId: 357160215
kimvde committed -
PiperOrigin-RevId: 357158075
kimvde committed -
This behavior is consistent with DefaultControlDispatcher#dispatchNext(). #minor-release PiperOrigin-RevId: 357145076
kimvde committed -
It's closely tied to SimpleExoPlayer, so cannot be part of a UI module that depends only on common. PiperOrigin-RevId: 357085802
olly committed -
The available end time was accidentally substracted by the start time of the last period. To avoid similar time reference confusion in the future, also renaming many variables and methods to clearly reflect the time reference point. And to avoid constant conversion, the processManifest method also attempts to converge to time relative to the start of the window as quickly as possible. Issue: #8537 PiperOrigin-RevId: 357001624
tonihei committed -
If keepalive is disabled the existing code over-eagerly releases DrmSession instances. This is arguably OK since a (Default)DrmSession should be released before its (Default)Manager is released (since the underlying MediaDrm instance might be released when the manager is released). And if all sessions are released before the manager is released then `sessions` is empty, so the loop is a no-op. Issue: #8576 #minor-release PiperOrigin-RevId: 356955308
ibaker committed -
The `DrmConfiguration.sessionForClearTypes` property is often used to ensure a secure decoder is used for clear ads played in encrypted content. This is because some devices show black frames when switching decoders. Before this change the DRM config isn't propagated down when constructing the ad media source, meaning `DrmSessionManager.DRM_UNSUPPORTED` is always used, which will cause playback to switch from secure to clear decoder when transitioning to an ad break (ignoring the MediaItem `sessionForClearTypes` option. Issue: #8568 #minor-release PiperOrigin-RevId: 356951124
ibaker committed -
Also move out of the mediacodec package into the util package. PiperOrigin-RevId: 356949401
aquilescanta committed
-
- 11 Feb, 2021 7 commits
-
-
Issue: #4803 #minor-release PiperOrigin-RevId: 356923345
andrewlewis committed -
It's used by the UI and mediasession modules. We may be able to move it into the UI module if/when the mediasession module goes away. PiperOrigin-RevId: 356734939
olly committed -
PiperOrigin-RevId: 356695284
christosts committed -
Issue: #8565 #minor-release PiperOrigin-RevId: 356691251
andrewlewis committed -
Without this a new manager is instantiated for every item in a playlist, meaning the impact of caching improvements to DefaultDrmSessionManager are reduced (since the cache doesn't persist across playlist items). With this change, playlists of items with identical DRM config will use the same manager instance (and thus share existing sessions). Issue: #8523 #minor-release PiperOrigin-RevId: 356690852
ibaker committed -
PiperOrigin-RevId: 356622155
gyumin committed -
All threads created by ExoPlayer should now have the prefix "ExoPlayer:". PiperOrigin-RevId: 356518037
andrewlewis committed
-
- 09 Feb, 2021 14 commits
-
-
PiperOrigin-RevId: 356479682
olly committed -
PiperOrigin-RevId: 356474350
olly committed -
This parameterized test execute a single playback with a variety of specified network conditions, user country and network types, and then compares some basic ABR performance data against a dump file to detect changes. PiperOrigin-RevId: 356468304
tonihei committed -
ControlDispatcher and DefaultControlDispatcher also need to move to common for the UI module. As does PlaybackPreparer, although that will be removed entirely in a future release. PiperOrigin-RevId: 356467394
olly committed -
PiperOrigin-RevId: 356456843
olly committed -
Also allow the player's prepared ad media period durations array to exceed the length of the loaded ad URIs array, as it's possible for the player to buffer an ad media period fully at the point where it's known that an ad is coming up but its URI is still unknown. #minor-release PiperOrigin-RevId: 356249284
andrewlewis committed -
This may happen for HLS live streams without program date time information. Issue: #8560 #minor-release PiperOrigin-RevId: 356227729
tonihei committed -
#minor-release PiperOrigin-RevId: 356221487
kimvde committed -
PiperOrigin-RevId: 356157035
aquilescanta committed -
PiperOrigin-RevId: 355896218
olly committed -
We currently block the loading thread until the calculated load time has past and then unblock again by a message sent from the playback thread. However, because the loading thread itself is not using a Looper and runs freely, we don't control when the short calculations on the loader thread that determine how long we have to wait are happening, and we also don't control how long it takes to start and stop this thread. To solve these problems and to make the playback deterministic we can 1. Send a message on the playback thread to block until the loader thread has started. 2. Block the playback thread whenever a loading thread is doing its short calculation of wait times. The playback thread knows when it can continue because loading either enter a new waiting state for a simulated load time or loading is finished completely. 3. Also wait on the playback thread until the loader has shut down. As this is waiting for a message on the playback thread, we can achieve this by sending messages to ourselves at the current time until the loader is shut down. All 3 steps together ensure that the loading thread interaction is compeltely deterministic when simulating bandwidth profiles with the BandwidthProfileDataSource. As we need to notify the source before and after the load started/finished, we also need a small wrapper for the chunk source when running the playback. PiperOrigin-RevId: 355810408tonihei committed -
PiperOrigin-RevId: 355664280
olly committed -
PiperOrigin-RevId: 355659628
olly committed -
The current naming had cause confusinon in b/179369346 and #8545. PiperOrigin-RevId: 355656404
krocard committed
-
- 04 Feb, 2021 5 commits
-
-
#minor-release PiperOrigin-RevId: 355652144
kimvde committed -
- When throwing a recoverable error from a renderer, it's important to understand exactly how the player will attempt recovery. Clarify the documentation to make this explicit. - Rename some methods/constants to make it clear that error recovery is specific to renderer errors. The current recovery mechanism only makes sense for renderer errors. Making the naming renderer specific avoids reader doubt that the implementation doesn't appear to be generic enough for other types of errors. PiperOrigin-RevId: 355650945
olly committed -
PiperOrigin-RevId: 355621265
olly committed -
It's for classes to clearly denote they support bundling and it gives us a good place to document the best practice to implement fromBundle. PiperOrigin-RevId: 355609942
gyumin committed -
Before, the level was set to null in this case. MediaCodecUtil.getCodecProfileAndLevel() was therefore returning null and the fallback to AVC/HEVC was not enabled in MediaCodecVideoRenderer. Issue:#8530 #minor-release PiperOrigin-RevId: 355574499
kimvde committed
-