With the internal playlist some new situation may happen that were not possible before:
- handlePlaylistInfoRefreshed in EPII called in IDLE state
- handlePlaylistInfoRefreshed in EPII called in ENDED state with an empty playlist
- seeks in ENDED state with an empty playlist
PiperOrigin-RevId: 270316681
*** Original commit ***
Refactor HlsSampleStreamWrapper#track() to clarify the return paths
I found the original implementation quite hard to follow, and I believe this is functionally identical.
***
PiperOrigin-RevId: 270263186
This option allows to set the preferred text language and role flags based
on the user's accessiblity captioning settings.
Issue:#5749
PiperOrigin-RevId: 270233205
Allows streamlining the way we handle unsupported DRM. In general, either:
* The device does not support the CDM. For example, phones don't support
PlayReady.
* The device does not support the protection scheme. For example, API < 25
devices do not support AES-CBC.
Currently we handle both cases differently. A dummy ExoMediaDrm will allow
the existence of dummy DefaultDrmSessionManagers.
PiperOrigin-RevId: 269315687
Allows shared ownership of ExoMediaDrms. Shared ownership will
allow users to pre-create ExoMediaDrms in their apps, as opposed
to having the DrmSessionManager create the ExoMediaDrm.
Issue:#4721
PiperOrigin-RevId: 269305850
The playback speed set in MediaSession's PlaybackStateCompat needs to be the
actual speed at which the playback position progresses and not the user-defined
target speed.
This fixed a bug where the position advances although the player lost audio
focus.
Issue:#6203
PiperOrigin-RevId: 269295249
The player may suppress playback when waiting for audio focus even if the
state==Player.READY. There is currently no getter or callback to obtain this
piece of information for UI updates or analytics.
Also, it's a important derived state to know whether the playback position is
advancing. Add isPlaying and the corresponding callback to allow retrieving
this information more easily.
Issue:#6203
PiperOrigin-RevId: 268921721
We currently force render the first frame in all cases. However, when joining
video to an ongoing playback, there is no defined first frame and we should
rather drop frames if we are late until we caught up with the audio playback.
PiperOrigin-RevId: 268698093
When the queue is empty, we may still get multiple requests for a window
sequence number using the same periodUid. We should keep the initially
assigned number because no window change happened.
PiperOrigin-RevId: 268649009
The fLaC prefix is included in the initialization data output
from the MKV extractor, so this is highly likely ot be the
right thing to do.
Issue: #6397
PiperOrigin-RevId: 268244365
