If IMA loads an empty VAST document for an ad group it notifies via a LOG
AdEvent. Handle the event by updating the AdPlaybackState accordingly.
The error state will be handled in ExoPlayerImplInternal in a separate change.
Issue: #3584
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184516585
Try to delay failure for as long as possible. That is, propagate
DRM session failures only after an encrypted buffer arrives or clear
sample playback without session is not allowed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183076348
Track the expected next ad group index so that it can be used as a fallback if
IMA does not notify the ad index via a LOADED event.
Also do some miscellaneous minor cleanup (including logging all LOG events, and
logging at debug level where appropriate).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183048612
Also disable use of dummy surface for devices that require the
workaround. It's only useful in the case that we can use
setOutputSurfaceWorkaround, so if it's disabled the dummy surface
has no purpose (it actually makes things worse by consuming past
the key-frame prior to the current position, which doesn't happen
if you have no surface at all).
Issue: #3724
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182750068
- In IDLE, the button will now call a preparer. This allows
removal of the separate retry button from the demo app.
- In ENDED, the button will seek back to the default position
and play.
- Behavior is made consistent with LeanbackPlayerAdapter.
Issue: #3689
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182506855
It seems good to have EventLogger available from the library.
In particular because when app developers use it and then
submit bug reports, it makes it much easier to work out what
happened. It will also allow EventLogger to be used across
our (now multiple) demo apps.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182389407
For live streaming, there are several types of DASH `emsg' events that directly
target the player. These events can signal whether the manifest is expired, or
the live streaming has ended, and should be handle directly within the player.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182034591
This it to distinguish between actual period transitions and the
transitions occuring to and from ads within one timeline period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181606023
----------------------------------
Original change description:
DRM fixes
- Parse multiple kids from default_KID. It's specified as a whitespace
separated list of UUIDs rather than a single UUID.
- Opportunistically proceed with playback in cases where the manifest
only defines a single SchemeData with the common PSSH UUID. In such
cases the manifest isn't saying anything about which specific DRM
schemes it supports.
Issue: #3630
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181137621
If SimpleExoPlayer is using TextView as output, we can handle video rotation by
automatically applying a matrix transformation to the TextureView when we have
this information available from the video (from video's metadata).
GitHub: #91
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180925571
In certain conditions CacheDataSource switch to reading from upstream
without writing back to cache. This change makes it detect the change of
these conditions and switch to reading from or writing to cache.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180901463
- Parse multiple kids from default_KID. It's specified as a whitespace
separated list of UUIDs rather than a single UUID.
- Opportunistically proceed with playback in cases where the manifest
only defines a single SchemeData with the common PSSH UUID. In such
cases the manifest isn't saying anything about which specific DRM
schemes it supports.
Issue: #3630
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180675056
Whilst the previous behavior was WAI and had the advantage of
updating the position to be more exact when known, there were
a couple of disadvantages:
1. If seeking to the very end of a period in a playlist when
paused, the position adjustment could trigger a position
discontinuity to the next period.
2. We de-duplicate seeks to the current playback position.
The position adjustment can prevent this from being
effective. This is particularly important with the new
SeekParameters support. When seeking to nearest sync point
it's often possible to de-duplicate seeks, but we cannot
do so if the playback position adjusts away from the sync
point's time.
Issue: #2439
Issue: #2882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180540736
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also attempts to update these
when the source info is refreshed. A sorted list of pending posts is kept and the
player triggers these posts when the playback position moves over the specified
position.
Issue:#2189
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179683841
*** Original change description ***
Add possiblity to send messages at playback position.
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also at...
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179666357
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also attempts to update these
when the source info is refreshed. A sorted list of pending posts is kept and the
player triggers these posts when the playback position moves over the specified
position.
Issue:#2189
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179563355
This adds a parameter to configure a maximum buffer size in bytes. If left
at its default of C.LENGTH_UNSET, the target buffer is determined using a
overridable method based on the track selection. Also adding a parameter
to decide whether to prioritize time or size constraints.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179048554
Also fix ClippingMediaSource to consider the start position an
artificial key-frame, and to properly offset the value returned
by getAdjustedSeekPositionUs.
Issue: #2882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179032243
Also fix propagation of ad errors that occur when no player
is attached.
Issue: #3548
Issue: #3556
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178767997
If allowed, the media period will try to finish preparation without downloading
chunks (similar to what DashMediaPeriod does). To create track groups,
HlsMediaPeriod will try to obtain as much information as possible from the
master playlist. If any vital information is missing for specific urls,
traditional preparation will take place instead.
This version does not support tracks with DrmInitData info. This affects tracks
with CDM DRM (e.g: Widevine, Clearkey, etc). AES_128 encryption is not affected.
This information needs to be obtained from media playlists, and this version
only takes the master playlist into account for preparation.
Issue:#3149
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178098759
In some occasions, we may want to discard a part of the buffered media to
improve playback quality. This CL adds this functionality by allowing the
loading media period to re-evaluate its buffer periodically (every 2s) and discard
chunks as it needs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177958910
